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.

Operating without constraints

The subject of the latest issue of Wired magazine is failure. And rather unsurprisingly one of the subjects taking center stage in any discussion about major failures is the now-cancelled Duke Nukem Forever. The story of DNF is well-known by now, the delays, the engine changes, the drama behind its cancellation (and if not then the article is a great summary of the downfall of 3D Realms and the Duke).

The lead for the article sums it up nicely. 3D Realms had success, had time, and had the money to make its dream project. And while there were plenty of other mistakes make along the way to cancellation and vaporware infamy, the story of Duke Nukem Forever would be much different if 3D Realms didn’t have those resources available to it. And as the article tells its story it becomes very clear: the failures of Duke Nukem Forever are a direct result of too much time and too much money. Any other project would have been released a decade earlier because of the time and financial constraints typically associated with game development. 3D Realms had the luxury of not releasing a game unless they absolutely wanted to and that became the major issue with DNF.

To compare look at the idea of art from adversity. The production of Werner Herzog’s Fitzcarraldo was a nightmare that resulted in an amazing film. Jaws was fraught with delays and filming difficulties almost driving Spielberg to give up on the project. Even ignoring the extremes of actual adversity constraints can be enormously useful. Hemingway once said his best work was the six word story “For sale: baby shoes, never worn.” Or look at the success of rapid game development competitions like Ludum Dare or the Global Game Jam. 48 hours seems like no time to complete a good game yet some of the best games of last year (like Beacon) were developed fully within this time span.

Adversity and constraints are elements that are enormously useful in the process of creation. They force you to be creative, they force you to find compelling solutions to problems, and most importantly they often force you to just complete the damn thing. With no constraints placed on themselves 3D Realms doomed themselves to the sad ending that befall Duke Nukem Forever. Let’s not let the Duke’s fall go in vain. Place constraints on your projects and you’ll end up much happier (and successful) for it.