The problem prototypes solve
Whether a game idea is fun is hard to judge from a description. An idea can sound exciting on paper and feel dull in the hands, or sound modest and turn out to be absorbing. The only reliable way to find out is to play it. A prototype is a quick, rough version of a game, or a part of one, built to answer a specific question as cheaply as possible.
The reasoning is financial as well as creative. The cost of changing a game grows as work piles up. Altering a rule in the first week is cheap. Altering the same rule after hundreds of levels, animations and voice lines have been built around it can be very costly. Prototypes move the risky discoveries to the point where they hurt least.
What a prototype looks like
A prototype is not a small version of the finished game. It usually looks plain. Characters may be boxes, the world may be flat grey, and the menus may not exist. That is deliberate. Polished visuals take time, and they can hide the real question, which is whether the central activity is enjoyable.
Prototypes are meant to answer narrow questions, such as:
- Is jumping between these platforms satisfying?
- Does this puzzle mechanic make sense to a new player?
- Is a turn-based or real-time version of this battle more engaging?
- Can the technology do what the design assumes?
A good prototype is built around one question and ignores everything else.
Types of prototype
Paper prototypes. Board-game style versions using cards, dice, tokens and hand-drawn maps. They are fast to change and suit systems with rules, such as resource management, card battles or economies. Simulating a game economy on paper or in a spreadsheet can reveal flaws before any code is written.
Digital gameplay prototypes. Simple interactive builds in a game engine, focused on controls and feel. These test movement, camera, combat or other moment-to-moment play.
Technical prototypes. Experiments to check whether something can be done, such as running a very large number of characters at once or generating terrain with procedural generation. The question here is feasibility, not fun.
Art or visual prototypes. Mock-ups of a visual style, sometimes in a small scene, to see how it looks in motion and whether it can be produced within the budget.
Vertical slices. A later and more polished sample of the game, showing the intended quality in a small part. This is usually a different goal from an early prototype, as it shows the team can deliver the finished product and is often used to reassure funders.
Throwaway or evolutionary
Teams often decide in advance what will happen to a prototype. A throwaway prototype is built quickly and discarded once it has answered its question; its code is not meant to be reused, because it was written for speed rather than quality. An evolutionary prototype is built more carefully and grows into the real game.
Each has risks. Throwaway code tends to creep into the final product if nobody enforces the rule, creating problems later. Evolutionary prototypes take longer and may encourage teams to keep an idea they should have dropped. Many experienced teams favour throwing prototypes away, though practice varies.
How a team judges the result
Developers look for signs that the core activity works. The most useful evidence is often simple observation. Do people keep playing when no one asks them to? Do they want another turn? Do they invent their own goals? Do they understand what to do without explanation? Frustration and confusion are valuable information too.
A prototype test is an early form of playtesting, with the same cautions: players’ comments and behaviour may differ, the team knows too much to judge fairly, and a few opinions should not overrule patterns across many people. Fun is also subjective. A prototype can show that a mechanic is engaging for some players but cannot prove that it will succeed with a broad audience.
What prototypes cannot tell you
A prototype does not show whether a game will sustain interest across many hours. A mechanic that is delightful for ten minutes may become repetitive, and one that seems slow at first may deepen. It also says little about the final art, story, sound design, market conditions or whether the game will be profitable. Testing a rough version answers a specific question and nothing more.
Another risk is overreacting to early results. A prototype is intentionally crude, and a team may reject an idea that needed more refinement. Careful developers separate problems with the idea from problems with the quick implementation.
Prototypes in the larger process
Prototyping belongs to the early stages of development, usually before full production begins. Results feed into the design document, which records which ideas survived. They also inform the choice of technology, including which of the available game engines to use. Large and small teams both rely on the practice, though indie development may do more of it informally because the cost of failure is so personal.
Events such as game jams show prototyping in an extreme form: teams build a playable idea in a day or a weekend. Many full games began as one of these quick experiments.
Many prototypes never become games. That is not a failure of the process. Finding out that an idea does not work in a week, instead of after two years, is the main reason prototypes exist.