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

Editorial review 2026-09-26

Build Changed the Wrong Thing

If a prompt changes the wrong object, verify whether the requested target was uniquely identifiable in the current scene. Use role, location and relevant state together, then state which similar elements must remain unchanged. Avoid requesting a broad change to every matching object as compensation.

Symptom

A requested change appears on another object or affects additional lookalike elements.

Immediate action

Identify both the intended and actual changed targets using observable roles and landmarks.

Diagnostic branches

Several objects match the original description.: Add a stable role or landmark that distinguishes the intended target.
The identifying property is itself being changed.: Use an unaffected role or location instead of relying on that property alone.
The intended target is repaired but another remains unintentionally changed.: Track restoration of that separate affected target rather than assuming it happened.
The previous state is not documented.: Specify the desired state honestly as a design choice, not verified restoration.

Least-destructive change

Clarify the affected target and exclusions instead of issuing a scene-wide replacement.

Retest

The intended role can be identified without hidden object IDs.
The requested behavior is checked on that target.
Previously affected and excluded elements are inspected separately.

Escalation

Carry the target comparison into an inspectable editing workflow if repeated ambiguity remains. No exact object-selection API or automatic restoration is assumed.

Working notes

Compare the intended target and the changed target side by side. A request about the gate may be ambiguous when the scene has an entrance gate, a goal gate and a decorative fence. Record what actually changed, rather than assuming the generator selected an internal object with a particular name.

Choose an observable anchor that remains stable during the repair. A role such as the gate blocking entry to the workshop is stronger than a color that the same prompt asks to change. Location alone may also become ambiguous if the scene layout moves. Combine only the cues needed to identify the target reliably.

Separate the positive change from the exclusion. The intended goal gate should open after delivery; the entrance gate and decorative fence retain their current appearance and behavior. This is not an instruction to freeze the whole scene or a guarantee of object-level selection support; it is a clearer requested boundary.

Inspect the mistakenly changed element after the correction as well as the intended one. Fixing the intended gate does not automatically restore the unrelated entrance. If you lack evidence of its earlier state, state the desired restoration as a new explicit design decision rather than pretending to recover a known original.

Examples

Target distinction: the gate beside the delivery desk, which controls exit after the parcel arrives, is not the entrance arch near the start. Name the function and landmark rather than referring only to the blue gate when its color is being revised.
Correction request: Change the delivery-exit gate's opening condition only. Preserve the entrance arch and the workshop door. Also compare the entrance arch with the recorded pre-change view because it was modified in the last result.