Game development · 5 min read
A prototype should answer a question.
Choose the uncertainty first, build only what the test needs, and let the result change the plan.
In this article
Name the decision before opening the editor
A prototype becomes expensive when nobody can explain what decision it supports. 'See whether the game is fun' is usually too broad for a short experiment. 'Find whether players can anticipate the enemy's next attack from this animation' is testable. So is 'find whether a city block can stream within the target device's memory limit.' Write the question and what you will do differently depending on the answer.
Choose the uncertainty that could change the project most. A technical risk may require a rough executable on the real hardware. A confusing workflow may need a paper interface. A combat concept may need a greybox arena and readable feedback. Building a polished menu before testing the central interaction can make progress visible while leaving the most consequential uncertainty untouched. The prototype's shape should follow the question rather than a standard list of features.
Choose the fidelity the question requires
Low fidelity is useful when it preserves the signals you need. Placeholder art can reveal navigation problems or test movement speed. It may be inadequate for judging whether players recognize a threat, because silhouette, sound and animation are part of that judgment. Technical placeholders can distort results too: a tiny test level cannot establish the streaming behavior of a dense production environment.
For a hypothetical traversal game, a greybox route might be enough to compare jump distances and camera behavior. Add representative landing feedback if players cannot tell whether a maneuver succeeded. Do not build the final city simply to answer that question. Conversely, a visual readability test needs representative lighting and clutter. Spend fidelity selectively and record what the prototype does not model. That prevents a narrow positive result from becoming an unsupported claim about the whole product.
Set a stopping rule and an evidence plan
Before the test, decide what observations would support, weaken or invalidate the idea. You do not need a laboratory-grade experiment to make a prototype useful, but you do need something more specific than a favorable impression. Choose a small set of tasks, record the build and keep the instructions consistent. Ask for permission before recording participants and collect only information you actually need.
For the attack-readability example, observe whether players can predict the incoming move after a short introduction, how often they react too late and what cue they say they used. Do not supply hints during the attempt unless the test explicitly includes them. Record the hint if you must intervene. A handful of sessions can uncover obvious problems, but it cannot establish a population-wide success rate. Treat small samples as evidence for the next iteration, with appropriate uncertainty.
Separate a learning prototype from a sales demonstration
A pitch build needs to communicate a vision quickly and recover gracefully when somebody uses it unexpectedly. A learning prototype may deliberately expose a rough interaction to find out whether it works at all. Both are legitimate, but they create different incentives. A scripted demonstration can hide the exact uncertainty a team needs to investigate, while an unframed experimental build can make a promising idea difficult for an external audience to understand.
If one build must serve both purposes, document the distinction. Keep a short guided route for presentation and a separate test procedure that allows participants to explore the relevant mechanic. Clearly identify temporary limitations internally so nobody schedules production around an illusion of completeness. A convincing slice demonstrates that a particular experience can be achieved under certain conditions. It does not automatically prove that a full game's content volume, progression and production cost are understood.
Expect some prototype code to be discarded
A time-boxed experiment can reasonably use hardcoded data, a temporary interface or a limited content path. Those shortcuts are useful because they buy information cheaply. They become dangerous when a successful presentation silently turns the prototype into the production foundation. Before continuing, inspect the assumptions that made it fast: single-player state, a tiny world, one input device or a save format that cannot evolve.
Decide which parts deserve to survive. A well-isolated movement model may be worth keeping, while the surrounding scene logic needs replacement. Record the migration work in the plan rather than calling it polish. Avoid a reflexive total rewrite too; prototype code can contain valuable tested behavior. The decision should come from the requirements of production and the cost of changing the existing implementation, rather than embarrassment about rough code or attachment to work already done.
End with a decision someone can use
Write a brief result: the question, build, participants or test conditions, observations, limitations and next action. Include contradictory evidence. If half the players understood a mechanic and half did not, do not compress that into 'players liked it.' Investigate differences in prior experience, instructions or cues. The GOV.UK guidance on research in alpha similarly emphasizes testing ideas with likely users and improving understanding of their needs; the principle transfers well to interactive prototypes.
A useful outcome may be to continue, narrow the scope, change the interaction or stop the idea. Preserve the recordings and build where appropriate so future discussions can return to evidence. Then close the experiment. A prototype that runs indefinitely without a decision has become an unplanned project. The value of fast prototyping is the ability to learn while changes are still cheap, and to spend the larger production budget on an idea whose important assumptions have actually been challenged.
Sources & further reading
Primary material behind the discussion and useful places to go deeper. The recommendations and worked examples in this article are our synthesis.
Working through a software or game-development problem of your own?
Talk to Winnitude! ↗Explore our tools ↗