Growing Pains changes

I recently released an update to Growing Pains which completely changed the graphics. It was a slightly unusual thing to do given the game has actually been released and has already been available for a while on the Xbox 360 (I haven’t updated the graphics on the 360 version by the way, I don’t have a membership any more).


Original screenshot of Growing Pains

The change was prompted by a few different bits of feedback I had about the game. Generally I try to be fairly thick-skinned concerning feedback about my games. There will always be negative feedback whenever you launch a game and I try to tell myself everyone is entitled to their own opinion. Having released several 2D platformers I’m well aware that for some people the controls will always “feel wrong” because they expect them to be like some other game they’re used to playing. No matter how the controls handle someone will say it feels too slippery and someone will say there isn’t enough intertia. That’s fine though, I’ve learnt to live with that. The feedback about the graphics for Growing Pains seemed to be fairly heavily on the negative side though. Here’s one email I received from someone at a large well known website:

Hi David. We have indeed been getting your emails. I hope you take the following as constructive criticism, and don’t feel too hurt by it.

Your game is ugly. Like, really really really ugly. Hideous. The concept behind it is solid, and I would almost be willing to check it out based on that alone, but I cannot get past how terrible it looks.

I am generally very supportive of indie game designers, and so I offer this advice: hire yourself an artist/designer to help you with the look of your game. It’s clear you have interesting gameplay ideas, and you can program it to work, but you need some help with the visual aspect. Nobody is going to touch this game until it stops looking like the art assets were thrown down by a novice using Corel draw.

If you aren’t able to hire somebody (understandable), then I recommend you take a look at works like those from Terry Cavanaugh (Super Hexagon) or Metanet (N+). They both have simple designs as far as the art direction goes (which would fit Growing Pains), but they aren’t an eyesore. Good luck.

It’s pretty difficult not to take something like that personally but I tried my best to take the criticism on the chin and think “OK, I need to do something about this”.

On both Shuggy and Gateways I worked with an artist who handled all of the graphical stuff but for Growing Pains I decided it was a fairly small scale project so I’d have a bash myself. Clearly that was a mistake, for any future projects I’ll be working with someone who has a slightly more artistic eye than myself. Rather than get someone involved at this late stage of Growing pains I decided I’d make a few changes myself and get the opinions of people with a more artistic background. I set about basically removing most of the graphical features and trying to make it much simpler. After a few variants I came up with this look:


Each level now has its own color palette with plain colored walls and a scrolling background. Hopefully it looks a bit better now but I worry it might look a little bland. But what do I know, I thought the original version looked OK!

To date the game has sold a whopping 190 copies so this hasn’t been the most successful release for me. It does make me question if I want to continue doing this for a living. I certainly can’t in the short term so I’m starting a regular full time non-games job very soon. Hopefully I’ll be able to return to making games at some point but with two kids I’m not sure I can really justify the amounts of money I’m earning by doing it.

Oh, and I did get back in contact with the person from the well known website about the new changes to the graphics. They very kindly agreed to have a look at the game,… it crashed on start up.

Ah well!

Growing Pains on Steam -

Getting Growing Pains to Steam

I’ve been blabbing about it for a while on Twitter now but Growing Pains is finally going to be released on Steam later on today. I actually made Growing Pains a few years ago for the Xbox Live Indie games channel but it never really managed to catch on, like many games on the indie channel. I’ve always thought porting it to the PC would be a sensible idea because the game basically already runs there with it being written in XNA. The main thing that’s put me off is the fact the game is very much a time trial type of game so I’d have to set up a server to deal with leaderboards. Thankfully when I contacted Steam about the game they said I could release it on there meaning I’d have access to their leaderboard systems. Once I heard that I forged ahead with the port.


As ever, the port of the game didn’t go quite as smoothly as I’d hoped. There weren’t any major problems but integrating support for Steam leaderboards and using the user generated content system for storing replays did take a little while to implement. I’ve also had to add support for different screen resolutions and keyboard controls which can be redefined. There have been a few changes to the game since the Xbox version. The shock wave indicating the right time to do a super jump was added, the camera works slightly differently, fast growing is much faster and some levels have been tweaked slightly.

Something else I’ve had to spend a bit of time implementing is the competition where anyone can win a Steam code for Gateways by placing at the top of any leaderboard in Growing Pains. Retrieving a code from a database isn’t in itself a particularly complicated thing to do but I’ve had to add some security measures to try and prevent someone from hacking it and clearing out the database of codes… I hope I’ve done enough!


Well, that’s about it. There’s my brief outline of what was involved in the port. It actually only took about 2 months to do so I can’t complain. I just hope everyone out there enjoys the game!

Growing Pains on Steam

Dead Underground

I’ve been working on a game recently called Dead Underground and I think I’m ready to call it finished. Go here to give it a try!

It’s a strategy game based around the London Underground. You control a group of survivors who have taken to the underground system following a zombie outbreak on the surface. Each survivor can be moved around the map and can fend off zombies as they break in to the underground network through each station. The survivors can collect items they find, rescue more survivors they discover or perform research to discover a cure for the infestation. Stations can be fortified by leaving someone on them which gives the survivors somewhere to recover and helps defend against the zombies.


This game has come about as part of a little side project I’ve been working on called Underground Mapper. Basically I can generate maps like the London Underground quite easily so I thought it would be fun to generate them based on peoples’ Facebook friends. If you’re interested in getting a map made so you can play the game with outbreaks occurring on your friends then pop along to the website. Oh, and be sure to follow the Twitter account!

Candy Crush Aga

As some of you may have noticed, the company that makes Candy Crush Saga (King) have trademarked the word Candy and are demanding that games using the word be removed from the app store. This is a rather disgusting move and as a result a number of indie developers have decided to produce games using the word Candy. Hopefully this will help spam King’s lawyers leaving them to sift through a sea of games with the word Candy in the title and they will eventually drop this ridiculous idea.

So, here’s my game, Candy Crush Aga! In which you use an Aga (it’s a kind of cooker thing which people seem keen on but is actually quite hard to cook stuff with) to crush candy as it comes along a conveyor belt.



If anyone else is planning on making a Candy game I can recommend heading over the Candy Jam homepage to submit your entry.

New Gateways graphics

When we were first making Gateways the graphics weren’t in an 8-bit style, they were higher definition. While we liked the graphics it seemed like they were missing something. After a suggestion from the author of ASCII Portal we tried reducing the graphics to a more 8 bit style and ended up with the graphics that are currently in the game.

Due to the way the graphics were scaled down from a higher resolution version they did end up looking a little on the blurry side. Some key graphics were completely changed to be more true to the 8-bit style like Ed and the enemies. Other graphics were touched up slightly to seem less on the blurry side but it’s always been one of those things it would have been nice to completely redo. We’re now finally finding the time to go back over a lot of the graphics like the backgrounds and make them much more like what we would have wanted had we started out using an 8-bit art style.

We’re aiming to have a new version out in January which will have the updated graphics. Here’s a few comparison screenshots to whet your appetite. You might need to click ‘em big to really see the differences:

newgfx00 newgfx01 newgfx02 newgfx03 newgfx04 newgfx05

Gateways is currently part of the Groupees Holiday Helpings bundle if you want to grab it for a great price!

The trouble with time travel

A post appeared on the Gateways forums recently with a video showing,… a bug, or a kind of a bug. Here it is:

It raises some interesting questions and took me back to handling the time travel stuff so I thought I’d write a blog post about it.

If you’ve played Gateways and got as far as the time travel guns then hopefully it’s obvious what’s going on here. If you’ve not then you probably don’t have a clue what’s going on so I should explain a bit how the time travel gateways work. The first gateway that’s placed (on the wall to the left) is the ‘return’ gateway. When the second gateways is placed (on the floor) it connects up to this first one at the time it was placed. Travelling through the second gateway takes you back in time. The first gateways is placed at 0:04 and the second one at 0:10 so travelling through takes you back in time by about 6 seconds.

The switch in this level has been wired up to close the door rather than open it. This means that before travelling back in time Ed can walk back and forth through the door. By travelling back in time and standing on the switch the door closes and it appears that Ed is walking back and forth through a closed door. You can see how it can happen but it looks like a bug. The question is, how would you fix something like that? The previous echo of Ed has already been recorded, should that be changed?

The initial time travel game I wrote back in 1999, TimeSlip, first made me think about this issue. In order to implement time travel you have to record the previous actions of the player so they can appear as past echoes when they travel back in time. My first instinct was to implement this by recording the player’s key presses and playing them back to make the past echoes recreate the previous actions. Here’s an example of what can happen when that’s the case:


There’s a single door here and the switch on the left will open it when stood on. In TimeSlip you travelled back in time automatically so there are no gateways to travel through.


The player walks into the door and hold down the right key. The door is in the way so stops the player moving.


The player walks back and stands on the switch which opens the door.


The timeslip happens and the player travels back to encounter his past self. He becomes the snail numbered 2 and the first echo is number 1. This echo walks to the door but is now able to walk through it putting him in a different place to what actually happened first time round.


The past echo (1) now walks back but only walks as far as he did the first time when he was blocked by the door. This means he doesn’t end on the switch. The current snail steps off the switch, making the door close.


We travel back in time again so past echo 1 reappears. The snail that used to be numbered 1 becomes 2 and the one that used to be 2 becomes 3. This time round the first past echo reverts back to what happened originally because the door is closed. It walks up to the door and is blocked by it.


Now the first past echo walks back and stands on the switch, exactly what happened the first time round. When we travel back in time again the switch will be pressed and the door will be open so the first echo will go through the door again, just like the second time round the loop. We end up in a weird state of alternating between two different versions of events on each timeslip.

While this initially seems quite fun the end result is something that’s incredibly confusing for the player, and time travel is confusing enough as it is! Past echoes end up jumping around randomly and eventually land on spikes or cause paradoxes between other past echoes. All this can happen off screen so the player often has no idea why they just lost the level. The whole system doesn’t work.

What actually happens in any game involving time travel I’ve made is that the actual positions of the player are recorded rather than the key presses. This ensures that they always take exactly the same action so the player can rely on their past echoes doing what they did the previous time.

It still leaves the problems like the one shown in the video, so how are we supposed to get round that? It basically boils down to the classic Grandfather paradox,where a time traveller goes back in time to kill their grandfather. If they kill their grandfather they will never be born and never travel back in time to kill their grandfather. If they don’t kill their grandfather then they will born so they’ll travel back in time and kill their grandfather. It’s a paradox.

One method that’s used in TV and movies to get round this paradox is the idea that travelling back in time takes the protagonist to an alternate version of reality. If they kill their grandfather in the alternate reality then that’s fine, they won’t go on to be born in this version of reality and they can change the past as they see fit. This sucks from a gameplay point of view though, you need your past echoes to perform the same actions as before and the past to remain the same.

Of course I used interacting with yourself in TimeSlip, Shuggy and Gateways as the cause of a paradox which generally meant you had to restart the level. I could have done the same thing for the type of situation shown in the video. I could have recorded the key presses and the positions. If, during the course of replaying the key presses the echo ended up in a different place to the recorded position that would cause a paradox. In Gateways that would mean the screen would go all wobbly and the time travel effect would end as soon as the player started to move through the door. I decided I didn’t like the idea of this method as it’s too easy to cause a paradox in this way and it can often happen off screen leaving the player wondering what went wrong.

The answer I decided to go with follows the Novikov self-consistency principle which states that a time traveller simply can’t make changes that would lead to a paradox. There would be no way for them to prevent their own time travel event. If they were trying to shoot their own grandfather then the gun would jam, if they tried to run them over they would have a car crash before reaching them. This is implemented in Gateways (or it should have been :/) by preventing the switch from working that would close the door. The door would remain open until Ed was finished dancing around underneath it; at which point it would mysteriously start working again.

Here’s a couple of examples of where it does actually work in the game:

Here the switch has been wired up to make the platform move. By standing on the platform before travelling back in time we have to make sure that the platform is in that position for Ed to stand on it. Hence the switch fails when it’s stood on after travelling back in time. As soon as the player’s past echo stands off the platform the switch becomes active and the platform moves again.

In this example a laser is being redirected to activate a switch that opens a door. We then try and prevent this from happening by deflecting the laser away. The mirror mysteriously fails to reflect the laser because that would prevent the door from opening. Note, at the times when the laser isn’t hitting the switch the mirror functions again and the laser can be redirected.

Implementing this stuff did prove rather tricky and I suspect I never implemented the case with the door because there weren’t any doors like that in the original game. I suspect most people that played the game didn’t even realise these cases could arise and were handled so in many ways I’m glad someone has raised this! With the release of the editor people will probably find more weird cases like this,… can you think of some?

Oh, and my next game won’t involve time travel. Too much of a headache! :)


Ludum Dare – Little Peeps

After missing several Ludum Dare competitions because I’ve had too many other things on I finally managed to take part in one this weekend. I came up with a Pikmin-like game called Little Peeps. Here’s the Ludum Dare page -


I’d been messing around with Javascript recently because I thought it would be a handy thing to use for game jams like this. Although I wasn’t that familiar with the language I decided just to use it for this jam thinking that coming up with a quick game might help the learning process and giving people a link to a game is much more appealing than giving them an installer or pointing them at an .exe and telling them there’s dependencies.

When I saw Ludum Dare coming up I wasn’t sure if I’d take part or not but when the theme was announced (10 seconds) I knew immediately what game I wanted to make which is quite rare for a game jam. I’d been playing Pikmin 3 recently and wondered why there wasn’t a similar game on the PC (perhaps there is, I haven’t look that hard to be honest).  Each level would be a single screen with a time limit of 10 seconds but you could pause the game and decide who you were sending where before letting it run again, a bit like FTL. Each level would have a target object that you had to carry back to your base but collecting the other tokens dotted around would be key to increasing the number of little peeps you have as they carried over to the next level.

I knew the path finding was going to be the difficult bit to get right so I decided to tackle that first. I decided to use a node based system where the map was made up of several interconnected nodes and the peeps would move from node to node. Here’s a picture showing the nodes from one of the levels:


The red nodes are the ones that are explicitly specified in the code for the level. The white nodes are created when I specify that two red nodes are connected. There’s a function that splits the connection into smaller chunks, automatically creates nodes in a line and connects them all together. There’s another function for creating a circular shape, the white nodes around the edge of the circle are created automatically based on the centre node. Doing all this meant the code for this level only contained 17 lines specifying the key nodes. This system help me create 5 levels for the final game.

One terrible decision I made was that the peeps should be stored in groups. They would initially start all in the same group but if the player shift-clicked to move some peeps a new group would be created. Only one group could be selected a time so selecting one group and shift-clicking on another would merge the two together. I had problems when some members of a group collected one of the tokens because they would head back to the base, splitting the group in 2. I had to code a special case for this which was really fiddly. I then realised that a lot of peeps would all end up back at the base but all be in separately selectable groups. The player would have to merge them all together manually, it clearly wasn’t working.

I realised the group idea wasn’t going to work so I had to make quite a few changes and introduce the click-drag method of selecting peeps (before you would just click on the group). A lot of code ended up getting taken out which is normally a sign that you’re doing things the right way. I feel pretty confident that the system I ended up with is much better.

The barriers and enemies were added next. They are associated with one of the key nodes and never move. Adding them was relatively simple, I just had to update the path finding code so that peeps could move into the same node as them but couldn’t move past them. If I detect a peep is trying to move into an enemy or a barrier they don’t move but attack instead. Each enemy and barrier has a health count that decreases as it’s being attacked and disappears when it reaches zero.

The tokens were a bit more tricky because they have to be carried by the peeps. As a peep reaches a token they tell it that they’re trying to lift it and the token keeps a count of how many peeps are lifting. Once that counter reaches the appropriate amount the peeps are told they can move it and all start heading back to the base. At this point the token’s position becomes the average position of all the peeps carrying it.

Towards the end I focused more on adding levels and testing the game. I found the game to be really quite enjoyable to play and I’m really happy with it. My aim in designing the levels was that it should be possible to collect all tokens but not necessary. It’s always hard to pitch the difficulty of your own game but hopefully I’ve not made it too tricky. Why not give it a try and see what you think:


London GameCraft – Get Off My Data

I had booked my ticket for London GameCraft almost as soon as it was announced, I do enjoy a good game jam. To my surprise as the date for the event approached I was actually invited to be a judge. I’ve never been a judge for a game jam before but I thought it sounded like great fun and agreed. And then it dawned on me; if I was a judge I wouldn’t be able to take part! In the end I decided not to let being a judge stand in my way and tinkered away on my own little project in between checking out the real entries and walking around with tinfoil on my shoes,… don’t ask.

There were some really impressive entries and we had winners in a few different categories. The theme was “The Impact of Prism”, presumably referring to the NSA data gathering program. It led to a split in the entries with some people going with the data collecting thing and other people going with the light refracting type of prisms. Other jammers have blogged about their day here and here.

I ended up being quite fond of the little game I produced that day so yesterday I polished it up a bit and have stuck it on the website for your playing pleasure. It’s called “Get Off My Data”:


You can download it for PC here. You’ll need XNA 4.0 installed.

It’s a twin stick shooter, tower dense type of game. You can use keyboard/mouse or an Xbox pad. You must defend your datas from the NSA by shooting them and placing defensive turrets. Collect tokens dropped by the NSA mobs to upgrade your turrets, weapons and movement speed. If you have enough tokens to buy something then the item will flash.

If an NSA agent collects your data you can still shoot them before they leave the screen to get it back. Move over data to pick it up and return it to the centre of the screen. If all your datas are taken then it’s game over. Get hit by too many NSA agents and lose all your lives then it’s game over.

See how long you can survive.


Gateways coming to Mac and Linux tomorrow!


By now everyone has the 16th of July pencilled in their diary for the release of Gateways on Linux and Mac. Eventually all deadlines for video game releases have to move though. Can you believe we’ve actually decided to move the Gateways release forward? As of tomorrow (the 9th of July) Gateways will be available for Linux and Mac through the Smudged Cat website and Steam. Ultimately it makes perfect sense for a game about time travel to have its release date moved forward. Since I’m so generous there will also be a 50% discount. Even more good news!

Opening the game up to other platforms will be interesting for me. Fifteen thousand people or so have played the game now so it will be fun to see how much that figure changes with the launch of these new versions.

Since the beta release of the Gateways editor about a week ago it’s been interesting to see a few home brew levels appearing. To be honest I’d love to see even more. Eventually I’ll get support for Steam Workshop in there which will hopefully inspire more people to test it out. As work progresses on the editor I’ll keep you posted about any exciting new features. My own new map designed using the editor should be available very soon!

So that’s all for now. As always you can follow me on Twitter or like the Facebook page to hear about any new announcements. Look out for Gateways for Mac and Linux tomorrow. Email if you have any problems!