1. Don’t do it!

Do a mind-experiment. Imagine the system you would be prototyping as you want it in the final version of the game and “play around with it”. Is it fun? Is it useful? Is it pleasant to use?
If not, skip the prototype and the game system. To paraphrase Kyle Gabler, a participant in The Experimental Gameplay project: The prototype will never be more fun/useful then what you see in your head.

See if the game system exist in other games. Check for online flash games as well as the AAA blockbusters. It’s a lot faster and cheaper to buy a game than spend days on programming a prototype.

2. Don’t code it

If you do go ahead with the prototype, ask yourself: What is the simplest way to set up the prototype? Can you use chess pieces and a couple of dice? Excel? Or do you have to program it?

My favorite prototyping tool is a placemat that can be drawn on by markers. (old RPG tool)

Excel is second. Learn how to use it and you can simulate very complex systems in a fairly easy manner there.

3. Exactly one question

Know exactly what question the prototype is supposed to answer and make sure it’s only one question. This may seem like common sense but it’s amazing how often prototypes end up as exploratory tools with no clear goals.

4. Fail fast and often

What is most likely to cause your system to fail? Identify it and test that first. If the prototype proves that a system isn’t feasible you want to know as soon as possible. Prototypes aren’t there to show you what works, they are there to show you what doesn’t.

If all of your prototypes are resounding successes, you probably aren’t being creative enough! One of the best things about prototypes is that it allows you to test crazy ideas cheaply. Use that!

5. Cheap, fast and easy

Cheat, hack and steal. Abstract everything that doesn’t help you answer the question. Do a pass at designing the prototype, then look at it and say “What can I cut away?”. Do this again and again until you can’t cut anything more without hurting the prototype.

A prototype isn’t done when there is nothing left to add but when there is nothing left to take away.

6. Presentable

The reason you are doing a prototype is probably to convince someone (your creative lead, senior designer or anyone outside the proto dev team) that the system you are suggesting is a good idea. Make sure it is understandable and easy to play with after only minimal instruction.

7. Over-Communicate

There are two types of communication: Under-Communication and Over-Communication. The latter takes less time.

Sit down with all the stakeholders before you start working on the prototype and get them to agree what they want to see and how. Put it in print and distribute it. This way there will be no surprises (ok, a minimal amount. People still always manage to understand things differently) at the end of the prototype.

If something changes mid-way, let everyone know, even those you think might know already. Get their feedback and opinions. This saves you from a world of headaches down the line.

Probably the biggest sin I’ve commited against good prototyping is changing the goal of the prototype half-way in and not letting anyone outside the design department know about it! You can imagine how much fun we had at the wrap-up meeting. Don’t let this happen to you!