This article tells you how to get started with game prototyping.

Key Properties of a (Game) Prototype

Prototypes can be analog or digital, made out of paper, assembler, clay or python. They can take any shape or form, but still share some key properties. The reason for a prototype is always that you want to test a specific feature, technique or design decision as cheap as possible. In order to make the prototype cheap, it needs to be easy to create and fast to get started. Use whatever is at hand or, even better, create a prototyping environment. The environment can mean a box of crayons and some sheets of paper or setting up Processing. The ultimate fate of every prototype should be the trash can. Once you’ve created it, tested it, and noted the results of the test, you best throw away the prototype. Of course you might keep it around in case you want to iterate it, but that should be the exception rather than the rule. It is especially dangerous to create a prototype that could potentially be used in the final product. Most production environments are too complex to allow for agile prototyping. As soon as you run into a technical problem, you are most likely working in the wrong environment (or really clumsy with scissors). Also, a prototype should never be optimized. Since prototypes might be used for all kinds of experimenting, different tools are appropriate for different prototypes. Always remember that a prototype should test one specific aspect of your design. Don’t make it holistic. Don’t let any feature creep hamper your agility.

In summary, a prototype has the following key properties:

• Easy to create, fast to get started
• Cheap to work with, so that you can throw away the results
• Should not produce something you can use in finished product
• Should not allow optimization
• Be made with the right tool for this specific design challenge
• Allows to judge one specific aspect of design

Why Should I Build a Prototype?

The problem with prototypes is that they sound like extra work. Most people have trouble throwing away anything that required an investment from their side. To overcome this, a prototype needs to be as cheap as possible. Throwing away something cheap is easier than trashing something expensive. If the prototype requires too much work to be worth the effort or to be thrown away, you are most likely building it with the wrong tools.

The key benefit of building a prototype is that it enforces design decisions. Once you put a design to paper in the form of a testable prototype you have to settle for the behavior of the system. Also, if the team plays the prototype together they are confronted with those design decisions. The prototype fosters team communication. If the prototype is played by people other than the designers, those inevitably find loops in the rule set. The prototype then acts as a coverage check for your rule set.

Different Prototypes for Different Experiments

Different prototypes for different aspects of a game sounds great in theory. But what exactly can you test with a prototype? The easiest part is game design. Most game rules can be formalized and written down on paper. It’s a bit difficult for action-intensive games, but still doable. I’ve even read about first person shooters that were Wizard-of-Oz’ing. Remember, AD&D is all smoke and mirrors.

Things might get more complicated if you want to prototype more technical elements of a game. Game controls are a classic example of where a prototype is helpful, especially if you’re trying something new. Novel interfaces, the Wii Remote or the iPhone’s touch screen, can be tested for specific interaction forms before integrating those controls into the game proper. A.I. is another area where it makes sense to prototype a new algorithm before rewriting the engine. If you have e.g. a plant growing algorithm in your game you can develop a Lindenmayer-System in a dedicated piece of software before carrying over the rules that work for your game. Arranging audio before putting it into the game is so common I wouldn’t even call it prototyping, but what if you build an interactive dedicated audio-prototype?

Making Game Design Prototypes

Stone Librande gave a wonderful talk about paper prototyping at GDC09. Apart from numerous examples of paper prototypes he has built, one of his slides listed the do’s and don’ts of game prototyping. Here’s the gist of it:

What To Do

• Focus on one key idea at a time
• Abstract as much as possible

What Not To Do

• Don’t worry if the paper version is not “fun”
• Don’t try to duplicate the whole game
• Don’t simulate computer functions (physics, math, …)

Make Rules, Not Boards

Apart from prototyping my own games, I’ve taught this technique in game design and interaction design courses over the last six years. My students usually fall into expected traps when building their first gameplay prototypes. What goes wrong? They start with a board.

If you’re not experienced with prototyping, a game board is a bad starting point. A card game game is easier to create because it requires less assets and is faster to balance and iterate. Also, boards restrict character movement and thus have the tendency to make games slower and rounds longer. Think of popular card games and board games and compare the average match duration. It is far easier to build card games where the system escalates from a stable into an extreme state (I am resisting the urge to make a pun about the board leveling the playing field). That means it makes the game shorter, allowing for more iteration in the same time frame. It also makes for a better test setup for your rules because they are tested more intensively for their dynamics.

Another thing I learned through having students fail at assignments: Avoid using dices in your first prototypes. Balanced random makes it too easy to create a good game dynamic. Try to make a game without random first, and introduce dices when you need them.