Paper Prototypes

Designers love to design, and they are full of design ideas.

For most game designers, the early stages of a project are candy - brainstorming, throwing piles of ideas out on the table, and discussing them with other designers. It's genuine fun to work on something new; to get to decide the rules from the beginning.

An issue with developing prototypes for most computer games is that they require an engine, and a comprehensive set of tools for implementing assets and content. If these are not already developed, designers (if they are not also coders) can end up with a lot of time on their hands while they wait for the coders to get the fundamentals in place.

Here's the danger. Because game designers love to design games, it's easy for them to use this time to design additional, and potentially overambitious, aspects of the game. In a worst case scenario, you end up with a game far too enterprising for the scope of the project.

Considering the <20/>80 rule of thumb that I discuss in a previous post, designers ought to be spending this extra time playtesting their prototype. But how can they do that if their prototype only exists as a design document?

The problem can be solved by testing the game system on paper while it is being coded. I've seen it work. Applying iterative design to a paper UI can help solve many design problems ahead of time, and help make the system more fun than it would have been.

If you time it right, when the code is ready for the final design and content steps to be taken, it's possible to have many gameplay kinks worked out (instead of a thicker design document).

Paper prototypes for the win.