Should retry erase all progress?

Only the progress your attempt contract says to clear. An intentional checkpoint can remain, but distinguish it from temporary attempt state and verify that the restart location agrees with that choice.

Is deleting the project a way to reset a failed attempt?

No. A gameplay retry should operate within the project. Project deletion or rebuilding discards work and is unrelated to specifying how a player recovers from an in-game failure.

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-0030 · CORE GUIDE

Editorial review 2026-09-26

How to Define a Fail Condition in Build

Define failure as a specific event and decide what a new attempt resets. Separate temporary attempt state from anything deliberately retained, then verify the reset order before adding penalties or checkpoints.

Objective

Specify a failure-and-retry transition with a complete, inspectable reset inventory.

Before you start

Identify the exact event that ends an attempt.
List the temporary state used by the current objective.
Record any checkpoint or progress that is intentionally retained instead of assuming everything persists or disappears.

Steps

Distinguish terminal failure from a recoverable setback.
Write a clear player-facing explanation of the failure cause.
Make separate lists for state to clear, state to restore and state to retain.
Define the intended restart location and any checkpoint exception.
Inspect the transition with progress already accumulated, not only from an untouched starting state.
Repeat the same objective after retry to detect stale state or objects that were not restored.

Verification

The specified hazard ends the attempt, while the documented recovery area does not.
Further contact during the failed state does not stack additional failure outcomes.
The restart location matches the stated entrance or retained checkpoint.
Carried objects and attempt progress match the reset inventory after retry.
The result panel and temporary effects from the previous attempt are gone when interaction resumes.
The objective remains possible after restarting from a failed attempt.

Limitations

The reset inventory is editorial guidance to test against the actual generated game.
Saved progress across sessions needs separate persistence design and verification.
Fixing retry behavior does not diagnose unrelated account access, publication or moderation issues.

Working notes

Name what failed rather than treating every unwanted event as defeat. Falling outside the route might end an attempt; missing a collectible might only leave the objective incomplete. This distinction prevents a failure handler from firing when the player is still allowed to recover through ordinary play.

Create a reset inventory. Position, carried items, attempt progress, temporary effects and the active result panel may all need different treatment. If a checkpoint is intentionally retained, say so explicitly. Do not call a reset correct merely because the character moved back to the entrance while hidden progress remained unchanged.

Order the transition so the restarted attempt begins consistently. Stop the failed attempt from accepting more progress, clear the intended temporary state, restore the player and objects, then resume interaction. These are design requirements to inspect in the generated result, not a prescription for an undocumented internal Build API.

Keep failure feedback brief and specific. Tell the player what ended the attempt and where retry will begin. A large penalty is not a substitute for explaining a hazard. If the failure cause is visually unclear, improve that signal before trying to tune the punishment.

Examples

Reset inventory for a bridge route: restore the player to the entrance, return the carried parcel to its pickup point, clear delivery progress and dismiss the failure panel. Retain the level layout. There is no saved checkpoint in this version, so an old safe location must not override the entrance.
Recovery distinction: touching water ends the attempt; stepping onto the side platform does not. From the side platform the player can return to the route. The failure rule should follow these explicit boundaries rather than treating any unexpected position as a reset trigger.
Repair brief after a stale-state observation: Retry places the player at the entrance but leaves the parcel marked as carried. Preserve the route and controls. Restore the parcel and clear carried state as part of restarting the failed attempt, then check collection and delivery again.

Common questions

Should retry erase all progress?: Only the progress your attempt contract says to clear. An intentional checkpoint can remain, but distinguish it from temporary attempt state and verify that the restart location agrees with that choice.
Is deleting the project a way to reset a failed attempt?: No. A gameplay retry should operate within the project. Project deletion or rebuilding discards work and is unrelated to specifying how a player recovers from an in-game failure.