Prototyping
Game prototypes: what to test before production
You have built a prototype with menus, effects and several mechanics. The session ends, and you still cannot tell whether the movement works. What did you actually need to test? Defining that question changes what is worth building.
Key idea
Before building a prototype, define the decision you need to make and the observation that would help you make it.
The value of a prototype is not in its visual polish. It is in the quality of the question it allows you to answer.
A team may want to find out whether movement feels good, whether a turn takes too long, whether two players have real incentives to cooperate or whether a route offers an interesting decision. Each question needs a different test. When a prototype tries to test everything at once, it becomes difficult to interpret why the session worked or failed.
Build the smallest possible test
To test a movement mechanic on the tabletop, a hand-drawn board, tokens and temporary rules may be enough. In a video game, a room built from simple geometry can reveal whether running, jumping or dodging conveys the intended feeling. Illustrations, menus, narrative and effects can wait if the hypothesis does not require them.
Reducing scope does not mean giving up on the final product. It is a way of isolating variables. The fewer elements involved, the easier it is to identify what caused a reaction in players and repeat the test with one specific change.
Test to learn faster
A simple prototype makes it possible to iterate before a decision brings art, programming or production work with it. If a mechanic does not work, discovering that with temporary pieces or grey cubes costs much less than discovering it once it is integrated into an advanced build.
The initial question also defines what to observe. If you are testing whether cooperation exists, asking people at the end whether they enjoyed the game is not enough: you need to observe when they collaborate, what information they share and which reward or risk shapes that decision.
The prototype as a decision tool
Prototyping is not about building a small version of the entire game. It is about designing an experiment. A good result does not necessarily mean confirming an idea; it may also mean quickly discovering that a hypothesis was wrong and approaching the next attempt with better information.
Apply it to your game
- Write a specific question: for example, do players share information before choosing a route? Avoid using 'is it fun?' as your only hypothesis.
- Build the smallest test that lets you observe it. Include only the rules, space and information needed for that decision.
- Decide in advance what you will observe and what result would make you change direction. Then change one variable and repeat the test.
A session provides observations, but you still need to interpret the playtest feedback. Keeping that test small also helps you control the project's scope.
In Shadow Strike, I compare camera and aiming alternatives to solve a specific target-selection problem. Read the Shadow Strike camera and aiming case.