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

Editorial review 2026-09-26

Collectible Does Not Count in Build

When a collected object does not advance an objective, first check whether that object belongs to the objective's required set. Optional bonuses, decorative lookalikes and required objects can have different counting rules. Compare the authored role with the wording players see before changing pickup or scoring behavior.

Symptom

An apparently collected object does not advance a goal, and its membership in that goal's required set is unclear or disputed.

Immediate action

Compare the object's authored role with the exact requirement and the instruction shown to the player.

Diagnostic branches

The item is optional or decorative but the instruction implies it is required.: Correct the role cue or goal wording while preserving the intended membership rule.
An accepted item clearly belongs to the required set but receives no corresponding credit.: Record that specific excluded member and inspect its collection event without adding unrelated item roles.
The goal requires distinct members and the collected role is already credited.: Show the missing member rather than treating another already-satisfied role as a substitute.
The design and instructions never defined which objects belong.: Decide and explain membership before calling either outcome a counting defect.

Least-destructive change

Resolve the membership or instruction mismatch without making every object eligible or changing unrelated reward amounts.

Retest

A known required role and an optional role follow their different declared rules.
The instruction identifies what remains required, including distinct members when applicable.
A proven pickup failure is routed separately instead of being hidden by a broader eligibility rule.

Escalation

Carry the role comparison and exact goal wording into a focused repair. This does not establish hidden item identifiers, persistent inventory or which internal condition caused the mismatch.

Working notes

Write the membership rule in plain language: which object role advances this objective, which role gives an optional benefit, and which is scenery. Use the current design brief and visible instruction. If neither identifies the required set, the immediate problem is an undefined rule; do not reverse-engineer intended membership from whichever counter happens to move.

Compare an expected member with an expected nonmember under the same active objective, using existing observations or safe ordinary play. Ask whether the required item is excluded, the optional item is included, or both behave consistently but the label promises something else. You do not need internal object identifiers, hidden tags or repeated rewards to make this comparison.

A class-based goal and a unique-set goal also differ. Collect any marked supply is not the same instruction as collect each named ingredient. In a unique-set design, an additional example of an already credited ingredient may legitimately add nothing to completion. Make the remaining requirement visible rather than changing the system to finish after collecting unrelated extras.

Choose the repair by the mismatch. Correct membership behavior when a known required role is omitted; correct the instruction when optional items were never intended to advance that goal; or define the missing role rule before either change. If the object's required role is already clear and its pickup still fails, hand that event to the collection-lifecycle guide instead of expanding this investigation into reset or duplicate-credit mechanics.

Examples

Membership comparison: marked medicine parcel—required rescue supply; loose coin—optional bonus; painted crate—scenery. The instruction says rescue supplies. If collecting a coin leaves rescue progress unchanged, that is consistent with this rule; a clearly accepted medicine parcel that does not advance it is the candidate defect.
Unique-set case: the recipe needs a leaf and a mineral. Another leaf after leaf credit is already shown does not substitute for the missing mineral. The useful correction may be showing the unmet ingredient, not crediting every pickup toward completion.
Proposed repair for an instruction mismatch: Keep coins as optional bonuses and medicine parcels as rescue requirements. Label the goal as rescue supplies and distinguish those parcels visually. Do not make bonus coins satisfy rescue progress merely to make every collection change that counter.