Thursday, November 1, 2007

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.

1 comment:

Aaron Miller said...

I only just entered the industry, and as a writer, but it seems to me that non-programmers could help the programmers to build the prototype. Half of programming is logic, breaking down events and environments into deductive formulae, and that's something a non-programmer could do. A non-programmer would not understand the limitations and quirks of a particular programming language, but couldn't he or she be useful working in tandem with the programmer?

These postings are mine alone, have not been reviewed or approved by any employer or company, and do not necessarily reflect the views of anyone but me.