Plan and test game mechanics

A mechanic needs an observable rule: an action, a change in state and feedback to the player. Before adding more systems, test whether the first action, win condition and restart work together. The existing guides below provide the starting workflow and debugging checks.

Open Mechanics collection ↗

Prepare a game for publishing

Publishing starts with a game that can be tested, understood and maintained. Check the available creator controls, audience settings and safety requirements before a release. Use the publishing guide for the sequence, and the troubleshooting guide for an actual blocked step.

Open Publish collection ↗

BC-0293 · TROUBLESHOOTING

Editorial review 2026-09-27

Build Game Has Low Retention

Low retention needs a comparable cohort and enough elapsed time to observe the return being measured. Then ask what useful experience a returning player can actually resume or discover. Do not confuse a long initial session, a reminder click or intended saved progress with a verified reason to return.

Symptom

A return-visit measure is weak or the creator cannot identify a useful repeat-play task.

Immediate action

Confirm comparable cohort opportunity before diagnosing the game's return value.

Diagnostic branches

The observation window is incomplete or populations differ.: Wait for comparable evidence or report the comparison as inconclusive.
A real return task exists but is hard to resume.: Inspect the return context and next-action guidance.
No meaningful additional visit is intended.: Decide whether extension serves the game instead of imposing artificial recurrence.

Least-destructive change

Improve a genuine return experience without fabricated urgency, unsupported persistence or reward coercion.

Retest

Cohorts had equivalent opportunity to return.
The promised repeat task actually exists in the current game.
A local design improvement is not reported as measured retention uplift without data.

Escalation

Use official analytics definitions and a focused return-session observation where available. A universal retention target or ranking gain is not established by this guide.

Working notes

Read the retention measure's actual definition and compare cohorts with equivalent observation opportunity. A recently acquired group may not yet have reached the relevant return window. Keep acquisition source, game version and reporting limits visible rather than treating an incomplete cohort as confirmed failure.

Identify the return proposition in the actual game. A returning player might face a meaningful new choice, improve a learned skill or continue a clearly supported objective. Merely adding a streak label or larger reward does not establish value, and this guide does not assume generated persistent storage or scheduled content exists.

Inspect the return experience separately from the first visit. Can the player recognize what is available now and what their next action is? A repeated tutorial may frustrate familiarity, while missing context may make resumption impossible. Use observed behavior without promising that every player wants the same cadence.

Propose an improvement tied to a real return task and measure it only when comparable data exists. Do not use deceptive urgency, fabricated expiring rewards or forced check-ins to manufacture activity. An honest conclusion can be that the current compact game is designed for a complete visit rather than indefinite return.

Examples

Cohort error: a newly acquired group has not had the opportunity to complete the return window shown for an older group. The comparison cannot establish a retention decline yet.
Return-task audit: a player recognizes the completed route but finds no understandable next challenge. Decide whether a meaningful new task fits the design rather than adding a countdown with no real purpose.