Making a game in 48 hours

Earlier this month I was lucky enough to talk as a speaker at the 2nd Triangle Game Conference right near me in downtown Raleigh, North Carolina. My talk was on my experiences during rapid game development over the past year or so in a talk entitled “Short & Sweet: Making a game in 48 hours”.

Originally I had planned a more introductory sort of talk that mixed in some elements of being a tutorial. Basically introducing my audience to the ropes of rapid game development discussing planning, development tools, and other boring stuff. The day before my presentation I nixed that idea and instead went the alternate route of having a quick hits session where I basically ran through everything I’ve learned the hard way about rapid game development.

I absolutely love rapid game development. The worst part of game development for me is the moments when you’re not doing anything. Rapid game development is all about constant motion and activity; when you give yourself either 72 hours or 2 hours you barely have enough time to make the pieces fit. With rapid game development you also get exposed to certain elements of game dev such as experimentation and the experience of failure that helps engender better development in the future. It also compacts the learning curve so instead of spending two or three years of your life making mistakes you spend just a few weekends.

With that in mind the bulk of my presentation went over some “guidelines” for working with huge time constraints. I purposefully tried to avoid any “Goofus and Gallant”-type of demagoguery instead presenting them as things that worked for me for the most part which I then divided into two parts: rules that you probably should follow and rules that could probably be ignored. The guidelines I found most useful where:

1. Know your tools. Having experience with your game development toolset (including such things as programming language, your IDE of choice, graphics editing program, sound editing program, etc.) is a huge boost to successfully developing a game in a short timespan. Don’t waste your first hours learning how to setup your game to compile properly.
2. Having a plan. Even when the plan is thrown out in the first few hours it’s great to have an idea where you want to go. Here I recommend not building a 200-page game design doc, but even having a paragraph or two about theme, setting, gameplay, and characters can guide development enormously. I follow the advice of people smarter than me like Kyle Gabler who talked about building emotional targets for his prototypes.
3. Expecting plans to fail. When your initial idea fails (and it will fail) don’t panic! Failure at some point is a totally expected outcome of rapid game dev. Instead step back and figure out how you can reconfigure your game for the remaining time you have.
4. Staying on target. My way of saying don’t sweat the small stuff. When you start out don’t spend the first hours working on a finely-crafted mockup that won’t meaning anything. Work on a single element of the game at a time and don’t move on until that portion is acceptably complete.
5. Develop in tiers. A nicer way of saying that you need to be prepared to cut your game down. Be ruthless in removing flourishes from you game as the deadline nears. I envision this as a level of tiers. You have the first tier which are things your game requires to be functionally-working (like a running executable and the ability to take input), the second tier which is the stuff you most want to work on in your game (hopefully an experimental idea of some sort), and the next couple of tiers are flourishes in order of importance. Be prepared to lose all of that in your quest to come in under your time limit.
6. Steal, beg, and borrow. The final point is that in order to be successful at making games quickly you need to be willing to take what’s already done and use it. Don’t reinvent the wheel in the limited time you have, copy code from other people, copy code from yourself, take existing libraries and jam them into whatever parts of the game as necessary.

After this portion of the presentation I gave out other tips I’ve heard or followed in the past that I think aren’t as necessary as the tips above. Those include:

1. Collaborative versus solo development. In my mind having done both in short timespans I don’t think either one is an issue. Both allow different ideas and different processes to develop. Working in a team under time pressures will teach you things that you would never learn working solo and vice versa. But doing either in the end will help you become a better developer.
2. Being realistic in your targets. Another tip I followed initially and have heard a lot is being conservative in what you’re attempting to do in a short timespan. And while realistically you’re not going to accomplish 10% of what you set out to do, after some experience I don’t think aiming low should ever be an initial goal. Having ambitious targets is a great way to get started and with smart use of tiered development and being ruthless when cutting it’s something that won’t end up hurting you in the long run.
3. Developing to your strengths. The last thing that’s often repeated is developing to your strengths. If you’re a programmer then you should avoid doing something that requires a lot of art assets, if you’re an artist avoid something code-heavy, etc. But half the fun of rapid game developing is learning things on the fly, trying out new things, and even failing in the end (but at least walking away with better experience). So I now say screw this piece of advice and do what you want to do. Developing to your strength is like working out the same muscle over and over again – after a certain point it becomes functionally-useless.

I ended the presentation with a quick runthrough of a timelapse I created when doing a game in 2 hours for the site Glorious Trainwrecks. In two hours I was able to get a stupid, simple platformer up, running, and playable with graphics, sound, and menus. In order to accomplish this I had to borrow artwork, use programs like sfxr to create sounds, and lean heavily on the built-in functions of the engine (flixel) I was using to build the game. You can play the end result of this 2-hour process right now!

With such events like Ludum Dare 17 coming up this weekend it’s a perfect time to try out rapid game development for yourself. It’s a worthwhile experience that builds skill, knowledge, experience, and even character (like walking 10 miles to school in snow uphill). I highly encourage anyone with even the most remote interest in game development to try it for themselves.

Finally, thanks to the Triangle Game Conference and my audience for attending my presentation. I hope everyone enjoyed it and got at least a little something out of the whole ordeal at 10 AM that Thursday. You can download my presentation slides in PDF format here. Please note that the presentation slides is mostly non-sequitur without the benefit of the actual presentation.