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

Editorial review 2026-09-26

Prompt Broke the Controls

After a prompt breaks a previously working control, compare the input context that changed: active play, an opened panel, a held action or the return from a menu. Preserve the new feature while restoring the old control's ownership in the right state. A generic request to fix all controls can hide which interaction now consumes or blocks the action.

Symptom

A recorded working input fails in or after a newly introduced interaction state.

Immediate action

Compare the old input sequence before, during and after the new state's actual use.

Diagnostic branches

The new panel legitimately owns input while open.: Preserve that separation and examine whether ownership returns correctly afterward.
An existing action was replaced by a different new action.: Specify distinct access or an explicit state-dependent rule.
Only a held-action transition fails.: Include release and return behavior in the targeted repair.

Least-destructive change

Restore the intended input ownership transition while retaining the new feature's valid controls.

Retest

The baseline input works in its intended state.
The new feature remains operable without input reaching the game beneath it.
Return and release behavior are checked on the actually available input method.

Escalation

Keep the state-transition comparison if the repair fails. It does not prove a focus, listener or platform input bug, and does not justify removing legitimate safeguards.

Working notes

Use the last working input sequence and the intervening prompt as the baseline. A newly added overlay or action may introduce a new state that the old control never had to handle. Record whether the problem exists immediately, only with that addition active, or only after it closes; do not infer a particular event handler from this timing.

State which interaction should own the input in each observed context. While a legitimate menu is open, a tap may belong to the menu rather than gameplay. After it closes, the ordinary movement action should follow the authored game rule. Removing all input blocking would be an unsafe repair if it makes menu taps activate the game underneath.

Keep the new feature's valid action separate from the restored old one. If a help control replaced an existing action by mistake, specify distinct clearly labeled access rather than requiring the same input to do both without a state rule. Do not use purchases, deletion or unknown external links to test a conflicting control.

Inspect entering and leaving the new state, including release of an action held before the transition where safe. A repair that works only on a fresh load may still leave movement stuck after returning from the panel. Device and input-method coverage must describe actual observations, not assumed parity.

Examples

Hypothetical regression record: movement worked before the help-panel revision; it still works before opening Help but not after closing it. Preserve the panel's useful instructions and restore the intended return-to-play input state rather than deleting Help entirely.
Ownership correction: During the actual open menu, its controls must not trigger the game underneath. After the existing close action, ordinary movement resumes; any prior held action follows the explicitly chosen release behavior.