The core loop is the smallest repeated unit of play
Aliases: gameplay loop · moment-to-moment loop
What it is
Most of what a player actually does in a session is not experiencing unique content but repeating the same short sequence of behavior — read the situation, decide, act, get feedback, and start again. This high-frequency unit is the core loop (also called the gameplay loop). A stealth game's core loop might be "observe patrol route → pick a moment → move → take down the target"; a card game's might be "draw → evaluate hand → play a card → resolve." The core loop is not a specific level or story beat — it's the skeletal action left over once you strip away particular content.
Why it happens
The core loop deserves its own analysis because it is judged by a completely different standard than one-off content (cutscenes, story text, unique set pieces). One-off content only has to work once; it is judged on novelty and emotional impact, and its value naturally hits zero once consumed. The core loop, by contrast, gets executed dozens or hundreds of times, so what matters is whether marginal satisfaction survives repetition — how much the feeling on the fiftieth execution has dropped from the first determines whether the loop is sustainable. That forces the loop to carry a source of satisfaction that does not depend on novelty: the feel of the action itself, the depth of the decision, the immediacy of the feedback — none of which get exhausted by repetition the way a plot twist does. Whether players keep playing depends far less on how much unique content a game has than on whether this repeated skeletal action holds up on its own.
Where it stops holding
The framework assumes there's a high-frequency action skeleton that can be abstracted out in the first place. For genres that barely depend on repeated action — visual novels, some walking simulators — "core loop" as a unit of analysis has limited reach, and forcing it onto these games tends to produce a thin, low-explanatory-power result. Many games also run multiple nested loops rather than one: a combat loop inside an encounter, an exploration loop inside a level, a meta-progression loop at the account level — each running independently and at a different timescale. Describing "the core loop" of such a game as a single verb chain flattens that hierarchy; each layer needs to be identified and analyzed at its own scale.
Applying it
- Write the core loop as a single executable verb chain ("move — aim — fire — loot"), keeping it short enough that players can hold the whole chain in mind and anticipate the next step — typically three to five steps.
- Test each step for whether it's still worth doing with everything else stripped away: turn off the story, turn off progression rewards, and hand a tester just the raw action for ten minutes to see if the skeleton holds on its own.
- Confirm the core loop already works before designing the systems built on top of it (level structure, narrative, progression). If the loop itself is broken, adding more content just amplifies the defect at greater scale instead of hiding it.
- Verification: log how many times the same group of testers repeats the loop before voluntarily stopping. If most people lose interest after a single-digit number of repetitions with no external reward involved, the skeleton itself cannot sustain repetition, and the loop needs fixing before any content work.