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

Editorial review 2026-09-26

Prompt Broke the Score

When scoring changes after a revision, compare the old earning event with the new actions added around it. A pickup, delivery and feedback animation can accidentally become competing interpretations of when credit is earned. Restore the intended event boundary instead of adjusting the displayed total to conceal a changed rule.

Symptom

A revision changes which visible event earns credit or how the earned result affects completion.

Immediate action

Compare the recorded old earning event with the stages introduced by the new prompt.

Diagnostic branches

A new feedback stage now coincides with unintended credit.: Retain the feedback while specifying that the original qualifying event owns that reward.
The revision intentionally introduced another reward.: Separate and label its purpose instead of silently merging both awards.
Only displayed text changed but completion behavior is uncertain.: Keep display and qualification checks separate before declaring scoring restored.

Least-destructive change

Restore the intended reward event boundary without erasing useful feedback or legitimate distinct bonuses.

Retest

Credit follows the deliberately chosen qualifying event.
Nonqualifying feedback does not silently award the same reward.
Completion responds to the intended earned state, or remains explicitly untested.

Escalation

Use the old-versus-new event comparison for further repair. This does not identify internal callbacks, secure economy behavior or a verified account balance.

Working notes

Record the earlier qualifying event and its observed result before reviewing the new prompt. If the earlier amount or qualification was never known, keep it uncertain. The new result cannot establish its own baseline just because its number looks plausible.

Break the revised interaction into observable stages and ask where credit now appears. A new carrying animation or delivery effect may coincide with an extra increase, but coincidence does not identify a hidden duplicate callback. The useful fact is which player-visible stage now changes the total compared with the intended earning event.

Choose the earning rule deliberately. If the revision intentionally adds a second distinct reward, label its purpose rather than treating all increased credit as a defect. If only the original event should earn, retain the new feedback but state that it must not independently grant the same reward.

Inspect the ordinary qualifying path and a safe nonqualifying contrast using existing observations where possible. Do not exploit a repeated award loop or introduce paid events to measure the discrepancy. A display-only repair is insufficient if the actual completion threshold still responds to unintended credit.

Examples

Hypothetical changed event boundary: credit previously appeared on parcel delivery; after adding a carry effect, it appears at pickup and again at delivery. Decide whether pickup is genuinely a new reward or whether it should remain feedback only.
Repair request: Preserve the carrying animation and delivery celebration. Award the delivery credit at the qualified delivery event, not merely when the carry effect starts; keep optional bonus rewards separate and labeled.