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

Editorial review 2026-09-26

A Build Change Broke the Game

When a Build change breaks a previously working behavior, preserve the exact intervening prompt and the last observation that showed the behavior working. Reproduce the same safe scenario on the changed result, then request a bounded repair that retains the intended improvement. Do not promise rollback or overwrite the only remaining project.

Symptom

A behavior with a known or suspected earlier working state fails after a specific change.

Immediate action

Save the intervening prompt and distinguish actual prior evidence from an assumed baseline.

Diagnostic branches

No earlier observation establishes that the behavior worked.: Use ordinary symptom diagnosis and keep regression causality unconfirmed.
The same safe scenario now fails after the recorded change.: Request restoration of that behavior while retaining the intended improvement.
A real recovery control is available but its scope may replace later work.: Preserve the record and evaluate that actual scope before use; do not assume saved prompts are a restore point.
Several related behaviors fail after the change.: Use the multiple-regression dependency record before issuing a stack of independent repair prompts.

Least-destructive change

Repair the bounded regression and keep the current project rather than deleting it for an assumed rollback.

Retest

The original known-working scenario is restored under comparable conditions.
The intended improvement from the intervening prompt remains present.
Unobserved baseline behavior and unavailable recovery mechanisms remain explicit.

Escalation

Carry the before/prompt/after record to the relevant behavior-specific repair. No automatic undo, exact regeneration or complete backup is implied by this method.

Working notes

Distinguish a regression from a newly noticed old defect. A remembered expectation is weaker evidence than a recorded earlier sequence. Label the baseline as observed or uncertain, and include any changed starting conditions that could explain a different result without blaming the prompt automatically.

Separate the requested improvement from the new failure. If a visual update made a passage unusable, retain the desired appearance while describing the route behavior that must return. Asking to undo everything may discard useful changes and still not reconstruct the exact earlier game.

Inspect recovery options only if they actually exist and their scope is understood. A saved prompt, screenshot or iteration note is not a complete saved game version. Before using any available recovery operation, preserve the current record and consider what later work that operation would replace.

After the repair, run the same original scenario and the intended new behavior. A restored old action with a lost new feature is not the entire requested outcome. If the observed failures are numerous, stop stacking corrections and move to the multiple-regression dependency record.

Examples

Regression record: the doorway was traversable in the recorded earlier test; a decoration prompt was sent; the same approach is now blocked while the new appearance is present. This supports a scoped comparison, not a diagnosis of a particular collision property.
Proposed repair: Preserve the new doorway appearance. Restore the previously observed passable opening for the same player and route, without changing movement speed or the goal. Retest passage and the desired visual result together.
Uncertain baseline: the player did not try the reverse route before the update. Mark that earlier behavior unknown instead of claiming the prompt broke a path that was never inspected.