Does every core loop need an upgrade system?

No. A route choice, an immediate challenge or progress toward a visible objective can provide a reason to repeat the action. Add upgrades only when you can explain which decision they change and how their state behaves.

How is a core loop different from a win condition?

The loop describes the recurring interaction during play. A win condition identifies when the intended objective is complete. They should agree, but a clear completion screen cannot replace an understandable interaction leading to it.

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

Editorial review 2026-09-26

How to Define a Core Loop for Build

Define a core loop as an action, understandable feedback and a reason to act again. A genre or feature list does not explain what changes when the player repeats the interaction.

Objective

Write a repeatable action-and-feedback sequence that explains why the player would continue.

Before you start

Choose a player action that can be observed in a small prototype.
Identify the state the action should change and the feedback that communicates it.
Keep optional meta-progression in a separate note until the immediate interaction is understandable.

Steps

Describe the choice or input that starts an iteration of the loop.
Name its immediate consequence in the game state.
Specify feedback that lets the player connect the action with that consequence.
Explain what the player is trying to accomplish by acting again.
Define the point at which the loop ends or deliberately changes into another state.
Inspect a proposed repeat and retry sequence before attaching an economy or persistent progression system.

Verification

After an action, an observer can identify the feedback that resulted from it.
The visible progress agrees with the actual state change rather than incrementing independently.
The player can describe the next intended action without being told about a future feature.
Repeated contact with a completed objective does not count as another distinct action unless explicitly designed that way.
The ending condition and retry behavior agree with the loop's stated starting and terminal states.

Limitations

These checks are a proposed editorial test plan; they do not establish that we played a generated version.
An understandable loop is not a retention, ranking or earnings prediction.
Features involving permanent ownership or interaction with other players require separate design and technical verification.

Working notes

Write the loop in terms of a decision the player makes. 'There are crystals and upgrades' describes objects. 'Choose a reachable crystal, collect it, see progress toward the exit, then choose the next route' describes a repeatable interaction.

Name the state that changes. In a short collection route, that may be the set of remaining crystals and progress toward completion. The feedback should explain that change without requiring the player to infer hidden rules. If progress increases without any clear connection to the action, the loop is hard to learn.

Give repetition a purpose. The next action might move the player closer to an exit, offer a route choice or require a different response to an obstacle. Merely asking the player to repeat an input is not a design explanation; identify what they are trying to accomplish with the repetition.

Keep the within-attempt loop distinct from longer-term progression. Returning to spend a permanent currency would add persistence and economy decisions. You can plan those later, but they should not conceal an unclear interaction in the current attempt. This is editorial design guidance rather than a promise about generated features.

Examples

Loop statement: Choose a visible crystal, travel to it, receive clear collection feedback, inspect remaining progress and select the next destination. The attempt ends when the stated objective is satisfied. Retry restores the intended starting collection state.
Counterexample: 'Explore, collect, fight, upgrade, trade and unlock worlds.' This is a list of possible systems. Select the interaction that makes an attempt meaningful before introducing dependencies between those systems.
Observation that sharpens the loop: the player collected a crystal but could not tell whether it mattered. First clarify pickup feedback and progress toward the objective. Adding another collectible type would make that same ambiguity harder to diagnose.

Common questions

Does every core loop need an upgrade system?: No. A route choice, an immediate challenge or progress toward a visible objective can provide a reason to repeat the action. Add upgrades only when you can explain which decision they change and how their state behaves.
How is a core loop different from a win condition?: The loop describes the recurring interaction during play. A win condition identifies when the intended objective is complete. They should agree, but a clear completion screen cannot replace an understandable interaction leading to it.