Can a game continue after the player wins?

Yes, if continued play is intentional. Distinguish the finished objective from the ongoing state and explain what further actions mean. Do not leave scoring or rewards running accidentally behind a completion panel.

Should a win condition always grant a reward?

No. Clear completion feedback and a meaningful next action are enough for a small prototype. A reward adds ownership, repeat-grant and reset decisions that should be specified separately.

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

Editorial review 2026-09-26

How to Define a Win Condition in Build

A win condition needs an objective check, a visible change to the completed state and a deliberate next action. Define what stops after success, what remains interactive and what retry restores.

Objective

Define an observable completion transition that cannot be retriggered accidentally during the same attempt.

Before you start

Describe the objective in terms of a state that can be inspected.
Name the action or event that asks the game to check completion.
Choose whether finished play ends, restarts or enters a separate continuation state.

Steps

Write the completion condition independently of its celebration or visual effect.
Describe the feedback for reaching the trigger before the objective is satisfied.
List which gameplay actions remain valid after completion.
Specify how repeated contact behaves once the finished state is already set.
Define the next action and the state it must clear or preserve.
Use the same route to inspect premature arrival, valid completion, repeated contact and retry.

Verification

Arriving without the required objective does not finish the attempt.
Meeting the objective and reaching the trigger produces visible completion feedback.
Repeated interaction with the completed trigger leaves the recorded outcome unchanged.
The next-action control leads to an implemented state rather than a decorative destination.
Retry restores the objective and removes stale completion feedback before play resumes.
Success remains understandable when audio is muted.

Limitations

These are checks for the creator to perform, not reported results from a played Build project.
Persistent prizes or purchases require separate delivery and ownership handling.
Completing a prototype objective does not establish publication eligibility or platform approval.

Working notes

Start with the event that should finish the attempt. Reaching an exit is different from reaching it while carrying the required parcel. Write the condition precisely enough to test arrival before and after the objective is satisfied. A celebration appearing on contact does not establish that the objective was checked.

Treat completion as a state transition, not just a message. During play, the game accepts actions that advance the objective. After completion, decide whether those actions stop, become harmless or deliberately continue in a separate free-play state. Otherwise the player may keep collecting progress behind a success panel without understanding whether the attempt ended.

Specify repeat behavior at the trigger. Walking out of and back into the exit, remaining in contact or pressing a completion control repeatedly should not create fresh rewards for the same finished attempt. This is a proposed design invariant, not a claim that any particular generated game currently violates it.

Make the next action legible. A retry control should describe starting another attempt; a continue control needs an actual next destination. If the prototype has no next level, do not ask for a decorative button that promises one. Completion feedback should also remain understandable without sound or an animation finishing.

Examples

Completion contract for a parcel route: arrival at the marked depot checks that the parcel is carried. If it is missing, explain the unmet objective without ending the attempt. If it is present, mark delivery complete, show the result and offer a retry that restores the parcel to its starting location.
Follow-up brief: Keep the route and movement controls unchanged. At the depot, complete the attempt only when the parcel is carried. After delivery, further depot contact must not change the result. Let Retry restore the starting parcel and clear the completed state before another attempt begins.
Useful failure observation: the victory message appears correctly, but touching the depot again changes the result underneath it. Record both the initial completion and the repeated-contact sequence. Repair the completed-state guard before adding another reward animation.

Common questions

Can a game continue after the player wins?: Yes, if continued play is intentional. Distinguish the finished objective from the ongoing state and explain what further actions mean. Do not leave scoring or rewards running accidentally behind a completion panel.
Should a win condition always grant a reward?: No. Clear completion feedback and a meaningful next action are enough for a small prototype. A reward adds ownership, repeat-grant and reset decisions that should be specified separately.