How to write a 48-hour game in just 2 years
Published on 26 Jul 2013 by Joe
(or how to make, and finish, video games in your spare time)
Two years ago I was browsing through the results of a 48-hour games jam and felt inspired to try my hand at something similar.
Asteroids, I thought. That's the kind of thing I could do in 48 hours. I know my limits.
48 hours later my iPhone was displaying a black screen with a white triangle on it. Clearly my limits were being tested.
The problem, I realised, was two-fold. Firstly I had decided to implement the game in C on an iPhone (the subject of a future post). The second was that I had failed to get into a true hacking mindset.
In my day job I build biggish commercial websites, mobile apps and other assorted software projects. The terms enterprise and blue chip are bandied about. If you do enough of that kind of thing you soon start to appreciate code with an air of rigorousness and structure, especially when it requires nurturing over periods of years.
I constantly have side-projects on the go, but they are nearly all fragmentary and nebulous affairs where my goal is to investigate and learn, rather than to actually make something, and even here I tend to adopt a fairly rigorous approach.
Letting go of all that to try and hack something together in 48 hours proves difficult, and clearly requires a peculiar discipline of its own.
Fortunately that lonely white triangle adrift in the infinite vacuum inspired me to continue.
Over the next three months I poked and tweaked the code during lunch times and the odd evening, slowly morphing the prototype into something more complete.
Then I hit a wall, inexplicably losing momentum and the project languished, lonely and forgotten for the next seven months.
A chance encounter with a game development blog inexplicably sparked my interest again. I was reinvigorated and, flushed with purpose I opened up XCode, only to be confronted with yet another iOS upgrade. By the time I'd downloaded the new version and fixed various issues it identified with the project format I'd run out of time and energy to continue.
Time passed ... (another three months). At this point I had the basics sorted. Some wireframe graphics, scores, lives asteroids and a smattering of foes. I'd open the project and stare at the code, daydream a bit and shut it down again.
Start. Added some power-ups.
Stop. Four months passed.
Finally I tired of my inability to progress. I called a halt to this stop-start development program and decided that it was time I actually finished something. I jotted down some basic rules that led me from half finished to completion in about three months.
And then ... published on the App Store! For the first time in my life I'd followed a (self-driven) project through to completion and now I actually had something up and on sale.
It may not sound like much; after all, my game is one of many Asteroids clones on the App Store. However if you spend even a small amount of time browsing game development forums you'll soon realise just how rare it is that a part-time game development project is completed.
Here's some rules I eventually followed that helped me make the transition from a wannabe games developer to an actual games developer.
Let's say you're a fairly experienced programmer of some sort. Go on, flatter yourself. Despite your experience you really aren't going to build a MMORG. You really aren't. You're never going to finish it.
Resist adding new features
Your game is coming along nicely. You've a protagonist, some levels, some bad guys. Let's add another bad guy; a few more weapon types; a boss level; some cut scenes; online play. Uh oh, look what's happened. You're never going to finish it.
Time-slice your work
As a part-time games programmer with a full time job, a family and a social life (I'm projecting here; this is not from experience) you don't actually have that much spare time to develop your game. Spare time crops up unexpectedly and just when you've got all your toys out and are set to start, it's gone again.
To counteract this you need to do a little bit of advanced planning. Always have the next task ready and divide the work up into little chunks. The next time you find yourself with a bit of spare time you're all set and ready to roll.
If you don't have a handy half hour task, well use the time to create some for next time.
Don't build an engine instead of a game
Building engines, libraries and frameworks is fun. Unfortunately it won't help you finish writing a game. It might help you write the next one, but that's a hypothetical scenario at the moment. Write the minimum code you can to achieve what this game needs, not what the next one might.
Know when to stop
With self-driven projects it's hard to know when to call a halt to the work and just get it out there. With QB1-0 I fell into a long cycle of making little tweaks, or listing things I really should do before I pushed it. But none of it mattered - the main game was done, none of these things would make or break it.
Seriously - that's it. Most IT projects fail because of scope-creep, bad estimates and being afraid to ship. Single-developer side-projects are no different.
If I was being cynical I might now note that developing your game turns out to be the easy bit. Getting people to buy it ... well that's a whole different kettle of ball games.