Super Puzzle Adventure Dungeon - Post Mortem

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.