Prototype Before Production: Spend Less Time on the Wrong Game

A prototype earns its place by changing a decision. It can show that a mechanic needs a clearer response, that the intended camera makes navigation difficult, or that an ambitious system creates less interesting play than a simpler alternative. These discoveries are valuable precisely because they arrive before the team has built a large amount of dependent content.

The mistake is to treat prototyping as an informal phase with no boundaries. An experiment that keeps accumulating features can become an accidental production codebase without ever answering the question that justified it. Give each prototype a purpose, an audience, and a stopping condition.

Know which artifact you are building

A mechanic prototype tests an interaction. A technical spike tests feasibility or a specific constraint. A vertical slice tests how disciplines and pipelines combine into a representative finished segment. An MVP is a usable product with a deliberately limited feature set. These labels describe different kinds of evidence and should not be used interchangeably.

For example, a rough combat room might reveal whether dodging creates meaningful choices. It says little about the rate at which a team can produce polished enemy characters. A vertical slice containing one finished enemy, its animations, sounds, effects, and encounter is better suited to examining that production question.

Make failure informative

Write down what would lead you to stop or change direction. “Players do not understand the risk after several attempts” is actionable. “It needs more polish” is too broad to guide a decision. Distinguish between a failure of communication and a failure of the underlying interaction before deciding what to change.

Keep your test audience relevant. Experienced action players may understand conventions that a casual audience does not recognize. Friends who know the project may compensate for unclear onboarding. Use their feedback, but do not confuse familiarity with evidence that a new player will understand the same build.

Protect disposable code from production expectations

It is reasonable for an experiment to contain shortcuts. It is unreasonable to forget those shortcuts when the project moves forward. Label temporary systems and document known limits. A prototype save system that only works on one machine should not become a release dependency because it happened to exist first.

• Keep the prototype in source control so useful findings remain recoverable.
• Record which parts can be reused and which need replacement.
• Preserve tuning values and design observations separately from implementation.
• Estimate the cost of productionizing the successful mechanic.

Rewriting is not automatically required. A simple, well-bounded component may survive intact. The decision should follow a review of reliability, ownership, and future requirements, rather than the emotional appeal of keeping everything already built.

Turn findings into a production plan

At the end of the experiment, write a short summary: what was tested, what was observed, what remains uncertain, and which decision follows. Include a playable build and the instructions needed to reproduce the experience. A video is useful context, but it cannot replace interaction when movement or timing is the question.

Use the findings to adjust the next milestone. If the mechanic works but requires more animation than expected, that is a staffing and scope signal. If it only works in a tiny arena, investigate level design before commissioning a large world. Evidence should change the plan, not sit in a retrospective document nobody reads.

Keep the cost of learning low

Good prototyping is disciplined curiosity. The team invests enough effort to get trustworthy answers while resisting the temptation to finish every surrounding detail. The result can be a stronger concept, a smaller scope, or a justified decision to stop. All three are better outcomes than discovering the same problem after full production has committed to it.