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

Editorial review 2026-09-27

Build UI Is Inconsistent

UI inconsistency becomes a usability problem when the same label means different actions or equivalent actions appear under unrelated names. Compare control meaning and return behavior across actual screens before standardizing appearance. A menu close action and a round restart should not become interchangeable merely because both look like leaving a panel.

Symptom

Control labels, effects or return behavior disagree across the interface in ways that mislead the next action.

Immediate action

Compare label, consequence and return contract before changing colors or positions.

Diagnostic branches

The same label causes different consequences.: Differentiate the labels and disclose the actual state effect.
Different labels perform the same established safe action.: Choose consistent language while preserving the real destination.
An effect is unknown, paid or destructive to inspect.: Keep it unresolved and avoid diagnostic activation.
The element belongs to platform UI rather than the game.: Respect that boundary instead of promising a game prompt can rename it.

Least-destructive change

Align action meaning and truthful labeling before applying cosmetic uniformity.

Retest

Each label predicts its actual safe observed consequence.
Equivalent actions share understandable wording where appropriate.
Return and progress-retention differences remain explicit.

Escalation

Use the action-vocabulary comparison for a focused repair. No hidden navigation architecture or safe execution of untested risky controls is assumed.

Working notes

Build a short action vocabulary from the interface actually present. Record the label, destination or effect, state where it appears and what happens to current progress. This makes a misleading Continue label visible when one instance resumes play and another starts a fresh attempt.

Decide whether the actions are truly equivalent. If they have different consequences, clarify their names and supporting text instead of giving them the same label. If they perform the same safe action in different panels, consistent language can reduce unnecessary interpretation without changing their destination.

Check the return contract as well as the forward action. Back may mean returning to the previous menu, dismissing help or abandoning a round; those differences matter. Do not activate destructive or paid actions to complete the vocabulary table. Use existing evidence or leave their effect unresolved until it can be inspected safely.

Apply presentation consistency only after the meaning is settled. Matching colors and positions cannot repair a mislabeled progress-losing action. Preserve legitimate disabled-state explanations and platform-provided controls; this guide does not assume that every visible interface belongs to the game creator.

Examples

Meaning conflict: Continue closes an optional help panel in one view but starts a new attempt in the outcome view. Use labels that express resume versus new attempt, with the actual retention consequences kept clear.
Equivalent action: Help and Instructions both open the same game-owned reference panel from comparable states. If they really have the same destination and return behavior, choose consistent wording without altering the underlying action.