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

Editorial review 2026-09-27

How to Tell Build What Must Not Change

Tell Build what must not change by naming working behaviors and the conditions in which they matter. Avoid a blanket preserve everything instruction that contradicts the requested edit. A useful preserve list distinguishes fixed requirements, allowed changes and dependencies that need a deliberate decision.

Symptom

A revision changes working behavior because preservation boundaries were missing or incompatible with the requested edit.

Immediate action

Separate proven fixed behavior, permitted changes and unresolved dependencies.

Diagnostic branches

The preserve clause names a feature without its relevant behavior.: Add the actual action, condition and expected result to be checked.
The requested edit contradicts a frozen property.: Choose which requirement changes before sending the prompt.
A dependency is important but not yet observed.: Label it a requirement or pending check rather than a passed baseline.

Least-destructive change

Protect the working relationships that matter without freezing properties the edit must legitimately change.

Retest

Each fixed behavior has an inspectable acceptance condition.
Permitted changes and fixed requirements do not conflict.
Unverified preservation is reported honestly after the revision.

Escalation

Use the explicit boundary list if a repair still affects unrelated behavior. It does not establish a built-in preserve mode or guarantee that every dependency is covered.

Working notes

Start from behavior actually observed to work. Record the action, qualifying state and result rather than only naming the feature. Preserve movement is less precise than retaining the current response to press and release while the new outcome panel is closed. If the behavior has not been checked, label it a desired requirement, not a proven working baseline.

Mark what the new request is permitted to change. A larger visible destination marker can coexist with a preserved passable route, but a request to move the destination cannot also freeze its exact location. Resolve this contradiction before sending instead of asking the generator to guess which clause wins.

Include dependencies that are easy to miss. Changing a collectible's appearance may still need its existing objective role and feedback. A new shortcut may affect the deliberate gate that makes delivery meaningful. The list should protect those relationships, not merely the original colors and labels.

Use the preserve list as acceptance checks after the edit. A message saying everything else is unchanged is not evidence that those behaviors survived. Keep the list short enough to inspect honestly and route broader unverified coverage into a separate test plan rather than claiming exhaustive preservation.

Examples

Preservation row: destination marker appearance may change; delivery qualification and passable approach remain fixed; exact location is fixed unless the current request explicitly moves it; verification uses the same qualifying delivery state.
Conflict resolution: if a requested new route necessarily bypasses the old gate, decide whether to preserve the gate's purpose through a different relationship or reject the shortcut. Preserve everything does not resolve that design choice.