Why a mobile game prototype is needed before development starts
Mechanics are verified only in live interaction. The feel of control consists of the delay between tap and response, the input window, character inertia, and how the camera follows the action — none of this is reproduced in a description or on paper.
Until the core mechanic is assembled and running in hands, the team argues about assumptions, not the game.
An early prototype deliberately forgoes graphics, sound, and the meta layer: rough blocks, physics, and controls remain.
This provides validation of mechanics before release — on live players, not on the authors' opinion — and each iteration costs hours of revision instead of weeks of rework. A mobile game prototype in this form is assembled in one to three weeks.
Late edits are expensive not in themselves, but through connections.
When a mechanic has grown over with animations, balance, interface, progression, and monetization, changing one parameter pulls a rebuild of adjacent systems: pacing is reconfigured, rewards are recalculated, and the difficulty curve diverges.
The risks of late edits are that by the time of the first real retention numbers, half the project already rests on an unverified decision.
We formulate game hypotheses as testable statements: is control understandable without training, does the loop of the first minutes hold, does the reward feel rewarding.
An early prototype closes or discards three to five such hypotheses before months of production are invested in them — next we'll look at how this is structured.
What early hypothesis validation gives: timelines, risks, scope of rework
A change in the prototype takes hours; the same change in a release build takes weeks: first data migration, then rebuild, then regression on a dozen devices.
The early stage compresses the revision cycle from weeks to days, so what reaches production is not the first conceived version, but the tenth verified one.
We break down the core mechanics using the MDA framework — the rule and its response are checked separately from presentation and meta-progression. The interaction loop is assembled in its simplest form: action, response, reward.
If a player doesn't understand why to tap a second time, it's visible in the very first test, not a month later from sagging retention.
Prototype metrics are proxies for player retention: time to first meaningful action, share who abandon at the first challenge, number of closed loops per session. A hypothesis that fails on these numbers is cut before interfaces, progression, and economy are written for it.
Cutting hypotheses directly reduces the scope of rework: content that would have been made for an unconfirmed core does not go in the bin — it is simply not started.
Across our projects, the share of such work drops by about half, and team time goes to what the player has already confirmed through their behavior.
Validation formats: tabletop test, grey block, working build
Formats differ in depth of reliability: a tabletop test validates the game rule without a single line of code, an interactive mockup — response to screens and gestures, and a build without graphics — real logic.
The closer the format is to a finished game, the more expensive the revision: changing a rule on paper is an hour of work; in a vertical slice, a week of rework.
The order is usually this: a hypothesis is tested by a tabletop test, the riskiest parts by a grey block, and only then a vertical slice of one game loop is assembled. This way we don't spend time drawing what may not survive the first test.
| Format | When it fits | Limitations |
|---|---|---|
| Tabletop test | Validate the rule and balance before development — cards, dice, loop diagram | No feel of controls and pacing; hard to tell whether the player "sticks" |
| Interactive mockup | Validate navigation and screen flow before code | Response to actions is approximate; balance and economy are not validated |
| Grey block (build without graphics) | Validate live logic and progression with people | Visuals are placeholders; some testers drop off before reaching the point |
| Vertical slice | One game loop end to end: controls, graphics, sound, progression | More expensive and longer than the others; mechanic edits after the build are the most costly |
We choose the format for the question that needs an answer: unclear rule — tabletop test; unclear response to controls — vertical slice.
Work stages: from hypothesis statement to build handover
A mobile game prototype is needed not for demo, but to answer one question: does the core mechanic work. Therefore the route is built around the hypothesis and measurements, not around content volume. Below are six stages through which we guide the work from idea to build handover.
- Hypothesis statement. We lock a testable statement and the metric that will confirm it: for example, the share of players who complete the first loop and start a second. Without a criterion, a prototype turns into a set of screens.
- Mechanics diagram. We break the loop into states and transitions: what the player does, what they receive in response, what brings them back after failure. Edits on a diagram are cheaper than edits in a build.
- Build setup. One build scenario for the target platforms: the version installs on testers' devices without manual edits and updates on command.
- Mechanics testing. We take measurements on live players: time to first meaningful action, share of abandoned sessions, repeat launches. We separately note where participants act at random — this is a sign of an misunderstood rule.
- Refinement based on measurements. We change one or two parameters per iteration and compare with previous numbers — this shows what exactly influenced behavior. The hypothesis is confirmed or replaced.
- Result handover. We provide the build, mechanics diagram, measurements, and conclusions: what was confirmed, what was discarded. The development team starts from a verified core without reinventing the rules.
Each stage ends with an artifact that can be reviewed and challenged — disputed decisions don't surface in the middle of development.
Handover package: build, mechanics diagram, measurement report
A prototype is needed not for the fact of launching on a device, but for recorded decisions. Therefore the stage closes not with a build demo, but with a handover package: a working build, a description of mechanics, measurements, and a launch procedure.
Everything is stored in the customer's repository, so the team doesn't have to reconstruct the logic from messages.
- Build source code — the entire project with build profiles and instructions for deployment on a clean machine: it can be built and launched without us.
- Mechanics diagram — the flow of states from input to progress accrual and exit conditions. It is separately marked what has been confirmed by measurement and what remains a hypothesis.
- Measurement report — response time on a low-end device, share of completed loops, steps where players dropped off. Raw data is attached; conclusions can be rechecked.
- Launch procedure — which environment parameters are needed, where keys are stored, what is considered a healthy stand state.
- Environment configurations — separate sets of settings for development, the test stand, and demonstration; balance parameters are externalized and changed without a rebuild.
- Check matrix — a list of acceptance scenarios: what has been run, on which device classes, and with what result.
- Decision log — why this loop pacing and input method were chosen. This is exactly what is most often lost during handover.
We review the launch procedure and mechanics diagram together with the customer's team: we show where everything is and answer questions on the code. This way the prototype remains a working foundation for development, not an archive.
Case: how an early loop run removed the risk of a restart
Where the loop stood before
The project is a one-button arcade game: a tap sets an impulse, then physics determines behavior. In a closed test, 34% of players reached the first scoring action, and the average time to first tap was 19 seconds, of which 11 were spent on tutorial screens. Players went through the instruction but did not connect it to the result — the loop did not close.
Measurements were placed on every step: screen display, first tap, first point, first loss, exit. Aggregated Google Play statistics do not provide such slices, so events were collected in the client — this gave a funnel per individual player, not app-wide averages.
What was changed and how it was confirmed
The intermediate tutorial screen was removed, the first loss was made without punishment — restart in one action — and the first success was moved to the fifth to seventh second.
The difficulty curve was rebuilt so that the first win was almost guaranteed, while the second already required precise rhythm. Events after the edits were left in production — the same metrics are visible on the live audience, not only in the test.
Over three weeks, loop entry grew from 34% to 71%, day-one retention increased 1.8 times, and the share of sessions with three or more runs rose from 26% to 58%.
The risk of restarting the project was removed: controls and pacing proved workable, and further content can be scaled rather than reworking the foundation.
How a prototype differs from a vertical slice
A prototype answers one question: is it interesting to repeat the core action again and again. Therefore it is assembled from grey primitives, without final graphics and sound — the whole value of the stage is in validating the game loop, controls, and pacing.
If the core doesn't hold the player here, graphics won't fix it, which means it's too early to invest in them.
A vertical slice is one section of the game brought to target quality: one location, one battle, one shop screen, but with real graphics, animation, sound, and interface, as in release.
Here other risks are checked — how the mechanic feels in final execution, how much time it takes to produce such a section, and whether it holds up on low-end devices.
The scope of work differs by multiples. A prototype is weeks and a minimal team: a programmer and a mechanics designer complete hypothesis validation and finish the stage when the mechanic is confirmed or discarded.
A slice requires artists, animators, sound, and a build engineer, and any core edit at this stage is more expensive — it pulls rework of finished materials. Next in scope comes alpha: all game content is assembled in full, but not yet polished.
Hence the rule for transitioning between stages: until the prototype gives a stable signal — the share of players returning the next day and the number of sessions in a row — it is too early to move to the slice.
When the signal exists, controls, pacing, and economy are locked, mechanics readiness is considered confirmed, and only then does production at quality begin.
Technical doubts before the start: access, data, acceptance
Before a prototype starts, the customer's technical team usually has the same set of questions: what is needed from you, by what criteria the result is accepted, and what will remain in the code after delivery. We answer to the point, and we discuss any discrepancies with your process before work begins.
What is needed from you at the start?
Access to the repository and build system, a developer account, mockups or references, a list of devices for testing. If there is no account, we create one and hand over ownership together with the project.
How is the result accepted?
We fix the criteria in writing before the start: the build installs on the target device, the game loop is completed from launch to the end of a round, the mechanic reproduces consistently across a series of runs. Acceptance is by checklist, not by feel.
What about edits after the prototype?
The scope includes one or two rounds of refinements on the agreed mechanics: balance, control responsiveness, screen order. New mechanics and changing the idea are a separate task with an estimate.
Is the prototype code thrown away?
No. We write it as the foundation of the product: layers are separated, game systems are isolated, the build is configured for releases. Architecture, saves, input, and level configuration are then carried over.
How is the work structured by timeline?
Iterations by week: at the end of each — a working build via link and a short report on what was validated. A prototype of the core mechanic fits into one to three weeks; we name the exact timeline after reviewing the task.
Let's discuss the task: what is needed from you for a quick start
To come back with an estimate and plan rather than clarifying questions, we need a minimum of input data. The more specifically the idea and constraints are described, the more accurate the scope of work and the timeline to the first playable build.
- The core mechanic we are validating: one or two sentences — what the player does and what they receive in response.
- References: 2-3 games with similar mechanics and what exactly we take from them, and what we deliberately do not take.
- Platforms and devices: one platform at the start or two at once, including the weakest models on which the prototype must run.
- Controls: gestures, on-screen elements, tilt — how the player interacts with the play field.
- What is fixed: setting, character, graphics style — and where we are free in decisions.
- Materials: existing work, interface sketches, graphics files, if they already exist.
- Team communication: who on your side makes decisions and in which channel we discuss edits.
This is enough to discuss the task substantively and lock the scope: what is included in the prototype, what we validate at each iteration, and by what sign we consider the mechanic confirmed.
Then we send an estimate and work plan with stages and a project start date — after approval, we begin immediately.