Why a hyper-casual game does not reach the top by installs
The prototype of a hyper-casual game is assembled: the core mechanic works, levels are generated, the build passes moderation and appears in Google Play.
Installs are coming in, but on the second or third day the funnel collapses: return rate drops below 20%, the average session is under a minute, and the numbers go no further.
The cause is usually not advertising. Traffic buying algorithms evaluate the behavior of the first sessions: if a player does not return the next day, the system classifies the audience as weak, and the cost per install grows faster than the player base.
It becomes a vicious circle — buying volume is increased, while low retention and rising cost pull the project down.
Prototype failure is almost never in the graphics.
What breaks is the link "first action — first success — next launch": the player does not understand the goal within 5-10 seconds, the difficulty curve on the third to fifth level hits the beginner, and they leave before the mechanic has time to unfold.
Mechanic testing is needed exactly here — on behavior, not on a subjective "it plays interestingly."
Next, we break down how to get out of this state: which metrics to capture on the prototype, how to separate the retention problem from the traffic problem, and at what point to scale buying.
What a hyper-casual game with a tuned iteration loop gives you
A tuned iteration loop is not "many iterations" but a fixed hypothesis route: the mechanic is described in words and target numbers, a game prototype is assembled on one level, and only then is it decided whether to develop it or close it.
One development iteration does not touch progression, the store, or analytics — only the node being tested changes, so assembly and measurement take days, not weeks.
The main measurement of the loop is retention of the first sessions. We look not at the average figure but at the curve: the share of players who reach the second session, the length of the first session, drop-off points on the first levels and at the first difficulty increase.
If the drop-off is on a specific screen, the cause is usually in the balance or in the explanation of the rule, not in the traffic source — and this is fixed by the next build.
Mechanic hypotheses are tested one at a time and in order of impact: first controls and goal, then reward pacing, then progression and ad placements.
Weak ones are filtered out before large-scale assembly, when a fix costs one prototype rather than reworking levels, UI, and the reward system. The rule is simple: a mechanic without an increase in measurement does not go into production.
Testing speed becomes a manageable value. By the end of the loop, the team has a hypothesis log with results, a metrics dashboard for first-session retention, and a clear cutoff criterion.
The client sees not a "we did it" report but dynamics: which mechanics were kept, which were closed, and at which measurement this was confirmed.
Work formats: ready-made core, turnkey prototype, hybrid
The format is chosen by one criterion: how many iterations separate the team from the first launch on ad traffic and how much the mechanic diverges from proven references.
A ready-made mechanics core removes risks in physics, controls, and input response, but immediately imposes template limitations; a turnkey prototype removes limitations but adds scope of work before the first build.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made mechanics core | The hypothesis is tested in a familiar genre: runner, stacker, puzzle solving | Ceiling in depth: unique level conditions and progression require rewriting logic layers |
| Turnkey prototype | The mechanic itself is the hypothesis — custom physics and non-standard gesture response are needed | Longer to first build, higher chance of missing retention targets |
| Hybrid development | The core is unique, while analytics, ad placements, and onboarding are standard | More integration points: module versions must be kept compatible with the core |
| Full cycle | The launch has already produced a workable cost per install and it makes sense to grow content | Justified only after a confirmed hypothesis, otherwise errors are scaled |
How the formats fit together
We assemble all options on a single event contract: analytics and internal level logic connect to the core through a shared layer, so the transition from prototype to release branch does not require rewriting.
We keep the engine branch on the current LTS branch of Unity so that ready-made modules and the core do not diverge during updates, and first-launch metrics can be compared directly with release metrics.
How the work proceeds: from hypothesis to source code handover
The work proceeds in stages, and after each one there is a decision point: we confirm the hypothesis with data or close it before weeks are invested in it.
The order is the same for a single mechanic and for a series of prototypes — first reference audit, then scheme and assembly, and only then testing on a live install flow.
-
Reference audit. We analyze 8–12 games in the genre: the loop of one session, the difficulty curve, the moment of the first reward, and the places for ad placements. The output is a table of mechanics marked "take / adapt / discard."
-
Mechanics scheme and math. We fix the time to first success, the difficulty step, and reward points. We calculate balance in tables: how many levels the average player passes and where they drop off.
-
Prototype development stages. We assemble a playable build on gray placeholders: one mechanic, about ten levels, minimal visuals. This tests the mechanic itself, not the quality of the artwork.
-
Analytics instrumentation. Events for session start, level completion, progress, and ad impressions. Without them, the install flow gives numbers without causes, and it is unclear what exactly to tune.
-
Testing on an install flow. A limited launch on real traffic: day-one retention, session length, progression depth, and the share of players reaching the key screen.
-
Decision on the success metric. If the numbers hold the bar set before launch, we scale and grow content. If not, we record which hypothesis failed and change the mechanic, not the graphics.
-
Handover. Source code, builds for target platforms, balance tables, analytics event map, and build instructions — the client's team continues the work without us.
What you keep: builds, analytics, procedures
Project handover is not an archive with code and a link to a build. For a hyper-casual game, we hand over a package with which your team or a new contractor can assemble a release, see player behavior, and ship an update without us. Below is the list of what is recorded in the acceptance act.
- Source code handover — a repository with full change history, release branches, and comments on key modules of the game loop.
- Rights to the build — a signed release published in app stores under your developer account.
- Access and ownership — publishing accounts, signing keys, and settings are re-registered to your organization rather than remaining with us.
- Configured analytics — events, funnel from impression to first session, reports on retention by day and acquisition costs.
- Project documentation — architecture, progress storage scheme, level balance description, and release build instructions.
- Update procedure — the order for releasing fixes for new system versions, review timelines, and the rule for rolling back to the previous release.
- Acceptance checklist — a set of checks confirming that the build, analytics, and access work on your side already.
Each item is closed by a test, not a signature: you build the release from source and verify that events reach the reports.
Project breakdown: metric dynamics before and after fixes
A playable prototype of a hyper-casual game came to us: the basic loop "launched — passed — failed — repeated" worked, but on the first test buys the cohort left almost immediately.
Measurements via Adjust showed the same picture on all attempts: a significant share of players did not survive to the first win. Onboarding took more than a minute, and the first loss occurred on a level where the rules were not yet clear.
What we reworked in the mechanic
We removed the tutorial screen and moved familiarization with the rules into action — the first win now fits within 15 seconds. We rebuilt the difficulty curve: failure occurs after two consecutive successes, not on the first level.
A one-tap restart appeared on the loss screen, a progress bar to the next reward was added, and a bonus for returning on the second day was introduced.
| Metric | Before fixes | After |
|---|---|---|
| Day-one retention | 24% | 37% |
| Day-seven retention | 4% | 9% |
| Average session length | 2.1 min | 4.3 min |
| Return within two days | 18% | 34% |
The rework touched only the motivation and presentation layer: the core and level system remained the same, so the next buying cycle was launched without rebuilding the project.
Metric dynamics in such a case almost always hinge on the first 60 seconds and the moment of the first loss — the amount of content at launch has a much weaker effect.
How does a test prototype differ from a full build?
A prototype and a full build are different tools, and confusing them is expensive. A prototype tests whether the game loop itself hooks players and answers that question in a matter of weeks.
A full build tests something else: whether the mechanic can withstand a paid traffic flow and pay it back.
Timelines for a prototype are short — two to four weeks, because the visuals are tentative and some systems are replaced with placeholders. A full build takes many times longer: meta-progression, ad placements, in-app purchases, and event tracking are added.
The differences in the accuracy of conclusions are fundamental. A prototype shows whether the loop is interesting but does not confirm payback: without real art and ad networks, the cost-per-install (CPI) test gives a skewed picture.
Therefore, not everything moves into the full build — the mechanics framework, balance of the first levels, and event tracking, while visuals and economy are assembled anew.
Frequently asked questions about mechanics, analytics, and handover
Decisions on mechanics are made not "by taste" but by numbers: the prototype has a set of events — first session, its length, level completion, return the next day.
A branch does not go into the release build until it delivers stable growth of the key metric on a short traffic segment.
Rights transfer is fixed before the start, not after: source code is stored in your repository, store publishing, the analytics dashboard, and ad accounts are registered to you.
We work as a contractor, not as an account holder — this removes half the questions when changing contractors.
We already have a prototype — can it be improved?
We look at the build, the screen structure, and which events it already sends. If the foundation allows adding mechanics and connecting analytics, we develop it.
If not, we move the logic into a clean codebase: this is usually faster than fixing someone else's architecture, and we separately agree on the scope.
Who owns the source code and accumulated data?
You. The source code, level configurations, and accumulated events remain on your side; we transfer access upon completion of the stage. Data from one project is not reused in others — this is stipulated in the contract and technical specifications.
How do mechanics change after testing?
We test hypotheses one at a time: we change a specific parameter, keep the others unchanged, and see how the metric reacts. This shows what exactly produced the effect and what simply coincided with traffic growth.
Let's discuss the task: what to send for an estimate and plan
A concept in the form of a description, references, and a couple of screens is enough for us to come back with an estimate of the scope of work and a plan for the first loop.
Below are the inputs that widen the estimate range the most: the more completely they are covered, the fewer clarifying iterations.
- Gameplay core: key mechanics, round duration, loss condition, and what pulls the player into the next run.
- References: 2–3 benchmark games and what matters in them — pacing, difficulty curve, presentation.
- Art and content: 2D or 3D, number of levels and assets, whether source files exist or we build from scratch.
- Platforms and regions: app stores, minimum OS versions, screen orientation, launch geography.
- Monetization and analytics: ad formats between rounds, in-app purchases, list of events for funnel and retention.
- Access and test criteria: store accounts and ad accounts, as well as the metric we consider success and at which we scale.
Next is a discussion of the task: a short call, after which we send a stage-by-stage work plan, timelines, and team composition for the first loop. Describe the task in free form — we will clarify what is missing ourselves.