I originally planned on making a text adventure for March's entry. I had a basic engine up and running, and it was possible to move around, pick up and use items.

However, I quickly realised it would take more time to complete than I could spare, so I tried to come up with something I could build a little quicker. Considering I built everything in four hours, I'm very pleased with how it turned out.

It's not going to win any awards, but it's still playable.

I've never made a game with an online high score table before. Now I have.

Well, maybe not fun, but it is pretty neat to see how the game evolved over such a short space of time. I might even do something similar for future games, to complement the development log and video timelapse.

I couldn't have built the game as quickly as I did without borrowing from previous projects. The particle explosions, powerups, sound effects and most of the graphics all came from previous games. Having these bits of code lying around has been a real help, and each project adds a little bit more to the toolbox.

I started late, and ended up building Zap even later. So far that's 3 entries that I've left until the last minute.

There are a tonne of little bugs and annoyances left in the game. Spending time on play testing and polishing would have made for a much better end result.

For example, spawning enemies in a random position works fine when playing to make sure everything works. However, the longer you play, the more likely it is that an enemy will spawn right on top of you and you'll die. A better option would be to check to make sure the player is not in range before creating the enemy, but this isn't something that really comes up during the crunch.

Sure, you can fly around and shoot things, but it doesn't really add anything new.

Every game I've made this year has suffered due to lack of time. I think there's a lesson in there somewhere…

A little polish can go a long way. For future entries I'd like to spend at least 10-20% of my time polishing what I have, rather than adding half-baked features.

Every game I've made has taught me something, and these little snippets of knowledge can then go towards something better. It's quite liberating to be able to try out new ideas without having to worry about keeping things maintainable.

This is something I should have done a long time ago.

Most of the art in the game came from existing projects or from the excellent opengameart.org. Not only did this save a lot of time at the start, but it meant I could spend more effort polishing the bits I had.

I have a habit of coding the more challenging parts before getting around to the actual game. This time I started with the main block-matching element, which meant there was something playable within the first few hours.

Having something playable so early had a couple of advantages:

• Validated the idea – Once I saw the board and adventure placeholder, I knew it was something I'd like to play.
• Made adding new features easier – I came up with most of the power-ups during the initial idea phase, but the paint came much later. Because I'd already coded the board and gem classes, it was easy to add.
• Motivated me – Nothing kills motivation quite like having a bunch of unfinished pieces of code and nothing to play. Having the initial stages of the game playable kept me going.
• Eased the end crunch – I planned things much better this time, but still ended up crunching at the end. Thankfully most of what I added wasn't essential to the game, which took off some of the pressure.

There's a full start -> play -> restart loop, and some actual gameplay as well. Average time on the game page is about 4 minutes. It's not exactly setting the world on fire, but it's better than Haywire's 90 seconds.

There are a few big features I wanted to add, but didn't have enough time for. Having said that, most of the features I really wanted are included: gem matching, items, combat and progression though the different adventure fields are all there.

That might sound odd, but I think I spent too much time at the start trying to come up with an amazing, original idea. Instead, it was better to come up with an average idea and make it better over time.

There's an "Equip" screen, but no equipment. There are also a couple of items that do absolutely nothing which should have been removed. These all started off as good ideas, but got pushed to the back in favour of more important things.

It would have been much smarter to add one feature at a time, rather than leaving in all the loose ends.

Nobody really played it until release, but I think the overall game would have benefited significantly from having people play it as it was in process. The combat isn't particularly balanced, and it would have been nice to tweak it in response to player feedback rather than just guessing at the numbers.

I got the puzzle part working quickly, but then got bogged down trying to get the adventure part working, which was more difficult than expected.

I jumped around a lot whilst developing things, which meant there's few parts with unfinished or broken content. It would have been better to focus on one feature at a time before adding new ideas.

Having said that, sometimes a good idea comes out of nowhere during development it's hard not to go straight to work on it. Perhaps a way to enabled and disable features during development would be better.

Halo is famous for having "30 seconds of fun" that is used throughout the game. Once you have that bit of fun, it gets much easier to develop the rest of the game around it. It also makes it easier to tweak things and refine the whole experience.

A lot of my sticking points revolve around these things:

• Animating things (like a walking character) in a sequence
• Telling different parts when something has happened – What's the best way to notify other parts of the game when something happens? For example, when a block is destroyed, the score needs to be increased. What part of the engine takes care of the notifications?
• Drawing the line between a visible entity and "data" – As an example, the adventure field sometimes contains enemies. Each enemies has a couple of components - the statistics part (base health, attack etc), the graphical representation, and the individual instance (current health, experience gained etc)

In the end I found the best way to deal with entities was to treat the game more like a database and not to cram too much functionality into a single object. I've used an Entity Systems approach in other projects, and although it takes a bit of getting used to it works very well.

Even though I've been programming for a long time, I really don't like showing people software until it's finished. However, it's important to get as much feedback as possible, especially when developing games. I think it would have been more beneficial to have people play the game, even if it meant showing something unfinished and unpolished.

The battle screen intro could just have been a straight label that said "fight", but I wanted it be a little more graphically interesting because it's what I would like to see. It took a lot longer to create, but it made me happy, so I guess that's a win.