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

Editorial review 2026-09-27

Use Expected vs Actual to Fix a Build Game

Write a repair prompt as the relevant starting state, action, expected result and actual observation. Keep explanations of hidden causes out unless independently established. The useful difference is what the player can observe, not a guess about which internal component must be broken.

Symptom

A repair request says the game is broken without identifying a testable expected-versus-observed difference.

Immediate action

Write the relevant starting state and action, then separate expected result from actual observation.

Diagnostic branches

The expected rule was never chosen.: Decide the design requirement before calling the output a defect.
The actual field contains only a guessed internal cause.: Replace it with the player-visible result and keep the hypothesis separate.
The proposed repair would also change a valid contrasting state.: Add that preservation boundary without prescribing unconditional success.

Least-destructive change

Request correction of the demonstrated behavior boundary without replacing unrelated systems.

Retest

The same safe sequence can evaluate the intended change.
The contrasting valid state remains part of the acceptance criteria.
Unperformed reproduction and uncertain causes remain labeled.

Escalation

Use the behavior record for further inspection or assistance. It is not proof of an internal root cause or a guarantee that a corrective prompt will succeed.

Working notes

Describe the shortest safe sequence that reaches the discrepancy. Include a prerequisite if it changes the result, such as carrying the required object or returning from an outcome panel. Do not make a reader reproduce purchases, lost progress or destructive actions just to fill in a report.

State the expected result from the chosen game rule. If the rule was never defined, make that a design question rather than a bug assertion. The actual field should contain what happened, including no visible response, not a restatement that the feature is broken.

Separate observation from interpretation. The gate remains closed after delivery is an observation; a missing internal listener is a hypothesis. Request the intended boundary correction and preserve the working pickup or route without requiring an implementation diagnosis that the creator cannot verify.

Add a contrasting case when it helps distinguish the rule. A gate that must stay closed without delivery should not become always open as a repair. Keep proposed checks and actual completed checks visibly separate, especially when the contrast would be unsafe to reproduce.

Examples

Repair record: starting state—carrying the required parcel; action—use the marked delivery destination; expected—delivery feedback and usable exit; actual—feedback appears but exit stays closed; preserve—the current pickup and route. This is a hypothetical record to replace with real observations.
Unsupported cause removed: replace fix the broken event listener with the observed qualification and result. An inspectable implementation workflow may later identify a cause, but the initial behavior report does not establish it.