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

Editorial review 2026-09-26

Prompt Created Duplicate UI

Do not remove duplicated-looking UI until you know whether the elements have the same role and state. A live counter and an outcome summary may legitimately coexist; repeated active controls or contradictory displays need a clearer ownership decision. Identify which element remains before requesting cleanup.

Symptom

A revision produces repeated-looking labels, panels or controls that compete or disagree.

Immediate action

Compare each element's role, phase and meaning before choosing the survivor.

Diagnostic branches

The elements show different legitimate scopes.: Clarify their labels or phase placement rather than deleting useful information.
The same action appears redundantly in the same state.: Keep an explicit valid entry and remove the redundant presentation.
The apparent survivor has an unknown or risky action.: Do not activate it for diagnosis; define the intended safe role first.

Least-destructive change

Remove redundant presentation without deleting the underlying feature or legitimate alternate view.

Retest

Each remaining element has an unambiguous task and scope.
The intended destination and return path work where safely testable.
Reopening the relevant panel does not recreate the unwanted duplicate.

Escalation

Carry the role comparison into further repair. Visible duplication alone does not prove duplicate code, handlers or a particular UI architecture.

Working notes

Record where each element appears, which phase it belongs to and what information or action it represents. Similar labels do not prove redundancy. A carried-item count and delivered-item total can differ correctly, while identical retry controls active in the same panel may create an unnecessary or confusing choice.

Choose a surviving role, not merely the prettiest copy. Preserve the element whose action, label and current state match the intended task. If neither is clearly correct, define the required role before removal. Avoid clicking paid, destructive or unknown actions just to discover which duplicate is wired.

Specify the cleanup boundary: remove the redundant game-owned presentation or entry while retaining the valid destination and underlying behavior. A request to delete the score could be interpreted as removing scoring itself. Do not assume a shared implementation or diagnose repeated event listeners from visible duplication.

Inspect the relevant state transition after cleanup. A duplicate that disappears only until the menu reopens is not resolved. Conversely, intentionally separate results and active-play displays should remain available in their own phases without returning as conflicting simultaneous controls.

Examples

Role comparison: carried items during play and delivered items in the outcome view are not interchangeable. Clarify the labels if confused; do not remove one merely because both contain a number.
Cleanup brief: Keep the existing Retry action in the outcome panel and its fresh-attempt behavior. Remove the additional redundant Retry entry from that same panel; retain the separate Help destination and confirm the panel remains usable after reopening.