March's #1GAM Entry - Zap

It's taken me a little while to get around to packaging up March's game, but here it is.

Zap is a really simple shoot-em-up with a not-so-great control scheme. It's also probably the least amount of time I've ever spent making a game - just under 4 hours total.

Originally I'd intended to make a text adventure. I had a basic prototype up and running, but as the month wore on I was getting busier with client work, and it became clear that I could never get it finished on time.

In order to make such a short project more interesting, there are 4 versions of the game to play. Each one was built after an hour of work, and it's kind of neat to see how things change over such as short space of time.

Here's a rough rundown of what you can expect in each version:

  1. One type of enemy, and you'll need to refresh once you die.
  2. Working score, high score and different kinds of enemies. Full title, play and game over loop.
  3. Power-ups, particles, sound effects and a improved gameplay loop.
  4. Online high score table. Slightly tweaked speeds.

For April I'll be taking part in Ludum Dare #29, so expect some updates once that gets closer.

Play it here


Super Puzzle Adventure Dungeon - Post Mortem

It took a little longer than expected, but here's the post mortem for my second #1GAM entry - Super Puzzle Adventure Dungeon. Even though it didn't have everything I wanted, I'm very pleased with how it turned out.

Development Overview

Source Files 31
Lines of code 3,046
Development Time 28:45

Overall the game took 4 times longer to develop than Haywire, but it definitely shows. Like last time I kept a full development log, although it's a little long so it's on a page of its own: Super Puzzle Adventure Dungeon Development Log.

What Went Right

Graphics

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.

Gameplay came first

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.

It's playable

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.

It's almost how I wanted It

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.

What Went wrong

Too much time thinking

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.

Started a lot of features that didn't get finished

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.

Didn't spend long enough actually playing it or getting feedback

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.

Burnt out a little too quickly

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.

Lessons For The Future

One thing at a time

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.

Find the fun as quickly as possible

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.

Practice the technical parts

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.

Don't develop in a bubble

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.

Make time to do the fun things

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.