Prototyping: Do it Quick + Dirty

In this article, creative director Eitan Glinert describes the process of prototyping that has worked for his company, Fire Hose Games.

So you've got an idea for a game, but you're missing an artist, you don't have the design nailed down, you need to find funding, and you don't know what platform you're going to develop for, you're not sure that the concept is even feasible, or you [insert development hurdle of your choice here]. How do you even start? With prototyping!

Prototyping is the process of making a small, crappy, slapped-together version that demonstrates certain key aspects of your final vision. It's a great way to start making games since it is far less daunting, and during the process you'll learn a lot about what you should actually do in the full version. Prototypes are throw away, but that's a good thing since it'll give you more freedom to experiment in ways you might not normally try.

Starting out

Take stock of what you have, and make a list of your strengths and weaknesses. When we started out at Fire Hose we were 3 MIT nerds with a good amount of design experience. We were especially good at programming and game design, but we completely sucked when it came to art and we had almost no money whatsoever. As a result, we decided to focus on the technology and design, and to just rip off artwork from other games. A larger, more established studio might have strengths of lots of money and a large code base, but weaknesses of time and manpower. Whatever the case may be it's important to focus on what you're good at and (for the time being) ignore the rest.

Scoping is really important as it dictates how big the prototype will be. We recommend making a few rounds of prototypes, starting with quick + dirty one day versions, then a 1-3 week build, and then a 2 or 3 month final prototype which is a good vertical slice of what the game eventually might feel like. Of course this will vary team by team, as larger groups can accomplish more, and not everyone has 3 months or so to devote to prototyping (though we certainly recommend spending at least that long if you can afford it). It's worth noting that there is a limit to how big a prototyping team should be; larger than 10 people will probably not be useful since the goal is NOT to make a final version, but just something quick and dirty that can be tested. We find that 3 – 4 people can do a good job of rapidly comping up with something worth playing with.

Let the development begin!

Once you've got your team, get to it! Remember, the standard rules of development don't apply, so feel free to take shortcuts. Want to steal assets/code from other games? Go for it! Want to use stand in, crummy programmer art? Why not! Code in whatever is faster, not most robust (i.e. python, not C). In fact, you should do whatever is necessary to get it done quickly. We've done prototypes where someone sits behind the monitor and reads the spoken parts to the user, pretending to be the computer. Don't feel bad about taking such shortcuts, remember that it's all throw away anyway.

The one rule that DOESN'T change during early prototyping is that you need to test, test, test. In fact, you should be testing more than you normally do, since you're probably throwing more new features in front of your users now than during any other part of development. Test on a weekly basis, ask lots of questions, and try to direct users towards rating the features you actually care about (but don't be leading when you do this!) It's amazing how much users are willing to forgive when they are presented with an obviously half-assed prototype, so don't feel bad about asking for feedback.

Finish the job!

It's easy to stop after making one prototype and calling it a day, but don't stop there! Analyze testing results and iterate on the prototype, taking what you've learned and making it better in the next version. Feel free to try out completely new, different, orthogonal, or contrary features/designs in subsequent builds, since you're trying to learn more about what will work. You should also start looking to fix your weaknesses during this phase – hire that artist, find more funding, or start putting together a schedule that is actually appropriate for the full title.

Deadlines are your friends, so be sure to schedule them in. It's easy to just keep iterating with prototypes forever, don't fall into this rut. Set hard deadlines for when you will finish certain versions and stick to them. Testing days are generally useful as deadlines since it'll force you to have finished builds that users can play with.

And when you're done...

Throw the prototype away and start fresh! Trust me, this is the right thing to do. It feels rotten since you've spent a lot of time working on it, but you can't build off of a hacked together prototype full of spaghetti code, stolen assets, and written in a non-robust language. Prototypes serve a purpose, but should not turn into a final game. The main things that should survive are the design and lessons learned.

Eitan Glinert is Fire Hose Games' founder and creative director. Before Fire Hose, Eitan spent several years making educational and accessible games, including AudiOdyssey, the first Wii Remote game accessible to the blind. If you have any questions on prototyping, feel free to contact Eitan Glinert at this e-mail address.