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

Editorial review 2026-09-27

Prompt Broke Mobile Layout

For a mobile layout regression, compare the same available device, orientation and game state before and after the prompt. Identify the new element or changed text that displaced previously usable information. Preserve the useful addition while restoring the affected layout relationship; a desktop screenshot cannot prove the touch layout recovered.

Symptom

A prompt's new content displaces a previously usable mobile relationship under comparable conditions.

Immediate action

Match device, orientation, state and visible content before isolating the added space demand.

Diagnostic branches

The before-and-after conditions differ materially.: Mark the comparison uncertain instead of claiming a demonstrated regression.
A new label or panel displaces an existing necessary action.: Preserve its useful meaning while repairing that specific layout relationship.
Every proposed relocation conflicts with other immediate information.: Use the constrained-layout disposition rather than indiscriminate shrinking.

Least-destructive change

Repair the affected game-owned relationship without discarding valid information or platform controls.

Retest

The same actual affected state is checked with the new content present.
The required action remains readable and reachable where observed.
Viewport approximation and real-touch coverage are reported separately.

Escalation

Keep the matched captures and unresolved state coverage. This does not imply a universal safe area, a platform-control setting or proven compatibility on every phone.

Working notes

Use an actual earlier capture or recorded touch sequence when available. Different viewport, orientation, text length or menu state can explain a visual difference without proving a regression from the prompt. Keep these conditions separate and do not invent a prior passing device test.

Locate the added demand on space. A new objective line, status badge or expanded outcome description may push an existing action away; a larger object can obscure the route while leaving the HUD unchanged. Describe the first displaced relationship instead of labeling the entire phone layout broken.

Restore that relationship with a bounded presentation change. Preserve the meaning of new information rather than deleting it blindly, and keep legitimate platform UI intact. If relocating it causes another important conflict, use the constrained-layout guide to decide what can be combined or deferred; do not shrink everything until it technically fits.

Inspect the same state with the new content actually present, then the relevant changed or longer label. A fix that works only before the new objective appears misses the regression. Record any unavailable physical-device check separately from a viewport approximation.

Examples

Matched comparison: same device and outcome panel, before and after adding the long next-stage description. Retry was previously reachable and is now displaced. Preserve the useful next-stage information while restoring a readable, reachable next action.
Unproven regression: an old portrait image is compared with a new landscape viewport and different objective text. Record those differences first; do not attribute every shift to the latest prompt.