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

Editorial review 2026-09-27

Prompt Broke the Win Condition

When a revision breaks completion, compare the goal now communicated to the player with the action that formerly satisfied it. A renamed objective, replaced required object or relocated destination can leave those contracts inconsistent. Decide which goal is intended before repairing the completion response.

Symptom

The visible revised goal and the required completion action no longer agree.

Immediate action

Decide whether the intervening prompt changed the objective itself or only its presentation.

Diagnostic branches

A cosmetic revision left labels or required roles inconsistent.: Align the player-facing contract while preserving the intended qualifying action.
The objective was deliberately replaced.: Define the new qualification and feedback instead of reinstating obsolete success.
The correct goal is satisfied but order affects recognition.: Use the separate order-sensitive completion diagnosis.

Least-destructive change

Make the intended objective, required role and completion response coherent without granting unconditional success.

Retest

The displayed objective corresponds to an available qualifying action.
The intended action reaches completion where safely observed.
An obsolete or unqualified action does not receive the new result.

Escalation

Keep the old and intended-new goal contracts for further repair. This comparison does not reveal internal goal flags or prove every completion sequence.

Working notes

Preserve the earlier observed success condition and the exact requested change. If the old condition was never verified, call it the earlier intended rule rather than a working baseline. Then identify whether the revision was meant to change the objective or only its presentation.

Read the current objective as a player would and compare its required objects and destination with the scene. A label that says deliver medicine while only the former tool crate exists is a contract mismatch. Do not manufacture a hidden item identity to explain it; the visible instructions and available action already disagree.

Choose which side needs correction. A cosmetic theme change should preserve the underlying intended qualification while keeping its new labels and objects coherent. A deliberate new objective requires updating the qualification and feedback together, not restoring old success simply because it once worked.

Check both the chosen qualifying action and a nearby nonqualifying case without farming outcomes. If the intended goal is satisfied but recognition depends on the order of otherwise correct steps, use the order-sensitive completion guide; that is a different question from whether the new objective and requirement agree.

Examples

Theme-only revision: parcels are visually restyled as rescue kits, but the instruction still refers to the former destination. Align the destination cue and carried-object role while preserving the intended delivery qualification.
Intentional objective change: the new brief replaces arrival with collection of a required set. Decide and test that new requirement; reopening the old arrival-only exit would restore the obsolete rule rather than the desired game.