Many projects call every early build an MVP. A mechanic prototype is then expected to look like a product, a vertical slice grows into dozens of levels, or an MVP reaches users without measurement and operations. These artifacts can form a sequence, but each exists to answer a different risk.
Direct answer: A prototype tests a mechanic or assumption at low cost. A vertical slice proves a small integrated experience near the intended quality and demonstrates the production pipeline. An MVP is the minimum end-to-end product that delivers value to a real user group and generates evidence for a product decision. Choose by the risk question, not by fashionable terminology.
Prototype: “Does this work or feel right?” Low fidelity; small test; temporary code and art can be acceptable.
Vertical slice: “Can the team achieve this quality and pipeline?” Near-target fidelity; narrow content; cross-functional integration.
MVP: “Does a real audience receive value and behave in a way that supports the product direction?” End-to-end, stable enough to operate and measure.
A prototype isolates the greatest risk. If the risk is control feel, focus on input, camera, and feedback. If it is puzzle depth, build enough situations to observe decisions—not a shop or narrative.
It needs a hypothesis, playable loop, test task, observations, decision criteria, and a timebox. It does not automatically need final art, scalable architecture, full economy, store UX, content volume, or live backend.
Temporary does not mean careless. A bug that changes how players understand the mechanic invalidates the evidence.
Gate: Keep, modify, compare an alternative, or stop. Success means reduced uncertainty, not merely a completed build.
A vertical slice connects core gameplay, art, UI, audio, performance, and content pipeline in one representative piece.
It should demonstrate experience pillars, target-device art, readable UI, audio/VFX rhythm, performance budgets, repeatable asset or level pipeline, functioning handoffs, and more credible effort per content unit.
Beware the golden path: a beautiful slice produced through manual work, custom scripts, and overtime may not be reproducible. Record tools, handoffs, rework, and actual effort.
Gate: Greenlight production, reduce scope, invest in pipeline, or pivot art/technology.
Minimum still has to be viable. A player must enter, understand value, experience enough of the loop to behave meaningfully, while the team can measure and support the product.
Depending on the question, an MVP may need onboarding, progression, save/account, analytics, crash reporting, test distribution, consent/privacy, payments, support, and update/rollback.
It does not need broad public release. A closed test can use real users when behavior is representative and the objective is explicit.
Gate: Validate, iterate, pivot, expand, or stop. Compliments are not a substitute for behavioral evidence.
A project may use several prototypes, one vertical slice, and staged MVPs. The decision matters more than the label.
Classify desirability, usability, feasibility, viability, and compliance risks. Estimate impact and uncertainty. Attack high-impact, high-uncertainty assumptions first. If combat feel is the greatest risk, an account system does not reduce project uncertainty.
Visual, interaction, technical, and content fidelity can move independently.
Polish matters when it removes test bias or proves the quality bar. Improve UI if placeholders hide affordance; keep art simple when it is irrelevant to the question.
Prototype: Short tasks, targeted think-aloud, observation of input, error, and decision. Small samples support qualitative learning, not statistical claims.
Vertical slice: Cross-functional review, target-device profiling, pipeline retrospective, art/UX quality assessment, and effort capture.
MVP: Cohorts, event funnels, suitable retention windows, interviews, support signals, incidents, and economic hypotheses, with valid consent and data.
Do not copy the prototype wholesale. Summarize the hypothesis and result, identify keep/discard, document debt, update rules and rationale, translate learning into acceptance criteria, record remaining risk, and define the next artifact.
A failed prototype can be valuable when it stops waste. A “successful” prototype without a learning record can be overinterpreted.
Ask every stakeholder to answer six questions independently:
Compare answers. If one stakeholder wants a mechanic prototype, another wants a pitch-ready vertical slice, and another wants a retention MVP, the project contains three different objectives. Separate them or choose one priority decision.
Estimate build, content, art, UX, technology, data, testing, analysis, and handoff. A feature-light MVP may still need distribution, consent, measurement, and support. A single-mechanic prototype may need several alternatives before it provides a useful comparison.
A milestone becomes learning-complete when the build is testable, participants and protocol are ready, evidence is collected, findings are synthesized, and the keep/discard decision is recorded. Delivering only the build leaves the artifact’s most valuable work unfinished.
Store the hypothesis, build identifier, known issues, participant criteria, protocol, raw observations, event definitions, results, interpretation, decision, and remaining risks together. This prevents a test from being retold as stronger evidence than it was.
When an artifact is used in a pitch, label what is representative and what is temporary. When it enters production planning, audit technical debt and asset rights. The same build can support different conversations only when its limitations remain explicit.
For a control prototype, exit may require that most test participants can perform the intended action without explanation, that input errors are understood, and that the team has compared at least one credible alternative. For a vertical slice, exit may require a target-device build, integrated art and audio, repeatable content creation, documented performance, and an agreed quality review. For an MVP, exit may require reliable distribution, valid tracking, completed first-time flow, support readiness, and a cohort readout mature enough for the planned decision.
These are examples, not universal thresholds. Write exit criteria before implementation and connect each criterion to evidence. Otherwise a team may continue polishing because no one knows when the artifact has answered its question.
The Game Studio brief supports prototype/MVP, full-cycle development, co-development, and dedicated teams. The starting point follows risk and current state. An untested concept may need a prototype. A proven core loop with quality or pipeline uncertainty may need a vertical slice. An audience question may need an instrumented MVP.
Discovery should confirm IP, source assets, technical constraints, devices, quality bar, ownership, and decision gates before estimation.
It needs enough stability and clarity for the test. It does not have to be production-ready, but debt must be documented and assessed before reuse.
No. Closed distribution can work when users and behavior are representative. A separate store test may be required for conversion questions.
There is no universal count. Use the smallest content set that represents gameplay, quality, and pipeline.
Yes, when the relevant mechanic and risk already have evidence in a current build. Do not skip merely because the schedule is tight.
It depends on the pitch objective. A prototype proves playability; a vertical slice demonstrates integrated quality. Align expectations first.
Primary CTA: Share your concept or current build so SAVA META can help identify the smallest artifact that answers the project’s largest risk.