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

Editorial review 2026-09-27 · Official sources conflict

Playtest UI Is Broken on Mobile

For a broken mobile test interface, identify the game phase and the exact useful element that becomes unreadable, unreachable or covered. Inspect the layout while the relevant panel is open, not only the clean opening screen. Repair the collision without removing the information needed to act.

Symptom

A mobile game interface becomes unreadable or blocks a required interaction in a particular phase.

Immediate action

Record the obstructed element and the overlay or phase that produces the collision.

Diagnostic branches

The target is covered.: Resolve the competing space requirements while preserving the necessary action and information.
The target is readable but its meaning is unclear.: Revise the instruction or label rather than merely moving it.
The failure appears only after a panel opens or closes.: Inspect that transition and the restored interaction state.

Least-destructive change

Make a phase-specific layout repair instead of replacing the whole interface or shrinking all controls.

Retest

Opening, affected phase and return are inspected separately.
The repair does not create another obstruction.
Unobserved devices remain untested rather than assumed equivalent.

Escalation

Provide the phase and collision record for a bounded UI revision. If entry itself fails, use access guidance instead of layout diagnosis.

Working notes

Capture the actual arrangement at the failure: control, objective, progress cue, game target and any active overlay. Distinguish a hidden control from visible text that the player cannot interpret, and from a target that is visible but rejects the intended action. They require different revisions.

Inspect transitions that add interface elements. A result panel, instruction card or expanded objective can occupy space that was free during ordinary movement. The opening layout can pass while the outcome or return layout blocks play. Do not infer that all phases are usable from an empty scene.

Resolve competing needs explicitly. If moving the control covers the target, relocation alone is not a complete repair. Decide which information must remain visible during that phase, which can be shortened faithfully, and which can appear after the action. Do not reduce a necessary touch target merely to fit more decoration.

Retest the phase transition and the return path. Closing a panel should restore the intended controls and instructions; hidden old panels must not leave the player with unexplained blocked input. Keep unavailable devices and orientations marked untested.

Examples

Phase collision: normal movement is readable, but the completion panel covers the retry control. Fix the outcome arrangement and verify return to play, rather than moving every control globally.
Information tradeoff: a long objective overlaps movement input. Preserve the actual required action in a shorter instruction; do not delete the objective and call the uncluttered screen usable.