Scarcity creates value and decisions

A resource matters only when it is scarce enough to force choices. Abundance trivializes — if you can have everything, there's nothing to decide; over-scarcity frustrates and paralyzes. Tune scarcity so that spending a resource is a real tradeoff.

---
id: GDC-L1-ECON-0002
title: Scarcity creates value and decisions
layer: L1
domain: ECON
subdomain: scarcity
type: contextual
confidence: 4
status: canonical
tags:
  - economy
  - scarcity
  - value
  - decisions
  - resources
related:
  - GDC-L1-DESIGN-0002
  - GDC-L1-BAL-0002
  - GDC-L1-ECON-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-economy-design
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> A resource matters only when it is scarce enough to force choices. Abundance trivializes —
> if you can have everything, there's nothing to decide; over-scarcity frustrates and
> paralyzes. Tune scarcity so that spending a resource is a real tradeoff.

## Rationale
Value is a function of scarcity: a resource the player has in unlimited supply carries no
weight, so decisions about it are hollow (buy everything, use freely, feel nothing)
[S-economy-design]. Meaningful resource decisions — *this potion now or save it? this upgrade
or that one?* — only exist when having one thing means forgoing another, which requires
scarcity. This is DESIGN-0002 (interesting decisions) expressed through economics: scarcity is
what makes a spending choice a genuine tradeoff rather than a formality, and it's what gives
rewards their emotional weight. But the dial has two bad ends — abundance drains meaning, and
crushing scarcity produces frustration, hoarding (players too afraid to spend), and analysis
paralysis. The craft is finding the tension in between.

## Applies when
Any resource the player accumulates and spends — currency, consumables, materials, action
economy, time. Central to RPG, survival, strategy, and roguellike design.

## Does not apply / Exceptions
Some resources are *meant* to be abundant — a resource that exists to be spent freely for
expressive or comfort reasons (cosmetic currency, generous ammo in a power-fantasy shooter)
shouldn't be artificially starved. Power-fantasy and relaxation designs deliberately loosen
scarcity. And scarcity that's too tight in a *learning* context (early game) can gate players
out; scarcity often tightens as mastery grows.

## Implementation (kept separate from the principle)
Tune each resource's scarcity to the weight you want its decisions to carry — tighter for
resources meant to create tension, looser for those meant to enable expression. Watch for
hoarding (a sign of either too much scarcity or unclear value) and for trivializing abundance
(a sign of weak sinks — ECON-0003). Scarcity and the faucet/drain balance (ECON-0001) are the
same dial seen from two angles.

## Disagreement
Tight scarcity (tension, meaningful decisions, survival stakes) vs. generous abundance (power
fantasy, expression, low friction) — both are valid depending on whether the resource is meant
to create *tension* or enable *freedom*. Over-scarcity's frustration and abundance's
meaninglessness are the two failure modes to steer between.

## Notes
The value-and-decision rationale beneath the flow model (ECON-0001) and a direct economic
expression of DESIGN-0002 (interesting decisions) and BAL-0002 (meaningful choice). Confidence 4.

gdc-l1-econ-0002 scarcity creates value and decisions economy scarcity value decisions resources > a resource matters only when it is scarce enough to force choices. abundance trivializes — if you can have everything, there's nothing to decide; over-scarcity frustrates and paralyzes. tune scarcity so that spending a resource is a real tradeoff. value is a function of scarcity: a resource the player has in unlimited supply carries no weight, so decisions about it are hollow (buy everything, use freely, feel nothing) [s-economy-design]. meaningful resource decisions — this potion now or save it? this upgrade or that one? — only exist when having one thing means forgoing another, which requires scarcity. this is design-0002 (interesting decisions) expressed through economics: scarcity is what makes a spending choice a genuine tradeoff rather than a formality, and it's what gives rewards their emotional weight. but the dial has two bad ends — abundance drains meaning, and crushing scarcity produces frustration, hoarding (players too afraid to spend), and analysis paralysis. the craft is finding the tension in between. any resource the player accumulates and spends — currency, consumables, materials, action economy, time. central to rpg, survival, strategy, and roguellike design. some resources are meant to be abundant — a resource that exists to be spent freely for expressive or comfort reasons (cosmetic currency, generous ammo in a power-fantasy shooter) shouldn't be artificially starved. power-fantasy and relaxation designs deliberately loosen scarcity. and scarcity that's too tight in a learning context (early game) can gate players out; scarcity often tightens as mastery grows. tune each resource's scarcity to the weight you want its decisions to carry — tighter for resources meant to create tension, looser for those meant to enable expression. watch for hoarding (a sign of either too much scarcity or unclear value) and for trivializing abundance (a sign of weak sinks — econ-0003). scarcity and the faucet/drain balance (econ-0001) are the same dial seen from two angles. tight scarcity (tension, meaningful decisions, survival stakes) vs. generous abundance (power fantasy, expression, low friction) — both are valid depending on whether the resource is meant to create tension or enable freedom. over-scarcity's frustration and abundance's meaninglessness are the two failure modes to steer between. the value-and-decision rationale beneath the flow model (econ-0001) and a direct economic expression of design-0002 (interesting decisions) and bal-0002 (meaningful choice). confidence 4.


Most economy problems are missing or weak sinks. Faucets are easy and fun to add — rewards feel good to give — while sinks (compelling reasons to spend or destroy resources) are harder to design and routinely neglected, which is why inflation and hoarding are the default failure states. Design sinks as carefully as sources.

---
id: GDC-L1-ECON-0003
title: Design sinks deliberately — the missing half of most economies
layer: L1
domain: ECON
subdomain: sources-and-sinks
type: contextual
confidence: 4
status: canonical
tags:
  - economy
  - sinks
  - drains
  - inflation
  - spending
related:
  - GDC-L1-ECON-0001
  - GDC-L1-ECON-0004
  - GDC-L1-ECON-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-economy-design
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Most economy problems are missing or weak **sinks**. Faucets are easy and fun to add —
> rewards feel good to give — while sinks (compelling reasons to *spend* or *destroy*
> resources) are harder to design and routinely neglected, which is why inflation and
> hoarding are the default failure states. Design sinks as carefully as sources.

## Rationale
There is an asymmetry in how economies get built: giving players resources is rewarding and
gets attention, so faucets proliferate, while sinks — which take resources *away* — feel less
generous and get under-designed [S-economy-design]. The result is predictable: resources
accumulate faster than they leave, the currency inflates (ECON-0004), and a rich player has
nothing worth buying. The fix is to treat sinks as first-class design: give players things
they genuinely *want* to spend on, so draining resources feels like a choice they make, not a
tax. And distinguish sink types — a **hard sink** destroys value (repair costs, consumables,
fees) and truly fights inflation; a **soft sink** merely *transfers* value between players
(buying from another player) and does *not* remove it from the economy. When you need to
control inflation, you need hard sinks.

## Applies when
Any accumulating economy, especially persistent and multiplayer ones (MMOs, live-service,
economy sims) where resources pile up over months and inflation compounds.

## Does not apply / Exceptions
Short, non-persistent economies (one playthrough) can tolerate weak sinks — there's not
enough time for inflation to bite. Deliberately generous power-fantasy designs may want few
sinks. And sinks must be *attractive*, not punitive — a sink players resent (arbitrary decay,
punitive taxes) drains fun along with resources; the goal is desirable spending, not
confiscation.

## Implementation (kept separate from the principle)
Audit the ratio of faucets to sinks in your design — if faucets outnumber compelling sinks,
that's the bug. Add sinks players *want* to use (aspirational purchases, upgrades,
customization, consumables, services). Favor hard sinks (destroy value) where inflation is a
risk; know that player-to-player trade is a soft sink that doesn't help. Scale sink cost with
player wealth so the rich have somewhere to spend (a "gold sink").

## Disagreement
Little that sinks are necessary; the nuance is *how* to drain — attractive, aspirational
sinks (players want to spend) vs. structural sinks (decay, taxes, upkeep that players may
resent). Aspirational sinks preserve fun; structural sinks are reliable but can feel punitive.
Most healthy economies use both, weighted toward the aspirational.

## Notes
The most commonly-neglected half of the faucet/drain balance (ECON-0001) and the direct lever
against inflation (ECON-0004). Confidence 4.

gdc-l1-econ-0003 design sinks deliberately — the missing half of most economies economy sinks drains inflation spending > most economy problems are missing or weak sinks. faucets are easy and fun to add — rewards feel good to give — while sinks (compelling reasons to spend or destroy resources) are harder to design and routinely neglected, which is why inflation and hoarding are the default failure states. design sinks as carefully as sources. there is an asymmetry in how economies get built: giving players resources is rewarding and gets attention, so faucets proliferate, while sinks — which take resources away — feel less generous and get under-designed [s-economy-design]. the result is predictable: resources accumulate faster than they leave, the currency inflates (econ-0004), and a rich player has nothing worth buying. the fix is to treat sinks as first-class design: give players things they genuinely want to spend on, so draining resources feels like a choice they make, not a tax. and distinguish sink types — a hard sink destroys value (repair costs, consumables, fees) and truly fights inflation; a soft sink merely transfers value between players (buying from another player) and does not remove it from the economy. when you need to control inflation, you need hard sinks. any accumulating economy, especially persistent and multiplayer ones (mmos, live-service, economy sims) where resources pile up over months and inflation compounds. short, non-persistent economies (one playthrough) can tolerate weak sinks — there's not enough time for inflation to bite. deliberately generous power-fantasy designs may want few sinks. and sinks must be attractive, not punitive — a sink players resent (arbitrary decay, punitive taxes) drains fun along with resources; the goal is desirable spending, not confiscation. audit the ratio of faucets to sinks in your design — if faucets outnumber compelling sinks, that's the bug. add sinks players want to use (aspirational purchases, upgrades, customization, consumables, services). favor hard sinks (destroy value) where inflation is a risk; know that player-to-player trade is a soft sink that doesn't help. scale sink cost with player wealth so the rich have somewhere to spend (a "gold sink"). little that sinks are necessary; the nuance is how to drain — attractive, aspirational sinks (players want to spend) vs. structural sinks (decay, taxes, upkeep that players may resent). aspirational sinks preserve fun; structural sinks are reliable but can feel punitive. most healthy economies use both, weighted toward the aspirational. the most commonly-neglected half of the faucet/drain balance (econ-0001) and the direct lever against inflation (econ-0004). confidence 4.


Unchecked faucets — and positive feedback loops that scale rewards with the wealth or progress a player already has — cause inflation: currency loses value, stockpiles pile up, and spending stops mattering. Monitor the money supply and drain the excess. The symptom looks like "the content got trivial," but the cause is economic.

---
id: GDC-L1-ECON-0004
title: Guard against inflation and runaway accumulation
layer: L1
domain: ECON
subdomain: inflation
type: contextual
confidence: 4
status: canonical
tags:
  - economy
  - inflation
  - runaway
  - feedback-loops
  - money-supply
related:
  - GDC-L1-SYS-0004
  - GDC-L1-PROG-0006
  - 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
> Unchecked faucets — and positive feedback loops that scale rewards with the wealth or
> progress a player already has — cause **inflation**: currency loses value, stockpiles pile
> up, and spending stops mattering. Monitor the money supply and drain the excess. The
> symptom looks like "the content got trivial," but the cause is economic.

## Rationale
Inflation is the natural end state of an economy whose faucets outpace its sinks, and it's
made worse by feedback: if wealthier players earn *faster* (a positive loop — SYS-0004), the
money supply grows super-linearly and value collapses [S-economy-design]. Its damage is
insidious because it disguises itself — designers see rewards feeling meaningless, prices
feeling trivial, new players unable to afford anything a veteran casually owns, and reach for
content or difficulty fixes when the real cause is too much currency chasing too few sinks.
This is the economic face of runaway positive feedback (SYS-0004) and of the unplanned power
curve (PROG-0006): unchecked accumulation trivializes the game whether the resource is gold or
raw power.

## Applies when
Persistent and long-lived economies especially — MMOs, live-service, economy sims — and any
game where resources accumulate across a long play horizon.

## Does not apply / Exceptions
Idle/incremental games are *deliberately* inflationary — the exploding numbers are the
appeal, and they control it by scaling *costs* alongside income rather than by stabilizing
value. Short, non-persistent economies rarely inflate meaningfully. Mild, managed inflation
can even be healthy (it pressures players to keep engaging with the economy rather than
sitting on a hoard).

## Implementation (kept separate from the principle)
Track the total money supply and prices over time, not just per-player balances (telemetry —
PLAYTEST-0005). Avoid or dampen faucets that scale with wealth/progress (SYS-0004). Keep hard
sinks (ECON-0003) sized to the money being generated, and scale sink costs with wealth so the
richest players still drain. Treat "rewards feel meaningless" as a possible economy signal,
not just a tuning-numbers one.

## Disagreement
Stable-value design (fight inflation to keep purchasing power and new-player viability) vs.
managed-inflation or deliberately-inflationary design (idle games; or mild inflation used to
keep players economically active). The right stance depends on whether stable value or growth-
as-spectacle serves the game.

## Notes
The economic form of SYS-0004 (runaway positive feedback) and PROG-0006 (runaway power); its
primary countermeasure is deliberate sinks (ECON-0003). Confidence 4.

gdc-l1-econ-0004 guard against inflation and runaway accumulation economy inflation runaway feedback-loops money-supply > unchecked faucets — and positive feedback loops that scale rewards with the wealth or progress a player already has — cause inflation: currency loses value, stockpiles pile up, and spending stops mattering. monitor the money supply and drain the excess. the symptom looks like "the content got trivial," but the cause is economic. inflation is the natural end state of an economy whose faucets outpace its sinks, and it's made worse by feedback: if wealthier players earn faster (a positive loop — sys-0004), the money supply grows super-linearly and value collapses [s-economy-design]. its damage is insidious because it disguises itself — designers see rewards feeling meaningless, prices feeling trivial, new players unable to afford anything a veteran casually owns, and reach for content or difficulty fixes when the real cause is too much currency chasing too few sinks. this is the economic face of runaway positive feedback (sys-0004) and of the unplanned power curve (prog-0006): unchecked accumulation trivializes the game whether the resource is gold or raw power. persistent and long-lived economies especially — mmos, live-service, economy sims — and any game where resources accumulate across a long play horizon. idle/incremental games are deliberately inflationary — the exploding numbers are the appeal, and they control it by scaling costs alongside income rather than by stabilizing value. short, non-persistent economies rarely inflate meaningfully. mild, managed inflation can even be healthy (it pressures players to keep engaging with the economy rather than sitting on a hoard). track the total money supply and prices over time, not just per-player balances (telemetry — playtest-0005). avoid or dampen faucets that scale with wealth/progress (sys-0004). keep hard sinks (econ-0003) sized to the money being generated, and scale sink costs with wealth so the richest players still drain. treat "rewards feel meaningless" as a possible economy signal, not just a tuning-numbers one. stable-value design (fight inflation to keep purchasing power and new-player viability) vs. managed-inflation or deliberately-inflationary design (idle games; or mild inflation used to keep players economically active). the right stance depends on whether stable value or growth- as-spectacle serves the game. the economic form of sys-0004 (runaway positive feedback) and prog-0006 (runaway power); its primary countermeasure is deliberate sinks (econ-0003). confidence 4.


Give each currency a distinct purpose

Each currency or resource type should have a clear, distinct role. When multiple currencies collapse into one fungible pile — same sources, same uses — they add complexity without meaning. Separate currencies to segment the economy and create distinct decisions, but only add a currency that earns its place.

---
id: GDC-L1-ECON-0005
title: Give each currency a distinct purpose
layer: L1
domain: ECON
subdomain: currencies
type: contextual
confidence: 3
status: canonical
tags:
  - economy
  - currencies
  - orthogonality
  - elegance
related:
  - GDC-L1-SYS-0005
  - GDC-L1-DESIGN-0007
  - GDC-L1-ECON-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-economy-design
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Each currency or resource type should have a clear, distinct role. When multiple currencies
> collapse into one fungible pile — same sources, same uses — they add complexity without
> meaning. Separate currencies to segment the economy and create distinct decisions, but only
> add a currency that earns its place.

## Rationale
Multiple currencies are a tool for *segmenting* an economy: a currency earned only one way and
spent only on one thing creates a separate, controllable sub-economy with its own faucets and
sinks (ECON-0001) — which is why games use distinct currencies for, say, routine spending vs.
rare aspirational purchases vs. time-gated progression. But the tool is often misused: piling
on currencies that are acquired and spent interchangeably just multiplies the UI and the
player's mental load without adding a single real decision. This is orthogonality (SYS-0005)
and elegance (DESIGN-0007) applied to economics: each currency must do something no other does,
or it shouldn't exist. Distinct currencies also let you protect one economy from another's
inflation (a premium or progression currency insulated from the grindable one).

## Applies when
Designing the set of currencies/resources — most acute in RPGs, live-service, and F2P games
that tend to accumulate many currencies over time.

## Does not apply / Exceptions
Many games are better with a *single* clean currency — added currencies are only worth it when
segmentation genuinely helps, and a proliferation of currencies is a common, real design smell
(confusing, grindy, opaque). Some multi-currency systems in live games exist for monetization
segmentation rather than player benefit (a MON/ethics concern, not a pure economy one). Default
to fewer currencies; add one only when it earns a distinct role.

## Implementation (kept separate from the principle)
For each currency, state its unique role: how it's earned, what it buys, and why it isn't just
the main currency. If two currencies share sources and sinks, merge them. Use separate
currencies deliberately to insulate economies from each other's inflation, to gate progression,
or to separate routine from aspirational spending — not by accident. Watch the UI/cognitive
cost (UX-0002) that each currency adds.

## Disagreement
Single-currency simplicity (clean, legible, fewer sinks to balance) vs. multi-currency
segmentation (controllable sub-economies, insulated inflation, distinct decisions — at the cost
of complexity and, sometimes, monetization-driven confusion). Lean simple; segment only where
it pays.

## Notes
The economic expression of orthogonality (SYS-0005) and elegance (DESIGN-0007) — no redundant
currencies. Confidence 3: a sound heuristic, but "how many currencies" is genuinely
game-dependent and often distorted by monetization pressures.

gdc-l1-econ-0005 give each currency a distinct purpose economy currencies orthogonality elegance > each currency or resource type should have a clear, distinct role. when multiple currencies collapse into one fungible pile — same sources, same uses — they add complexity without meaning. separate currencies to segment the economy and create distinct decisions, but only add a currency that earns its place. multiple currencies are a tool for segmenting an economy: a currency earned only one way and spent only on one thing creates a separate, controllable sub-economy with its own faucets and sinks (econ-0001) — which is why games use distinct currencies for, say, routine spending vs. rare aspirational purchases vs. time-gated progression. but the tool is often misused: piling on currencies that are acquired and spent interchangeably just multiplies the ui and the player's mental load without adding a single real decision. this is orthogonality (sys-0005) and elegance (design-0007) applied to economics: each currency must do something no other does, or it shouldn't exist. distinct currencies also let you protect one economy from another's inflation (a premium or progression currency insulated from the grindable one). designing the set of currencies/resources — most acute in rpgs, live-service, and f2p games that tend to accumulate many currencies over time. many games are better with a single clean currency — added currencies are only worth it when segmentation genuinely helps, and a proliferation of currencies is a common, real design smell (confusing, grindy, opaque). some multi-currency systems in live games exist for monetization segmentation rather than player benefit (a mon/ethics concern, not a pure economy one). default to fewer currencies; add one only when it earns a distinct role. for each currency, state its unique role: how it's earned, what it buys, and why it isn't just the main currency. if two currencies share sources and sinks, merge them. use separate currencies deliberately to insulate economies from each other's inflation, to gate progression, or to separate routine from aspirational spending — not by accident. watch the ui/cognitive cost (ux-0002) that each currency adds. single-currency simplicity (clean, legible, fewer sinks to balance) vs. multi-currency segmentation (controllable sub-economies, insulated inflation, distinct decisions — at the cost of complexity and, sometimes, monetization-driven confusion). lean simple; segment only where it pays. the economic expression of orthogonality (sys-0005) and elegance (design-0007) — no redundant currencies. confidence 3: a sound heuristic, but "how many currencies" is genuinely game-dependent and often distorted by monetization pressures.


The moment players can trade, a market emerges with its own dynamics — pricing, arbitrage, hoarding, speculation, and real-money-trading pressure — that no designer authored. Design the rules and constraints and let the economy emerge (second-order design), then watch for and curb degenerate outcomes.

---
id: GDC-L1-ECON-0006
title: Player-driven economies are emergent systems — design the rules, not the transactions
layer: L1
domain: ECON
subdomain: trade
type: contextual
confidence: 3
status: canonical
tags:
  - economy
  - player-driven
  - markets
  - trade
  - emergence
related:
  - GDC-L1-SYS-0002
  - GDC-L1-SYS-0007
  - GDC-L1-SYS-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
> The moment players can trade, a **market emerges** with its own dynamics — pricing,
> arbitrage, hoarding, speculation, and real-money-trading pressure — that no designer
> authored. Design the *rules and constraints* and let the economy emerge (second-order
> design), then watch for and curb degenerate outcomes.

## Rationale
A player-driven economy is a system, not a set of transactions: once players set prices and
trade freely, aggregate behavior produces phenomena you didn't script — supply and demand
curves, price bubbles, cornered markets, botting and farming, and real-money trading — exactly
the kind of unplanned complexity that emergence (SYS-0003) predicts [S-economy-design]. So you
can't design the outcomes directly; you design the *rules* (what's tradeable, transaction
costs, market structure, information visibility) and the economy self-organizes around them
(second-order design, SYS-0002). And because players optimize relentlessly (SYS-0007), a
player-run economy will find and exploit every inefficiency — so the designer's ongoing job is
to watch the emergent market and intervene against the degenerate cases (runaway inflation,
exploitative farming, RMT that corrodes the game) without trying to micromanage prices.

## Applies when
Any game with meaningful player-to-player trading or markets — MMOs, trading-heavy multiplayer,
economy sims with player exchange.

## Does not apply / Exceptions
Closed/authored economies (single-player, or multiplayer with no trading) have no emergent
market — the designer controls all prices and flows directly, which is simpler and more
controllable. Many games deliberately forbid or tightly constrain trade precisely to *avoid*
the emergent-market headaches (bind-on-pickup items, no player trading). Choosing a closed
economy is a legitimate way to sidestep this entire problem.

## Implementation (kept separate from the principle)
Decide first whether you even want a player-driven economy — the control cost is high. If you
do, design the market's rules (tradeable set, fees as sinks — ECON-0003, information you
expose) and expect to *observe and adjust* rather than dictate (telemetry, live-ops).
Anticipate optimization and exploitation (SYS-0007): botting, arbitrage, RMT. Build hard sinks
and transaction costs into the market to fight inflation and skim froth.

## Disagreement
Open/player-driven economy (rich emergent trading, player-authored value, but hard to control
and prone to exploitation) vs. closed/authored economy (fully controllable, simpler, but no
emergent market life). Sandbox and MMO design leans open; tightly-tuned and single-player design
leans closed. It's a fundamental structural choice, not a tuning knob.

## Notes
Where ECON meets emergence (SYS-0003), second-order design (SYS-0002), and the optimization
pressure of SYS-0007. Confidence 3: the phenomena are well-established, but player-economy design
is a specialized, high-variance discipline. Confidence would rise with dedicated MMO-economy
sources.

gdc-l1-econ-0006 player-driven economies are emergent systems — design the rules, not the transactions economy player-driven markets trade emergence > the moment players can trade, a market emerges with its own dynamics — pricing, arbitrage, hoarding, speculation, and real-money-trading pressure — that no designer authored. design the rules and constraints and let the economy emerge (second-order design), then watch for and curb degenerate outcomes. a player-driven economy is a system, not a set of transactions: once players set prices and trade freely, aggregate behavior produces phenomena you didn't script — supply and demand curves, price bubbles, cornered markets, botting and farming, and real-money trading — exactly the kind of unplanned complexity that emergence (sys-0003) predicts [s-economy-design]. so you can't design the outcomes directly; you design the rules (what's tradeable, transaction costs, market structure, information visibility) and the economy self-organizes around them (second-order design, sys-0002). and because players optimize relentlessly (sys-0007), a player-run economy will find and exploit every inefficiency — so the designer's ongoing job is to watch the emergent market and intervene against the degenerate cases (runaway inflation, exploitative farming, rmt that corrodes the game) without trying to micromanage prices. any game with meaningful player-to-player trading or markets — mmos, trading-heavy multiplayer, economy sims with player exchange. closed/authored economies (single-player, or multiplayer with no trading) have no emergent market — the designer controls all prices and flows directly, which is simpler and more controllable. many games deliberately forbid or tightly constrain trade precisely to avoid the emergent-market headaches (bind-on-pickup items, no player trading). choosing a closed economy is a legitimate way to sidestep this entire problem. decide first whether you even want a player-driven economy — the control cost is high. if you do, design the market's rules (tradeable set, fees as sinks — econ-0003, information you expose) and expect to observe and adjust rather than dictate (telemetry, live-ops). anticipate optimization and exploitation (sys-0007): botting, arbitrage, rmt. build hard sinks and transaction costs into the market to fight inflation and skim froth. open/player-driven economy (rich emergent trading, player-authored value, but hard to control and prone to exploitation) vs. closed/authored economy (fully controllable, simpler, but no emergent market life). sandbox and mmo design leans open; tightly-tuned and single-player design leans closed. it's a fundamental structural choice, not a tuning knob. where econ meets emergence (sys-0003), second-order design (sys-0002), and the optimization pressure of sys-0007. confidence 3: the phenomena are well-established, but player-economy design is a specialized, high-variance discipline. confidence would rise with dedicated mmo-economy sources.


"Balanced" is meaningless without a goal. Decide what balance serves — competitive integrity, viable variety, a power fantasy, a difficulty target, a fair economy — because different goals demand opposite tuning. Balance toward the intended experience, not toward an abstract notion of "fairness."

---
id: GDC-L1-BAL-0001
title: Decide what balance is for before you tune
layer: L1
domain: BAL
subdomain: balance-philosophy
type: contextual
confidence: 4
status: canonical
tags:
  - balance
  - philosophy
  - fairness
  - intent
related:
  - GDC-L1-BAL-0006
  - GDC-L1-DESIGN-0001
  - GDC-L1-BAL-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-schell-artofgamedesign
  - S-schreiber-balance
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> "Balanced" is meaningless without a goal. Decide *what* balance serves — competitive
> integrity, viable variety, a power fantasy, a difficulty target, a fair economy — because
> different goals demand opposite tuning. Balance toward the intended experience, not toward
> an abstract notion of "fairness."

## Rationale
Balance is not one thing; it's a family of goals that often conflict, and the word hides
which one you mean [S-schell-artofgamedesign]. Tuning a competitive game so every option is
viable at expert level is a completely different job from tuning a power-fantasy RPG (where
the player is *supposed* to become overwhelmingly strong) or a co-op game (where balance
means everyone contributes) or a horror game (where "unfair" is the point). Chasing generic
"fairness" without naming the target produces incoherent results — nerfing something that
was doing exactly what the design wanted, or "balancing" the fun out of a deliberately
lopsided moment. Naming the goal (this is DESIGN-0001 applied to numbers: balance for the
experience produced) turns tuning from vague fiddling into aimed work.

## Applies when
Before and during any balance pass, and any time someone says something is "unbalanced" —
the first question is "relative to what goal?"

## Does not apply / Exceptions
Not an exception so much as a caution: even within one game, different subsystems may have
different balance goals (the competitive PvP mode vs. the power-fantasy campaign), so
"decide what balance is for" is per-context, not one global answer. And some games
genuinely want *imbalance* as an experience (asymmetric horror, David-vs-Goliath), which is
a legitimate goal, not a failure to balance.

## Implementation (kept separate from the principle)
State the balance goal for each system explicitly (e.g. "all five archetypes should be
viable for a full playthrough" vs. "the mage should feel strongest late"). Judge tuning
changes against that goal, not against a reflex toward parity. Recognize when a subsystem's
goal differs from the game's and tune it on its own terms. Revisit the goal if the design
shifts.

## Disagreement
Balance-as-fairness (parity, competitive integrity) vs. balance-as-experience (tune toward
the intended feeling, even if "unfair") is the philosophical split under the whole domain.
Competitive games lean fairness; single-player and authored experiences lean experience.
This principle says: pick your meaning deliberately.

## Notes
The framing principle of the BAL domain — everything else (dominant strategies, symmetry,
methods) is *how*; this is *toward what*. Directly an application of DESIGN-0001. Confidence 4.

gdc-l1-bal-0001 decide what balance is for before you tune balance philosophy fairness intent > "balanced" is meaningless without a goal. decide what balance serves — competitive integrity, viable variety, a power fantasy, a difficulty target, a fair economy — because different goals demand opposite tuning. balance toward the intended experience, not toward an abstract notion of "fairness." balance is not one thing; it's a family of goals that often conflict, and the word hides which one you mean [s-schell-artofgamedesign]. tuning a competitive game so every option is viable at expert level is a completely different job from tuning a power-fantasy rpg (where the player is supposed to become overwhelmingly strong) or a co-op game (where balance means everyone contributes) or a horror game (where "unfair" is the point). chasing generic "fairness" without naming the target produces incoherent results — nerfing something that was doing exactly what the design wanted, or "balancing" the fun out of a deliberately lopsided moment. naming the goal (this is design-0001 applied to numbers: balance for the experience produced) turns tuning from vague fiddling into aimed work. before and during any balance pass, and any time someone says something is "unbalanced" — the first question is "relative to what goal?" not an exception so much as a caution: even within one game, different subsystems may have different balance goals (the competitive pvp mode vs. the power-fantasy campaign), so "decide what balance is for" is per-context, not one global answer. and some games genuinely want imbalance as an experience (asymmetric horror, david-vs-goliath), which is a legitimate goal, not a failure to balance. state the balance goal for each system explicitly (e.g. "all five archetypes should be viable for a full playthrough" vs. "the mage should feel strongest late"). judge tuning changes against that goal, not against a reflex toward parity. recognize when a subsystem's goal differs from the game's and tune it on its own terms. revisit the goal if the design shifts. balance-as-fairness (parity, competitive integrity) vs. balance-as-experience (tune toward the intended feeling, even if "unfair") is the philosophical split under the whole domain. competitive games lean fairness; single-player and authored experiences lean experience. this principle says: pick your meaning deliberately. the framing principle of the bal domain — everything else (dominant strategies, symmetry, methods) is how; this is toward what. directly an application of design-0001. confidence 4.


A dominant strategy — one option that is simply best — collapses choice: once found, everyone uses it, and the rest of the design becomes decoration. The central balance goal is that many options remain viable, especially in expert play. Hunt down and remove always-best options; success is a rich space of reasonable choices, not one correct answer.

---
id: GDC-L1-BAL-0002
title: Hunt down dominant strategies; protect viable diversity
layer: L1
domain: BAL
subdomain: dominant-strategies
type: contextual
confidence: 4
status: canonical
tags:
  - balance
  - dominant-strategy
  - viable-diversity
  - degenerate-strategy
related:
  - GDC-L1-SYS-0007
  - GDC-L1-DESIGN-0002
  - GDC-L1-BAL-0004
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-sirlin-balance
  - S-schreiber-balance
  - S-meier-interesting-decisions
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> A **dominant strategy** — one option that is simply best — collapses choice: once found,
> everyone uses it, and the rest of the design becomes decoration. The central balance goal
> is that *many options remain viable*, especially in expert play. Hunt down and remove
> always-best options; success is a rich space of reasonable choices, not one correct answer.

## Rationale
Once a single strategy dominates, informed players converge on it and the game's apparent
depth evaporates — a roster of "many characters" or "many builds" is a lie if only one is
worth picking [S-sirlin-balance]. This is the balance-craft enforcement of two principles
already in the constitution: interesting decisions require no dominant option (DESIGN-0002),
and players will optimize the fun out of a game by finding and repeating the best strategy
(SYS-0007). "Viable diversity" is the concrete target Sirlin names: a large number of the
available options should be reasonable choices, particularly at high skill. Balance work is,
in large part, the ongoing hunt for the current dominant option and the act of pulling it
back into the viable pack.

## Applies when
Any game with options that can be compared and optimized — builds, characters, weapons,
tactics, deck archetypes, upgrade paths. Sharpest in competitive and highly-optimized games,
but it applies to single-player build variety too.

## Does not apply / Exceptions
Perfect parity is neither achievable nor always desirable (see BAL-0006 and the
perfect-imbalance debate) — the goal is *viable diversity*, not identical power. Some
single-player games happily let players find an overpowered build as a reward for system
mastery (the "break the game" pleasure), where the dominant strategy is a feature the player
earned. And a *temporary* dominant strategy that a healthy metagame will answer is different
from a permanent one.

## Implementation (kept separate from the principle)
Actively look for the current best option (playtest, telemetry, expert feedback — BAL-0005)
and rein it in, rather than waiting for players to find it. Prefer bringing weak options up
to bringing the strong one down where it preserves fun. Give options situational strengths
and counters (BAL-0004) so "best" is context-dependent. Measure viability by *expert* play,
where dominance shows most clearly.

## Disagreement
"Kill dominant strategies for viable diversity" (Sirlin) is broadly held, but two live
tensions qualify it: whether to chase parity at all (perfect-imbalance camp says slight
dominance keeps the meta fresh — BAL-0006), and whether single-player games should even
prevent players from finding a dominant "break-the-game" build (many say let them).

## Notes
The BAL-domain enforcement of DESIGN-0002 (interesting decisions) and SYS-0007 (optimize the fun out). Confidence 4.

gdc-l1-bal-0002 hunt down dominant strategies; protect viable diversity balance dominant-strategy viable-diversity degenerate-strategy > a dominant strategy — one option that is simply best — collapses choice: once found, everyone uses it, and the rest of the design becomes decoration. the central balance goal is that many options remain viable, especially in expert play. hunt down and remove always-best options; success is a rich space of reasonable choices, not one correct answer. once a single strategy dominates, informed players converge on it and the game's apparent depth evaporates — a roster of "many characters" or "many builds" is a lie if only one is worth picking [s-sirlin-balance]. this is the balance-craft enforcement of two principles already in the constitution: interesting decisions require no dominant option (design-0002), and players will optimize the fun out of a game by finding and repeating the best strategy (sys-0007). "viable diversity" is the concrete target sirlin names: a large number of the available options should be reasonable choices, particularly at high skill. balance work is, in large part, the ongoing hunt for the current dominant option and the act of pulling it back into the viable pack. any game with options that can be compared and optimized — builds, characters, weapons, tactics, deck archetypes, upgrade paths. sharpest in competitive and highly-optimized games, but it applies to single-player build variety too. perfect parity is neither achievable nor always desirable (see bal-0006 and the perfect-imbalance debate) — the goal is viable diversity, not identical power. some single-player games happily let players find an overpowered build as a reward for system mastery (the "break the game" pleasure), where the dominant strategy is a feature the player earned. and a temporary dominant strategy that a healthy metagame will answer is different from a permanent one. actively look for the current best option (playtest, telemetry, expert feedback — bal-0005) and rein it in, rather than waiting for players to find it. prefer bringing weak options up to bringing the strong one down where it preserves fun. give options situational strengths and counters (bal-0004) so "best" is context-dependent. measure viability by expert play, where dominance shows most clearly. "kill dominant strategies for viable diversity" (sirlin) is broadly held, but two live tensions qualify it: whether to chase parity at all (perfect-imbalance camp says slight dominance keeps the meta fresh — bal-0006), and whether single-player games should even prevent players from finding a dominant "break-the-game" build (many say let them). the bal-domain enforcement of design-0002 (interesting decisions) and sys-0007 (optimize the fun out). confidence 4.


Symmetric design (all sides given identical options) is fair by construction but often bland and limits variety. Asymmetric design (different options with different strengths) is far richer and more expressive — but it is not fair by construction and must be balanced through extensive playtesting and data. The more asymmetric the game, the more testing balance demands.

---
id: GDC-L1-BAL-0003
title: Symmetry is safe; asymmetry is rich but must be earned through testing
layer: L1
domain: BAL
subdomain: symmetry-vs-asymmetry
type: contextual
confidence: 4
status: canonical
tags:
  - balance
  - symmetry
  - asymmetry
  - playtesting
  - variety
related:
  - GDC-L1-BAL-0002
  - GDC-L1-PLAYTEST-0005
  - GDC-L1-BAL-0004
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-schreiber-balance
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> **Symmetric** design (all sides given identical options) is fair by construction but often
> bland and limits variety. **Asymmetric** design (different options with different strengths)
> is far richer and more expressive — but it is *not* fair by construction and must be
> balanced through extensive playtesting and data. The more asymmetric the game, the more
> testing balance demands.

## Rationale
Symmetry buys fairness cheaply: if everyone has the same tools, no one can complain the sides
are unequal (chess is nearly symmetric — the main asymmetry is who moves first)
[S-schreiber-balance]. But symmetry also caps variety and can feel sterile — every mirror
match is the same match. Asymmetry (distinct factions, classes, characters, decks) is where
richness, identity, and replayability live, but each added difference multiplies the
interactions you must balance, and none of it is guaranteed fair — it has to be *discovered*
to be fair through play and data. Schreiber's rule is the practical takeaway: asymmetry and
required-playtesting scale together, so the expressive choice is also the expensive one.

## Applies when
Choosing and tuning any set of distinct options — factions, classes, characters, races,
decks, loadouts. The design decision (how asymmetric to be) is upstream of the balance cost.

## Does not apply / Exceptions
Symmetry isn't automatically boring — positional and emergent asymmetry (chess, Go) generate
enormous depth from symmetric starts. And some asymmetric games embrace *deliberate*
imbalance as identity (asymmetric-horror, 1-vs-many), where "fair" isn't the goal (BAL-0001).
Small or resource-constrained teams may choose more symmetry precisely to avoid the balancing
burden — a legitimate scope decision.

## Implementation (kept separate from the principle)
Decide how much asymmetry the game's identity needs, and budget the playtesting/data work to
match (BAL-0005) — don't ship heavy asymmetry you can't afford to balance. Use quantification
(cost curves, comparable stats) to get asymmetric options into the same rough range, then
lean on extensive expert play to find the real imbalances numbers miss. Prefer situational,
counter-based asymmetry (BAL-0004) so options differ in *kind*, keeping many viable.

## Disagreement
Symmetry (fair, cheaper to balance, can feel sterile) vs. asymmetry (rich, expressive,
expensive and never fair-by-default) is a core design/balance tradeoff. Competitive-fairness
purists and small teams lean symmetric; variety- and identity-driven designs lean asymmetric
and pay the testing cost.

## Notes
Sets the balance *cost* of a variety decision, and points at the methods (BAL-0005) and
structure (BAL-0004, counterplay) that make asymmetry tractable. Confidence 4.

gdc-l1-bal-0003 symmetry is safe; asymmetry is rich but must be earned through testing balance symmetry asymmetry playtesting variety > symmetric design (all sides given identical options) is fair by construction but often bland and limits variety. asymmetric design (different options with different strengths) is far richer and more expressive — but it is not fair by construction and must be balanced through extensive playtesting and data. the more asymmetric the game, the more testing balance demands. symmetry buys fairness cheaply: if everyone has the same tools, no one can complain the sides are unequal (chess is nearly symmetric — the main asymmetry is who moves first) [s-schreiber-balance]. but symmetry also caps variety and can feel sterile — every mirror match is the same match. asymmetry (distinct factions, classes, characters, decks) is where richness, identity, and replayability live, but each added difference multiplies the interactions you must balance, and none of it is guaranteed fair — it has to be discovered to be fair through play and data. schreiber's rule is the practical takeaway: asymmetry and required-playtesting scale together, so the expressive choice is also the expensive one. choosing and tuning any set of distinct options — factions, classes, characters, races, decks, loadouts. the design decision (how asymmetric to be) is upstream of the balance cost. symmetry isn't automatically boring — positional and emergent asymmetry (chess, go) generate enormous depth from symmetric starts. and some asymmetric games embrace deliberate imbalance as identity (asymmetric-horror, 1-vs-many), where "fair" isn't the goal (bal-0001). small or resource-constrained teams may choose more symmetry precisely to avoid the balancing burden — a legitimate scope decision. decide how much asymmetry the game's identity needs, and budget the playtesting/data work to match (bal-0005) — don't ship heavy asymmetry you can't afford to balance. use quantification (cost curves, comparable stats) to get asymmetric options into the same rough range, then lean on extensive expert play to find the real imbalances numbers miss. prefer situational, counter-based asymmetry (bal-0004) so options differ in kind, keeping many viable. symmetry (fair, cheaper to balance, can feel sterile) vs. asymmetry (rich, expressive, expensive and never fair-by-default) is a core design/balance tradeoff. competitive-fairness purists and small teams lean symmetric; variety- and identity-driven designs lean asymmetric and pay the testing cost. sets the balance cost of a variety decision, and points at the methods (bal-0005) and structure (bal-0004, counterplay) that make asymmetry tractable. confidence 4.


Options don't need equal power to be balanced — they need answers and contexts. An intransitive (rock-paper-scissors) structure and situational strengths keep many options viable without forcing everything to the same number, and they create interesting decisions: when to pick or play what.

---
id: GDC-L1-BAL-0004
title: Balance through counterplay and situational strength, not raw parity
layer: L1
domain: BAL
subdomain: numbers-and-curves
type: contextual
confidence: 4
status: canonical
tags:
  - balance
  - counterplay
  - intransitive
  - rock-paper-scissors
  - viable-diversity
related:
  - GDC-L1-DESIGN-0002
  - GDC-L1-BAL-0002
  - GDC-L1-BAL-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-schreiber-balance
  - S-sirlin-balance
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Options don't need *equal power* to be balanced — they need *answers* and *contexts*. An
> intransitive (rock-paper-scissors) structure and situational strengths keep many options
> viable without forcing everything to the same number, and they create interesting decisions:
> *when* to pick or play what.

## Rationale
Balancing purely by raw power (making everything numerically equal — a "transitive" tuning)
tends toward sameness and is brittle: the moment one option edges ahead, it dominates
(BAL-0002). Intransitive balance sidesteps this: if A beats B, B beats C, and C beats A, then
no option is universally best — each is strong in some matchups and weak in others, so the
interesting decision becomes *reading the situation and choosing accordingly*
[S-schreiber-balance]. Situational strength generalizes this: an option can be powerful in
its niche and weak outside it, staying viable without being universally strong. This is
DESIGN-0002 (interesting decisions) realized through balance structure — the choice matters
because context decides the winner, not a stat sheet.

## Applies when
Any set of competing options where you want many to stay viable — units, characters, weapons,
tactics, tools. Especially valuable where pure numeric parity would flatten variety.

## Does not apply / Exceptions
Hard rock-paper-scissors can feel arbitrary or "unfair" if a player is *forced* into a losing
matchup with no agency (pre-commitment RPS with no adaptation is frustrating) — counterplay
works best when players can *respond* (swap, adapt, outplay) rather than being locked into a
predetermined loss. And some games do want largely transitive, "bigger number" progression
(power fantasy, PvE scaling), where counter-structures aren't the point. Situational strength
also needs the situations to actually arise in play.

## Implementation (kept separate from the principle)
Give options distinct niches and answers rather than tuning them to identical power. Build
intransitive relationships where matchups matter, but let players adapt within a match so a
bad matchup is a challenge, not a sentence. Combine with asymmetry (BAL-0003) — counter-based
differences are how you make many distinct options viable at once (BAL-0002).

## Disagreement
Counterplay/intransitive balance (many viable options, decisions are contextual) vs. flat
parity or transitive power (simpler, but tends toward sameness or dominance). And hard RPS
without player agency is itself contested as frustrating. The craft is counters the player
can *respond* to.

## Notes
The structural technique that makes viable diversity (BAL-0002) and asymmetry (BAL-0003)
achievable, and a direct expression of DESIGN-0002 (interesting decisions). Confidence 4.

gdc-l1-bal-0004 balance through counterplay and situational strength, not raw parity balance counterplay intransitive rock-paper-scissors viable-diversity > options don't need equal power to be balanced — they need answers and contexts. an intransitive (rock-paper-scissors) structure and situational strengths keep many options viable without forcing everything to the same number, and they create interesting decisions: when to pick or play what. balancing purely by raw power (making everything numerically equal — a "transitive" tuning) tends toward sameness and is brittle: the moment one option edges ahead, it dominates (bal-0002). intransitive balance sidesteps this: if a beats b, b beats c, and c beats a, then no option is universally best — each is strong in some matchups and weak in others, so the interesting decision becomes reading the situation and choosing accordingly [s-schreiber-balance]. situational strength generalizes this: an option can be powerful in its niche and weak outside it, staying viable without being universally strong. this is design-0002 (interesting decisions) realized through balance structure — the choice matters because context decides the winner, not a stat sheet. any set of competing options where you want many to stay viable — units, characters, weapons, tactics, tools. especially valuable where pure numeric parity would flatten variety. hard rock-paper-scissors can feel arbitrary or "unfair" if a player is forced into a losing matchup with no agency (pre-commitment rps with no adaptation is frustrating) — counterplay works best when players can respond (swap, adapt, outplay) rather than being locked into a predetermined loss. and some games do want largely transitive, "bigger number" progression (power fantasy, pve scaling), where counter-structures aren't the point. situational strength also needs the situations to actually arise in play. give options distinct niches and answers rather than tuning them to identical power. build intransitive relationships where matchups matter, but let players adapt within a match so a bad matchup is a challenge, not a sentence. combine with asymmetry (bal-0003) — counter-based differences are how you make many distinct options viable at once (bal-0002). counterplay/intransitive balance (many viable options, decisions are contextual) vs. flat parity or transitive power (simpler, but tends toward sameness or dominance). and hard rps without player agency is itself contested as frustrating. the craft is counters the player can respond to. the structural technique that makes viable diversity (bal-0002) and asymmetry (bal-0003) achievable, and a direct expression of design-0002 (interesting decisions). confidence 4.


Use quantification — cost curves, spreadsheets, telemetry, win-rates — to reason about balance systematically and to flag outliers. But make the final call by play: math finds what's suspicious; playing decides what's fun and fair. The harder quantities are to compare, the more you must lean on playtesting.

---
id: GDC-L1-BAL-0005
title: Tune with data and math; decide with play
layer: L1
domain: BAL
subdomain: tuning-methods
type: contextual
confidence: 4
status: canonical
tags:
  - balance
  - tuning
  - quantification
  - telemetry
  - playtest
  - measure
related:
  - GDC-L1-PLAYTEST-0005
  - GDC-L1-PERF-0001
  - GDC-L1-PLAYTEST-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-schreiber-balance
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Use quantification — cost curves, spreadsheets, telemetry, win-rates — to reason about
> balance systematically and to *flag* outliers. But make the final call by *play*: math
> finds what's suspicious; playing decides what's fun and fair. The harder quantities are to
> compare, the more you must lean on playtesting.

## Rationale
Numbers are indispensable for balance at scale: a cost curve lets you price a hundred items
consistently, and telemetry surfaces the option with a 70% pick rate you'd never spot by feel
[S-schreiber-balance]. But numbers also lie by omission — they can't fully capture how an
option *feels*, how it interacts with everything else, or whether a statistically-fine option
is miserable to play against. So the two methods are complementary: quantify to narrow the
search and catch outliers, then *play* to judge. Schreiber's own caveat — the harder direct
comparison is, the more playtesting you need — captures the balance: math scales, play judges,
and the murkier the math, the more the judgment falls to play. This is the balance-specific
form of "measure, don't guess" (PERF-0001) fused with "watch behavior, not just numbers"
(PLAYTEST-0005).

## Applies when
Any balance pass, at any scale — from pricing a single item to tuning a live competitive
roster. Data-heavy at large scale; play-heavy where interactions are complex or subjective.

## Does not apply / Exceptions
Tiny option sets can be balanced almost entirely by play (no spreadsheet needed for three
weapons). Conversely, at massive scale (live-service with millions of matches) telemetry
carries more weight — though even there, the numbers point and humans still decide (PROG-0004's
warning against optimizing the metric instead of the experience applies). Pure faith in either
extreme — spreadsheet-only or vibes-only — fails.

## Implementation (kept separate from the principle)
Build a cost/value model so options are priced consistently, and instrument the game to see
pick rates, win rates, and drop-off (PLAYTEST-0005). Use both to *find* imbalances; then
playtest the flagged cases and decide by experience, not by the number alone. Where quantities
resist comparison, weight playtesting more. Keep before/after data so you can tell a change
helped.

## Disagreement
Data-driven balance (quantify, trust metrics, A/B test) vs. designer-judgment balance (play,
feel, expert intuition). Data scales and catches blind spots; judgment captures fun and
context that numbers miss. The synthesis — data flags, play decides — is what most balance
designers converge on; the debate is the *weighting*, which shifts with scale and how
measurable the game is.

## Notes
The methods principle of BAL, unifying the "measure, don't guess" thread (PERF-0001,
PLAYTEST-0001/0005) with the reality that balance is ultimately a judgment about experience.
Confidence 4.

gdc-l1-bal-0005 tune with data and math; decide with play balance tuning quantification telemetry playtest measure > use quantification — cost curves, spreadsheets, telemetry, win-rates — to reason about balance systematically and to flag outliers. but make the final call by play: math finds what's suspicious; playing decides what's fun and fair. the harder quantities are to compare, the more you must lean on playtesting. numbers are indispensable for balance at scale: a cost curve lets you price a hundred items consistently, and telemetry surfaces the option with a 70% pick rate you'd never spot by feel [s-schreiber-balance]. but numbers also lie by omission — they can't fully capture how an option feels, how it interacts with everything else, or whether a statistically-fine option is miserable to play against. so the two methods are complementary: quantify to narrow the search and catch outliers, then play to judge. schreiber's own caveat — the harder direct comparison is, the more playtesting you need — captures the balance: math scales, play judges, and the murkier the math, the more the judgment falls to play. this is the balance-specific form of "measure, don't guess" (perf-0001) fused with "watch behavior, not just numbers" (playtest-0005). any balance pass, at any scale — from pricing a single item to tuning a live competitive roster. data-heavy at large scale; play-heavy where interactions are complex or subjective. tiny option sets can be balanced almost entirely by play (no spreadsheet needed for three weapons). conversely, at massive scale (live-service with millions of matches) telemetry carries more weight — though even there, the numbers point and humans still decide (prog-0004's warning against optimizing the metric instead of the experience applies). pure faith in either extreme — spreadsheet-only or vibes-only — fails. build a cost/value model so options are priced consistently, and instrument the game to see pick rates, win rates, and drop-off (playtest-0005). use both to find imbalances; then playtest the flagged cases and decide by experience, not by the number alone. where quantities resist comparison, weight playtesting more. keep before/after data so you can tell a change helped. data-driven balance (quantify, trust metrics, a/b test) vs. designer-judgment balance (play, feel, expert intuition). data scales and catches blind spots; judgment captures fun and context that numbers miss. the synthesis — data flags, play decides — is what most balance designers converge on; the debate is the weighting, which shifts with scale and how measurable the game is. the methods principle of bal, unifying the "measure, don't guess" thread (perf-0001, playtest-0001/0005) with the reality that balance is ultimately a judgment about experience. confidence 4.


Players experience balance as a feeling, and a game can be mathematically balanced yet feel terrible — or slightly "imbalanced" yet feel great. Weigh perceived fairness and fun alongside the numbers: a slightly imbalanced option that's exciting can beat a perfectly tuned one that's dull, and even perfect balance can go stale.

---
id: GDC-L1-BAL-0006
title: Balance for fun and perceived fairness, not just mathematical parity
layer: L1
domain: BAL
subdomain: balance-philosophy
type: stylistic
confidence: 3
status: canonical
tags:
  - balance
  - perceived-fairness
  - fun
  - perfect-imbalance
  - metagame
related:
  - GDC-L1-BAL-0001
  - GDC-L1-DESIGN-0001
  - GDC-L1-BAL-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-perfect-imbalance
  - S-sirlin-balance
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Players experience balance as a *feeling*, and a game can be mathematically balanced yet
> feel terrible — or slightly "imbalanced" yet feel great. Weigh perceived fairness and fun
> alongside the numbers: a slightly imbalanced option that's exciting can beat a perfectly
> tuned one that's dull, and even perfect balance can go stale.

## Rationale
Balance serves the experience (BAL-0001, DESIGN-0001), and the experience is subjective:
what matters to players is whether the game *feels* fair and fun, which doesn't always track
the spreadsheet. Two well-known consequences. First, *perceived* imbalance can wreck a
mathematically-fine game (an option that's technically balanced but feels cheap or
un-fun-to-face poisons the experience), while a bit of genuine imbalance can go unnoticed or
even feel good. Second — the "Perfect Imbalance" argument — a perfectly balanced game trends
toward *solved*: once optimal play is found, everyone executes the same known strategies and
the metagame stagnates, whereas slight, shifting imbalances keep players hunting new answers
and keep the game alive [S-perfect-imbalance]. So chasing parity for its own sake can cost
you fun and freshness.

## Applies when
Balance philosophy and any decision that trades measured parity against how the game feels
or how lively its metagame stays. Most pointed in competitive and long-lived games.

## Does not apply / Exceptions
This does *not* license lazy or lopsided balance — "it's more fun imbalanced" is often an
excuse for a dominant strategy (BAL-0002) that genuinely needs fixing. Competitive-integrity
contexts (esports, ranked ladders) weight measured fairness heavily, because perceived
unfairness there erodes trust in the competition itself.

## Implementation (kept separate from the principle)
Track *perceived* fairness (player sentiment, "feels cheap" complaints, what people ban or
avoid) alongside the numbers (BAL-0005). When an option is technically balanced but hated to
play against, treat that as a real problem. Be willing to leave — or even introduce — slight,
healthy imbalance to keep the meta evolving, while still hunting the *dominant* strategies
that actually collapse choice.

## Disagreement
This is the domain's sharpest live debate. **Perfect Imbalance** (Extra Credits): deliberate,
shifting slight imbalance keeps the metagame fresh and avoids the "solved game" endpoint.
**Balance-for-viable-diversity** (Sirlin): intentionally making the game unfair doesn't make
sense; aim for many viable options through genuine balance, and let a healthy metagame emerge
from *diversity*, not from engineered unfairness. Both agree perfect parity can stagnate and
that dominant strategies are bad; they disagree on whether the answer is *engineered
imbalance* or *viable diversity*. Typed `stylistic` because it is a genuine, unresolved values
split among expert designers.

## Notes
Where balance meets fun and perception, and home to the Perfect-Imbalance-vs-Sirlin debate
(see `index/DISAGREEMENTS.md`). Confidence 3: the phenomena (perceived fairness, solved-game
stagnation) are real and well-argued, but the prescriptive question is genuinely contested.

gdc-l1-bal-0006 balance for fun and perceived fairness, not just mathematical parity balance perceived-fairness fun perfect-imbalance metagame > players experience balance as a feeling, and a game can be mathematically balanced yet feel terrible — or slightly "imbalanced" yet feel great. weigh perceived fairness and fun alongside the numbers: a slightly imbalanced option that's exciting can beat a perfectly tuned one that's dull, and even perfect balance can go stale. balance serves the experience (bal-0001, design-0001), and the experience is subjective: what matters to players is whether the game feels fair and fun, which doesn't always track the spreadsheet. two well-known consequences. first, perceived imbalance can wreck a mathematically-fine game (an option that's technically balanced but feels cheap or un-fun-to-face poisons the experience), while a bit of genuine imbalance can go unnoticed or even feel good. second — the "perfect imbalance" argument — a perfectly balanced game trends toward solved: once optimal play is found, everyone executes the same known strategies and the metagame stagnates, whereas slight, shifting imbalances keep players hunting new answers and keep the game alive [s-perfect-imbalance]. so chasing parity for its own sake can cost you fun and freshness. balance philosophy and any decision that trades measured parity against how the game feels or how lively its metagame stays. most pointed in competitive and long-lived games. this does not license lazy or lopsided balance — "it's more fun imbalanced" is often an excuse for a dominant strategy (bal-0002) that genuinely needs fixing. competitive-integrity contexts (esports, ranked ladders) weight measured fairness heavily, because perceived unfairness there erodes trust in the competition itself. track perceived fairness (player sentiment, "feels cheap" complaints, what people ban or avoid) alongside the numbers (bal-0005). when an option is technically balanced but hated to play against, treat that as a real problem. be willing to leave — or even introduce — slight, healthy imbalance to keep the meta evolving, while still hunting the dominant strategies that actually collapse choice. this is the domain's sharpest live debate. perfect imbalance (extra credits): deliberate, shifting slight imbalance keeps the metagame fresh and avoids the "solved game" endpoint. balance-for-viable-diversity (sirlin): intentionally making the game unfair doesn't make sense; aim for many viable options through genuine balance, and let a healthy metagame emerge from diversity, not from engineered unfairness. both agree perfect parity can stagnate and that dominant strategies are bad; they disagree on whether the answer is engineered imbalance or viable diversity. typed stylistic because it is a genuine, unresolved values split among expert designers. where balance meets fun and perception, and home to the perfect-imbalance-vs-sirlin debate (see index/disagreements.md). confidence 3: the phenomena (perceived fairness, solved-game stagnation) are real and well-argued, but the prescriptive question is genuinely contested.


Lead the player's attention and movement with the environment itself — light, color, contrast, leading lines, and composition — so they find their way and notice what matters without explicit markers, quest arrows, or hand-holding. Build the space so the right place pulls the eye.

---
id: GDC-L1-LEVEL-0001
title: Guide the player's eye with the environment, not with hand-holding
layer: L1
domain: LEVEL
subdomain: guidance-and-legibility
type: contextual
confidence: 4
status: canonical
tags:
  - level-design
  - guidance
  - composition
  - lighting
  - leading-lines
related:
  - GDC-L1-LEVEL-0002
  - GDC-L1-LEVEL-0006
  - GDC-L1-DESIGN-0006
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-leveldesign-guidance
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Lead the player's attention and movement with the environment itself — light, color,
> contrast, leading lines, and composition — so they find their way and notice what
> matters *without* explicit markers, quest arrows, or hand-holding. Build the space so the
> right place pulls the eye.

## Rationale
Players read space the way they read a photograph: bright areas, high-contrast edges,
saturated color, converging lines, and framing all draw the eye, and movement tends to
follow the gaze [S-leveldesign-guidance]. A designer who controls these controls where
players look and go — a spotlight in a dark room, a shaft of light on a doorway, a pipe or
hedgerow that leads toward the exit, an architectural line that points at the objective.
This "implicit" guidance preserves the feeling of self-directed discovery (the player
believes they chose the path), whereas explicit markers (giant arrows, waypoint UI)
short-circuit that feeling and train players to follow a HUD instead of reading the world.
Guiding through the environment keeps players *in* the space.

## Applies when
Any spatial game where the player navigates and where you want them to reach places, notice
things, or feel guided without being told. Especially valuable for immersive, exploration-,
and atmosphere-driven games.

## Does not apply / Exceptions
Explicit guidance (markers, minimaps, objective arrows) is legitimate and often necessary —
in large open worlds, for accessibility, and where finding-the-way is friction rather than
fun. Highly systemic or sandbox games may deliberately provide *no* guidance and let players
set their own goals. And implicit guidance can fail: over-subtle cues leave players lost
(see LEVEL-0002 on legibility). Match the guidance strength to how much wayfinding should
be part of the experience.

## Implementation (kept separate from the principle)
Use light and contrast as your strongest tools (the eye goes to the brightest readable
point). Add leading lines in architecture, props, and terrain that point where you want
players to go. Reserve your most saturated color and strongest contrast for things that
matter. Playtest by watching where first-time players actually look and walk (PLAYTEST-0001)
— if they miss the path, the composition, not the player, is wrong.

## Disagreement
Implicit (environmental) vs. explicit (UI markers) guidance is a real spectrum: implicit
preserves immersion and the sense of discovery; explicit guarantees players aren't lost and
aids accessibility. Immersive-sim and exploration design lean implicit; large open-world and
broad-audience design lean explicit. Most games blend, matching the mix to how much
wayfinding should be a skill.

## Notes
The attention half of level legibility; its orientation half is LEVEL-0002. A concrete,
spatial expression of DESIGN-0006 (legible consequences/agency). Confidence 4.

gdc-l1-level-0001 guide the player's eye with the environment, not with hand-holding level-design guidance composition lighting leading-lines > lead the player's attention and movement with the environment itself — light, color, contrast, leading lines, and composition — so they find their way and notice what matters without explicit markers, quest arrows, or hand-holding. build the space so the right place pulls the eye. players read space the way they read a photograph: bright areas, high-contrast edges, saturated color, converging lines, and framing all draw the eye, and movement tends to follow the gaze [s-leveldesign-guidance]. a designer who controls these controls where players look and go — a spotlight in a dark room, a shaft of light on a doorway, a pipe or hedgerow that leads toward the exit, an architectural line that points at the objective. this "implicit" guidance preserves the feeling of self-directed discovery (the player believes they chose the path), whereas explicit markers (giant arrows, waypoint ui) short-circuit that feeling and train players to follow a hud instead of reading the world. guiding through the environment keeps players in the space. any spatial game where the player navigates and where you want them to reach places, notice things, or feel guided without being told. especially valuable for immersive, exploration-, and atmosphere-driven games. explicit guidance (markers, minimaps, objective arrows) is legitimate and often necessary — in large open worlds, for accessibility, and where finding-the-way is friction rather than fun. highly systemic or sandbox games may deliberately provide no guidance and let players set their own goals. and implicit guidance can fail: over-subtle cues leave players lost (see level-0002 on legibility). match the guidance strength to how much wayfinding should be part of the experience. use light and contrast as your strongest tools (the eye goes to the brightest readable point). add leading lines in architecture, props, and terrain that point where you want players to go. reserve your most saturated color and strongest contrast for things that matter. playtest by watching where first-time players actually look and walk (playtest-0001) — if they miss the path, the composition, not the player, is wrong. implicit (environmental) vs. explicit (ui markers) guidance is a real spectrum: implicit preserves immersion and the sense of discovery; explicit guarantees players aren't lost and aids accessibility. immersive-sim and exploration design lean implicit; large open-world and broad-audience design lean explicit. most games blend, matching the mix to how much wayfinding should be a skill. the attention half of level legibility; its orientation half is level-0002. a concrete, spatial expression of design-0006 (legible consequences/agency). confidence 4.


Design space so the player can always answer where am I, where can I go, where have I been? Give the world the ingredients of a mental map — memorable landmarks, distinct districts, clear paths, readable edges and nodes — so it organizes into a coherent whole and players navigate by understanding rather than by luck.

---
id: GDC-L1-LEVEL-0002
title: Make space legible — support the player's mental map
layer: L1
domain: LEVEL
subdomain: guidance-and-legibility
type: contextual
confidence: 4
status: canonical
tags:
  - level-design
  - legibility
  - wayfinding
  - landmarks
  - navigation
related:
  - GDC-L1-LEVEL-0001
  - GDC-L1-SYS-0006
  - GDC-L1-DESIGN-0006
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-lynch-image-city
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Design space so the player can always answer *where am I, where can I go, where have I
> been?* Give the world the ingredients of a mental map — memorable **landmarks**, distinct
> **districts**, clear **paths**, readable **edges** and **nodes** — so it organizes into a
> coherent whole and players navigate by understanding rather than by luck.

## Rationale
People build mental maps of a space from a small set of elements — paths (routes), edges
(boundaries), districts (areas with a shared character), nodes (junctions), and landmarks
(distinctive reference points visible from afar) — and a space rich in these is "legible":
easy to recognize, organize, and navigate without disorientation [S-lynch-image-city]. A
level that ignores them becomes a samey maze where every corridor looks alike and players
get lost, retread, and disengage. Strong landmarks let players orient after a distraction
(a big fight, a detour) and re-fix their goal; distinct districts make "I'm in the
sewers now" legible at a glance; clear paths and nodes make choices comprehensible.
Legibility is what turns navigation from a chore into confident movement.

## Applies when
Any navigable space, and critically any large, open, or interconnected world where getting
lost is a real risk. The bigger and more open the space, the more it depends on landmarks
and district identity.

## Does not apply / Exceptions
Disorientation is sometimes the *goal*: horror, dread, and certain puzzle or dream-logic
spaces deliberately break legibility to unsettle the player (a legible haunted house isn't
scary). Deliberately labyrinthine design — mazes, getting-lost-as-content — inverts this on
purpose. And an intentionally illegible *first* impression can make later mastery of the
space satisfying (Dark Souls' interconnected world rewards learning it). The principle is
the default; breaking it should be a choice.

## Implementation (kept separate from the principle)
Plant landmarks tall or bright enough to be seen across the level, and make them distinct
from each other. Give districts their own palette, architecture, and mood so areas are
identifiable at a glance. Keep paths readable and junctions (nodes) clear. Vary silhouettes
so places aren't confusable. Test by asking players to point toward where they've been —
if they can't, the space isn't legible.

## Disagreement
Legibility vs. deliberate disorientation is the axis: readable, confident navigation (most
games) vs. intentional lostness for horror, mystery, or mastery-through-learning. Both are
valid; the question is whether *knowing where you are* should be given or earned.

## Notes
The orientation half of level legibility (LEVEL-0001 is the attention half), and the spatial counterpart of SYS-0006 (legible systems). Confidence 4.

gdc-l1-level-0002 make space legible — support the player's mental map level-design legibility wayfinding landmarks navigation > design space so the player can always answer where am i, where can i go, where have i been? give the world the ingredients of a mental map — memorable landmarks, distinct districts, clear paths, readable edges and nodes — so it organizes into a coherent whole and players navigate by understanding rather than by luck. people build mental maps of a space from a small set of elements — paths (routes), edges (boundaries), districts (areas with a shared character), nodes (junctions), and landmarks (distinctive reference points visible from afar) — and a space rich in these is "legible": easy to recognize, organize, and navigate without disorientation [s-lynch-image-city]. a level that ignores them becomes a samey maze where every corridor looks alike and players get lost, retread, and disengage. strong landmarks let players orient after a distraction (a big fight, a detour) and re-fix their goal; distinct districts make "i'm in the sewers now" legible at a glance; clear paths and nodes make choices comprehensible. legibility is what turns navigation from a chore into confident movement. any navigable space, and critically any large, open, or interconnected world where getting lost is a real risk. the bigger and more open the space, the more it depends on landmarks and district identity. disorientation is sometimes the goal: horror, dread, and certain puzzle or dream-logic spaces deliberately break legibility to unsettle the player (a legible haunted house isn't scary). deliberately labyrinthine design — mazes, getting-lost-as-content — inverts this on purpose. and an intentionally illegible first impression can make later mastery of the space satisfying (dark souls' interconnected world rewards learning it). the principle is the default; breaking it should be a choice. plant landmarks tall or bright enough to be seen across the level, and make them distinct from each other. give districts their own palette, architecture, and mood so areas are identifiable at a glance. keep paths readable and junctions (nodes) clear. vary silhouettes so places aren't confusable. test by asking players to point toward where they've been — if they can't, the space isn't legible. legibility vs. deliberate disorientation is the axis: readable, confident navigation (most games) vs. intentional lostness for horror, mystery, or mastery-through-learning. both are valid; the question is whether knowing where you are should be given or earned. the orientation half of level legibility (level-0001 is the attention half), and the spatial counterpart of sys-0006 (legible systems). confidence 4.


Shape a level's intensity over time like music: build tension, deliver a peak, then grant release. Sustained high intensity exhausts and numbs; sustained low intensity bores. Design the dramatic curve deliberately, with genuine rest beats after peaks.

---
id: GDC-L1-LEVEL-0003
title: Pace intensity — shape a rhythm of tension and release
layer: L1
domain: LEVEL
subdomain: pacing
type: contextual
confidence: 4
status: canonical
tags:
  - level-design
  - pacing
  - tension-release
  - rhythm
  - flow
related:
  - GDC-L1-DESIGN-0004
  - GDC-L1-PROG-0001
  - GDC-L1-LEVEL-0004
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-leveldesign-guidance
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Shape a level's intensity over time like music: build tension, deliver a peak, then grant
> release. Sustained high intensity exhausts and numbs; sustained low intensity bores.
> Design the dramatic curve deliberately, with genuine rest beats after peaks.

## Rationale
Intensity is relative — a climax only lands if quieter moments precede it, and a scary
moment only frightens against a lull. A flat-out level fatigues players and flattens its own
peaks (if everything is intense, nothing is); a flat-quiet level never grips. Pacing the
rise and fall keeps the player emotionally engaged and physically able to keep going, and it
gives the highs somewhere to stand out from [S-leveldesign-guidance]. This is the
level-scale expression of flow (DESIGN-0004): the intensity curve is how you keep challenge
oscillating in the engaging band, and the rest beats are where the player recovers and
consolidates. Combat, exploration, quiet, and spectacle are the instruments; their
arrangement over time is the composition.

## Applies when
Any level or sequence with a temporal experience — action, adventure, horror, and story
levels especially. Applies fractally: within an encounter, a level, and the whole game.

## Does not apply / Exceptions
Some experiences deliberately hold one register: a relentless bullet-hell or an unbroken
horror set-piece may sustain intensity on purpose, and a meditative/cozy game may stay
gentle throughout. Systemic sandboxes generate their own pacing from player choices rather
than authored curves. The principle is about *authored* pacing; emergent games shape the
conditions instead.

## Implementation (kept separate from the principle)
Sketch the intended intensity curve for a level before building it, and place peaks, builds,
and rests deliberately. Follow big peaks with real downtime — a safe room, a vista, a quiet
traversal — so the player recovers (this is also where reward/save/consolidation beats fit).
Vary the instruments (combat, puzzle, exploration, spectacle) to avoid monotony even at a
constant intensity. Watch playtesters for fatigue and for peaks that don't land.

## Disagreement
Authored pacing (deliberate curves) vs. emergent pacing (systems + player choice generate
rhythm) is the main split, plus the deliberate-monotone exception (sustained horror or
relentless action). All are valid; the choice follows whether the experience is composed or
generated.

## Notes
The temporal companion to the spatial LEVEL principles, and the level-scale form of
DESIGN-0004 (flow) and PROG-0001 (pacing of power). Confidence 4.

gdc-l1-level-0003 pace intensity — shape a rhythm of tension and release level-design pacing tension-release rhythm flow > shape a level's intensity over time like music: build tension, deliver a peak, then grant release. sustained high intensity exhausts and numbs; sustained low intensity bores. design the dramatic curve deliberately, with genuine rest beats after peaks. intensity is relative — a climax only lands if quieter moments precede it, and a scary moment only frightens against a lull. a flat-out level fatigues players and flattens its own peaks (if everything is intense, nothing is); a flat-quiet level never grips. pacing the rise and fall keeps the player emotionally engaged and physically able to keep going, and it gives the highs somewhere to stand out from [s-leveldesign-guidance]. this is the level-scale expression of flow (design-0004): the intensity curve is how you keep challenge oscillating in the engaging band, and the rest beats are where the player recovers and consolidates. combat, exploration, quiet, and spectacle are the instruments; their arrangement over time is the composition. any level or sequence with a temporal experience — action, adventure, horror, and story levels especially. applies fractally: within an encounter, a level, and the whole game. some experiences deliberately hold one register: a relentless bullet-hell or an unbroken horror set-piece may sustain intensity on purpose, and a meditative/cozy game may stay gentle throughout. systemic sandboxes generate their own pacing from player choices rather than authored curves. the principle is about authored pacing; emergent games shape the conditions instead. sketch the intended intensity curve for a level before building it, and place peaks, builds, and rests deliberately. follow big peaks with real downtime — a safe room, a vista, a quiet traversal — so the player recovers (this is also where reward/save/consolidation beats fit). vary the instruments (combat, puzzle, exploration, spectacle) to avoid monotony even at a constant intensity. watch playtesters for fatigue and for peaks that don't land. authored pacing (deliberate curves) vs. emergent pacing (systems + player choice generate rhythm) is the main split, plus the deliberate-monotone exception (sustained horror or relentless action). all are valid; the choice follows whether the experience is composed or generated. the temporal companion to the spatial level principles, and the level-scale form of design-0004 (flow) and prog-0001 (pacing of power). confidence 4.


Use the environment to teach. Introduce a mechanic in a safe space where failure is cheap, then let the layout pose progressively harder applications of it. A well-built level teaches by doing, spatially, without text boxes — it is the game's best tutorial.

---
id: GDC-L1-LEVEL-0004
title: Teach through space — the level is a tutorial
layer: L1
domain: LEVEL
subdomain: encounter-design
type: contextual
confidence: 4
status: canonical
tags:
  - level-design
  - teaching
  - onboarding
  - spatial-teaching
  - safe-introduction
related:
  - GDC-L1-PROG-0005
  - GDC-L1-DESIGN-0003
  - GDC-L1-LEVEL-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-mark-brown-4step
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Use the environment to teach. Introduce a mechanic in a **safe** space where failure is
> cheap, then let the layout pose progressively harder applications of it. A well-built
> level teaches by *doing*, spatially, without text boxes — it is the game's best tutorial.

## Rationale
Players learn mechanics far better by using them in a controlled space than by reading
instructions, and space is a superb teacher because it can *force* the right lesson: a pit
with a clear ledge teaches jumping; a gap that only a dash can cross teaches the dash the
moment after you earned it. The four-step arc (introduce safely → develop → twist → conclude)
maps directly onto physical space — a safe first encounter, a complication, a
recontextualization, and a final payoff [S-mark-brown-4step]. This is
"fun is learning" (DESIGN-0003) delivered through geometry, and it keeps guidance implicit
(LEVEL-0001) rather than interrupting play with tutorial pop-ups.

## Applies when
Introducing any mechanic, tool, or enemy through the world — tutorial areas, early levels,
and the first appearance of anything new anywhere in the game.

## Does not apply / Exceptions
Highly systemic games teach through experimentation rather than authored spatial arcs. And some complex systems genuinely need explicit instruction that space alone can't convey.

## Implementation (kept separate from the principle)
For each new mechanic, build a safe introduction (try and fail without punishment), then
spaces that develop and twist it, then a concluding payoff or demonstration. Use sightlines and composition
(LEVEL-0001) to show the lesson before demanding it. Sequence introductions so the learning
load stays steady (PROG-0005, PROG-0001). Where the game's identity is discovery, hide the
"teach" step and let the space *imply* the mechanic.

## Disagreement
Authored spatial teaching (guided, clear) vs. discovery teaching (unguided, figure-it-out).
The former maximizes clarity and reach; the latter maximizes the pleasure of insight and
suits systemic/mystery/discovery games. Same axis as PROG-0005, expressed in space.

## Notes
The spatial delivery of PROG-0005 (introduce-develop-twist-conclude) and DESIGN-0003 (fun is learning). Confidence 4.

gdc-l1-level-0004 teach through space — the level is a tutorial level-design teaching onboarding spatial-teaching safe-introduction > use the environment to teach. introduce a mechanic in a safe space where failure is cheap, then let the layout pose progressively harder applications of it. a well-built level teaches by doing, spatially, without text boxes — it is the game's best tutorial. players learn mechanics far better by using them in a controlled space than by reading instructions, and space is a superb teacher because it can force the right lesson: a pit with a clear ledge teaches jumping; a gap that only a dash can cross teaches the dash the moment after you earned it. the four-step arc (introduce safely → develop → twist → conclude) maps directly onto physical space — a safe first encounter, a complication, a recontextualization, and a final payoff [s-mark-brown-4step]. this is "fun is learning" (design-0003) delivered through geometry, and it keeps guidance implicit (level-0001) rather than interrupting play with tutorial pop-ups. introducing any mechanic, tool, or enemy through the world — tutorial areas, early levels, and the first appearance of anything new anywhere in the game. highly systemic games teach through experimentation rather than authored spatial arcs. and some complex systems genuinely need explicit instruction that space alone can't convey. for each new mechanic, build a safe introduction (try and fail without punishment), then spaces that develop and twist it, then a concluding payoff or demonstration. use sightlines and composition (level-0001) to show the lesson before demanding it. sequence introductions so the learning load stays steady (prog-0005, prog-0001). where the game's identity is discovery, hide the "teach" step and let the space imply the mechanic. authored spatial teaching (guided, clear) vs. discovery teaching (unguided, figure-it-out). the former maximizes clarity and reach; the latter maximizes the pleasure of insight and suits systemic/mystery/discovery games. same axis as prog-0005, expressed in space. the spatial delivery of prog-0005 (introduce-develop-twist-conclude) and design-0003 (fun is learning). confidence 4.


Give players a legible critical path so they rarely get truly stuck or lost — and reward those who stray from it with worthwhile discoveries. Pure linearity denies agency; pure openness invites disorientation and empty wandering. The craft is a readable spine with branches that pay.

---
id: GDC-L1-LEVEL-0005
title: Balance guidance with exploration — a clear spine and rewarded detours
layer: L1
domain: LEVEL
subdomain: open-vs-linear
type: contextual
confidence: 4
status: canonical
tags:
  - level-design
  - exploration
  - critical-path
  - agency
  - open-vs-linear
related:
  - GDC-L1-DESIGN-0006
  - GDC-L1-SYS-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-leveldesign-guidance
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Give players a legible critical path so they rarely get truly stuck or lost — and reward
> those who stray from it with worthwhile discoveries. Pure linearity denies agency; pure
> openness invites disorientation and empty wandering. The craft is a readable spine with
> branches that pay.

## Rationale
Exploration is only rewarding when two things are true at once: the player can always find their way forward (so straying is a choice, not a trap), and straying is *worth it* (so the choice has value). A level that is all corridor removes the player's agency to explore; a level that is all open space with no legible spine leaves players wandering, unsure if they're making progress or missing everything [S-leveldesign-guidance]. The resolution is a clear main route (guidance, LEVEL-0001/0002) threaded through optional space that rewards curiosity — so the directed player never gets lost and the curious player always gets paid.

## Applies when
Any level with more than a single forced path — most exploration, adventure, RPG, and
metroidvania design. The tension between guidance and freedom is central to all of them.

## Does not apply / Exceptions
Deliberately linear designs (many story-driven and cinematic games) trade exploration for a
tightly controlled, authored experience — a valid choice, not a failure. Fully open sandbox
designs push almost entirely to the freedom pole and accept some disorientation as the price
of emergence (SYS-0003). Where a game sits on the linear↔open axis is a defining decision;
this principle governs the large middle where both matter.

## Implementation (kept separate from the principle)
Establish a readable critical path (landmarks, leading lines, district identity) so forward progress is always findable. Scale the reward to the effort to reach it. Use guidance to keep the spine legible without walling off the branches.

## Disagreement
Linear (authored, controlled, no getting lost) vs. open (free, exploratory, some
disorientation) is one of level design's defining axes. Both extremes ship great games; the
choice follows whether the experience is a directed story or a space to inhabit. This
principle is the balanced middle both extremes bend toward.

## Notes
Connects to DESIGN-0006 (agency) and SYS-0003 (emergent vs authored). Confidence 4.

gdc-l1-level-0005 balance guidance with exploration — a clear spine and rewarded detours level-design exploration critical-path agency open-vs-linear > give players a legible critical path so they rarely get truly stuck or lost — and reward those who stray from it with worthwhile discoveries. pure linearity denies agency; pure openness invites disorientation and empty wandering. the craft is a readable spine with branches that pay. exploration is only rewarding when two things are true at once: the player can always find their way forward (so straying is a choice, not a trap), and straying is worth it (so the choice has value). a level that is all corridor removes the player's agency to explore; a level that is all open space with no legible spine leaves players wandering, unsure if they're making progress or missing everything [s-leveldesign-guidance]. the resolution is a clear main route (guidance, level-0001/0002) threaded through optional space that rewards curiosity — so the directed player never gets lost and the curious player always gets paid. any level with more than a single forced path — most exploration, adventure, rpg, and metroidvania design. the tension between guidance and freedom is central to all of them. deliberately linear designs (many story-driven and cinematic games) trade exploration for a tightly controlled, authored experience — a valid choice, not a failure. fully open sandbox designs push almost entirely to the freedom pole and accept some disorientation as the price of emergence (sys-0003). where a game sits on the linear↔open axis is a defining decision; this principle governs the large middle where both matter. establish a readable critical path (landmarks, leading lines, district identity) so forward progress is always findable. scale the reward to the effort to reach it. use guidance to keep the spine legible without walling off the branches. linear (authored, controlled, no getting lost) vs. open (free, exploratory, some disorientation) is one of level design's defining axes. both extremes ship great games; the choice follows whether the experience is a directed story or a space to inhabit. this principle is the balanced middle both extremes bend toward. connects to design-0006 (agency) and sys-0003 (emergent vs authored). confidence 4.