In 2004 I talked to some members of Heavy Iron Studios who gave me an important piece of advice that I remember to this day.

Ever tried explaining a board game to a friend with nothing but the rulebook? If you pulled it off, congrats! You’ve achieved the impossible. The rest of us usually end up sketching diagrams or hunting down a Let’s Play video. Now, picture pitching a game that isn’t even real yet, and asking someone to bankroll it. At this point you might understand why sometimes a game design doc by it self isn’t enough to green light a project. You might need a prototype.

A prototype is a small playable version of your game; making one can save you a lot of time and money. With a prototype, you can test your design quickly by putting it in front of real people. You can make a prototype cheaply, and that early feedback will keep you from sinking money into bad ideas. But most importantly, a prototype communicates your vision right away in a way even great documentation can’t because it let’s the systems speak for themselves. Often, this is also one of the only ways to convey emergent dynamics (the way your mechanics interact and build off of eachother) to other people.

In a 2013 Game Developers Conference presentation, the lead designer of X-COM recounted that the original X-Com game design document was very poorly received. It hadn’t fully communicated how the game worked. This resulted in confusion and a flow up meeting where the MicroProse developers asked a lot of questions that the document had failed to cover. Thankfully, they had made a proof of concept called “Laser Squad” building off of an existing project. As the lead designer, recalls,

A slide from Julian Gollop’s GDC presentation

Had it not been for that prototype, we all would have missed out on a great game (not to mention the excellent remake). This isn’t a fluke. Several games have been saved by prototypes that accurately conveyed the player experience when game design documents, and presentations didn’t.

This isn’t to say that making a good prototype is easy. Or that your first prototype will be a perfect, but less polished, version of your game. Most prototypes are are bound to fail. And, that’s ok! A failed prototype also gives you a lot of information about your game, and allows you to make changes to your game that make it better. Might as well fail early in the process when you haven’t put in a lot of work than fail after hundreds of hours of programming and creating art assets. So rather than focusing on getting everything right the first time test some assumptions and take some risks. Try thinking of yourself as a scientist and have each prototype be an experiment that is meant to discover something about your game. Some experiments you might want to conduct are:

• Is the core mechanic fun?
• Will my players understand how to use an item?
• Is this puzzle too difficult?
• What part do people spend the most time on?

Prototyping, should be a process that you use to make your games better. Really, there are very few downsides (maybe time) to prototyping, and when done correctly it can lead to very positive changes.

The type of prototype you make will depend on how much time you want to spend, your technical skills, and your game’s specific needs. In the next few weeks we’ll go over these different prototypes starting with paper prototypes.

If you want to try making a paper prototype check it out right now!

Or stay tuned for our blogs on these other methods.

• Paper Prototype: The fastest and cheapest option.
• Wireframe Prototype: Lower tech and easy to share.
• Greybox Prototype: Playable game with limited assets.