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

Editorial review 2026-09-27 · Official sources conflict

Playtest Progress Does Not Reset

If test progress does not reset, specify which state should clear and which action is expected to clear it. An in-game retry, leaving a session and reopening a destination are different actions. Do not assume any of them guarantees a fresh project, cleared saved progress or a particular checkpoint rule.

Symptom

Progress remains or disappears contrary to the creator's intended rule after a particular retry or return action.

Immediate action

Name the actual action and the intended lifetime of each affected state before calling the result a reset defect.

Diagnostic branches

The expected carry-over rule is unspecified.: Resolve the design rule before requesting a repair.
The wrong action is being treated as a reset.: Compare the actual control's intended effect rather than assuming every return starts fresh.
Visible feedback clears but a related gameplay prerequisite does not.: Record the coupled state mismatch and prepare a bounded reset repair.

Least-destructive change

Preserve the project and intended retained progress; do not erase data or change accounts merely to force a fresh-looking state.

Retest

Use an existing observation or safe ordinary progress before checking reset; leave risky reproduction untested.
Intended retained and cleared states are both inspected.
Reopening alone is not evidence of fresh state or persistent storage.

Escalation

For a reproducible game-rule mismatch, use the reset-repair guidance with the actual action and coupled state record. For entry failure before play, return to access diagnosis instead.

Working notes

Write the intended lifetime of each observed state: current attempt, a later attempt in the same game, or a future visit if the game intentionally defines that behavior. Keep the expected rule separate from observed behavior. This worksheet does not confirm that Build generated storage or that reopening uses persistent data.

Trace the action actually taken. Did the player choose an in-game retry, finish and continue, leave, or open the destination again? Name the visible control rather than calling all of these a reset. A retry that intentionally retains a checkpoint should not be judged against an invented full-wipe rule.

Inspect coupled state after a meaningful attempt: carrying flag, collectible availability, completion cue and allowed actions. A visible score returning to its starting value does not prove the required item is available again. Conversely, a cosmetic panel remaining visible may be a feedback defect even when the game state cleared.

If the intended lifetime is unclear, settle the design rule before requesting a repair. If the rule is clear and the observed sequence violates it, prepare a bounded request preserving intended carry-over. Do not promise that closing the application clears state, delete the project, or use another account to simulate a clean result.

Examples

Attempt-bound rule: retry should clear carried cargo and restore attempt collectibles while retaining the intended checkpoint. Test all of those outcomes rather than only the score display.
Ambiguous rule: the creator expects a fresh start after reopening but never specified whether progress should survive a visit. Define the intended behavior before reporting an implementation defect.
Coupled failure: carrying feedback clears after retry, but the parcel stays unavailable. The apparent reset does not satisfy the complete attempt-state rule.