A playtester puts your game down after 25 minutes and says, "Yeah, it was fine." Nothing crashed. The controls felt good. They laughed at the right moment in the tutorial. And they have no intention of ever opening it again.
That review is not about your mechanics. It is about your loops — specifically, about the one you never designed. Most small teams build a moment-to-moment loop that feels great and then assume the rest of the game will assemble itself around it. It does not. A game needs at least three loops running at different timescales, and each one has to hand the player off to the next.
Here is a practical method for mapping all three, catching the gaps before a playtest does, and writing them down in a form your team can argue with.
One loop is never enough
The classic "core loop" diagram — act, get feedback, get reward, act again — describes what the player does in a few seconds. It says nothing about why they are still playing at minute 40, or why they open the game again on Thursday.
Think in three nested scales instead:
| Loop | Duration | Question it answers | Symptom when it's broken |
|---|---|---|---|
| Moment | 1–30 seconds | "Is doing this thing fun?" | "The combat feels mushy." |
| Session | 15–60 minutes | "Do I have a reason to keep going right now?" | "It got repetitive." |
| Progression | 5–50+ hours | "Is there a reason to come back tomorrow?" | "It was fine." (then they stop) |
That last symptom is the dangerous one, because it does not sound like a bug. "It was fine" almost always means the moment loop worked and the progression loop never started.
The moment loop
This is the verb and its feedback. Swing, hit, the enemy flinches, a number pops, you swing again. It is measured in seconds and it lives or dies on game feel: input buffering, hit pause, animation cancels, audio punch.
Write it as a sentence with a timer: "Every 2–4 seconds the player aims, fires, and sees an enemy stagger or die." If you cannot put a number on the cadence, you have not designed it yet — you have described it.
The session loop
This is the one small teams skip. It is the structure that turns thirty minutes of your moment loop into something with a shape: a run, a shift, a day, a contract, a dungeon.
The session loop needs three things:
- An entry decision. Something the player chooses before they commit — a loadout, a destination, a starting relic. This creates the ownership that makes the next 30 minutes theirs and not yours.
- Escalation. Difficulty, stakes or density must rise so minute 25 is not minute 5 with a different backdrop.
- A clean exit. A win screen, a death, a payout, a "shift over" — a moment where stopping feels like completing something rather than abandoning it.
A roguelike's run is the most obvious version, but the pattern is everywhere. Stardew Valley's in-game day is a session loop: you choose what to plant, energy drains as an escalating pressure, and the day ends whether you like it or not. Slay the Spire's act does the same with a map you choose a path through.
The progression loop
This is what changes between sessions: unlocks, mastery, story chapters, a base that grows, a number that goes up permanently. Its job is to make session N+1 different from session N, and to make that difference visible at the moment the player quits session N.
The single most common failure in indie builds is a progression loop that exists in the design document but does not surface until hour three. If the player cannot see the shape of their long-term progress inside their first session, it does not exist.
A worked example
Say you are building a small deckbuilding roguelike. Written out at all three scales, with numbers:
- Moment (5–15s): Play a card, watch the enemy's telegraphed intent update, decide whether to block or push. Target: 8–12 card plays per combat.
- Session (25–35 min): A run of 3 acts, 14 encounters, 4 elite fights, 1 boss. Entry decision: pick 1 of 3 starting relics. Escalation: enemy HP and intent complexity rise per act. Exit: boss kill or death, followed by a run summary.
- Progression (15–25 hours): Each run, win or lose, awards shards that unlock new cards into the shared pool. Target: an unlock every 1–2 runs for the first 10 runs, then every 3–4.
Now the gaps are visible. If your first unlock costs more shards than a losing run can produce, the progression loop does not start for a player who loses their first three runs — which is most players. That is a ten-minute spreadsheet fix, and it is invisible until you write the loops next to each other.
Wire the exits to the entrances
Loops fail at the seams more often than in the middle. The rule: every loop's exit must contain the hook for the next loop's entrance.
- The moment loop's exit (an enemy dies) should hand back a session-loop resource: a card, gold, a key.
- The session loop's exit (a run ends) should hand back a progression-loop resource, and show the player the next thing it is close to unlocking.
- The progression loop's payoff should change the moment loop — a new verb, not just a bigger number. Unlocking +5% damage does not change what the player does at second three.
That last point is where a lot of upgrade trees quietly die. Audit yours: what fraction of nodes change a decision versus change a multiplier? If it is under a third, your progression loop is arithmetic, not design.
Diagnosing from playtest feedback
Players describe symptoms, not causes. This mapping catches most of them:
| What they say | Loop to look at first |
|---|---|
| "It feels floaty / mushy / slow" | Moment |
| "It got repetitive after a while" | Session — no escalation |
| "I didn't know what to do next" | Session — no entry decision |
| "I wasn't sure when to stop" | Session — no clean exit |
| "It was fine" / no return visits | Progression — never surfaced |
| "The upgrades didn't feel like anything" | Progression → moment link |
Log the quote and the loop you assigned it to, not just the quote. After five sessions you will see a cluster, and the cluster tells you which loop to rebuild.
The one-page loop audit
Run this before your next milestone:
- Each loop has a written duration range, with numbers.
- The session loop has an entry decision, escalation and a clean exit.
- A losing session still produces progression currency.
- The first progression unlock is reachable within 2 sessions.
- At least one third of progression rewards add or change a verb.
- A new player sees all three loops within their first 30 minutes.
- Every loop exit visibly feeds the next loop's entrance.
Write it down where your team can see it
Loops are shared assumptions, and shared assumptions rot silently. Keep the three-scale breakdown next to the systems it governs — in GameDesignerX, that means the mechanics module holding the loop definitions and their target durations, with playtest notes tagged by which loop they implicate, so the pattern across sessions is visible rather than buried in a chat log.
The value is not the diagram. It is that when someone proposes a new feature, you can ask a question with a real answer: which loop does this serve, and what does it cost the other two? Most features that get cut late would have been cut early if somebody had asked that in week three.