A prototype is not a small version of the final product. It is an instrument for reducing uncertainty. That distinction appeared in different forms across the portfolio: Radgear needed to prove swipe controls; Water Battle Arena, the readability of four players on water; and Stylized Action Prototype, the coexistence of area cameras, exploration and card combat.
The path to a playable MVP begins when the team chooses which uncertainty should be resolved first — and accepts leaving everything else visibly incomplete.
Start with a question that can fail
“Make an action game” is not a testable question. “Can the player read a camera change without losing direction?” is. “Does card order create decisions or just one correct sequence?” is too.
A strong prototype question has three qualities:
- there is observable behavior during a short session;
- a negative answer changes the project direction;
- the interaction can be tested without building the entire product.
The preserved Stylized Action Prototype slice focuses on exactly those central risks: world movement, transitions between fixed cameras and the basis of card combinations. Complete menus, content volume and commercial polish were not required to learn whether those parts could form a coherent experience.
Build the smallest honest vertical slice
“Small” does not mean isolated. A perfect controller in an empty room may hide issues that only appear when camera, enemy, objective and feedback compete for attention. The slice should be short, but it must connect cause and effect from end to end.
Three public Water Battle Arena builds document that growth. The first validates movement and collisions; the second adds selection and match flow; the third consolidates water, CPU, markers and visual composition. Every milestone remains playable and makes the next question more specific.
A practical order for that evolution is:
- Action: can the player perform the core mechanic?
- Readability: do they understand what happened and why?
- Rule: can they recognize success, failure and state changes?
- Pace: does repetition sustain a short session?
- Continuity: can the system accept the next variation without a rewrite?
Use polish to reveal, not conceal
Visual feedback, camera and audio belong early when they help evaluate the mechanic. They belong later when their only job is hiding that the rule is still unclear.
Radgear is a direct example: the interface stayed light so swipes and character response remained at the center of the test. In RacketGO, produced in one week, a simple core action received leaderboards, social quests and progress tracking only because the short loop could already sustain repetition.
The criterion is not “does it look good?” It is “can I now observe the player’s decision more clearly?” An effect that communicates direction, cooldown or a state change is part of the test instrument. A long presentation sequence can wait.
Record decisions, not only versions
A build video proves that something existed. To guide production, the team also needs to know what that build answered. A minimal record can include:
- the hypothesis under test;
- the observed behavior;
- the decision made;
- the risk that remains open;
- the next playable slice.
This discipline prevents the prototype from becoming an accumulation of features. If a change does not reduce a risk, improve readability or prepare the next validation, it probably does not belong in the current iteration.
Extract systems only after finding stability
Abstracting too early turns assumptions into architecture. Abstracting too late makes every variation break the previous one. The transition usually appears when the same rule survives more than one iteration while its values, content or presentation keep changing.
That is the moment to separate adjustable data, match state and presentation; define responsibilities; and make important transitions observable. The goal is not universal architecture. It is letting the next experiment happen without dismantling validated learning.
The MVP is a product decision
The prototype proves a hypothesis. The MVP gathers the essential hypotheses into an experience another person can start, understand, complete and evaluate. That includes less glamorous states: entry, restart, failure, recovery and ending.
Before calling a slice an MVP, the team should be able to answer:
- what experience promise is being delivered;
- what path the player completes without assistance;
- what evidence shows the loop is understandable;
- which risks were accepted for the next stage;
- what was deliberately left out.
The result does not need to look final. It needs to be honest, playable and decisive: small enough to change, complete enough to teach.
