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-0251 · TROUBLESHOOTING

Editorial review 2026-09-27 · Official sources conflict

Playtest Progress Is Lost

When test progress seems lost, compare the state before leaving with the state after returning, then identify what the game was actually intended to retain. An earlier visible score is not proof that it was saved. Preserve the observation without claiming a storage failure, recovery option or refund that has not been established.

Symptom

Previously visible game progress is absent on a later return.

Immediate action

Preserve the before-and-after observations and the intended state lifetime before making a data-loss claim.

Diagnostic branches

The lifetime was never specified.: Define the future requirement while leaving past storage behavior unconfirmed.
Project, version or round context differs.: Reconcile that difference before attributing the outcome to missing storage.
A defined retained state is missing in a matched return.: Record the discrepancy and separate future repair from unconfirmed historical recovery.

Least-destructive change

Avoid overwrite, repeat-purchase and reward-replay experiments; retain the existing evidence.

Retest

Observed acknowledgement is not automatically labeled saved data.
The same project and intended lifetime are compared.
Future repairs are not presented as restoration of past progress.

Escalation

Use official assistance for a relevant account or transaction concern with its actual notice; for generated game behavior, provide the state-lifetime discrepancy without promising recovery.

Working notes

Separate completed actions from displayed acknowledgements. A reward animation, score change and completed goal can be different events. Record which were actually observed before the interruption and which remain uncertain; do not repeat a paid or reward-related action merely to reconstruct missing evidence.

Classify the expected carry-over: an attempt-only score, a checkpoint within a round, or progress intended to survive a later visit. A design intention is not proof of generated persistence. If the game never defined the lifetime, that is a missing requirement rather than confirmed data loss.

Verify the same project and relevant entry context. A different version or a fresh round can present a different starting state for reasons unrelated to storage. If identity and intended lifetime are clear but the result differs, retain the before-and-after evidence without assigning an internal cause.

Recovery and repair are separate questions. A later prompt might change future behavior but does not establish that previously missing progress can be restored. Keep any official notice or available record, avoid speculative overwrite operations, and describe what remains unknown.

Examples

Observation: completion feedback appeared before leaving; after returning, the opening objective is visible. This supports a changed visible state, not proof that saved data was deleted.
Requirement record: state—checkpoint; intended lifetime—within the current attempt; observed return action—new attempt. Losing the checkpoint may match the intended rule rather than violate it.