Xerra's Blog

Drunken coder ramblings

2 more days —

Not going to write too much here as I am literally at the final crunch now with Envahi. It’s early Sunday morning and the game needs to be completed, hosted somewhere and will need final builds for both Mac and PC.

Spent a lot of time over the last week strictly whittling down the list of stuff to do as well as pushing through the stuff that I decided absolutely had to go into the game. Stuff that has been sacrificed includes a day/night mode, high score table, a few presentation aspects and the use of the other music track. I was worried it might come back and haunt me as I had nobody to get approval for using the track.

What has gone in though is as follows. I’ve long-since stopped adding anything new to the list of stuff that goes into the game.

Dam breaking and flooding city has been done.

All the graphic work has been done. The last part of this was putting in the game over and new life animations which were time consuming but I needed to have the transitions in the game to break it up a bit.

Music system has been put in for in-game and a set of retro loops (8 seconds each one) have been purchased and implemented randomly. Gameplay uses 8 of them or so and certain ones kick in at different events such as being grabbed, game over, new life and so on.

Sound effects have been put in. These don’t make your ears bleed – unlike the original Boulderdash effects according to Aaron 🙂

All the city backgrounds are in and working. I don’t have them as a level increase system yet but that’s still on the list to push through.

All sorts of other stuff to replace the temporary code like all the text messages that were there for key game events. I’ve still got some tidying up to do with all this but I’m mostly done now.

Strobing effects for key information sentences work finally. Harder than it sounds to get that right.

So, what’s still to get done?

I won’t bore you with a bugs list so it’s mainly just the balancing now and a couple of minor bugs to fix. I also have a bug with the splash screen that’s driving me nuts but I’ll code round that if I have to just to get the game done.

2 days to go. Crosses fingers.

 


Deadline day approaches —

Didn’t realise that it’s been over 3 weeks since the last update on the blog. Luckily the game hasn’t been neglected as well. As the title says, deadline day is fast approaching now for Envahi to be completed and submitted for the competition. Will it be complete by then? I think so. Will it have everything I want it to have in it? Absolutely not. I’ve already been hacking my notes and marking out the parts that must go in and deciding bits that I’m not going to try and put in now as it will take too long – especially as I’ll need to fix any bugs afterwards.

I’m not using any kind of engine or framework for this game apart from a few simple routines that I nicked from Boulderdash, so I’ve done a lot of experimenting to get things working. Most of it has gone well and I’m definitely more setup for whatever I go to work on next, after finishing Boulderdash. But I’m always going to think there could be more in this game – fortunately just polish and stuff like high score table. The game play elements from the original all made the cut and are already present, apart from the dam actually flooding the city. Still need to get that bit done.

Just after my last entry I ended up firing the girl I’d chosen to draw replacement sprites for the game as mine were dreadful. She seemed keen at first but ultimately spent a week doing nothing apart from ignoring my messages or complaining that exams were taking all her time. I sympathised to an extent but she should never have bid and accepted the job if she couldn’t come through – especially as it’s easy work compared to most stuff that gets listed. Luckily the guy I hired to replace her came through very well and he even got some extra work doing a big helicopter for the title screen as well. That work is all done and in the game now and it does make a big difference.

I’ve also had Aaron testing some more and finding some nice bugs that I’d missed completely. I was mostly game complete by the last blog entry but I didn’t count the fact that I had unfinished graphics and no sound as yet. Now the graphics are done I’m solely concentrating on getting all the balancing stuff done. I’ve got to implement progressive level increases, use the city backgrounds I’ve got in the game, especially as I’ve done 2 new ones to replace unsuitables now, and also get the four game levels correct. At present easy is too easy and the other three levels too hard. I actually enjoy playing on suicide level because it’s so quick to play a game which is what I’m aiming for on all the skill levels. I don’t want a game on any level going on too long as it will get boring.

I’ve been tinkering with particles as well because I really want some kind of impact effect on shooting objects that don’t die like the big UFO. I’m hoping to get proficient enough with the editor to get something reasonable in for this during the next week. That with sound effects is going to boost the game appeal by another fifty percent easy, I reckon.

As mentioned earlier, the dam flooding effect still needs to go in. I was playing with an extension I purchased to simulate wave water flooding an open area using a tile effect but I think it’s too slow to be used for this game so I’ll be sticking to my animated tile approach. I also feel it would take too much hacking of code to implement the former as well and I don’t have much of that left now.

On a side note I googled an old game I wrote back in 1994 out of curiosity during the week and actually got a hit on it via YouTube along with another demo project that I’d been looking to turn into a full game. Back then I was 24 years old and just getting started with Amiga Amos so it was fascinating to track down both the old archives from Aminet CD’s to get the games again – even if I lost all the source code disks many years ago. One of the games – Pacman returns – even had a 3 month diary I wrote back then which documented my development of the game. It’s a mess of a document with some lines chopped and full of spelling mistakes but I’ve been attempting to put it all together again and tidy up the text, while preserving the original writing, so I can throw it onto the blog at some point. I’ve got more chance of not losing it for another 25 years then. No luck with the source code, however, as I never gave that away on the disks with the games when I submitted them to a PD library but I wouldn’t be able to probably view it anyway as Amos was a strange language that used it’s own format that doesn’t show in a text editor anyway. Not to mention that the code was terrible for the day. We had no internet, object programming or any kind of manuals to actually do things correctly in those days. It was all trial and error so I was actually quite surprised to see the game running on this guys YouTube video and finding the game was a lot better than I remembered it when I finally finished the thing.

More on that another day as distractions probably aren’t too helpful right now. I’ve got the current game to finish…

 


The final gameplay element —

A dramatic title for this entry but probably a bit of an over-statement. Over the weekend I put a lot of time into Envahi again after my temporary switch back to Boulderdash to start work on the object system. I’ve got that working up to a point where I could test the enemies and, whilst improved, they still need some more work and I’m on a deadline, so it’s back onto the shelf until this game is done.

So we start with bug fixes:

The dam collision had stopped working due to something I had done or forgotten. I suspect I pushed delete by accident while the object was highlighted or something similar and never noticed until now.

I had more animation issues due to adding bits like new enemies since last testing pause and transition game scenes that needed fixing.

Improvements:

The UFO now spawns droppers going left to right like the original game. It doubles its speed coming back so it can make another pass. I thought the other way made more sense when I first put the UFO in but it really doesn’t so this was a quick fix to correct.

HUD panel is just an outline for the moment. I wasn’t happy with the original so something else will need to be done with this when I reach the tidying up stage of the game.

Background graphics have been edited to remove their old sky backgrounds from the converted photo’s. I ditched one that had a watermark on it that I still had in the game from the original images that I’d forgotten about. 2 new ones have been added but I will probably need one more as I need to ditch the night view city as it looks daft on a blue sky background. Tempted to also ditch another image that isn’t one of these city photographs as it also looks a bit out of place. Either that or I’ll just stick with the five cities I have. At present I still don’t actually know how I’m going to use these images – as in some kind of level change system or just have a random one each game.

Much work has gone into building a balanced level system based on Easy, Novice, Hard, Suicide now. The game is pretty tough even on Novice because the original game was quite tough and I wanted to keep that. I have a scoring adjustment system based on what level you’re playing so scoring is always fair, and I don’t need to have different high score tables this way. My thinking is on increasing the level of difficulty as the game progresses. At present the speeds based on level selected don’t change during the game which may mean games last too long and become boring. It’s not exactly a game with a lot of content so it would be better to make it a game that’s just played to get your best score possible and not take half a day of game-play before you eventually lose all your lives if you’re really good at it. As it is on Novice I can comfortably play a good 15 minute game even with the shields getting a hammering from acid rain pretty much constantly.

Other changes included making the collisions between player and the dam/buildings affect the shields on both elements. These are almost constantly being drained unless you’re really quick on the danger of the acid clouds now so sometimes you will be using the helicopter to actually absorb large patches of rain because you have more shield energy than the city and need to make that sacrifice so you stay playing a bit longer. This works really well and has changed the game dynamic to mean the clouds are now really number one kill priority when playing rather than the Zoomer, as you’ve got more time to deal with that. It makes the game play a bit better than the original now, I think. Up to the testers to confirm if that’s actually the case but the clouds are a much bigger threat now than the original game. There it only appeared in one place and was more of a annoyance than anything else because it was so damn hard to hit it without getting killed by one drop of its rain. Not great game-play that bit.

I’ve also made the grabber work a bit better now, and meaner, just for the hell of it. Now he does drop his base and roof when you shoot him too. Gone back to the original graphic I designed for him too but it’s still pretty poor. More on the sprites a bit later.

The dam has now been modified to have a single line of tiles as the wall as I’ve got the broken tiles in so the Nibblers could start to break the dam. These were the last enemy to go into the game and took a bit of time to get right as I’m working with both objects and tiles for this part whereas the other objects have been just sprites I could throw around. Now that they work perfectly and I’ve made adjustments to where they can go so I’ve always got a chance to be able to destroy them no matter where the helicopter is – remember the helicopter only fires upwards – the game has all the game-play stuff in place. That doesn’t mean it’s finished, however.

This has now given me the opportunity to think of other stuff that does need to get done before I can consider the game finished and there’s still a huge amount of things to get done. I approached Envahi with the intention of getting all the game-play stuff done as quick as possible and then I could work on improving each part in a priority list afterwards. It was done this way so, if I got to a point where I ran out of time, then I would be able to draw a line under the project as it was already still a complete game, if rough around the edges.

I’ve got more work to do with the level structure to make sure that I can keep most people happy with how easy/hard it is to play. I’ve got two testers – three including my partner but she’s not much of a game player so will probably be more helpful telling me what looks OK and what’s terrible. The other two guys, one of whom is obviously Aaron, have played a few games in their time. I’m hoping that they give it enough time, even if initially it seems to difficult, to get good at it so I’ll get a much better idea on any more tuning I need to do.

I also have to stick in some kind of speed-up effect for every event once a grabber takes the player off the screen. At present I deliberately let the events go on where the player can wait for the city to be destroyed or invaded and is helpless because his helicopter got caught. Sometimes it takes too long so I need this in there as a kind of fast-forward on a VCR so players don’t get bored waiting this out.

One other thing to mention is the high score entry music where I’ve settled on an old tracker file of the Infodroid game music from the C64 as composed by Fred Gray. The tracker music was free to use so I’ve converted it with VLC into an MP3 and will use that as I’ve always liked the track.

The last part of my work today was creating a load of sprites and tiles so I could create the flooding of the city when the Dam breaks. This was the major theme of the original game so I want to get this right. The graphics work took a while but I’m happy that’s all done now so it’s the actual code part that I’ll be approaching next visit. When that parts in it’s another 5% towards game completion in my mind.

 


Boulderdash update —

I spent a long weekend in Devon visiting Aaron over the last few days where we brain-stormed and decided to have a look at what could be done with the enemy AI in Boulderdash. At present Envahi is progressing steadily so we didn’t really look at that at all as I don’t really need any help with it at present.

One of the longest problems I’ve had with the original game is that it’s been built from scratch to work from tiles. Normally this would be no issue at all but I went the route of making every object a tile without having any kind of information about them which has caused problems from the off when trying to make some kind of working movement pattern when I don’t know where the tile I’m looking at has been previously.

Originally I tried to clone the system documented that showed how the original game worked and I got round the problem of not knowing which way the current tile was moving by changing the tile image number without actually changing the image so it wasn’t noticeable on the screen. Thus, a tile number could be TILE_BUTTERFLY_RIGHT or TILE_BUTTERFLY_LEFT for example, and that way I would know which way I should be looking to move it when I got to it on the next pass.

This wasn’t really working very well as I’ve documented on several previous blog posts so I would work on it a bit and then get frustrated and switch to working on another part of the game until I had another idea. The revelation on how to mostly fix it came recently when I realised that I had super-fast moving enemies in the right and down directions because I was parsing the whole tile map one tile at a time during each frame. For some reason I hadn’t considered that if I moved a tile to the right or down then it would actually then get processed again in the same loop until it couldn’t move in that direction any further. A daft mistake that Aaron kindly spotted. Fixing that by skipping the next tile whenever I moved one right mostly fixed that issue but bodging a skip to move past the next line on the tilemap to fix the down direction wasn’t really the answer so the problem wasn’t really fixed to a satisfactory solution.

Next step led to attempting to use an array system for the enemies that move in the game but this caused issues of it’s own when trying to keep track of everything. So Aaron reminded me for probably the 10th time now that maybe I could switch the game to using objects instead. I’ve written this idea off before out of both being stubborn and also with a feeling of dread because it would mostly mean rewriting the entire core of the game. As you can imagine it’s a huge weight to have a game that close to being complete and only to find that maybe the only way to get it working properly is to implement a major change this late in the day.

I’m pretty sure there are people coding with GMS that can, and do, use Tiles and objects for all their games anyway and could do this pretty quickly but I’m still relatively new to the system so I knew it would take me a lot longer.

Anyway, Aaron and I pulled on our thinking caps over a few hours during my visit and set to work on starting a new build of the game from scratch using the same graphics but weeding out the duped stuff and just writing the core parts of the game from scratch. These being the moving elements such as rocks, diamonds and Rockford himself, using objects and then removing the tiles from screen afterwards. This would work by using the same system of reading the tilemaps that I already have built and then deleting the tiles on the layer once an equivalent object was put in place. We then also put in the default values for all of the objects as the original game did, such as the rounded flag which tells wether that object can have other objects rolling off it. Classic example of that is a rock itself. This was all done using the new setup variables that you can now add into object classes.

We ran out of time before we could actually get to working on the enemies themselves but the diamonds and rocks now work on our revised base game and it’s my job to now strip out all the workable stuff in my project and put into the game while removing all the tile code so I can try and code the AI once again using an object system that remembers where it’s going now, just for starters.

Hopefully this will mean I can finally close that bit off once the rewrite is done. Not to mention have a lot less scripts to work with as a lot of it will be code that goes into the objects themselves.

I’ll update how I get on with that next time. Hopefully it won’t take too long and will let me leave the project in a good state to return to properly as soon as I finish Envahi.

 

 


Around week three now. —

More background work has gone into Envahi so what I have right now is a stable (as in no crashing) version 0.09 of the game currently in place. Version numbers don’t mean much to me as I just use them to keep track of where I am and will bump the game straight to V1.0 when I consider it finished. It’s handy to start from 0.00 and work up because I keep some development versions as I go along in case I need to go back to something I changed or maybe I broke something drastic and need to skip back a couple of builds.

I rarely have needed to do this but, because I’m so thorough with where I’m at in the notes for each version, I’m covered for most problems just in case. It’s pretty much guaranteed that I’d need to go back or something if I stopped doing it.

Since last entry I’ve done massive changes to the game state and how it processes events because more events are going into the game now – even in a temporary state. I’m allowing for the future adding of stuff like the cities flooding, quit game confirmations, pause game, invasion etc etc.

Previously I’d been putting all sorts of conditional checks into every alien object that was added into the game so each time I added a new event I had to go into each alien to add another part to the check. Stupid idea so I stripped all that out and just have each new enemy check the one flag instead. Much more efficient as I still have more objects to put in yet.

Lots of nice bugs like the grabber causing all sorts of chaos if it collided with another object while carrying players helicopter off the screen. That one caused explosions all over the place as it tried to move the helicopter up the screen with the grabber and tried to make it drop to the city below as it was exploding. Messy one that was.

Additionally, just to make things even more murderous to play at the moment, I added in the city shield so the clouds suddenly became priority to destroy first because the acid rain drops in droves. Ignoring them will cause the city to be destroyed very quickly right now – although I’ll adjust the level later on.

That brings me to the level as I need to start thinking of balance. I’ve got the nibber pretty much ready to go in now – shit graphic as well for now. Once i have them running and eating the dam tiles then I start to look at the level balancing so game starts a little easier and builds up. I’ve implemented a level selection on the title screen mock up for now so I’ll be able to test this. I think the game will start slow on easy mode and build up to level 4 – oh sh&^ gradually. So eventually, if player lasts long enough, then they’re up to that stage anyway. I’m not sure how to handle the scoring to make it fair to the people that play hard straight off, however. Maybe do a “Minter” and adjust the starting score accordingly.

I’m also considering seperating the score tables for each level too. But this is something I’ll think about once I actually have a level system in place.

 


End of week one progress —

Actually, it’s a bit further on than that as the competition started on January 30th and it’s now 10th of February. So, twelve days in. Just short of two weeeks. Around a fifth of the allowed time has already passed. Am I still on track?

Firstly I’ve been busy today setting up a proper network between my two Macs so I can keep up to date copy of my source code on the Mac mini. I’m planning a trip in a couple of weeks to visit Aaron at his new house for a few days so we’re plotting some development while I’m there. If I’m into that last 10% phase by then, he’ll be able to do some testing and suggestions for Envahi too as I’ll be around halfway to deadline by then.

While doing the network, I created new builds of Boulderdash and Envahi for him to look at. Took the opportunity to fix a bug which causes Boulderdash to crash when it’s launched on a new installation due to me initialising a variable after I’ve already tried to load it in the initialisation section. Because I was writing the data within the game itself to test the code, this bug would never have shown up for me as the data already existed so it’s lucky to get spotted now before other people tried it. A game that doesn’t even run would not go down well.

Also realised that, despite my previous post, Envahi is actually the fifth full game I’ve worked on since I started with Game Maker 2. Paradroid is the joint project Aaron and I have on hold at present which is what we were working on in Unity originally. After that I did a recode of my pee-take game called Numpty that I’d originally written in Swift. I actually took another look at that a couple of weeks back and made it even better just for t hell of it because I’d learned so much from continued work on Paradroid. We are coming back to finish that btw, everyone. It went on hold while Aaron had all his move stuff going on, which is why I switched to develop Boulderdash at the time.

My third game, thinking about it, is a half-written remake of Gravity Force, which I’ve blogged about considerably, earlier in the blog. If I get the urge I will finish that just to put another completed game under my belt. It’s certainly been a lot easier to remake that using this system so it wouldn’t take more than a week or so. Maybe while the competition is in it’s two week judging period, I’ll go back to complete it as a straight conversion, so I can resist the urge to add to it.

Fourth game is obviously Boulderdash and that’s also very close to completion as long as nothing else distracts me from Envahi and completing my entry for the competition.

So what has actually been done with Envahi now?

After purchasing the assets for the players helicopter I’ve decided that the only other usable image is for the cloud so I’ve needed to look around for stuff like buildings, Dam etc. I’ve got some placeholder stuff in there from Kenny’s game assets that I licensed a few years back but it’s exactly that. I’ve also sourced some temporary buildings initially, which lasted a few days, until I decided on an alternate route and found a photo’s site where there are lots of lovely photo’s of city backdrops you’re allowed to use as you wish. I found that importing some of them as sprites, snipping out the area I want, and then resizing to fit my screen dimensions for the city actually works rather well. There’s a lot of image manipulating to do afterwards as the background to the cities, like night sky for example, needs to be edited out or made transparent. I’ve got 6 in there at present but may put in more to use randomly – or in a level structure depending on available time further in.

With the enemy sprites I’ve hacked together some temporary extremely crap ones to use for now. I’ve got an idea for modifying how a couple of them work later on so will probably need to change the image anyway, so will also do for now. My searching online for stuff that works with this game to save me using the crap I’ve done.

Speaking of enemies, I’m almost done with them at the level where they work mostly the same as the original game.

Grabbers are in and work the same way where they drop down to the y-axis of the player and then move to the right trying to grab them in a cage if they connect. Easily dodged if you see one coming and aren’t distracted by something else.

Zoomers work the same way as the original game and are moving at a rapid rate to make them harder to hit. Again they must be shot down before they get to the city or it’s invasion. At present it’s actually just game over because I have no invasion event coded into the gamestate yet.

The UFO now moves right and left across the screen randomly. On it’s right to left path it will spawn droppers under it which will slowly move down to try and invade the city. In the original game it spawned them on the left to right path but I prefer it my way.

Acid cloud’s can appear now. At the moment there’s a max of three but this will be changeable based on level, I think. Acid rain is in and working nicely. More on this later.

Just nibblers are left to go in now. I’ve knocked up an image for it and just need an animation of some kind for them dying because I need to keep the original game system where enemies stay on screen dying for a while and you can’t shoot through them. This encouraged a lot more moving around trying to find a clear firing path. Zoomers already have this but the grabber does it’s own thing where it loses its base after you shoot it and flies off the screen uselessly.

I’ve resisted playing with the front end completely since putting a basic screen in place at the beginning and testing the music. I’ve got some interesting ideas to do with this involving using the different coloured helicopters that the asset pack included but it’s a lot safer to build that stuff in after the main game is complete so I don’t run out of time trying to cram game elements in right at the end. I’d rather forego some nice title screen effect at the end than have an incomplete game at deadline day.

Pretty much decided that I will be implementing some kind of level system now and enemies have been developed to make it easy to work that in. I can use different city backdrops as mentioned earlier, or just keep that random and gradually increase the speed and frequency of enemies as the game progresses. The idea being that starting on a harder level will have this already advanced and maybe increase scoring for playing that way as a reward. Potentially even seperate high score tables if I find that’s feasible depending on how names are actually entered.

With this game I’ve been using the object system rather than all tiles which I used for Boulderdash. Collisions have turned out to be a lot easier than expected as a result, as Envahi really doesn’t need anything more than basic area checks. I can overlay background objects behind the Dam for example and then just register a hit between both objects instead of any tricky bit-masking. As that stuff works so easily the game is playable as it is now, and pretty fun, even though there’s no Dam being threatened at present, missing the point completely.

I spoke previously about using some of Boulderdash’s code that could prove useful. Mostly that doesn’t even exist now, apart from a few simple routines like the saving of data and basic starting template. One of the great things about using a new development system is you’re always learning and improving. I could make a basic framework now for future games but there’s still so many features it would need that I’ve not needed yet that it would be pointless until I’ve got a few more games under my belt.

Finally there’s another big part of the game I’ve implemented that’s not in the original, which is the player shield. I wanted this so that acid rain could be a bit more forgiving than the insta-kill of the original game. It’s worth taking a bit of damage to get rid of a pesky cloud as you can shoot through the raid to get to it, if you’re positioned correctly. It’s also good for hitting the Dam wall as, while you don’t damage it, you do lose some energy but that’s much more player friendly than just dying instantly, as you’re moving around the screen quite rapidly and impacts are very likely.

I’ve also decided to implement a shield for the city so acid rain can damage it more of a priority to take down the clouds. This will involve some hud modifications but I need to edit that to put a border around the score/lives and shields info anyway so it will look much neater.

All on track so far then. Screenshots below. Remember it’s coder art and the title sequence is a mock up so it will look much better as development goes on.

 

 


Envahi continues —

Some nice Airwolf music goes in today as I got permission from the composer to use it for this game. It certainly sounds good when I play it on the hacked together title screen.

Took the unusual step of putting together the screen that shows when the game first launches today. I wanted to use the retro-evolved logo with the website name and state that the game is an entry for the competition and it gave me the opportunity to work on the logo some more. Not totally happy with it but it’s a lot better than it used to be.

My better half took a look at the elements I’e cobbled together so far and suggests – tactfully – that it all looks pretty shit at the moment. I’ve done a piss-poor job on the two large helicopters that hog the front screen and she’s pretty adamant that something more detailed should be there instead. As I’ve been considering having maybe having one bigger helicopter moving back and forth behind whatever I do on screen anyway, I concur. I explain it’s placeholder stuff just to hold the title screen scene while I work on the actual game scene.

She then reminds me that nothing of the sparse game that’s currently there has changed in the last 3 days so what have I actually been doing. It’s background stuff like making sure the lives counter display works correctly and I’m working on having the scores all a certain number of characters and padded with zero’s so everything lines up neatly.

Think that all fell on deaf ears. She’s waiting for me to make the damn flood the city which is a long way off yet. I still have 9 weeks and a couple of days, right?

Anyway, background stuff is being written that will make things much quicker once they start being put in. The state machine I’m creating already works a lot better than Boulderdash and I’m using one hud element for all the scenes in the game now to make editing much quicker. Definitely going to lighten up on the amount of scripts I use this time as well.

After the honest opinion of how the title screen looks right now, and the fact that there’s not enough game to really show off yet, I’ll leave the screen shots out of the blog for now.

 


Envahi – Day one —

Tuesday January 30th, 2018

Boulderdash – as close as it is to completion – is going on hold today as I’ve decided to enter a competition to code a small game based on either a TV or Movie theme. This competition is being run by the Syntax Bomb website which is frequented by a lot of ex-Blitz programmers who moved on to other things.

The competition gives you 10 weeks to get your game completed and up onto the site where there is two weeks of judging before the winning three games are chosen. I love the idea of a deadline in this case because I need to push myself to get a game nailed down and this will do it. I’ll be back to finish the current project after April the 10th and I think a break from it is probably going to do me good right now anyway.

So, I gave it some thought with the competition rules, and am going with the theme of Airwolf the TV series and Dambusters the movie. This is because I’ve been itching to do a remake of one of my favourite Vic 20 games which has elements of both. I’ll go with Airwolf as the topic because I like the music and want to use a remix for the game, if I can get a decent version and permission to use it.

First things first was to get a basic framework together before I start actually coding it. When I define start it’s getting the project together, putting all the assets in place and going through previous projects to see what I can pull out to use in the new game.

Envahi is a remake of a Vic 20 game I bought and played in the early eighties. It’s not particularly well remembered, judging by the lack of solid information about it via Google, but I had only just got my machine back then and this was one of the best Vic 20 games for me. As this game is a remake, the basic game design is already there. I don’t want to really do much to change it too much so I don’t really need to plan too much apart from different screen sizing, what elements I want to carry over and where I’m going to get them from. Or if I can get away with coder art here – bearing in mind it’s a competition so would be judged on that.

The original Envahi was probably knocked up using VicMon or a very simple assembler back then – a credit to the author for what he actually got out of the Vic in 8k. Luckily, in this day and age, we don’t even have to think of issues like that, and I’ll be putting it altogether in GameMaker 2.

So what’s the game about? Envahi is a static screen shoot’em up where you have a helicopter that you are flying to try and defend a damn from aliens that are crossing the screen trying to take chunks out of it. I think there’s an element of Cosmic Jailbreak (another classic Vic 20 game) in there – possibly the author, Jeremy Walker, had played that game and was influenced by it. The damn naturally is protecting the city below from getting very wet should the wall get breached.

Luckily it takes 3 bites out of any section of the wall before the water can escape but if it does then it will flood down out of the damn and drown the city.

No pressure then…

As well as the Nibblers attempting to take chunks out of the dam you also had other aliens out to try and get you out of the way so they could destroy the city.

Grabbers – these drop straight down the screen to get to your y-axis and then move horizontally to your position. If you don’t go up or down pronto then you’re lifted off the screen and the dam is left unprotected until the nibblers breach it.

Droppers move slowly down the screen and randomly left or right. They are pretty simple to take out as long as you can avoid everything else happening while you do it. Your helicopter is hindered by only having the ability to shoot up so some pretty deft movement is required.

Clouds appear randomly in the top-center of the screen and start dropping acid rain which will screw your helicopter electrics up and destroy it. You can shoot them but you’re going to have to be pretty dexterous to do this while avoiding the acid.

UFO will go left and right across the top of the screen creating droppers with some kind of regularity based on how long the player has been playing so the game gets harder.

Nibblers are the little buggers that move from right to left trying to bite chunks out of the Dam.

Zoomers are enemies that ignore the dam and just move left and right while moving down a line at a time when they reach the end of each x axis. Kind of like Space Invaders do. However, these are a lot faster and are murderous to take down in the original game.

There should be enough there to keep anyone who plays it busy.

So, because we’re dealing with an already set game plan, I just need to convert it. This actually makes it easier, apart from getting a difficulty balance right, because, just like my last remake, Boulderdash, I’m copying what someone else has done. And then just modifying parts that I think could work better if done a bit differently – although I don’t think I’ll be doing too much of that as the original was so good.

One idea I have had to mix it up is to change how the helicopter is affected by the acid rain from the cloud. The original game just destroyed the helicopter if you hit it but I’m thinking some kind of energy shield system could make it a bit more interesting as tactically you may need to get through that cloud in a hurry. Like if a nibbler is about to take a third chunk out of a wall segment, for example. I’ll decide on this when i implement the clouds and collision but plan for it now when considering the layout of scores and lives data, just in case.

So today’s job was to get the project up and running and get as far ahead with the assets so that it will be mostly about the code going forward after today. I have mostly achieved this which can be seen by first screenshots further down the page. I have most of my sprites in place, the tiles for the water effect (not working correctly but it’s there), some of the sounds ripped out of the original game, a mocked up city built up of public domain building sprites and my helicopter is in place ready for battle. I also did a logo for the title screen, got the image in place there of the big helicopter I already planned to use and animate then finally the basic framework of the project. This means all my slap-dash Boulderdash code has been dumped into the correct object, scripts moved over and basic title to game to title transition in place.

In my head I’ve already mapped out how both the title sequence is going to go so I’ve got extra images for that. I plan on having some bullet holes mark the helicopter with appropriate sounds before the title screen music kicks in. I have the original jingle from the Vic 20 ripped out but I’ll just have that play once on game over or something as a tribute because it can get pretty annoying.

I’m sure posts on this project will be just as spread out as the previous because my working time tends to vary wildly due to work and other commitments but Envhi isn’t a game that should take long. It will certainly be nice to see this one take shape a lot quicker as it’s now my third game using the GMS2 development system.

 


Don’t speak too soon —

Warp butterflies have returned with a vengeance. I’ve worked so much on the AI for these things now that it was inevitable that I’d get the bug coming back as I’ve rewritten the bloody script so much. They mostly still behave, however, so I’ve left them as they are and not ported the script to get the fireflies moving as well just yet.

Going on to other parts of the game in the meantime, I started working on another major part of the game now that the level end sequence had been clubbed together. This was the start sequence where the cave appears at the bottom right of the map and scrolls up to where Rockford is going to appear. This also has some zany random tile effect all over the screen which I’ve attempted to rectify, with mixed results. Sometimes I’m happy with it and sometimes it just seems to look shit. At least the core code is working so fine-tuning can be done relatively easy.

It was murder putting the start/end level sequences into the main game state as I hadn’t planned them ahead and had all sorts of problems with the main game functions still being active and screwing up how they worked. I’ll plan well ahead next time with stuff like this.

Because they all work rather slowly at present, bonus countdown and scrolling stuff that is, I’ve set up the fire button to just skip everything so player doesn’t have to wait around between lives. A pet hate of mine as the game’s hard and frustrating at times already. Why rub it in?

Also finally looked up and put in a full screen toggle switch on the title screen. I used the space on the title screen where the function keys that never actually ever worked used to display instructions or credits sequences if you press them. Talk about false promises. Both of those parts still aren’t in the game.

If the AI problems go on much longer then there’s a good chance those will be written first as well.

Sooner or later I’ll run out of tasks I have to do from the road plan and then I’ll have to knuckle down on the AI or I’ll never be able to actually release the game.

 


Warp mode butterflies are extinct —

Finally tracked down a nasty bug today which has been in the game since I first added the butterfly movement routines. Due to me using tiles for all the game play objects in this game, I’ve had to write a particularly long and cumbersome script to handle the movement pattern of the butterflies in-game. Currently it’s the only moving enemy in the game, even though fireflies are still present where they should be.

According to research on the original game, the fireflies used an almost identical movement pattern so my plan was to get the butterflies right and then copy the routine for fireflies, just changing the object references and tweaking them to work slightly different. As I’ve had this bug with the butterflies, the code isn’t working right, so there was no reason for me to move it over yet so the fireflies just sit there right now.

This is very noticeable, even playing the early levels, as you actually encounter the fireflies in level 3, one before the butterflies.

So, the bug was a problem with movement in two directions, where the butterflies decided to not move one square at a time and actually warp straight in that direction until they could not go any further. Effectively, they cheated and it was flippin’ obvious.

The code is rather large for butterflies movement,as there’s so much  to keep track of. The only collision system I can really use with tiles is to have the same tile image but have four different ID numbers so the routine can work out where it’s meant to go depending on which way it’s currently going. If you’re moving up then check left and go that way if there’s an empty tile. If you’re blocked going left and up then you need to switch the tile image to the new id number for moving down and let the script start checking for the next butterfly.

I expanded on my already powerful in-game cheat mode to allow for butterflies to not be able to kill Rockford and then ran the butterflies all over the screen to watch their AI movement and look for further errors. Apart from randomly coming to a stop for no-good reason the AI does currently seem to be working as intended. So, hopefully it’s just that one glitch to fix and I’ll have another major part of the game in and working.