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

Editorial review 2026-09-26

Prompt Broke Checkpoints

A route revision can leave a checkpoint visually present but no longer useful: its activation may be unreachable or its return position may no longer lead to a valid continuation. Compare the checkpoint with the changed route, not only with its old marker. Do not trigger a risky failure to inspect a return location.

Symptom

A previously useful checkpoint no longer fits the route after a scene or progression revision.

Immediate action

Compare activation access and return continuation against the specific route change.

Diagnostic branches

The checkpoint's activation is now unreachable at the intended stage.: Restore a legitimate activation relationship or explicitly revise the checkpoint's stage.
Return arrives but continuation is blocked or unsafe.: Repair the return-to-route relationship rather than only the marker appearance.
Testing return would require losing valuable progress.: Use existing evidence and keep that acceptance check unperformed.

Least-destructive change

Restore a usable route relationship while preserving the chosen checkpoint-selection rule.

Retest

Activation remains reachable at its intended stage.
The return state supports a clear legitimate next action where safely observed.
The repair does not silently move the checkpoint's design role.

Escalation

Carry the route-change comparison into an inspectable workflow if needed. No lossless respawn test or exact coordinate-edit capability is assumed.

Working notes

Identify what the prompt changed around the checkpoint: moved platforms, a new gate, altered path or changed starting direction. Keep the previously observed checkpoint selection rule separate from the route geometry. A marker still lighting up does not establish that returning there leaves the next objective attainable.

Inspect activation access and return usability as different questions. The original activation point may now sit behind the gate it is meant to help the player cross. Or the activation still works, but the return location no longer connects to safe ground. Use existing captures or a safe ordinary continuation; avoid deliberate progress loss merely for the report.

Preserve the authored checkpoint rule while requesting a valid relationship to the revised route. If the design intentionally moved the checkpoint to a later stage, make that a declared change rather than silently restoring the old position. Do not assume coordinates, teleport controls or an edit API are available from a prompt.

Verify the continuation after the return, not just arrival. A visually correct position can face the player away from the only readable cue or lack the required route state. Record the first useful action from that point and whether its prerequisite remains available.

Examples

Route mismatch: a new workshop gate separates the checkpoint marker from the continuation it previously supported. The repair must make activation and return consistent with the revised route, not simply repaint the marker.
Return acceptance: from the intended checkpoint state, the player can recognize and take the next legitimate route action without needing a resource lost at the reset. Leave this untested if observing it would sacrifice valuable progress.