How long an action takes to resolve once committed — its wind-up, follow-through, and cancelability — is a primary design lever, not a bug to minimize. Choose the game's position on the axis from "instantly cancelable and snappy" to "fully committed and weighty" deliberately, to serve the intended fantasy and risk/reward.

---
id: GDC-L1-FEEL-0008
title: Place the game deliberately on the responsiveness–commitment axis
layer: L1
domain: FEEL
subdomain: responsiveness
type: contextual
confidence: 4
status: canonical
tags:
  - responsiveness
  - commitment
  - weight
  - combat
  - risk-reward
related:
  - GDC-L1-FEEL-0001
  - GDC-L1-FEEL-0007
  - GDC-L1-ANIM-0002
  - GDC-L1-ANIM-0004
depends_on:
  - GDC-L1-FEEL-0001
conflicts_with:
  - GDC-L1-FEEL-0002
supersedes: []
sources:
  - S-swink-gamefeel
  - S-cooper-game-anim
first_added: 2026-07-14
last_verified: 2026-07-15
---

## Statement
> How long an action takes to *resolve* once committed — its wind-up, follow-through,
> and cancelability — is a primary design lever, not a bug to minimize. Choose the
> game's position on the axis from "instantly cancelable and snappy" to "fully committed
> and weighty" deliberately, to serve the intended fantasy and risk/reward.

## Rationale
Responsiveness (FEEL-0002) says the game must *hear* you instantly. This principle is
about how fast it *acts* — and here more speed is not always better. Commitment —
animations that must play out, actions you can't cancel — is what creates weight,
consequence, and readable risk/reward, and it is implemented as **animation priority**:
an action holds control until a designated frame, a lever the animator controls
[S-cooper-game-anim]. Deliberate attack and dodge commitment (as in weapon-based
souls-likes, or Monster Hunter's extreme swing commitment) is core to the tension and
mastery of such combat. That "heavy" feel is
*designed*, not a latency defect: the player is heard instantly (input is registered and
buffered) but the modeled action honors its own timing. Position on this axis defines
whole combat identities: twitch-cancelable character-action vs. deliberate weapon-based
souls-likes.

## Applies when
Any game with meaningful action timing, especially combat, and anywhere risk/reward
should come from committing to actions. The choice sets the game's core rhythm.

## Does not apply / Exceptions
Games whose fantasy is pure speed and flow (fast movement shooters, hyper-agile
character-action) legitimately sit at the fully-responsive end and minimize commitment.
There is no universally correct point — only a correct point *for a given intended feel*.

## Implementation (kept separate from the principle)
Separate the two latencies explicitly: always acknowledge input on frame one (buffer it,
show anticipation), then resolve on the action's designed schedule. Tune wind-up,
active, recovery, and cancel windows as first-class combat parameters. Use committed
recovery frames as the currency of risk (whiffing a heavy attack should hurt). If
players report the game feeling "laggy," diagnose whether it's true acknowledgment
latency (a defect — fix per FEEL-0002) or commitment they're reading as lag (a feature —
communicate it better via anticipation and telegraphing).

## Disagreement
This is the domain's central productive tension, and it is why this entry
`conflicts_with` FEEL-0002:

- **Responsiveness-maximalist:** every frame of delay is an enemy; the avatar should be
  a frictionless extension of the player (platformers, twitch shooters, Devil May
  Cry–style flow).
- **Commitment-maximalist:** weight, consequence, and deliberate pacing require actions
  that can't be instantly taken back (Souls games, Monster Hunter, fighting-game
  recovery frames).

**Reconciliation (both accept):** the conflict dissolves once you split *acknowledgment*
latency from *resolution* time. Acknowledgment should always be near-instant (FEEL-0002
holds absolutely); resolution time is the dial this principle governs. A great weighty
game and a great snappy game both register your input on frame one — they differ only in
how long the world takes to answer.

## Notes
The `conflicts_with: FEEL-0002` edge is deliberate and is the pilot's demonstration of
how the constitution preserves and *resolves* disagreement rather than flattening it. Its
animation-domain expressions are ANIM-0002 (responsiveness beats fidelity / cancel windows)
and ANIM-0004 (root-motion vs. code-driven). Confidence 4. *(2026-07-15: the weak community
source was retired and replaced with Cooper's* Game Anim*, a proper primary for the
animation-priority/commitment mechanism.)*

gdc-l1-feel-0008 place the game deliberately on the responsiveness–commitment axis responsiveness commitment weight combat risk-reward > how long an action takes to resolve once committed — its wind-up, follow-through, and cancelability — is a primary design lever, not a bug to minimize. choose the game's position on the axis from "instantly cancelable and snappy" to "fully committed and weighty" deliberately, to serve the intended fantasy and risk/reward. responsiveness (feel-0002) says the game must hear you instantly. this principle is about how fast it acts — and here more speed is not always better. commitment — animations that must play out, actions you can't cancel — is what creates weight, consequence, and readable risk/reward, and it is implemented as animation priority: an action holds control until a designated frame, a lever the animator controls [s-cooper-game-anim]. deliberate attack and dodge commitment (as in weapon-based souls-likes, or monster hunter's extreme swing commitment) is core to the tension and mastery of such combat. that "heavy" feel is designed, not a latency defect: the player is heard instantly (input is registered and buffered) but the modeled action honors its own timing. position on this axis defines whole combat identities: twitch-cancelable character-action vs. deliberate weapon-based souls-likes. any game with meaningful action timing, especially combat, and anywhere risk/reward should come from committing to actions. the choice sets the game's core rhythm. games whose fantasy is pure speed and flow (fast movement shooters, hyper-agile character-action) legitimately sit at the fully-responsive end and minimize commitment. there is no universally correct point — only a correct point for a given intended feel. separate the two latencies explicitly: always acknowledge input on frame one (buffer it, show anticipation), then resolve on the action's designed schedule. tune wind-up, active, recovery, and cancel windows as first-class combat parameters. use committed recovery frames as the currency of risk (whiffing a heavy attack should hurt). if players report the game feeling "laggy," diagnose whether it's true acknowledgment latency (a defect — fix per feel-0002) or commitment they're reading as lag (a feature — communicate it better via anticipation and telegraphing). this is the domain's central productive tension, and it is why this entry conflictswith feel-0002: - responsiveness-maximalist: every frame of delay is an enemy; the avatar should be a frictionless extension of the player (platformers, twitch shooters, devil may cry–style flow). - commitment-maximalist: weight, consequence, and deliberate pacing require actions that can't be instantly taken back (souls games, monster hunter, fighting-game recovery frames). reconciliation (both accept): the conflict dissolves once you split acknowledgment latency from resolution time. acknowledgment should always be near-instant (feel-0002 holds absolutely); resolution time is the dial this principle governs. a great weighty game and a great snappy game both register your input on frame one — they differ only in how long the world takes to answer. the conflictswith: feel-0002 edge is deliberate and is the pilot's demonstration of how the constitution preserves and resolves disagreement rather than flattening it. its animation-domain expressions are anim-0002 (responsiveness beats fidelity / cancel windows) and anim-0004 (root-motion vs. code-driven). confidence 4. (2026-07-15: the weak community source was retired and replaced with cooper's game anim, a proper primary for the animation-priority/commitment mechanism.)


Identify the core loop — the tight cycle of action, simulation, and feedback the player repeats most often — and make it satisfying on its own, before layering content, progression, or meta-systems on top. If the core loop isn't fun in isolation, nothing built on it will be.

---
id: GDC-L1-SYS-0001
title: Build around a core loop and make it satisfying in isolation
layer: L1
domain: SYS
subdomain: core-loop
type: objective
confidence: 4
status: canonical
tags:
  - core-loop
  - iteration
  - prototyping
  - systems-thinking
related:
  - GDC-L1-FEEL-0001
  - GDC-L1-DESIGN-0003
  - GDC-L1-SYS-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-cook-loops-arcs
  - S-schell-artofgamedesign
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Identify the core loop — the tight cycle of action, simulation, and feedback the
> player repeats most often — and make it satisfying on its own, before layering
> content, progression, or meta-systems on top. If the core loop isn't fun in isolation,
> nothing built on it will be.

## Rationale
Play is structured as nested loops, and the innermost loop is executed thousands of
times across a playthrough [S-cook-loops-arcs]. Because it repeats so often, any deficit
in the core loop compounds: a moment that is merely "fine" the first time becomes tedious
the thousandth. Conversely, a core loop that is intrinsically satisfying carries the game
even when surrounding systems are thin. Everything outside the loop — progression,
narrative, content variety — exists to *feed, vary, and frame* the loop, not to
substitute for it. This is why prototypes should prove the loop first.

## Applies when
Any game with a repeated central activity — which is nearly all of them (shooting/moving,
matching, building, negotiating, exploring). It is the first thing to prototype and the
last thing you can afford to get wrong.

## Does not apply / Exceptions
Highly authored, one-shot experiences (some narrative and art games) may have no single
dominant loop, distributing their value across unique moments instead. Even there,
micro-loops exist (read → choose → see consequence), but the "perfect the core loop
first" emphasis is weaker when repetition isn't the point.

## Implementation (kept separate from the principle)
Name the core loop explicitly ("aim → shoot → react → reposition"). Prototype it in
greybox with no content and ask: is this fun for five minutes with nothing else? Tune its
feel (see FEEL domain) before building progression around it. Layer secondary loops
(session, meta, social) only once the core holds. If playtesters get bored fast, fix the
loop, not the content.

## Disagreement
No serious disagreement that a strong core loop matters; debate is only about how much a
brilliant surrounding structure can carry a mediocre loop (rarely far) — an argument that
resolves in this principle's favor for replay-driven games.

## Notes
The core loop is where SYS, FEEL, and DESIGN meet: FEEL-0001 governs how the loop *feels* moment-to-moment, DESIGN-0003 governs how it *teaches*, and this principle governs its primacy. Confidence 4.

gdc-l1-sys-0001 build around a core loop and make it satisfying in isolation core-loop iteration prototyping systems-thinking > identify the core loop — the tight cycle of action, simulation, and feedback the player repeats most often — and make it satisfying on its own, before layering content, progression, or meta-systems on top. if the core loop isn't fun in isolation, nothing built on it will be. play is structured as nested loops, and the innermost loop is executed thousands of times across a playthrough [s-cook-loops-arcs]. because it repeats so often, any deficit in the core loop compounds: a moment that is merely "fine" the first time becomes tedious the thousandth. conversely, a core loop that is intrinsically satisfying carries the game even when surrounding systems are thin. everything outside the loop — progression, narrative, content variety — exists to feed, vary, and frame the loop, not to substitute for it. this is why prototypes should prove the loop first. any game with a repeated central activity — which is nearly all of them (shooting/moving, matching, building, negotiating, exploring). it is the first thing to prototype and the last thing you can afford to get wrong. highly authored, one-shot experiences (some narrative and art games) may have no single dominant loop, distributing their value across unique moments instead. even there, micro-loops exist (read → choose → see consequence), but the "perfect the core loop first" emphasis is weaker when repetition isn't the point. name the core loop explicitly ("aim → shoot → react → reposition"). prototype it in greybox with no content and ask: is this fun for five minutes with nothing else? tune its feel (see feel domain) before building progression around it. layer secondary loops (session, meta, social) only once the core holds. if playtesters get bored fast, fix the loop, not the content. no serious disagreement that a strong core loop matters; debate is only about how much a brilliant surrounding structure can carry a mediocre loop (rarely far) — an argument that resolves in this principle's favor for replay-driven games. the core loop is where sys, feel, and design meet: feel-0001 governs how the loop feels moment-to-moment, design-0003 governs how it teaches, and this principle governs its primacy. confidence 4.


A game designer cannot directly design play — only the rules that give rise to it. Treat the system as the object you author and the player's experience as a second-order effect you steer indirectly, by tuning rules, incentives, and feedback and then observing what emerges.

---
id: GDC-L1-SYS-0002
title: Design second-order — author the rules, not the outcomes
layer: L1
domain: SYS
subdomain: systems-thinking
type: objective
confidence: 5
status: canonical
tags:
  - systems-thinking
  - second-order-design
  - emergence
  - mda
related:
  - GDC-L1-DESIGN-0001
  - GDC-L1-SYS-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-salen-zimmerman-rulesofplay
  - S-hunicke-mda
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> A game designer cannot directly design play — only the rules that give rise to it.
> Treat the *system* as the object you author and the player's experience as a
> second-order effect you steer indirectly, by tuning rules, incentives, and feedback and
> then observing what emerges.

## Rationale
Designers work at the mechanics end of the chain; players receive the aesthetics end, and
the dynamics in between are produced by play, not authored directly [S-hunicke-mda]. This
is the "second-order design problem": experience is created only indirectly
[S-salen-zimmerman-rulesofplay]. The practical consequence is humility and method — you
propose rules, the system and its players dispose, and you learn what you actually built
by watching it run (which is why this depends on judging by the experience produced,
DESIGN-0001). Designers who forget this try to script outcomes and are repeatedly
surprised when players route around their intentions.

## Applies when
All systemic design: rules, economies, AI, progression, multiplayer. The more systemic
and less scripted the game, the more this dominates.

## Does not apply / Exceptions
Not an exception so much as a boundary: the more heavily *authored* and linear a moment
is (a scripted set-piece, a cutscene), the more directly the designer controls the
experience and the less second-order it is. Even then, the player's *response* remains
second-order — you author the stimulus, not the feeling.

## Implementation (kept separate from the principle)
Design incentives and constraints, then playtest to discover the actual dynamics; expect
surprises and treat them as data. Build tunable systems with exposed parameters so you can
steer emergent behavior without rewriting. Ask "what will players do with this?" not "what
do I want players to do?" Instrument and observe (telemetry, playtests) because you cannot
deduce second-order behavior from first principles alone.

## Disagreement
Foundational and essentially uncontested as a description of how design works; it is the
conceptual basis of systemic and emergent design. No credible counter-position.

## Notes
The theoretical backbone of the whole SYS domain and a direct partner to DESIGN-0001.
Confidence 5.

gdc-l1-sys-0002 design second-order — author the rules, not the outcomes systems-thinking second-order-design emergence mda > a game designer cannot directly design play — only the rules that give rise to it. treat the system as the object you author and the player's experience as a second-order effect you steer indirectly, by tuning rules, incentives, and feedback and then observing what emerges. designers work at the mechanics end of the chain; players receive the aesthetics end, and the dynamics in between are produced by play, not authored directly [s-hunicke-mda]. this is the "second-order design problem": experience is created only indirectly [s-salen-zimmerman-rulesofplay]. the practical consequence is humility and method — you propose rules, the system and its players dispose, and you learn what you actually built by watching it run (which is why this depends on judging by the experience produced, design-0001). designers who forget this try to script outcomes and are repeatedly surprised when players route around their intentions. all systemic design: rules, economies, ai, progression, multiplayer. the more systemic and less scripted the game, the more this dominates. not an exception so much as a boundary: the more heavily authored and linear a moment is (a scripted set-piece, a cutscene), the more directly the designer controls the experience and the less second-order it is. even then, the player's response remains second-order — you author the stimulus, not the feeling. design incentives and constraints, then playtest to discover the actual dynamics; expect surprises and treat them as data. build tunable systems with exposed parameters so you can steer emergent behavior without rewriting. ask "what will players do with this?" not "what do i want players to do?" instrument and observe (telemetry, playtests) because you cannot deduce second-order behavior from first principles alone. foundational and essentially uncontested as a description of how design works; it is the conceptual basis of systemic and emergent design. no credible counter-position. the theoretical backbone of the whole sys domain and a direct partner to design-0001. confidence 5.


Prefer depth that emerges from a few rules interacting over depth authored case-by-case. Emergence — the productive disconnect between simple rules and complex play — yields replayability and player-authored stories that hand-placed content can't match. But emergence must be cultivated and bounded, because the same interactions that create richness also create exploits and chaos.

---
id: GDC-L1-SYS-0003
title: Seek depth through emergence — few rules interacting, not enumerated content
layer: L1
domain: SYS
subdomain: emergence
type: contextual
confidence: 4
status: canonical
tags:
  - emergence
  - depth
  - systems-thinking
  - replayability
related:
  - GDC-L1-DESIGN-0005
  - GDC-L1-DESIGN-0007
  - GDC-L1-SYS-0002
depends_on:
  - GDC-L1-SYS-0002
conflicts_with: []
supersedes: []
sources:
  - S-salen-zimmerman-rulesofplay
  - S-adams-dormans-mechanics
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Prefer depth that *emerges* from a few rules interacting over depth authored
> case-by-case. Emergence — the productive disconnect between simple rules and complex
> play — yields replayability and player-authored stories that hand-placed content can't
> match. But emergence must be cultivated and bounded, because the same interactions that
> create richness also create exploits and chaos.

## Rationale
Emergence is unplanned pattern arising from within a system: a gap between the simplicity
of the rules and the complexity of what they produce [S-salen-zimmerman-rulesofplay]. It
is the most *efficient* form of depth — a small, teachable rule set generating a vast
possibility space (compare DESIGN-0005, easy to learn / hard to master). It is also the
least *controllable*: interacting systems produce outcomes the designer never
enumerated, including degenerate ones. So emergence is not "free depth" — it is depth
traded against predictability, requiring cultivation (designing rules that interact
richly) and bounding (constraints that keep emergence fun rather than broken)
[S-adams-dormans-mechanics].

## Applies when
Systemic games, sandboxes, strategy, simulation, immersive sims, roguelikes — anywhere
replayability and player expression matter more than precisely-paced authored moments.

## Does not apply / Exceptions
Authored, curated experiences deliberately choose *scripted* depth for the control it
gives over pacing, difficulty, and narrative beats. A tightly-tuned linear campaign or a
handcrafted puzzle sequence trades the possibility space of emergence for precision and
guaranteed quality of each moment — a legitimate and often superior choice for
story-driven or set-piece games. Emergence also raises balancing and QA cost sharply.

## Implementation (kept separate from the principle)
Favor mechanics that interact with many others over isolated one-off mechanics (see
SYS-0005 orthogonality — interaction, not redundancy). Design a few strong, general rules
rather than many narrow ones. Then *bound* the emergence: playtest for degenerate
strategies (SYS-0007) and add constraints that prune the unfun branches without killing
the fun ones. Expect to discover the real game by watching it played (SYS-0002).

## Disagreement
The central axis of systems design: **emergent/systemic** design (few deep interacting
rules; possibility space; player-authored stories) vs. **authored/curated** design (many
crafted, controlled moments; precise pacing). Both produce masterpieces; the choice is
about whether you want *possibility* or *control*. Most real games blend the two —
emergent core loop inside an authored frame. Typed `contextual` for exactly this reason.

## Notes
Sits between DESIGN-0005 (accessible depth) and DESIGN-0007 (elegance) on the design side and SYS-0005/0007 on the systems side. Confidence 4.

gdc-l1-sys-0003 seek depth through emergence — few rules interacting, not enumerated content emergence depth systems-thinking replayability > prefer depth that emerges from a few rules interacting over depth authored case-by-case. emergence — the productive disconnect between simple rules and complex play — yields replayability and player-authored stories that hand-placed content can't match. but emergence must be cultivated and bounded, because the same interactions that create richness also create exploits and chaos. emergence is unplanned pattern arising from within a system: a gap between the simplicity of the rules and the complexity of what they produce [s-salen-zimmerman-rulesofplay]. it is the most efficient form of depth — a small, teachable rule set generating a vast possibility space (compare design-0005, easy to learn / hard to master). it is also the least controllable: interacting systems produce outcomes the designer never enumerated, including degenerate ones. so emergence is not "free depth" — it is depth traded against predictability, requiring cultivation (designing rules that interact richly) and bounding (constraints that keep emergence fun rather than broken) [s-adams-dormans-mechanics]. systemic games, sandboxes, strategy, simulation, immersive sims, roguelikes — anywhere replayability and player expression matter more than precisely-paced authored moments. authored, curated experiences deliberately choose scripted depth for the control it gives over pacing, difficulty, and narrative beats. a tightly-tuned linear campaign or a handcrafted puzzle sequence trades the possibility space of emergence for precision and guaranteed quality of each moment — a legitimate and often superior choice for story-driven or set-piece games. emergence also raises balancing and qa cost sharply. favor mechanics that interact with many others over isolated one-off mechanics (see sys-0005 orthogonality — interaction, not redundancy). design a few strong, general rules rather than many narrow ones. then bound the emergence: playtest for degenerate strategies (sys-0007) and add constraints that prune the unfun branches without killing the fun ones. expect to discover the real game by watching it played (sys-0002). the central axis of systems design: emergent/systemic design (few deep interacting rules; possibility space; player-authored stories) vs. authored/curated design (many crafted, controlled moments; precise pacing). both produce masterpieces; the choice is about whether you want possibility or control. most real games blend the two — emergent core loop inside an authored frame. typed contextual for exactly this reason. sits between design-0005 (accessible depth) and design-0007 (elegance) on the design side and sys-0005/0007 on the systems side. confidence 4.


Every dynamic system contains feedback loops, and you must know which ones yours creates. Positive (reinforcing) loops amplify a lead — they accelerate outcomes, snowball advantages, and shorten games. Negative (balancing) loops resist change — they stabilize, enable comebacks, and prolong games. Deploy each deliberately; an unnoticed loop will shape your game whether you designed it or not.

---
id: GDC-L1-SYS-0004
title: Know your feedback loops — positive loops amplify, negative loops stabilize
layer: L1
domain: SYS
subdomain: feedback-loops
type: objective
confidence: 4
status: canonical
tags:
  - feedback-loops
  - balance
  - pacing
  - systems-thinking
related:
  - GDC-L1-DESIGN-0004
  - GDC-L1-SYS-0008
  - GDC-L1-SYS-0007
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-adams-dormans-mechanics
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Every dynamic system contains feedback loops, and you must know which ones yours
> creates. **Positive (reinforcing)** loops amplify a lead — they accelerate outcomes,
> snowball advantages, and shorten games. **Negative (balancing)** loops resist change —
> they stabilize, enable comebacks, and prolong games. Deploy each deliberately; an
> unnoticed loop will shape your game whether you designed it or not.

## Rationale
Feedback loops are the deep structure that determines a game's pacing and fairness
[S-adams-dormans-mechanics]. A positive loop (the winner gains resources that help them
win more) makes outcomes decisive and can feel thrilling — or hopeless, once a lead is
insurmountable. A negative loop (trailing players get help, leaders get friction) keeps
everyone in contention and games close — or can feel like it punishes skill and rewards
mediocrity. Neither is good or bad in itself; each is a tool with a characteristic effect
on drama and duration. The failure is having them by accident: runaway snowballs and
mushy stalemates are usually *unintended* feedback loops.

## Applies when
Any system with accumulating state: economies, scoring, combat, progression, and
especially competitive multiplayer where loop effects are felt most sharply.

## Does not apply / Exceptions
No exception to *understanding* your loops; the contextual part is *how much* of each to
use. High-positive-feedback designs (decisive, snowbally) suit short, dramatic matches;
high-negative-feedback designs (catch-up, rubber-banding) suit accessible, everyone-stays-
in-it experiences. Purely authored/linear content has weaker loop dynamics.

## Implementation (kept separate from the principle)
Diagram resource flows and mark each loop's polarity (economy-modeling tools make this
visible). Use positive feedback to resolve games that would otherwise stall; use negative
feedback to prevent early leads from becoming boring runaways — but keep catch-up
*legible* and skill-respecting so it doesn't feel like theft. Test late-game states
specifically: is a modest lead already unbeatable (too much positive), or is skill
irrelevant to the finish (too much negative)?

## Disagreement
Real and mostly about negative feedback / catch-up mechanics: competitive purists resist
rubber-banding because it dampens skill expression; accessibility- and drama-focused
designers favor it because it keeps all players engaged to the end. Both are right for
their goals; the deciding question is whether the design prioritizes *skill differentiation*
or *sustained tension for everyone*.

## Notes
Closely tied to SYS-0008 (feedback loops live inside the internal economy) and SYS-0007
(positive loops are what make optimization snowball). Bridges to DESIGN-0004 (loops shape
the difficulty/flow curve). Confidence 4.

gdc-l1-sys-0004 know your feedback loops — positive loops amplify, negative loops stabilize feedback-loops balance pacing systems-thinking > every dynamic system contains feedback loops, and you must know which ones yours creates. positive (reinforcing) loops amplify a lead — they accelerate outcomes, snowball advantages, and shorten games. negative (balancing) loops resist change — they stabilize, enable comebacks, and prolong games. deploy each deliberately; an unnoticed loop will shape your game whether you designed it or not. feedback loops are the deep structure that determines a game's pacing and fairness [s-adams-dormans-mechanics]. a positive loop (the winner gains resources that help them win more) makes outcomes decisive and can feel thrilling — or hopeless, once a lead is insurmountable. a negative loop (trailing players get help, leaders get friction) keeps everyone in contention and games close — or can feel like it punishes skill and rewards mediocrity. neither is good or bad in itself; each is a tool with a characteristic effect on drama and duration. the failure is having them by accident: runaway snowballs and mushy stalemates are usually unintended feedback loops. any system with accumulating state: economies, scoring, combat, progression, and especially competitive multiplayer where loop effects are felt most sharply. no exception to understanding your loops; the contextual part is how much of each to use. high-positive-feedback designs (decisive, snowbally) suit short, dramatic matches; high-negative-feedback designs (catch-up, rubber-banding) suit accessible, everyone-stays- in-it experiences. purely authored/linear content has weaker loop dynamics. diagram resource flows and mark each loop's polarity (economy-modeling tools make this visible). use positive feedback to resolve games that would otherwise stall; use negative feedback to prevent early leads from becoming boring runaways — but keep catch-up legible and skill-respecting so it doesn't feel like theft. test late-game states specifically: is a modest lead already unbeatable (too much positive), or is skill irrelevant to the finish (too much negative)? real and mostly about negative feedback / catch-up mechanics: competitive purists resist rubber-banding because it dampens skill expression; accessibility- and drama-focused designers favor it because it keeps all players engaged to the end. both are right for their goals; the deciding question is whether the design prioritizes skill differentiation or sustained tension for everyone. closely tied to sys-0008 (feedback loops live inside the internal economy) and sys-0007 (positive loops are what make optimization snowball). bridges to design-0004 (loops shape the difficulty/flow curve). confidence 4.


Each system, mechanic, or unit should occupy a distinct role that nothing else fills. When two elements do substantially the same job, one is redundant — merge them, cut one, or differentiate them. Orthogonality maximizes depth per unit of complexity and keeps the player's choices meaningful.

---
id: GDC-L1-SYS-0005
title: Make systems orthogonal — each earns its place by doing something no other does
layer: L1
domain: SYS
subdomain: complexity-management
type: contextual
confidence: 3
status: canonical
tags:
  - orthogonality
  - elegance
  - complexity-management
  - depth
related:
  - GDC-L1-DESIGN-0007
  - GDC-L1-DESIGN-0002
  - GDC-L1-SYS-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-adams-dormans-mechanics
  - S-schell-artofgamedesign
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Each system, mechanic, or unit should occupy a distinct role that nothing else fills.
> When two elements do substantially the same job, one is redundant — merge them, cut
> one, or differentiate them. Orthogonality maximizes depth per unit of complexity and
> keeps the player's choices meaningful.

## Rationale
Redundant systems are a double cost: they add complexity (to learn, build, balance) while
*subtracting* meaning, because overlapping options collapse into a dominant one (the
strictly-better version wins) or an arbitrary one (indistinguishable, so the choice
doesn't matter) — both failure modes from DESIGN-0002. Orthogonal design gives each
element a unique axis of purpose, so every system pulls its weight and every choice
between systems is a real tradeoff. This is the systems-level expression of elegance
(DESIGN-0007): not fewest systems for their own sake, but *no wasted* systems.

## Applies when
Designing sets of parallel elements: weapons, unit rosters, character classes, resource
types, upgrade paths, verbs. Especially valuable when a design feels bloated or when
players ignore large parts of it.

## Does not apply / Exceptions
Deliberate redundancy has uses: overlapping options can serve *expression* and *comfort*
(different-feeling tools that reach similar outcomes let players pick a style), and some
genres value abundance and horizontal variety over strict differentiation. Sidegrades that
are mechanically similar but aesthetically distinct are a legitimate design. So
orthogonality is a strong default, not an absolute — hence `contextual`.

## Implementation (kept separate from the principle)
For each element ask: what does this do that no other element does? If the answer is
"nothing," differentiate it (give it a unique niche), merge it, or cut it. Map elements
on their functional axes and look for clusters occupying the same point. Prefer giving a
weak-but-redundant option a *distinct tradeoff* over simply buffing it into a new dominant
choice.

## Disagreement
Tension with variety-and-expression design: minimalist orthogonality (every option
mechanically distinct) vs. expressive abundance (many similar-feeling options for
player self-expression and comfort). Both are valid; competitive and elegance-focused
design leans orthogonal, while sandbox and expression-focused design tolerates more
overlap.

## Notes
The systems-level companion to DESIGN-0007 (elegance) and DESIGN-0002 (interesting decisions). Confidence 3 — a sound and widely-taught heuristic, but genuinely qualified by expression-driven design.

gdc-l1-sys-0005 make systems orthogonal — each earns its place by doing something no other does orthogonality elegance complexity-management depth > each system, mechanic, or unit should occupy a distinct role that nothing else fills. when two elements do substantially the same job, one is redundant — merge them, cut one, or differentiate them. orthogonality maximizes depth per unit of complexity and keeps the player's choices meaningful. redundant systems are a double cost: they add complexity (to learn, build, balance) while subtracting meaning, because overlapping options collapse into a dominant one (the strictly-better version wins) or an arbitrary one (indistinguishable, so the choice doesn't matter) — both failure modes from design-0002. orthogonal design gives each element a unique axis of purpose, so every system pulls its weight and every choice between systems is a real tradeoff. this is the systems-level expression of elegance (design-0007): not fewest systems for their own sake, but no wasted systems. designing sets of parallel elements: weapons, unit rosters, character classes, resource types, upgrade paths, verbs. especially valuable when a design feels bloated or when players ignore large parts of it. deliberate redundancy has uses: overlapping options can serve expression and comfort (different-feeling tools that reach similar outcomes let players pick a style), and some genres value abundance and horizontal variety over strict differentiation. sidegrades that are mechanically similar but aesthetically distinct are a legitimate design. so orthogonality is a strong default, not an absolute — hence contextual. for each element ask: what does this do that no other element does? if the answer is "nothing," differentiate it (give it a unique niche), merge it, or cut it. map elements on their functional axes and look for clusters occupying the same point. prefer giving a weak-but-redundant option a distinct tradeoff over simply buffing it into a new dominant choice. tension with variety-and-expression design: minimalist orthogonality (every option mechanically distinct) vs. expressive abundance (many similar-feeling options for player self-expression and comfort). both are valid; competitive and elegance-focused design leans orthogonal, while sandbox and expression-focused design tolerates more overlap. the systems-level companion to design-0007 (elegance) and design-0002 (interesting decisions). confidence 3 — a sound and widely-taught heuristic, but genuinely qualified by expression-driven design.


Players can only engage a system they can read. Surface enough of a system's state and behavior for players to build a mental model, form hypotheses, and see the results of their actions. A system whose cause-and-effect the player cannot perceive produces confusion or superstition, not depth.

---
id: GDC-L1-SYS-0006
title: Make systems legible — expose enough state for players to form and test hypotheses
layer: L1
domain: SYS
subdomain: systems-thinking
type: contextual
confidence: 4
status: canonical
tags:
  - legibility
  - feedback
  - systems-thinking
  - player-centric
  - learning
related:
  - GDC-L1-DESIGN-0006
  - GDC-L1-DESIGN-0003
  - GDC-L1-FEEL-0004
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-salen-zimmerman-rulesofplay
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Players can only engage a system they can read. Surface enough of a system's state and
> behavior for players to build a mental model, form hypotheses, and see the results of
> their actions. A system whose cause-and-effect the player cannot perceive produces
> confusion or superstition, not depth.

## Rationale
Meaningful play requires that the relationship between action and outcome be
*discernible* and *integrated* — the player must be able to perceive what their action
did and how it fits the larger game [S-salen-zimmerman-rulesofplay]. Depth that the
player can't observe is, functionally, not depth: they can't reason about it, so they
can't make skillful decisions, and they can't *learn* (which breaks DESIGN-0003, since
learning requires readable feedback). When systems are opaque, players fall back on
guesswork and ritual — attributing outcomes to the wrong causes — and the richest
underlying model goes to waste.

## Applies when
Any system the player is expected to master: combat, economy, crafting, AI behavior,
progression. The bar rises with how central the system is to skillful play.

## Does not apply / Exceptions
Deliberate opacity is a legitimate tool. Survival, horror, mystery, and discovery-driven
games hide systems on purpose — the *not knowing* creates dread, curiosity, or the joy of
figuring it out. The key distinction: you may hide the *rule*, but you should still expose
enough *feedback* that players can learn by experiment. Hidden answer, visible
consequences. Fully hiding both rule and feedback produces frustration, not mystery.

## Implementation (kept separate from the principle)
Give systems clear feedback (see FEEL-0004): show what changed and, where appropriate,
why. Prefer readable representations (numbers, states, tells) for systems meant to be
mastered. When intentionally hiding a rule, compensate with rich observable consequences
so the player can still test hypotheses. Playtest for superstition — if players
consistently misattribute cause and effect, legibility is too low.

## Disagreement
Transparency vs. mystery is a real design axis. Systems-mastery designs (strategy,
fighting games, sims) push toward maximum legibility; discovery- and atmosphere-driven
designs deliberately obscure. The reconciliation most designers accept: match legibility
to whether the system is meant to be *mastered* (expose it) or *discovered/feared* (hide
the rule, keep the feedback).

## Notes

gdc-l1-sys-0006 make systems legible — expose enough state for players to form and test hypotheses legibility feedback systems-thinking player-centric learning > players can only engage a system they can read. surface enough of a system's state and behavior for players to build a mental model, form hypotheses, and see the results of their actions. a system whose cause-and-effect the player cannot perceive produces confusion or superstition, not depth. meaningful play requires that the relationship between action and outcome be discernible and integrated — the player must be able to perceive what their action did and how it fits the larger game [s-salen-zimmerman-rulesofplay]. depth that the player can't observe is, functionally, not depth: they can't reason about it, so they can't make skillful decisions, and they can't learn (which breaks design-0003, since learning requires readable feedback). when systems are opaque, players fall back on guesswork and ritual — attributing outcomes to the wrong causes — and the richest underlying model goes to waste. any system the player is expected to master: combat, economy, crafting, ai behavior, progression. the bar rises with how central the system is to skillful play. deliberate opacity is a legitimate tool. survival, horror, mystery, and discovery-driven games hide systems on purpose — the not knowing creates dread, curiosity, or the joy of figuring it out. the key distinction: you may hide the rule, but you should still expose enough feedback that players can learn by experiment. hidden answer, visible consequences. fully hiding both rule and feedback produces frustration, not mystery. give systems clear feedback (see feel-0004): show what changed and, where appropriate, why. prefer readable representations (numbers, states, tells) for systems meant to be mastered. when intentionally hiding a rule, compensate with rich observable consequences so the player can still test hypotheses. playtest for superstition — if players consistently misattribute cause and effect, legibility is too low. transparency vs. mystery is a real design axis. systems-mastery designs (strategy, fighting games, sims) push toward maximum legibility; discovery- and atmosphere-driven designs deliberately obscure. the reconciliation most designers accept: match legibility to whether the system is meant to be mastered (expose it) or discovered/feared (hide the rule, keep the feedback).


Given the opportunity, players will optimize the fun out of a game — they will find and repeat the most efficient path even when it makes their own experience worse. Anticipate degenerate and dominant strategies, and shape constraints and incentives so that the fun path stays the effective path. Part of the designer's job is to protect players from themselves.

---
id: GDC-L1-SYS-0007
title: Players optimize the fun out — protect the experience from degenerate strategies
layer: L1
domain: SYS
subdomain: systems-thinking
type: contextual
confidence: 4
status: canonical
tags:
  - degenerate-strategy
  - dominant-strategy
  - balance
  - player-centric
related:
  - GDC-L1-DESIGN-0002
  - GDC-L1-SYS-0004
  - GDC-L1-SYS-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-soren-johnson-optimize
  - S-meier-interesting-decisions
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Given the opportunity, players will optimize the fun out of a game — they will find and
> repeat the most efficient path even when it makes their own experience worse. Anticipate
> degenerate and dominant strategies, and shape constraints and incentives so that the fun
> path stays the effective path. Part of the designer's job is to protect players from
> themselves.

## Rationale
Players under challenge seek efficiency, and once a clearly-best strategy exists, many
will grind it regardless of enjoyment, then experience the resulting monotony as the
game's fault [S-soren-johnson-optimize]. A designer cannot rely on players to
self-restrain toward fun; the incentive gradient wins. This is why "protecting the player
from themselves" is a real responsibility [S-meier-interesting-decisions]. The lever is
the *incentive structure*: if the optimal action is also boring, players will take it and
suffer — so the design must ensure the engaging way to play is also (at least
competitively) the rewarding way.

## Applies when
Any game with optimizable systems and a persistent player incentive to win, progress, or
accumulate — RPG builds, strategy, competitive play, progression and grind systems,
economies.

## Does not apply / Exceptions
Some games make optimization *itself* the fun: incremental/idle games, min-max sandboxes,
and puzzle-optimization games are *about* finding the efficient path, and there the
optimization pressure is the point rather than a threat. The principle inverts there —
give players a rich optimization space rather than protecting them from it. Elsewhere,
beware over-constraining: railroading players away from all efficiency can feel
patronizing.

## Implementation (kept separate from the principle)
Hunt for dominant strategies in playtest and remove them (buff alternatives, add costs,
introduce situational counters — see DESIGN-0002). Avoid incentive structures that reward
tedium (e.g. grinding a safe, dull action for optimal returns); make the exciting option
also the rewarding one. Watch feedback loops (SYS-0004): positive loops are what let a
single optimal strategy snowball into the only strategy. Use soft constraints (diminishing
returns, variety incentives) to keep the fun path competitive.

## Disagreement
Mostly about *how much* to intervene. Systemic-freedom advocates warn that
over-protecting players removes agency and the satisfaction of finding your own path;
experience-protection advocates note that unchecked optimization reliably flattens games.
The synthesis: shape incentives so the fun path is viable, but don't wall off exploration
entirely — protect the experience, don't confiscate the agency.

## Notes
The systems-level enforcement mechanism behind DESIGN-0002 (interesting decisions). Confidence 4.

gdc-l1-sys-0007 players optimize the fun out — protect the experience from degenerate strategies degenerate-strategy dominant-strategy balance player-centric > given the opportunity, players will optimize the fun out of a game — they will find and repeat the most efficient path even when it makes their own experience worse. anticipate degenerate and dominant strategies, and shape constraints and incentives so that the fun path stays the effective path. part of the designer's job is to protect players from themselves. players under challenge seek efficiency, and once a clearly-best strategy exists, many will grind it regardless of enjoyment, then experience the resulting monotony as the game's fault [s-soren-johnson-optimize]. a designer cannot rely on players to self-restrain toward fun; the incentive gradient wins. this is why "protecting the player from themselves" is a real responsibility [s-meier-interesting-decisions]. the lever is the incentive structure: if the optimal action is also boring, players will take it and suffer — so the design must ensure the engaging way to play is also (at least competitively) the rewarding way. any game with optimizable systems and a persistent player incentive to win, progress, or accumulate — rpg builds, strategy, competitive play, progression and grind systems, economies. some games make optimization itself the fun: incremental/idle games, min-max sandboxes, and puzzle-optimization games are about finding the efficient path, and there the optimization pressure is the point rather than a threat. the principle inverts there — give players a rich optimization space rather than protecting them from it. elsewhere, beware over-constraining: railroading players away from all efficiency can feel patronizing. hunt for dominant strategies in playtest and remove them (buff alternatives, add costs, introduce situational counters — see design-0002). avoid incentive structures that reward tedium (e.g. grinding a safe, dull action for optimal returns); make the exciting option also the rewarding one. watch feedback loops (sys-0004): positive loops are what let a single optimal strategy snowball into the only strategy. use soft constraints (diminishing returns, variety incentives) to keep the fun path competitive. mostly about how much to intervene. systemic-freedom advocates warn that over-protecting players removes agency and the satisfaction of finding your own path; experience-protection advocates note that unchecked optimization reliably flattens games. the synthesis: shape incentives so the fun path is viable, but don't wall off exploration entirely — protect the experience, don't confiscate the agency. the systems-level enforcement mechanism behind design-0002 (interesting decisions). confidence 4.


Treat every resource in the game — currency, health, ammo, time, XP, materials — as part of an internal economy of sources (where resources enter), sinks (where they leave), and converters (where one becomes another). The rates of flow through this economy govern pacing, difficulty, and progression; many problems that look like content problems are actually flow problems.

---
id: GDC-L1-SYS-0008
title: Model resources as an internal economy — mind the sources, sinks, and flows
layer: L1
domain: SYS
subdomain: interlocking-systems
type: objective
confidence: 4
status: canonical
tags:
  - internal-economy
  - resources
  - pacing
  - balance
  - systems-thinking
related:
  - GDC-L1-SYS-0004
  - GDC-L1-DESIGN-0004
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-adams-dormans-mechanics
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Treat every resource in the game — currency, health, ammo, time, XP, materials — as
> part of an internal economy of **sources** (where resources enter), **sinks** (where
> they leave), and **converters** (where one becomes another). The *rates of flow* through
> this economy govern pacing, difficulty, and progression; many problems that look like
> content problems are actually flow problems.

## Rationale
An internal economy is the connective tissue that turns isolated mechanics into a
system, and its structure — the balance of sources against sinks — is what generates
challenge and paces progression [S-adams-dormans-mechanics]. When a game feels too easy,
too grindy, too rich, or too starved, the cause is usually an imbalance in flow: a source
outpacing its sinks (runaway accumulation, trivialized challenge) or sinks outpacing
sources (starvation, grind). Seeing resources as an economy makes these diagnosable and
tunable at the level of *rates*, rather than as a pile of unrelated numbers.

## Applies when
Any game with accumulating or spent resources — which is almost all of them. Essential
for RPGs, strategy, survival, simulation, and any game with progression or crafting.

## Does not apply / Exceptions
Games with minimal or no resource accumulation (pure skill/action games, many puzzle
games) have thin economies where this lens adds little. Even there, "attention" and
"time" can be modeled as resources, but the framework earns its keep only when flows are
substantial.

## Implementation (kept separate from the principle)
Enumerate each resource's sources, sinks, and converters, and reason about *rates*, not
just totals. Model or diagram the flows (economy-simulation tools exist for this) to spot
runaway accumulation or starvation before players do. Tune pacing by adjusting flow rates
rather than bolting on content. Watch for feedback loops inside the economy (SYS-0004),
where a resource feeds a source of itself and snowballs.

## Disagreement
No serious disagreement on the framework's usefulness where economies are substantial;
debate lives one level down (how much scarcity, how fast progression) and belongs to the
ECON and BAL domains.

## Notes
Partners with SYS-0004 (feedback loops are the dynamics *of* the economy) and bridges to the future ECON and BAL domains, which will treat currencies, scarcity, and tuning in depth. Confidence 4.

gdc-l1-sys-0008 model resources as an internal economy — mind the sources, sinks, and flows internal-economy resources pacing balance systems-thinking > treat every resource in the game — currency, health, ammo, time, xp, materials — as part of an internal economy of sources (where resources enter), sinks (where they leave), and converters (where one becomes another). the rates of flow through this economy govern pacing, difficulty, and progression; many problems that look like content problems are actually flow problems. an internal economy is the connective tissue that turns isolated mechanics into a system, and its structure — the balance of sources against sinks — is what generates challenge and paces progression [s-adams-dormans-mechanics]. when a game feels too easy, too grindy, too rich, or too starved, the cause is usually an imbalance in flow: a source outpacing its sinks (runaway accumulation, trivialized challenge) or sinks outpacing sources (starvation, grind). seeing resources as an economy makes these diagnosable and tunable at the level of rates, rather than as a pile of unrelated numbers. any game with accumulating or spent resources — which is almost all of them. essential for rpgs, strategy, survival, simulation, and any game with progression or crafting. games with minimal or no resource accumulation (pure skill/action games, many puzzle games) have thin economies where this lens adds little. even there, "attention" and "time" can be modeled as resources, but the framework earns its keep only when flows are substantial. enumerate each resource's sources, sinks, and converters, and reason about rates, not just totals. model or diagram the flows (economy-simulation tools exist for this) to spot runaway accumulation or starvation before players do. tune pacing by adjusting flow rates rather than bolting on content. watch for feedback loops inside the economy (sys-0004), where a resource feeds a source of itself and snowballs. no serious disagreement on the framework's usefulness where economies are substantial; debate lives one level down (how much scarcity, how fast progression) and belongs to the econ and bal domains. partners with sys-0004 (feedback loops are the dynamics of the economy) and bridges to the future econ and bal domains, which will treat currencies, scarcity, and tuning in depth. confidence 4.


Treat the rate at which the player's power grows relative to challenge as a designed curve, not an accident. If power grows too slowly, progress feels absent; too quickly, and the game becomes a cakewalk. Pace power so the player stays near the edge of their ability.

---
id: GDC-L1-PROG-0001
title: Design the power curve deliberately — pace growth against challenge
layer: L1
domain: PROG
subdomain: pacing-of-power
type: contextual
confidence: 4
status: canonical
tags:
  - progression
  - power-curve
  - pacing
  - flow
  - difficulty
related:
  - GDC-L1-DESIGN-0004
  - GDC-L1-PROG-0005
  - GDC-L1-SYS-0004
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-csikszentmihalyi-flow
  - S-schell-artofgamedesign
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Treat the rate at which the player's power grows *relative to challenge* as a designed
> curve, not an accident. If power grows too slowly, progress feels absent; too quickly,
> and the game becomes a cakewalk. Pace power so the player stays near the edge of their
> ability.

## Rationale
Progression only feels good in relation to challenge: the same +10% damage is thrilling
against a wall the player was stuck on and meaningless against trivial enemies. Because
engagement lives in the band where challenge matches ability (flow, DESIGN-0004), the
*gap* between the player's rising power and the game's rising challenge is the real design
object [S-csikszentmihalyi-flow]. Left unmanaged, that gap drifts: content built for an
early power level trivializes once power outpaces it, and positive feedback loops
(SYS-0004) can make a modest lead snowball into runaway dominance. A deliberately shaped
power curve keeps the player perpetually "almost overpowered, then challenged again."

## Applies when
Any game with character or player growth over time — RPGs, action games, roguelikes,
progression-driven games. The longer the progression and the more power accrues, the more
this matters.

## Does not apply / Exceptions
Games with little or flat progression (many competitive, arcade, or puzzle games) hold
power roughly constant and derive difficulty from content and player skill instead. And a
perfectly smooth curve isn't always the goal: deliberate power *spikes* (a burst of
power-fantasy after a hard stretch) and difficulty *walls* (a gate that demands mastery)
are valid pacing tools — the point is that they're chosen, not accidental.

## Implementation (kept separate from the principle)
Model both curves — player power and content/enemy power — and look at their gap over
time, not either alone. Tune so the gap oscillates within the flow band rather than
trending to trivial or brutal. Distinguish vertical growth (raw strength for tougher
challenges) from horizontal growth (new options and variety); many games pace both. Watch
for runaway positive feedback (SYS-0004) flattening the late game (see PROG-0006).

## Disagreement
Steady-curve design (smooth, predictable growth) vs. punctuated design (deliberate spikes
and valleys for drama) are both legitimate; the choice follows the intended emotional
rhythm. Neither "always keep it smooth" nor "always spike it" is universally right.

## Notes
The pacing backbone of the PROG domain; it is DESIGN-0004 (flow) extended across the whole
progression, and it interacts with SYS-0004 (feedback loops) in the late game. Confidence 4.

gdc-l1-prog-0001 design the power curve deliberately — pace growth against challenge progression power-curve pacing flow difficulty > treat the rate at which the player's power grows relative to challenge as a designed curve, not an accident. if power grows too slowly, progress feels absent; too quickly, and the game becomes a cakewalk. pace power so the player stays near the edge of their ability. progression only feels good in relation to challenge: the same +10% damage is thrilling against a wall the player was stuck on and meaningless against trivial enemies. because engagement lives in the band where challenge matches ability (flow, design-0004), the gap between the player's rising power and the game's rising challenge is the real design object [s-csikszentmihalyi-flow]. left unmanaged, that gap drifts: content built for an early power level trivializes once power outpaces it, and positive feedback loops (sys-0004) can make a modest lead snowball into runaway dominance. a deliberately shaped power curve keeps the player perpetually "almost overpowered, then challenged again." any game with character or player growth over time — rpgs, action games, roguelikes, progression-driven games. the longer the progression and the more power accrues, the more this matters. games with little or flat progression (many competitive, arcade, or puzzle games) hold power roughly constant and derive difficulty from content and player skill instead. and a perfectly smooth curve isn't always the goal: deliberate power spikes (a burst of power-fantasy after a hard stretch) and difficulty walls (a gate that demands mastery) are valid pacing tools — the point is that they're chosen, not accidental. model both curves — player power and content/enemy power — and look at their gap over time, not either alone. tune so the gap oscillates within the flow band rather than trending to trivial or brutal. distinguish vertical growth (raw strength for tougher challenges) from horizontal growth (new options and variety); many games pace both. watch for runaway positive feedback (sys-0004) flattening the late game (see prog-0006). steady-curve design (smooth, predictable growth) vs. punctuated design (deliberate spikes and valleys for drama) are both legitimate; the choice follows the intended emotional rhythm. neither "always keep it smooth" nor "always spike it" is universally right. the pacing backbone of the prog domain; it is design-0004 (flow) extended across the whole progression, and it interacts with sys-0004 (feedback loops) in the late game. confidence 4.


"Getting better" can come from two sources: the player improving (execution, knowledge, timing) or the character growing (stats, gear, unlocks). Decide the intended blend deliberately — it determines whether mastery is earned at the controller or accumulated on the character sheet.

---
id: GDC-L1-PROG-0002
title: Decide the mix of player skill and character power
layer: L1
domain: PROG
subdomain: skill-vs-power
type: contextual
confidence: 4
status: canonical
tags:
  - progression
  - skill-vs-power
  - mastery
  - rpg
  - action
related:
  - GDC-L1-DESIGN-0002
  - GDC-L1-PROG-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-schell-artofgamedesign
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> "Getting better" can come from two sources: the **player** improving (execution,
> knowledge, timing) or the **character** growing (stats, gear, unlocks). Decide the
> intended blend deliberately — it determines whether mastery is earned at the controller
> or accumulated on the character sheet.

## Rationale
The two sources feel completely different. Player-skill progression rewards practice —
muscle memory, pattern recognition, better decisions — and is satisfying because *you*
got better [S-schell-artofgamedesign]. Character-power progression rewards investment —
time, resources, choices — and is satisfying because your avatar can now do what it
couldn't. Games sit somewhere on this axis, and the position shapes everything:
difficulty tuning, how failure feels, whether a stuck player should grind or improve, and
who the game is for. Leaving it unexamined produces incoherence — e.g. a game that asks
for twitch skill but lets players out-level every challenge, satisfying neither the action
player nor the RPG player.

## Applies when
Any game with progression and any real-time challenge — action-RPGs especially, where the
two sources are most in tension.

## Does not apply / Exceptions
Pure-skill games (fighting games, most competitive shooters) deliberately sit at the
player-skill pole with little character power; pure-build games and idle/incremental games
sit near the character-power pole with little execution demand. Both extremes are
coherent; the danger is an *unintended* muddle in the middle.

## Implementation (kept separate from the principle)
Decide, per system, whether a challenge should be beaten by getting better or by getting stronger — and make the game's answer consistent so a stuck player knows what to do.

## Disagreement
Action tradition (player skill is the point; character power should never trivialize
execution) vs. RPG tradition (character growth is the fantasy; the sheet, not the thumbs,
should decide outcomes). Both are valid design goals; the axis position is a defining
choice, not a mistake.

## Notes
Confidence 4.

gdc-l1-prog-0002 decide the mix of player skill and character power progression skill-vs-power mastery rpg action > "getting better" can come from two sources: the player improving (execution, knowledge, timing) or the character growing (stats, gear, unlocks). decide the intended blend deliberately — it determines whether mastery is earned at the controller or accumulated on the character sheet. the two sources feel completely different. player-skill progression rewards practice — muscle memory, pattern recognition, better decisions — and is satisfying because you got better [s-schell-artofgamedesign]. character-power progression rewards investment — time, resources, choices — and is satisfying because your avatar can now do what it couldn't. games sit somewhere on this axis, and the position shapes everything: difficulty tuning, how failure feels, whether a stuck player should grind or improve, and who the game is for. leaving it unexamined produces incoherence — e.g. a game that asks for twitch skill but lets players out-level every challenge, satisfying neither the action player nor the rpg player. any game with progression and any real-time challenge — action-rpgs especially, where the two sources are most in tension. pure-skill games (fighting games, most competitive shooters) deliberately sit at the player-skill pole with little character power; pure-build games and idle/incremental games sit near the character-power pole with little execution demand. both extremes are coherent; the danger is an unintended muddle in the middle. decide, per system, whether a challenge should be beaten by getting better or by getting stronger — and make the game's answer consistent so a stuck player knows what to do. action tradition (player skill is the point; character power should never trivialize execution) vs. rpg tradition (character growth is the fantasy; the sheet, not the thumbs, should decide outcomes). both are valid design goals; the axis position is a defining choice, not a mistake. confidence 4.


Rewards teach. Players learn to do whatever the game rewards, so reward the behavior you actually want to see. Make each reward legible (the player understands what earned it) and proportionate (greater effort or skill earns greater payoff). Misaligned rewards train the fun out of the game.

---
id: GDC-L1-PROG-0003
title: Reward the behavior you want — legibly and proportionately
layer: L1
domain: PROG
subdomain: reward-schedules
type: contextual
confidence: 4
status: canonical
tags:
  - progression
  - rewards
  - incentives
  - legibility
  - balance
related:
  - GDC-L1-SYS-0007
  - GDC-L1-DESIGN-0006
  - GDC-L1-PROG-0004
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-schell-artofgamedesign
  - S-soren-johnson-optimize
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Rewards teach. Players learn to do whatever the game rewards, so reward the behavior you
> actually want to see. Make each reward **legible** (the player understands what earned
> it) and **proportionate** (greater effort or skill earns greater payoff). Misaligned
> rewards train the fun out of the game.

## Rationale
A reward is a signal that says "do more of that." If the most-rewarded action is boring,
safe, or degenerate, players will gravitate to it and then blame the game for the tedium
(the optimization pressure of SYS-0007). So the reward structure must point at the
experience you want: reward bold play if you want bold play, exploration if you want
exploration, mastery if you want mastery. Legibility matters because a reward the player
can't attribute to an action can't reinforce that action — it reads as randomness (compare
DESIGN-0006, legible consequences). Proportionality matters because rewards that don't
scale with effort either trivialize achievement or feel unfair.

## Applies when
Any system that grants progress, loot, currency, unlocks, or score — i.e. most
progression and economy design.

## Does not apply / Exceptions
Deliberate randomness has a place (varicrity and surprise; see PROG-0004), so "legible"
means the player understands the *rules of the reward*, not that every drop is
deterministic. And not every action needs a reward — over-rewarding trivial actions
creates noise that drowns the signals that matter (compare FEEL-0004 on feedback). Some
cosmetic or expressive rewards are intentionally disproportionate to effort and that's
fine.

## Implementation (kept separate from the principle)
Audit what your game actually rewards versus what you want it to encourage, and realign the
gaps. Make the earning rule visible or discoverable. Scale payoff to effort/skill/risk so
the exciting path is also the rewarding path (this is the incentive lever behind SYS-0007).
Watch for accidental incentives — a reward attached to a boring-but-optimal action is a bug.

## Disagreement
How *tightly* to couple reward to desired behavior is debated: tight coupling steers
players cleanly but can feel manipulative or grindy; loose coupling preserves freedom but
lets degenerate strategies flourish. Balances differ by genre and by how much the game
trusts player-driven goals.

## Notes
The constructive counterpart to SYS-0007 (players optimize the fun out): SYS-0007 warns of
the failure, this says how to steer incentives so the fun path stays rewarding. Leads into
PROG-0004 (intrinsic vs. extrinsic). Confidence 4.

gdc-l1-prog-0003 reward the behavior you want — legibly and proportionately progression rewards incentives legibility balance > rewards teach. players learn to do whatever the game rewards, so reward the behavior you actually want to see. make each reward legible (the player understands what earned it) and proportionate (greater effort or skill earns greater payoff). misaligned rewards train the fun out of the game. a reward is a signal that says "do more of that." if the most-rewarded action is boring, safe, or degenerate, players will gravitate to it and then blame the game for the tedium (the optimization pressure of sys-0007). so the reward structure must point at the experience you want: reward bold play if you want bold play, exploration if you want exploration, mastery if you want mastery. legibility matters because a reward the player can't attribute to an action can't reinforce that action — it reads as randomness (compare design-0006, legible consequences). proportionality matters because rewards that don't scale with effort either trivialize achievement or feel unfair. any system that grants progress, loot, currency, unlocks, or score — i.e. most progression and economy design. deliberate randomness has a place (varicrity and surprise; see prog-0004), so "legible" means the player understands the rules of the reward, not that every drop is deterministic. and not every action needs a reward — over-rewarding trivial actions creates noise that drowns the signals that matter (compare feel-0004 on feedback). some cosmetic or expressive rewards are intentionally disproportionate to effort and that's fine. audit what your game actually rewards versus what you want it to encourage, and realign the gaps. make the earning rule visible or discoverable. scale payoff to effort/skill/risk so the exciting path is also the rewarding path (this is the incentive lever behind sys-0007). watch for accidental incentives — a reward attached to a boring-but-optimal action is a bug. how tightly to couple reward to desired behavior is debated: tight coupling steers players cleanly but can feel manipulative or grindy; loose coupling preserves freedom but lets degenerate strategies flourish. balances differ by genre and by how much the game trusts player-driven goals. the constructive counterpart to sys-0007 (players optimize the fun out): sys-0007 warns of the failure, this says how to steer incentives so the fun path stays rewarding. leads into prog-0004 (intrinsic vs. extrinsic). confidence 4.


Prefer progression that deepens genuine engagement — new abilities, meaningful choices, real mastery — over manufactured treadmills that rely on compulsion loops (grind, unpredictable reward schedules) to retain players. Let rewards sit on top of intrinsically fun play, not substitute for it.

---
id: GDC-L1-PROG-0004
title: Favor intrinsic progression over extrinsic treadmills
layer: L1
domain: PROG
subdomain: reward-schedules
type: stylistic
confidence: 3
status: canonical
tags:
  - progression
  - intrinsic-motivation
  - ethics
  - player-respect
  - grind
related:
  - GDC-L1-PROG-0003
  - GDC-L1-DESIGN-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-reward-schedules
  - S-koster-theoryoffun
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Prefer progression that deepens genuine engagement — new abilities, meaningful choices,
> real mastery — over manufactured treadmills that rely on compulsion loops (grind,
> unpredictable reward schedules) to retain players. Let rewards sit *on top of*
> intrinsically fun play, not substitute for it.

## Rationale
Reward-schedule techniques rooted in operant conditioning (variable-ratio "slot machine"
loops) reliably drive time-on-task, but they engage *extrinsic* motivation — playing for
the payout rather than the play [S-reward-schedules]. The overjustification effect warns
of the trap: rewarding an activity that was intrinsically fun can make players re-attribute
their behavior to the reward, so when the reward thins out, so does the enjoyment. A
game sustained mainly by compulsion loops is fragile and, past a point, works against the
player's own interests. Intrinsic progression — getting to *do* new and interesting things,
mastering real skills (DESIGN-0003) — is more durable and treats the player as someone to
delight rather than to retain. Notably, unpredictable rewards can be used *respectfully*
when they're a bonus on top of already-fun play rather than a gate that play must pass
through.

## Applies when
Any progression, reward, or retention design — and especially anywhere monetization or
engagement metrics tempt the team toward compulsion mechanics.

## Does not apply / Exceptions
Some pleasure genuinely *is* the loop: idle/incremental games and collectathons are
openly about the satisfying tick of accumulation, and players choose them for exactly
that. Variable rewards, used as surprise-and-delight on top of fun play, are a legitimate
and beloved tool (loot, crits). The line this principle draws is against progression that
*depends* on compulsion because the underlying play isn't carrying it.

## Implementation (kept separate from the principle)
Build the intrinsically fun loop first (PROTO-0001, find the fun) and add rewards as
amplifiers on top of it, not as the reason to keep playing. Apply the removal test: *would
players still enjoy this loop if the rewards were stripped out?* If not, the play isn't
carrying itself and no reward schedule will fix that honestly. When using variable/random
rewards, make them a bonus layered over already-fun play rather than a gate play must pass
through. Watch engagement/retention metrics but don't optimize them at the experience's
expense (the PROG-0003 / PLAYTEST-0005 caution against chasing a proxy). Be especially wary
of compulsion patterns (FOMO timers, mandatory daily logins, loss-aversion hooks) — use them
only where they genuinely serve the player, not merely the metric.

## Disagreement
This is a real values split, so it is typed `stylistic`. The engagement-optimization case
(as its proponents make it): retention and monetization are legitimate business goals,
reinforcement schedules are well-understood and effective, and players opt in freely — a
game that keeps people playing is succeeding. The player-respect/wellbeing case: compulsion
loops can exploit rather than serve, erode intrinsic enjoyment (overjustification), and
risk the player's time and wellbeing; a game should earn engagement through fun, not
manufacture it. This constitution leans toward the respect side, but presents both because
reasonable, successful developers land in different places.

## Notes
Confidence 3: the mechanisms (overjustification, reinforcement schedules) are well-established, but *how much* to weigh engagement vs. respect is a genuine, unresolved values question.

gdc-l1-prog-0004 favor intrinsic progression over extrinsic treadmills progression intrinsic-motivation ethics player-respect grind > prefer progression that deepens genuine engagement — new abilities, meaningful choices, real mastery — over manufactured treadmills that rely on compulsion loops (grind, unpredictable reward schedules) to retain players. let rewards sit on top of intrinsically fun play, not substitute for it. reward-schedule techniques rooted in operant conditioning (variable-ratio "slot machine" loops) reliably drive time-on-task, but they engage extrinsic motivation — playing for the payout rather than the play [s-reward-schedules]. the overjustification effect warns of the trap: rewarding an activity that was intrinsically fun can make players re-attribute their behavior to the reward, so when the reward thins out, so does the enjoyment. a game sustained mainly by compulsion loops is fragile and, past a point, works against the player's own interests. intrinsic progression — getting to do new and interesting things, mastering real skills (design-0003) — is more durable and treats the player as someone to delight rather than to retain. notably, unpredictable rewards can be used respectfully when they're a bonus on top of already-fun play rather than a gate that play must pass through. any progression, reward, or retention design — and especially anywhere monetization or engagement metrics tempt the team toward compulsion mechanics. some pleasure genuinely is the loop: idle/incremental games and collectathons are openly about the satisfying tick of accumulation, and players choose them for exactly that. variable rewards, used as surprise-and-delight on top of fun play, are a legitimate and beloved tool (loot, crits). the line this principle draws is against progression that depends on compulsion because the underlying play isn't carrying it. build the intrinsically fun loop first (proto-0001, find the fun) and add rewards as amplifiers on top of it, not as the reason to keep playing. apply the removal test: would players still enjoy this loop if the rewards were stripped out? if not, the play isn't carrying itself and no reward schedule will fix that honestly. when using variable/random rewards, make them a bonus layered over already-fun play rather than a gate play must pass through. watch engagement/retention metrics but don't optimize them at the experience's expense (the prog-0003 / playtest-0005 caution against chasing a proxy). be especially wary of compulsion patterns (fomo timers, mandatory daily logins, loss-aversion hooks) — use them only where they genuinely serve the player, not merely the metric. this is a real values split, so it is typed stylistic. the engagement-optimization case (as its proponents make it): retention and monetization are legitimate business goals, reinforcement schedules are well-understood and effective, and players opt in freely — a game that keeps people playing is succeeding. the player-respect/wellbeing case: compulsion loops can exploit rather than serve, erode intrinsic enjoyment (overjustification), and risk the player's time and wellbeing; a game should earn engagement through fun, not manufacture it. this constitution leans toward the respect side, but presents both because reasonable, successful developers land in different places. confidence 3: the mechanisms (overjustification, reinforcement schedules) are well-established, but how much to weigh engagement vs. respect is a genuine, unresolved values question.


Introduce each new mechanic in a structured arc: introduce it in a safe, low-stakes setting; develop it by adding complexity; twist it through an unexpected use; then conclude with a final payoff or demonstration. Stagger introductions so the player is always learning something new as they finish mastering the last.

---
id: GDC-L1-PROG-0005
title: Introduce complexity in four beats — introduce, develop, twist, conclude
layer: L1
domain: PROG
subdomain: mastery-curve
type: contextual
confidence: 4
status: canonical
tags:
  - progression
  - mastery-curve
  - teaching
  - level-design
  - pacing
related:
  - GDC-L1-DESIGN-0003
  - GDC-L1-DESIGN-0004
  - GDC-L1-PROG-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-mark-brown-4step
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Introduce each new mechanic in a structured arc: **introduce** it in a safe, low-stakes
> setting; **develop** it by adding complexity; **twist** it through an unexpected use;
> then **conclude** with a final payoff or demonstration. Stagger introductions so the player is always
> learning something new as they finish mastering the last.

## Rationale
The four-step structure described by Mark Brown (introduce → develop → twist → conclusion,
related to the Kishōtenketsu narrative shape) is an effective arc for turning a new mechanic into understanding in
minutes [S-mark-brown-4step]. Each step does a specific job: the safe introduction lets
the player fail and learn without punishment; development builds competence through added
complexity; the twist forces genuine understanding (not just memorized inputs) by
recontextualizing the mechanic; and the conclusion pays off the learning, often through a
confident final showcase. This is the concrete, teachable pacing of "fun is learning"
(DESIGN-0003) and keeps the player inside flow (DESIGN-0004) — always stretched, never
lost.

## Applies when
Introducing any new mechanic, tool, enemy, or system — level design, tutorial design, and
the overall sequencing of what the game teaches when.

## Does not apply / Exceptions
Not every mechanic needs the full four beats — trivial additions can be introduced in passing. Open/emergent games may teach through systems and experimentation rather than authored arcs.

## Implementation (kept separate from the principle)
For each new mechanic, sketch the four beats: a safe first encounter, a complication, a
recontextualizing twist, and a concluding payoff. Space new-mechanic introductions so the
learning load stays steady (pairs with the power curve, PROG-0001). Reuse the arc
fractally — within a level, an area, and the whole game. Where the game's identity is
discovery, consider hiding the "teach" step and letting the world imply it.

## Disagreement
Authored teaching (structured arcs, guided) vs. discovery teaching (unguided, figure-it-out)
is a real split — the former maximizes clarity and reach, the latter maximizes the pleasure
of insight and suits systemic/mystery designs. The four-step arc is the strong default for
accessibility; discovery-first games consciously trade it away.

## Notes
The teaching/pacing counterpart to DESIGN-0003 (fun is learning) and DESIGN-0004 (flow), and it directly informs LEVEL/encounter design. Confidence 4.

gdc-l1-prog-0005 introduce complexity in four beats — introduce, develop, twist, conclude progression mastery-curve teaching level-design pacing > introduce each new mechanic in a structured arc: introduce it in a safe, low-stakes setting; develop it by adding complexity; twist it through an unexpected use; then conclude with a final payoff or demonstration. stagger introductions so the player is always learning something new as they finish mastering the last. the four-step structure described by mark brown (introduce → develop → twist → conclusion, related to the kishōtenketsu narrative shape) is an effective arc for turning a new mechanic into understanding in minutes [s-mark-brown-4step]. each step does a specific job: the safe introduction lets the player fail and learn without punishment; development builds competence through added complexity; the twist forces genuine understanding (not just memorized inputs) by recontextualizing the mechanic; and the conclusion pays off the learning, often through a confident final showcase. this is the concrete, teachable pacing of "fun is learning" (design-0003) and keeps the player inside flow (design-0004) — always stretched, never lost. introducing any new mechanic, tool, enemy, or system — level design, tutorial design, and the overall sequencing of what the game teaches when. not every mechanic needs the full four beats — trivial additions can be introduced in passing. open/emergent games may teach through systems and experimentation rather than authored arcs. for each new mechanic, sketch the four beats: a safe first encounter, a complication, a recontextualizing twist, and a concluding payoff. space new-mechanic introductions so the learning load stays steady (pairs with the power curve, prog-0001). reuse the arc fractally — within a level, an area, and the whole game. where the game's identity is discovery, consider hiding the "teach" step and letting the world imply it. authored teaching (structured arcs, guided) vs. discovery teaching (unguided, figure-it-out) is a real split — the former maximizes clarity and reach, the latter maximizes the pleasure of insight and suits systemic/mystery designs. the four-step arc is the strong default for accessibility; discovery-first games consciously trade it away. the teaching/pacing counterpart to design-0003 (fun is learning) and design-0004 (flow), and it directly informs level/encounter design. confidence 4.


Decide what the top of progression looks like before you need it: where power converges, what expert play consists of, and whether the late game is a power fantasy or a tight skill test. An unplanned endgame collapses into trivialized challenge (runaway power) or a content cliff (nothing left to master).

---
id: GDC-L1-PROG-0006
title: Design the mastery ceiling and endgame explicitly
layer: L1
domain: PROG
subdomain: mastery-curve
type: contextual
confidence: 3
status: canonical
tags:
  - progression
  - endgame
  - mastery-ceiling
  - balance
  - retention
related:
  - GDC-L1-DESIGN-0005
  - GDC-L1-SYS-0004
  - GDC-L1-PROG-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-koster-theoryoffun
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Decide what the *top* of progression looks like before you need it: where power
> converges, what expert play consists of, and whether the late game is a power fantasy or
> a tight skill test. An unplanned endgame collapses into trivialized challenge (runaway
> power) or a content cliff (nothing left to master).

## Rationale
Progression has an end state whether or not you designed one, and the two default failures
are predictable. If power keeps compounding unchecked (a positive feedback loop, SYS-0004),
the late game trivializes — every challenge falls over, and the mastery that made the game
fun evaporates (Koster's "mastery problem": once a pattern is fully solved, it stops being
fun) [S-koster-theoryoffun]. If instead the game simply runs out of new patterns, players
hit a content cliff and leave. Designing the ceiling deliberately means choosing which of
two satisfying end states you want — the earned power fantasy (you *are* strong now, and
that's the reward) or sustained skill expression (power converges so mastery stays about
play) — and shaping the curve toward it.

## Applies when
Any game long enough to have a late game or endgame — RPGs, live-service, roguelikes,
progression-heavy games. Most acute where power compounds.

## Does not apply / Exceptions
Short or session-based games without a meaningful late game don't need an endgame design.
Deliberate power-fantasy finales (the game *wants* you to feel unstoppable at the end) are
a valid choice, not a failure — the point is that trivialization is chosen and framed as a
reward, not stumbled into.

## Implementation (kept separate from the principle)
Decide early whether late-game power converges (caps, diminishing returns, scaling
challenge) or crescendos (an intentional power fantasy). Guard against runaway positive
feedback (SYS-0004) if you want convergence. Plan a source of continued mastery for the
top end — new patterns, higher-skill content, or horizontal variety — so expert players
still have somewhere to go (compare DESIGN-0005, high skill ceiling).

## Disagreement
Convergent endgame (keep power in check so skill and challenge stay meaningful) vs.
crescendo endgame (let power run so the finale is a cathartic power fantasy) are both
legitimate, opposite answers. The right one depends on whether the game's late-game
pleasure is *expression* or *dominance*.

## Notes
The top-of-curve companion to PROG-0001 (pacing) and DESIGN-0005 (accessible depth / high
ceiling), and it's where SYS-0004's runaway positive feedback most often bites. Confidence
3 — sound reasoning, but endgame design is highly genre-dependent and less settled than the
earlier-curve principles.

gdc-l1-prog-0006 design the mastery ceiling and endgame explicitly progression endgame mastery-ceiling balance retention > decide what the top of progression looks like before you need it: where power converges, what expert play consists of, and whether the late game is a power fantasy or a tight skill test. an unplanned endgame collapses into trivialized challenge (runaway power) or a content cliff (nothing left to master). progression has an end state whether or not you designed one, and the two default failures are predictable. if power keeps compounding unchecked (a positive feedback loop, sys-0004), the late game trivializes — every challenge falls over, and the mastery that made the game fun evaporates (koster's "mastery problem": once a pattern is fully solved, it stops being fun) [s-koster-theoryoffun]. if instead the game simply runs out of new patterns, players hit a content cliff and leave. designing the ceiling deliberately means choosing which of two satisfying end states you want — the earned power fantasy (you are strong now, and that's the reward) or sustained skill expression (power converges so mastery stays about play) — and shaping the curve toward it. any game long enough to have a late game or endgame — rpgs, live-service, roguelikes, progression-heavy games. most acute where power compounds. short or session-based games without a meaningful late game don't need an endgame design. deliberate power-fantasy finales (the game wants you to feel unstoppable at the end) are a valid choice, not a failure — the point is that trivialization is chosen and framed as a reward, not stumbled into. decide early whether late-game power converges (caps, diminishing returns, scaling challenge) or crescendos (an intentional power fantasy). guard against runaway positive feedback (sys-0004) if you want convergence. plan a source of continued mastery for the top end — new patterns, higher-skill content, or horizontal variety — so expert players still have somewhere to go (compare design-0005, high skill ceiling). convergent endgame (keep power in check so skill and challenge stay meaningful) vs. crescendo endgame (let power run so the finale is a cathartic power fantasy) are both legitimate, opposite answers. the right one depends on whether the game's late-game pleasure is expression or dominance. the top-of-curve companion to prog-0001 (pacing) and design-0005 (accessible depth / high ceiling), and it's where sys-0004's runaway positive feedback most often bites. confidence 3 — sound reasoning, but endgame design is highly genre-dependent and less settled than the earlier-curve principles.


A game economy is defined by its faucets (sources that create resources) and its drains (sinks that destroy them). Its health is a matter of flow: sinks must remove resources at a rate matched to what faucets generate. Watch the rates, not the stockpiles.

---
id: GDC-L1-ECON-0001
title: Balance faucets against drains — the flow, not the total, defines the economy
layer: L1
domain: ECON
subdomain: faucets-and-drains
type: contextual
confidence: 4
status: canonical
tags:
  - economy
  - faucets
  - drains
  - sources
  - sinks
  - flow
related:
  - GDC-L1-SYS-0008
  - GDC-L1-SYS-0004
  - GDC-L1-ECON-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-economy-design
  - S-adams-dormans-mechanics
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> A game economy is defined by its **faucets** (sources that create resources) and its
> **drains** (sinks that destroy them). Its health is a matter of *flow*: sinks must remove
> resources at a rate matched to what faucets generate. Watch the **rates**, not the
> stockpiles.

## Rationale
Resources in a game are created from nothing at faucets (quest rewards, loot, minigames)
and, ideally, destroyed at sinks (repair costs, consumables, fees) [S-economy-design]. What
determines whether the economy stays healthy is the *balance of flows* — if faucets pour in
faster than sinks drain out, resources accumulate, purchasing power falls, and the currency
inflates toward worthlessness (ECON-0004); if sinks over-drain, players feel starved. This is
the economy-specific deepening of SYS-0008 (model resources as an internal economy): SYS-0008
says treat resources as sources/sinks/converters; this says the *tuning target* is the flow
rate through them, and it interacts directly with feedback loops (SYS-0004 — a faucet that
scales with wealth is a positive loop that accelerates inflation). Designers who watch only
the current totals miss the trend that will break the economy weeks later.

## Applies when
Any game with accumulating resources — RPGs, MMOs, survival, city-builders, strategy,
economy sims, and most progression systems. The larger and longer-lived the resource pools,
the more flow balance dominates.

## Does not apply / Exceptions
Games with tiny or no persistent economies (most arcade, action, puzzle) don't need
flow modeling. Deliberately inflationary designs exist (idle/incremental games are *about*
numbers exploding — there the "economy" is the spectacle of growth, and control comes from
scaling costs alongside, not from stable purchasing power). Short, closed-loop economies
(one playthrough, no persistence) tolerate looser balance.

## Implementation (kept separate from the principle)
Enumerate every faucet and drain and estimate its rate; model the net flow over time (economy
-simulation tools help) rather than eyeballing current balances. Watch for faucets that scale
with player wealth, count, or game age — those are inflation engines (ECON-0004). Tune by
adjusting rates, and prefer adding/strengthening sinks (ECON-0003) over throttling the fun of
faucets. Instrument the live economy (telemetry — PLAYTEST-0005) to catch drift early.

## Disagreement
Little on the flow model itself; debate is about how *tightly* to control the economy —
stable-purchasing-power design (MMO-style, fight inflation hard) vs. deliberately
inflationary growth (idle games, where the exploding numbers are the point). The choice
follows whether stable value or the spectacle of growth is the goal.

## Notes
The economy-craft deepening of SYS-0008, and tightly coupled to SYS-0004 (feedback loops are
the dynamics of the flow). The parent of the more specific ECON principles (sinks, inflation,
currencies). Confidence 4.

gdc-l1-econ-0001 balance faucets against drains — the flow, not the total, defines the economy economy faucets drains sources sinks flow > a game economy is defined by its faucets (sources that create resources) and its drains (sinks that destroy them). its health is a matter of flow: sinks must remove resources at a rate matched to what faucets generate. watch the rates, not the stockpiles. resources in a game are created from nothing at faucets (quest rewards, loot, minigames) and, ideally, destroyed at sinks (repair costs, consumables, fees) [s-economy-design]. what determines whether the economy stays healthy is the balance of flows — if faucets pour in faster than sinks drain out, resources accumulate, purchasing power falls, and the currency inflates toward worthlessness (econ-0004); if sinks over-drain, players feel starved. this is the economy-specific deepening of sys-0008 (model resources as an internal economy): sys-0008 says treat resources as sources/sinks/converters; this says the tuning target is the flow rate through them, and it interacts directly with feedback loops (sys-0004 — a faucet that scales with wealth is a positive loop that accelerates inflation). designers who watch only the current totals miss the trend that will break the economy weeks later. any game with accumulating resources — rpgs, mmos, survival, city-builders, strategy, economy sims, and most progression systems. the larger and longer-lived the resource pools, the more flow balance dominates. games with tiny or no persistent economies (most arcade, action, puzzle) don't need flow modeling. deliberately inflationary designs exist (idle/incremental games are about numbers exploding — there the "economy" is the spectacle of growth, and control comes from scaling costs alongside, not from stable purchasing power). short, closed-loop economies (one playthrough, no persistence) tolerate looser balance. enumerate every faucet and drain and estimate its rate; model the net flow over time (economy -simulation tools help) rather than eyeballing current balances. watch for faucets that scale with player wealth, count, or game age — those are inflation engines (econ-0004). tune by adjusting rates, and prefer adding/strengthening sinks (econ-0003) over throttling the fun of faucets. instrument the live economy (telemetry — playtest-0005) to catch drift early. little on the flow model itself; debate is about how tightly to control the economy — stable-purchasing-power design (mmo-style, fight inflation hard) vs. deliberately inflationary growth (idle games, where the exploding numbers are the point). the choice follows whether stable value or the spectacle of growth is the goal. the economy-craft deepening of sys-0008, and tightly coupled to sys-0004 (feedback loops are the dynamics of the flow). the parent of the more specific econ principles (sinks, inflation, currencies). confidence 4.