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

Editorial review 2026-09-26

Mobile Controls Block the UI

If moving a covered mobile HUD element merely covers something else, treat the problem as a competition for limited space. Keep platform controls and necessary safety UI intact, then decide which game-owned information must stay visible now, can be combined, or can wait for a non-active view. A layout change is incomplete if it makes the next required action inaccessible.

Symptom

An important mobile HUD element is covered, and the obvious relocation conflicts with another necessary element.

Immediate action

List fixed control regions and classify the competing game-owned information by when the player needs it.

Diagnostic branches

Competing labels repeat the same immediate information.: Combine them only if the readable summary preserves the decision-relevant meaning.
Optional detail can wait and a suitable reachable view exists.: Move the detail there and verify its actual open and return actions.
The proposed destination or panel is not implemented.: Keep deferral marked as a design requirement, not a completed repair.
Required information still cannot fit without covering controls or warnings.: Leave the constrained layout unresolved and redesign game-owned presentation without removing legitimate platform UI.

Least-destructive change

Recover space from redundant or genuinely deferrable game-owned information before displacing immediate feedback or controls.

Retest

No retained immediate signal becomes unreadable during the actual held action.
Deferred detail has an implemented reachable destination and a working return action.
Changed goals and outcome states preserve their required information; untested devices stay unverified.

Escalation

Keep the unresolved constraint and disposition record when no safe arrangement exists. This does not establish universal safe-area dimensions, a platform-control removal method or a passing physical-device test.

Working notes

First separate fixed constraints from editable content. Record the actual control-and-finger area and legitimate platform overlays on the tested device. A game-owned label can be redesigned; that does not establish permission or an API to remove platform controls. Do not assume that rotating the device or changing a safe-area setting is available.

Assign each competing game-owned element a decision time. Health during an approaching hazard and the current objective may be needed during play; a completed-task history may only be needed afterward. Use a concrete consequence for deferring it: would the player make an uninformed immediate decision, or merely lose access to optional detail until later? This makes prioritization testable instead of calling every label essential.

Consider combination and deferral before another relocation. Duplicate status labels can become one readable summary if meaning is preserved. Optional detail can move to an existing reachable non-active view only if that view really exists and its return behavior is known. If no such view exists, record the missing design requirement; do not claim that hiding text or adding an unspecified menu solves it.

Check the constrained result in each relevant state. A compact goal summary must still express a changed objective, and an outcome panel must leave its real next action reachable. If all remaining elements are genuinely required simultaneously and cannot fit legibly, the resolution is a game-interface redesign with unresolved acceptance checks, not smaller illegible type, a hidden hazard cue or disabled platform UI.

Examples

Constraint decision: health and the next rescue target are needed during active play; the already-completed rescue log is reference material. If a usable results view already exists, retain a compact current-target summary and show that log there. If it does not exist, mark the deferral option unimplemented rather than deleting the log and declaring success.
Failed relocation: moving a covered health label to the top hides the only route warning. This exchanges one immediate-information failure for another. Remove duplicated optional text first, preserve both required signals, and leave the layout unresolved if no readable arrangement remains.
Disposition record: element / game-owned or platform / decision time / consequence if deferred / retained, combined or moved / actual destination / return action / untested state. It ends with a justified layout decision rather than a generic move-away instruction.