Xerra's Blog

Drunken coder ramblings

New competition, new game —

Syntax Bombs next game coding competition started on May 4th so I’ve had this bank holiday weekend to have a think about what I’d like to do this time. There are three category mixes to go for and the idea is you have to pick one of them and follow both the types of game:

Option 1 : Retro / Strategy
Option 2 : Puzzle / Endless
Option 3 : Arcade / Open World

I had to think about this for a while as I did a retro/arcade game last time which, while not applicable this time, it would be all too easy to just do the same kind of thing again and pick an old game to remake. However, I’ve already been on and on about how I maybe shouldn’t have actually done this last time and gone for something a little more original. Certainly everyone else did and I felt that maybe Envahi might have been looked upon better if it was something truly different.

So I’ve no intention of going with some kind of arcade shooting game, or anything remotely like that, in all honesty. So out of the three options we’ve been given, I pretty much ruled out option 2 almost immediately. A puzzle game isn’t really a puzzle if you can’t complete it, or it goes on endlessly just extending it (is that even viable?). The categories were chosen randomly and that one is a no-brain skip. I’m glad that wasn’t the only option.

Arcade / Open World does not work for me based on my earlier decision and I’m not sure a game to be written in 8 weeks can even be made open world, as you’d have to have a clear end-goal very early on and code to the limitations of the deadline.

So, Retro / Strategy it is. Coming up with a game idea was much easier once I had that set in mind.

I did have an idea of a kind of puzzle game I wanted to recreate as a coincidence before the competition was put in place but I don’t think it would actually impress anyone so I skipped the idea as something to create myself another day, outside of a deadline and any kind of judging.

With a game idea in mind I’ve definitely set my sights high in what I can realistically get done by the submission date. I wanted to use the old home computers from the 80’s as a theme and I always thought doing it with some kind of card game might be the best way. Top Trumps was a core idea to build on, I always thought, so I’m now swinging towards that but with ideas to expand on it to have a game that has several ways to play – including a chapter-based story mode, if I can pull that off.

I don’t think I’m completely there with the whole design as yet so I’ll elaborate on some of the game modes I’m planning in a later update. For now the core mechanism is going to be the four categories of each card and picking what you think is the best stat to capture the opponents card. I’m adding a couple of extra stats onto each card which will be used for other game modes that will mean the strategy to win the game will be different. For example a seperate value stat that obviously bigger is better so you would want to hold that card and perhaps try to lose the cards that have a lower point value deliberately, even if the other stats are good. That part will still need more thinking, however, as a card with any points value is better than losing one altogether, so maybe cards are swapped instead.

Another option will be a good/evil stat on each card. Every one has a number of one type and, if you’re looking to win the game for good, then you really do want to dump the evil cards as soon as you can, and certainly before the number of rounds expires.

Over the last couple of weeks I’ve been tinkering with the start of a project framework that’s now got the the useful stage, in that it saves a fair bit of time getting a new game up and running. I’m now using this as the start point for the new game – name to be decided although I think I’m set on it now.

The first three days have been accumulating data, such as free wiki images of retro computers, and getting all the data for the four main stats that the cards are going to have. To add to this, there’s a trivia line on each one, and possibly some other information that will be used in the final csv export of this data. I’m obviously using a csv file instead of coding the data within the game as it makes it a lot easier to make adjustments once the actual card code is written and gameplay can be tested.

Yes, it’s really taken 3 days of work before I even started on the game code, there’s so much design work to do for this game. I’ve got an idea of implementing a freeplay mode additionally, which is where the player just plays matches to earn coins and has to save enoughΒ  to purchase each part of their own super computer. I might need some graphics work commissioned to be able to get that done, however.

I have until June 30th to get this done and submitted so early days yet…

 


And the winner was … —

Not Envahi, as it turns out, but that was to be expected as the games submitted were excellent.

Third place was a nice little bonus, however, even if it was only because the holder of the competition always discounts the votes on his own game – and his was the winner by far.

I even earned a bit of prize money for the competition result although I won’t be quitting the day job just yet. Full details of the competition can be found here.

 

I’m now waiting on the next competition which runs for 8 weeks starting on May 4th. No Star Wars remakes before anyone comments on the date. The theme is yet to be decided so no idea of what I’ll be doing as yet. I’m spending my coding time working on improving my GameMaker studio 2 framework and tinkering with my Space Invaders remake until then.


Remaking another old game for the hell of it —

I was going to go straight back to the reworked Boulderdash project that I paused to code Envahi but decided to do something else first. The competition which I entered Envahi in has its voting finishing today so it will probably not be too long before the guys at Syntax Bomb start up another one and I’m pretty keen to have another try. As it stands it looks like Envahi has made third place when you discount the site owners own game as it’s only in there for voting and doesn’t count among the prize places. It sounds like a good achievement for a first time entering a competition like this but there were only six entries – and one was actually incomplete so wasn’t voted on by most people.

Anyway, I wanted to do a bit of coding in the meantime until the next competition was announced so I’m tinkering with a remake of Space Invaders just to test myself on something a little different. I’ve only had a couple of small sessions with it at present and it will be put to one-side if it’s not finished by the time the next competition starts but it’s something to keep me occupied as I wanted a break from the boulders for a while anyway. I will come back and finally finish Boulderdash soon, though. It’s too far in to leave it shelved forever now.

 


Evahi’s development timeline —

Over the last ten weeks I worked on Envahi to submit for a game coding competition on www.syntaxbomb.co.uk

Most of the guys who submitted entries made a seperate post about their games in a showroom forum so as not to clutter the voting thread. I did one too and posted the following message which I’m reposting here as there’s a huge amount of insight into what happened during and after nailing down the final bugs and releasing it. No need to repeat myself and type it all again.


Envahi is now released and available via ItchIO as my entry for competition 4.

You can download and look at it from this link: https://xerra.itch.io/envahi

Voting is in the competition thread but I’m interested in any and all feedback regarding the game. I kept a sporadic development diary of the process when I was creating Envahi at http://blog.xerra.co.uk/ for anyone who’s interested. It’s most of the topic of the last ten weeks as I shelved an almost complete remake of Boulderdash that I was developing at the time to enter the competition as I felt doing something to a deadline would give me some much needed focus. It worked very well it turns out.

I intend to talk a bit about the development process and about the game in this thread and, like the other guys who’ve entered, thought it would be best to keep that out of the actual voting or competition entry threads.

While working on Envahi I kept a reasonably accurate log of working hours in various areas which I will explore a bit later. I started working on the game on the 30th January, 2018 – which was the competition start date. I already had the idea in my head for remaking this game, but I hadn’t planned on starting it any time soon. However, because the theme of the competition was Movies/TV I decided to bring it to the front and use this as my project basing it on the theme of Airwolf and Dambusters. In retrospect they’re pretty loose links as I’ve basically just gone and made the remake I wanted to make and just made sure that I could get a decent copy of the Airwolf music in. I think I’ve paid the price for this – more on that later.

I developed the game using GameMaker Studio 2 – which I initially had concerns that judging wouldn’t be allowed for a dev system like this when other people were doing all their code in text editors. There was one objection but the rules of the competition were made clear that making a game is about making a game, not how you actually do it, and what tools you use. I dread to think how many lines of code I still had to use in Envahi as it’s difficult to track without breaking it all out of the objects system – but there is a lot. The GML language – part of GameMaker is used for most of the work regardless of it being a complete development system. The advantages are not having to do stuff like set up graphic screens and backgrounds with code a lot of the time, as you can drag and drop them into rooms. It doesn’t make it that much easier, I assure you.

I finished the game on the 8th of April, 2018 – which was 2 days before the end date of the competition. I was very chuffed that I still had a little time to spare. It wasn’t the end of the process, however, because I had to get some kind of instructions written up, get the project onto my crappy Windows laptop because I had to have a PC version or I’d lose out on the biggest user base, and do some screenshots etc. All that stuff took me most of the evening of the 9th before I finally got my game entry posted here in the competition thread.

One further point I would make clear – not for any defensive reason – is that Envahi is my first completed game using this system. I’ve written many games before using BlitzMax, Amos, Swift and all sorts of other languages since the early 80’s but it was a great learning curve for future projects from working on this. So, whatever the result of the competition, I’ve still gained a huge amount, so I’m very happy I entered. I do, however, suspect that I was wrong to choose remaking a retro game for a competition which is theme specific. In retrospect I would probably come up with something original to make and left the remakes for my own gratification to work on seperately.

This competition, while being a little short on entries, has had some very clever, original titles, so judging has been pretty tough for everyone so far. My game isn’t original or very clever at all so, while it would appeal to the guys who like having a quick blast, a lot of people are going to vote for the better, more creative games. I have learnt a lesson from this πŸ™‚

So, as I touched upon earlier, I did keep a working hours log that I’ve put into Excel to get an idea of how many hours I put into the game. The results shocked me as I was convinced I’d been more productive. I had six categories that I labelled for working time as follows:

Code – self explanatory. This is the grunt work. All the scripting, bug testing, events set up and the core of the game.

Refactoring. This is moving code around, borrowing snippets and routines from other stuff I’d half written. I could use some code from my unfinished Boulderdash remake and from a couple of other projects I’d half started putting together.

Research. This was mostly hunting around looking for stuff. I did a lot of playing of the original game again, watched some videos to track the bits that I didn’t see because I was concentrating on the game etc. I even bought the original Vic 20 game on Ebay so I could look at the instructions inlay. I also count the time I spent investigating the use of tilemaps for the game and locating stuff like the music.

Graphics. Again, this seems obvious, but I purchased some assets for this game and even ended up employing two freelancers to work on the sprites and the big helicopter you can see with the other screeenshots. The time here is for me putting images into sprite sheets, editing photo’s to remove backdrops so they worked with the sky colours etc. I put in and ripped out a lot of images that were originally planned for the game. Longer sprite animations and originally drew my own sprites – which were terrible. Coming into this game I was very poor at working with graphics at all. I’m now a lot better at it but I still can’t draw for toffee. I would use freelancers again even if it does mean I’m out of pocket because you take a bit more pride if your graphics look ok. I’m very much in the minority it does appear on the graphics for Envahi, however. I like them but there’s quite a few voters who didn’t. I will definitely take a lot more input on this next time.

Sound. All the sound effects in the game were created by me using BFXer. I’d never used it for so many effects before but, again, it looks like I could have done better with this.

Writing. Mostly blog posts about what I’ve been doing – and pretty irregular they ended up. Not a bad thing, in some ways, as I needed to get on with the actual game but I think I could have made more time, judging by the totals below.

Code – 71.05 hours.
Refactoring – 1.5 hours.
Research – 4.75 hours.
Graphics – 16.5 hours.
Sound – 2.0 hours.
Writing 3.75 hours.

Total development time was 99.55 hours. I was absolutely convinced I’d put in a lot more than this until I did the count.

Another shocking statistic was looking at my date entries so I could work out what kind of slacking gaps I had. The first two weeks I put in hours for almost every single day. After 17th February I didn’t do any work on the game again until 3rd March – that’s around 3 weeks off. Whatever was I thinking there?

And then I had 3 days work which was 4th, 10th, 16th of March. Almost a week off between each day. I don’t even remember this but I know I was pretty accurate with the logging.

I worked on the 21st March and then didn’t come back until the 30th although, in my defence, I put in the serious slog then and was coding every day until completion on the 8th of April.

In total, despite having 10 weeks to finish the game, I could have put my head down and got it done in 5. Or, as I should really be looking at it, I could have worked steady for the entire 10 weeks on the game and made it much, much better. I’ve never tracked stuff like this when working on a game before but you can bet I certainly will be doing so from now on. Another valuable lesson learned.

About the game itself:

Envahi came out in 1983 and was written for the Vic 20 +8K expansion. It was written by a chap called Jeremy Walker and, like the Virgin games of the day used to have, had a little bio about himself in the cassette inlay. In those days authors of games were more well known than now. I don’t recall ever seeing his name on another game, however.

The game itself puts you in charge of a futuristic helicopter that is tasked with protecting a city and a dam that’s been built right next to it from an unending alien invasion.

There are Nibblers who move across the screen from right to left , trying to bite chunks out of the dam wall.

Also present is an indestructible UFO that moves Right to left and back again at the top of the screen. He’s there to launch Droppers.

These Droppers move randomly left and right while falling, and have the sole aim of reaching the city so they can “Invade” it.

The Zoomer intermittently comes into play and will “Zoom” right and left between the edge of the screen and the dam wall, dropping down a little each time. If this guy reaches the city then it’s “Invasion” yet again.

You also have clouds appear randomly that drop bursts of acid rain. These clouds can be shot if you can shoot a path through the acid.

Finally there’s the Grabber. His sole purpose is to launch down the screen and grab you so he can take you off screen. Once he does then the game goes into warp mode where you can do nothing but wait while the aliens do there thing.

If you let the Nibblers eat through the dam then you’re going to need an umbrella. Your city, however, is going to have a much worse time of it.

Players helicopter can only shoot up, and there’s no scrolling, so you’re moving around lots of shifting aliens which makes a pretty challenging game. Every minute the difficulty increases too – which probably doesn’t help.

The final thing to take note of is that both your helicopter and the city have their own shields. Too much acid rain hitting the city and it’s going to get destroyed. And the same fate befalls you if your shield depletes too. Sometimes it’s a more than viable tactic to use your helicopter to absorb large bursts of the rain to save the city, if your shield is greater. Especially if the offending cloud is behind a UFO as that enemy being indestructible will protect the cloud while it’s in range.

That’s pretty much it apart from the usual three lives are given and you get an extra every 5000 points. Harder skill levels (there are four) will give you greater points so playing suicide is much more rewarding for the high score – as long as you can hack the pace. Additionally the game will save your high score, level selection and sound settings for the next time you play.

Two more things I will talk about which I have been doing since the launch of the game. Getting visibility was pretty important to me so I’ll explain some of the things I did for that but first here’s some analytics data I’ve got about the project from ItchIO where the game is hosted. I’m sure this stuff is boring to most people so I’m just going to highlight five bits of info that I found interesting after the game has been online for four days.

Downloads 20. Most of these will be from people trying the game for the competition.

Views 100. So i’ve got a download rate of 20% from people looking at the game. Again, misleading, because a lot of people went there specifically to download the game anyway.

Impressions 517. I’m not sure what this actually relates to but it’s a high number so I like it πŸ™‚

Ratings 2. It’s a well known fact that nobody bothers rating stuff they download much. I wouldn’t expect many people to rate the game. One of these ratings came from my friend, for example. Both ratings have been 5, though, which is nice.

Purchases 0. Not unexpected as it’s a free game. People can donate if they want to but I wouldn’t have expected that for this game.

To finish off here’s some things I did to try and get my game some visibility. I’m no marketing guy but I’ve made games before and talked to a lot of people who do it for a living, so I was curious to see how much I could do with no budget and no financial motive.

Tweeted about the game to my followers. I think i have around 100, or so. Probably most of them are women from abroad looking for potential husbands so I wouldn’t expect much joy there. I do have some game dev friends, however, but they are, totally understandably, all about pushing their own games, and I wouldn’t ask them to retweet for a free game. Retweets obviously amounted to zero.

Posted on Facebook about me finishing the game on my own status at first. I then also pushed out a post in the a dedicated page for GameMaker Studio users. That got me around 20 likes and a few comments. You can’t tell how many downloads came from Facebook but the analytics screen of ItchIO does tell you how many of your page visitors came from Facebook itself. It is currently holding around 30% of the visits so far – the most by far.

I already had a you tube video up of a gameplay from the middle of development on my own youtube channel which I posted here on Syntaxbomb in the competition discussion thread. I put a post on there to say the game is now complete. I then also searched for every video of the vic 20 original that’s up there (3 as I recall) and put in a comment to say I’d made my own remake.

After this I searched out the wiki page for game remakes and created an account so I could put my remake in. There was only one other Vic 20 game in there, Gridrunner, I think.

I sent a message to the freelancer who did my graphics and also the author of the theme music saying I had now finished my game and they can look at the result if they wished. Both did and liked it. I made it clear that I’m very happy for both of them to use the game as an advert for their work in any way they wish, should they want to. No idea if they will, and I wouldn’t push it, but it could help.

I have a blog site and my website so both sites now host the game. I ensure I link to the ItchIO download rather than host it myself because: analytics, baby.

Any relevant forum signatures now have a link to the game and I put a note in my normal email signature to state that the game is available to download too. You never know who you might email next.

I checked for a showcase forum for my development system and put Envahi up there too.

As mentioned earlier, I’m primarily a Mac user but I have a Windows laptop specifically for building games for PC because I know that there’s more PC’s than Mac’s out there and I don’t want to get no votes just because someone couldn’t play the game.

A couple of quick points about ItchIO. When you list your games up there then fill in as much info as you can. And by this I do mean get the right size images that are optional uploads so that there’s a chance your game goes into the browsing window. I found the search function on the site didn’t even find my game, only the direct link worked, until I did that part. You also have an option to use tags for your game when you submit it. Use these. I tagged mine Helicopter, Overrun, Remake, Vic 20, Retro game, Competition etc. I know i’ve had hits from those as I got a follow from someone who specifically hunts out retro games and sent me a nice tweet as well.

Hope this has given you all some insight into doing something like this. And I hope even more that the next competition will encourage even more of you to submit your own entries as well. Because , believe me, if I can make a game and do all this on the back of it, then anyone can. Good luck to all the guys who submitted entries πŸ™‚


Envahi is finished —

After a marathon coding session over Saturday and Sunday I finally got the game finished. It’s not perfect but it’s still a great pick-up game considering I sacrificed a few things at the end to make the deadline.

Most of the time on Sunday was spent tracking down some real pain-in-the-butt bugs from new stuff I put in on the Saturday to replace the text box notifications that I’d been using until now for events. Due to the way the game state was written and my extremely stupid management of the project with the number of objects, it really was a job adding in new stuff and getting it working with stuff already there. By the time I closed off on the code and fixed the last bug, it was something like 02:30 am and I had to be up in four hours for work. I wasn’t very useful yesterday, that’s for sure.

Learning from this, future games I write will be a lot more thought out because I had the same problem with Boulderdash which, while mostly finished, I made a tentative start a few weeks back on reworking most of the code at the same time as switching to an objects system due to the AI problems.

Monday I spent some time getting a PC build together on my crappy laptop which involved all sorts of visual studio fiddling but eventually the project was uploaded on ItchIO – as you can see from the link above. The widget will take you to the page if you want to play the final game.

We’ll see how it does in the competition in a week or so…


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.