A prototype proves a focused design or technical hypothesis. A vertical slice proves that representative game systems, content and presentation can work together at a production-relevant quality bar. Confusing the two creates one of the most expensive early-development mistakes: spending for finish before the team has reduced the right uncertainty.
Both builds can be playable. Both can help a team win alignment or investment. Their difference is not simply polish. It is the decision each build is designed to support.
Start with the decision, not the feature list
Before estimating an early build, write the decision that should become easier after someone plays it. Can the traversal mechanic carry repeated play? Can the networking model support the intended encounter? Can the art target run within the scene budget? Can a representative content unit be produced at the required pace? Is the pitch understandable when the systems and presentation appear together?
A useful build creates evidence for one or more of these questions. A weak build collects features because they sound expected in a prototype or pitch. The difference is visible in the review: evidence produces a decision; features produce opinions.
What a gameplay prototype should prove
A gameplay prototype isolates the loop, mechanic or interaction that carries the largest design risk. It may use temporary art, incomplete UI, narrow content and a simplified architecture when those choices make the question faster to answer. The prototype is allowed to be disposable if it records what the team learned.
Define observable proof criteria. Instead of “combat feels good,” specify the behaviours a test should expose: players understand the threat, input produces a readable response, positioning creates meaningful choices, tuning can change without code edits and a short encounter sustains the intended rhythm. The criteria guide the build and the playtest without pretending feel is fully objective.
What a technical prototype should prove
A technical prototype tests feasibility or performance before the surrounding product depends on an assumption. It may focus on streaming, multiplayer architecture, procedural generation, platform services, AI scale, animation, save data or a content pipeline. The smallest valid build includes the conditions most likely to break the idea, not a comfortable demo of the happy path.
Technical evidence should be captured. Record hardware, build version, content conditions, traces, failure states and the limits of the result. “It worked once” is not a production recommendation. The prototype should state what was proven, what remains unknown and what would need a different test.
What a vertical slice should prove
A vertical slice combines representative gameplay, art, audio, UI, content and technical performance in a bounded piece of the game. Its purpose is to test the production system and communicate the intended experience with much less imagination required from the reviewer.
Representative does not mean maximum. Choose a slice that contains the kinds of work the wider game will repeat: a level segment, mission, encounter, progression step or player journey with enough variation to expose dependencies. If the slice avoids the hardest content or hides every production tool behind hand-authored work, it may look convincing while proving little about the path to the full game.
Prototype and vertical slice compared
| Dimension | Prototype | Vertical slice |
|---|---|---|
| Primary purpose | Reduce a focused design or technical uncertainty. | Prove representative experience and production integration. |
| Fidelity | Only where fidelity affects the hypothesis. | Representative of the intended quality bar. |
| Content | Narrow and often temporary. | A production-relevant sample with connected disciplines. |
| Architecture | May be disposable, but learning must be documented. | Should inform production architecture and pipeline decisions. |
| Review | Playtest, trace or experiment against proof criteria. | Cross-disciplinary review against experience and production criteria. |
| Outcome | Continue, change the hypothesis or stop. | Plan production, revise the target or close a major capability gap. |
When to build several prototypes
One large prototype often hides which idea created the result. Separate experiments are useful when control feel, progression, technical scale and art performance can fail independently. Time-box each test, keep shared infrastructure only where it speeds learning and compare results against the same product goal.
This approach also protects the vertical slice. By the time multiple disciplines commit to representative content, the highest-risk mechanic and technology questions should already have evidence behind them.
When a prototype becomes a trap
Prototype code can quietly become production code because it already works. Sometimes that is sensible. Sometimes it freezes shortcuts, hidden dependencies and tuning assumptions into the foundation. Before carrying a prototype forward, review ownership, data, testability, performance, tools, failure states and the cost of change.
The decision does not need to be all or nothing. Preserve proven behaviours and useful tools while replacing architecture that was intentionally optimized for learning speed.
How to scope a credible vertical slice
- Name the audience and decision. Internal greenlight, publisher pitch and production planning need different evidence.
- Select a representative unit. Include repeated work and meaningful cross-discipline dependencies.
- Define the quality bar. Use concrete references and target conditions.
- Set technical budgets. Include representative hardware, performance and memory constraints.
- Plan source and tools. The slice should reveal how content is made, not only display finished content.
- Agree acceptance evidence. Playtest findings, build stability, captures, production estimates and open risks belong in the review.
What to hand off after the build
An early build is valuable only if the learning survives it. Package source, build instructions, asset conventions, tuning points, profiling evidence, playtest notes, unresolved risks and the recommendation for the next phase. Mark illustrative or temporary material clearly so it does not become an accidental commitment.
Kioto Gaming scopes prototypes and vertical slices around proof targets. Tell us the decision the build needs to unlock, and we will map the smallest credible path to that evidence.
Turn the build into a production estimate packet
A vertical slice should leave behind more than a playable executable. Capture the people and calendar time required for each representative content unit, including review and integration. Record which tools were production-ready, which steps were manual and which specialists became bottlenecks. Separate work that scales with content volume from work that belongs to the underlying systems.
Link performance evidence to the exact build, hardware and scene conditions used in review. Note where visual quality, content density or feature behaviour was reduced to hit the target. These details prevent a successful capture from becoming an unsupported promise about the full game.
Keep an assumption register beside the estimate. Examples include asset reuse, localization volume, network conditions, save compatibility, certification requirements, voice production and the rate at which internal leads can approve work. Estimate ranges become more useful when a producer can see which assumption moves the range.
Use decision gates instead of a blurred early phase
- Hypothesis gate: agree the question, audience and proof criteria.
- Mechanic gate: confirm the core behaviour deserves further investment.
- Technical gate: expose scale, platform and pipeline risks under representative conditions.
- Slice gate: review the combined experience and the method used to produce it.
- Production gate: approve the plan, range, open assumptions and work deliberately deferred.
A project can stop or loop at any gate. That is not failure when the build has prevented a larger commitment to the wrong assumption. The purpose of early development is to buy better decisions at the lowest responsible cost.
Common scope mistakes to remove before approval
Do not let a prototype inherit every system expected in the finished game. Authentication, full progression, localization, account recovery, content scale and platform services may be necessary later without being necessary to answer the immediate hypothesis. Name deferred work so temporary omissions are not mistaken for forgotten production requirements.
Do not let the vertical slice become a handcrafted exception. If the most impressive scene depends on one-off imports, undocumented scripts or permanent overtime, it demonstrates presentation but weak production feasibility. Track the repeatable method and the exceptional intervention separately.
Do not use a publisher presentation as the only review. Producers, discipline leads and maintainers need their own evidence: build stability, source state, asset provenance, tool readiness, performance traces, test findings and a list of risks that the slice did not attempt to resolve. The same build can support several decisions, but each decision needs a named owner.
Finally, avoid converting a successful early schedule directly into a full-production schedule. Prototype work can discard failed paths; production must sustain content volume, integration, regression, approvals and team change. Use the early build to establish a rate range and its assumptions, then add the work that was intentionally absent.
