Haywire - Post Mortem

Last week I released "Haywire", my first game for #1GAM. Seeing as I haven't really made anything in a while, I kept things as simple as possible. Overall I'm pleased that it got finished, although I would have liked there to be a bit more "game" to it.

Development Timeline

Overall the game took a total of 7 hours and 9 minutes to make. As well as tracking task time, I kept a separate log to make note of important milestones. As you can see, I left things pretty late before I got started…

[2014-01-25 Sat 08:00]

  • Created basic project skeleton, can compile it and view a title screen with version string

[2014-01-25 Sat 09:00]

  • Set up resource manager
  • Created a basic tileset and map
  • Can scroll the map manually using arrow keys

[2014-01-25 Sat 10:00]

haywire-dev-shot-1.png

  • Spent about an hour wrestling with Flixel's camera system. Turns out rather than using a constructor for states, the create method should be used/overridden.
  • Simple player ship can move left to right
  • Camera follows player
  • Background layer with parallax scrolling

[2014-01-25 Sat 13:00]

haywire-dev-shot-2.png

  • Basic player movement added – can now accelerate left and right, as well as thrust upwards. Really simple gravity
  • Proper graphics now
  • Got a stationary animal on the map. Just a sprite for now so not sure it counts as progress
  • Fixgured out how to draw a line (using an FlxSprite as the body) - Don't really like it, but it should do the trick
  • Added a nifty starfield to the far background

[2014-01-28 Tue 20:00]

  • Added some basic collision with the floor. For some reason the pixel perfect collision isn't working the way I want it to.
  • Added some little particles that shoot out of the bottom when the ship thrusts upwards

[2014-01-28 Tue 21:00]

haywire-dev-shot-3.png

  • Really simple grapple hook now

[2014-01-28 Tue 22:00]

  • Grapple hook now bends (rather terribly) depending on the velocity of the ship
  • Added a little mothership sprite that floats around

[2014-01-29 Wed 20:00]

  • Player can now pick up any animal and they will stick to the end of the hook
  • Grabbed animal can be delivered to the mothership
  • Grapple now affects physics - having the hook increases drag, and hooking an animals makes the ship heavier
  • Returning an animal now increases the score

[2014-01-29 Wed 21:00]

haywire-dev-shot-4.png

  • Player now has health
  • Running out of health makes SPLOSION
  • Multiple animals, all in random places. I guess this is a game now?
  • Added a really terrible title screen

What Went Right

No Feature Creep

I've taken part in a few game jams now, and the process is usually the same:

  1. Come up with a small idea
  2. Think of some really cool ideas that I just have to add
  3. Implement one or two of those features
  4. Run out of time
  5. Vow to keep things simple next time…

This time I actually kept things simple. I had a lot of ideas for things I wanted to implement, but I forced myself to stick to only the absolute basics.

Graphics

One area I constantly struggle with is coming up with half-decent graphics. This has been a constant pain for me, so this time I went with some simple vector art.

A couple of parallax layers and a starfield are all it took to create something that I was happy with. There's also a few particle effects, but other than that it's very simple.

It's Playable

As always, it's nice to come away at the end of a challenge with something that can be played. Granted, the main game loop is very small, but there's a kernel of something fun there.

Kept a Development Log

This is something I should have started doing years ago. I usually write notes on what I'm developing, but I don't normally keep track of each feature as I complete it. For Haywire I kept a simple text file, and then updated it whenever I made something new. Seeing the game's progress over time was a huge motivator for me.

What Went Wrong

Game? What Game?

Let's face it - there's not a lot of game here. There's no reward for rescuing animals quicker, no real obstacles to overcome, and you have to refresh the browser window to start again.

Not Enough Time

I only remembered about #1GAM a few weeks into January, so I didn't have a great deal of time to get started. Still, 7 hours isn't very long to spend making a playable game. Put it down to a mix of bad planning and laziness on my part.

No Polish

One thing I've always been conscious of is adding a layer of polish to my games, but I really dropped the ball this time. The score font doesn't work, the health indicator is a bit cryptic, and don't get me started on the awful collision.

On top of all that, there's no way to restart without refreshing the browser, which just adds to the half-baked feel.

Lessons For The Future

More Time Polishing

Even though these are small games, it's still worth scheduling a few hours to get the rough edges smoothed out. In future, I should probably build the full loop (title, play state, restart) at the beginning so I'm not rushing near the end.

More Time in General

Only spending 7 hours on a game? 'Nuff said.

Keep it Simple

It's very, very difficult to keep things small, especially when all these great ideas keep swimming around. Being creative is part of the fun of game development, but it's also a burden once deadlines start getting closer.

Not every game has to be 20 hours long and full of amazing graphics. Concentrate on a few areas you want to experiment with and go from there.

1 Comment

wow, 7 hours? That's pretty amazing for 7 hours.

perhaps I finally might have a piece of advice for ya(not game dev, application dev in my case) but feature creep is a real issue when original scope is what I've budgeted time for.

Whenever an extra idea is brought up: if the estimated additional time is over 10 minutes (very easy to guess that), it goes onto a wishlist.

The wishlist for some programs is short and filled with "big" ideas. Sometimes it has a tonne of smaller ideas. The ideas are usually not fleshed out, just bullet points - if the idea was good, I'll remember it.

It means that if we reach the end of core development and there is somehow extra time, we can cherry pick from the idea list.

The other great thing about it is if for example, your game is a hit - you already have a set of extra things to give to your fanbase.

Sometimes we see the same ideas cropping up again and again that don't get implemented, so I prepare it in as modular fashion as I can so I have it ready to plug in.

One example for you might be an about/credits screen which you have some standardised images and text ready for any of your game jam games.

February 16, 2014 at 08:37AM

Post a comment

org-mode tags allowed: /italic/, *bold* and =code=