Loop length sets pace and interruptibility
Aliases: session cadence · safe stopping point
What it is
Loop length is how long it takes to go once around the core loop, from start to closure. It sets the felt pace of a game — a few seconds per cycle for an action game's attack–dodge–combo, minutes per cycle for a strategy game's build–assess–adjust. It also determines whether a player can safely pause or leave at any moment: shorter loops pack in more safe stopping points, longer loops force players into mid-loop interruptions more often.
Why it happens
Loop length governs "can I stop right now" because in most games the only truly safe stopping point is the instant the loop closes — resolution complete, state reset to a clean baseline. Mid-loop, state is usually incomplete (resources spent, position exposed, a timing window already open), so leaving mid-loop means either eating a loss or redoing the setup next time. The shorter the loop, the more often these safe points come around, letting players absorb real-world interruptions — someone at the door, a phone call — at no cost. The longer the loop, the sparser the safe points, and players either eat a loss leaving mid-loop or stay pinned until the next one arrives. Mobile sessions are inherently interruption-prone, which is exactly why mobile games compress loops down to tens of seconds or a few minutes.
Studying it
- Paradigm: log in-loop action timestamps and exit-event timestamps via telemetry, then map each exit back to its relative position inside the loop (what fraction of the way through it happened). This needs no lab setting and scales to large samples.
- Variables: independent — designed loop length and density of safe points; dependent — the distribution of exit points within the loop, and the return interval after an unplanned interruption.
- Use in interface research: judging whether the current loop length matches how often the target context gets interrupted, giving a data basis for compressing or extending it.
- Methodological caveat: exit timestamps from live telemetry conflate two very different behaviors — forced interruption and voluntary abandonment — that the raw data cannot distinguish on its own. Cross-checking against the return interval helps: a quick return points to forced interruption, a long or permanent absence points to abandonment.
Where it stops holding
This holds only where players are actually subject to external interruption. In fully immersive, uninterrupted long sessions — a single sitting through a narrative game — lengthening the loop helps sustain immersion, and frequent resolution points instead break it. The right loop length depends on how interruption-prone the target context actually is; there is no universally optimal length, and carrying mobile-game short-loop conventions straight over to a console long-session context produces the wrong answer.
Applying it
- Mark explicit "safe stopping points" inside the loop (resolution complete, turn end, auto-save trigger) and restrict interruptive content — exit prompts, system notifications — to those points.
- Match loop length to the target context: compress to under a minute for contexts prone to sudden interruption (commuting, snack-time play); allow longer loops for focused, dedicated sessions.
- Inside a long loop, add secondary safe points so it breaks into independently interruptible segments instead of being safe only at full closure.
- Verification: track the actual distribution of exit timestamps. If exits cluster heavily mid-loop rather than near resolution points, the safe points are too sparse or too hard to notice, and the loop needs re-segmenting.