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

Editorial review 2026-09-27

Prompt Broke Restart

When a newly added mechanic breaks a previously working restart, assign that mechanic an explicit attempt, session or other authored lifetime. The old reset checklist may never have included the new state. Extend the contract deliberately instead of asking to clear everything or assuming the prior reset automatically covers the addition.

Symptom

Restart worked before a new mechanic introduced state or effects not covered by the original reset contract.

Immediate action

Identify the added state and choose its intended lifetime at the existing restart boundary.

Diagnostic branches

The new state belongs only to the current attempt.: Specify its fresh value and end its old-attempt effects coherently.
The new state represents legitimate longer-lived progress.: Retain its usable dependencies rather than clearing it indiscriminately.
The restart no longer reaches any new attempt.: Diagnose the transition first instead of guessing a fresh-state value.

Least-destructive change

Extend the existing reset contract only for the added state and necessary dependencies.

Retest

The new state's behavior matches its chosen lifetime.
The next objective remains achievable from the fresh state.
Previously working reset and retention responsibilities remain intact.

Escalation

Carry the added-state dependency record into further repair. This does not establish storage persistence or guarantee that a generic reset instruction covers future mechanics.

Working notes

Identify the state introduced by the intervening prompt: a temporary shield, carried ingredient, activated switch or newly unlocked route. Compare it with the original restart inventory. If the addition is not represented, decide whether it should be removed, restored, retained or made inactive when the next attempt begins.

Trace dependencies as well as the new value. Clearing a carried ingredient while retaining a gate that requires that ingredient can produce a different problem from simply forgetting to reset a label. Conversely, clearing a session-long route unlock merely because a new attempt begins may erase legitimate progress. The fresh state must remain coherent.

Preserve the existing reset responsibilities that already worked. Add a narrow rule for the new state and its visible effects; do not recreate all movement, score and scene behavior in the same request. If the restart action itself no longer reaches a new attempt, use that transition diagnosis before deciding which fresh-state value is wrong.

Inspect the new mechanic's actual boundary and the unchanged baseline where safe. A shield label disappearing does not prove that its protection ended, and a retained route label does not prove the route remains usable. Check the required behavior without forcing valuable progress loss or repeated rewards.

Examples

New-state contract: a temporary shield introduced by the last revision lasts for the current attempt. On the existing Retry, its indicator and protection end while the established session route unlock remains available.
Dependency check: if the new attempt resets the carried ingredient, the objective must still provide a legitimate way to obtain what its next required gate needs. Retaining the gate's requirement while removing every source creates an incoherent restart.