Let the player see a destination before they can reach it. A framed vista of a distant landmark, a glimpse of a locked-off area, or a preview of a coming challenge plants a self-directed goal and builds anticipation — so that arriving later feels earned and meaningful.

---
id: GDC-L1-LEVEL-0006
title: Show before you go — use vistas and foreshadowing to plant goals
layer: L1
domain: LEVEL
subdomain: composition
type: contextual
confidence: 3
status: canonical
tags:
  - level-design
  - vistas
  - foreshadowing
  - anticipation
  - composition
related:
  - GDC-L1-LEVEL-0001
  - GDC-L1-LEVEL-0002
  - GDC-L1-LEVEL-0005
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-leveldesign-guidance
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Let the player *see* a destination before they can reach it. A framed vista of a distant
> landmark, a glimpse of a locked-off area, or a preview of a coming challenge plants a
> self-directed goal and builds anticipation — so that arriving later feels earned and
> meaningful.

## Rationale
A goal the player forms themselves is more motivating than one the game assigns. When you
frame a striking landmark on the horizon ("I want to get up *there*") or reveal a barred
door ("what's behind that?"), you create desire and a memory that pays off on arrival — the
place is already meaningful because the player wanted it before they had it. Vistas also do
double duty as orientation: a landmark seen from afar becomes the reference point that makes
the space legible later (LEVEL-0002). And foreshadowing a challenge lets dread or excitement
build before the encounter, sharpening the moment. Showing-before-going turns traversal into
anticipation instead of transit [S-leveldesign-guidance].

## Applies when
Open and semi-open spaces, and any moment you want the player to *want* to reach somewhere.
Especially powerful at the start of a level (establishing the goal) and before major set
pieces.

## Does not apply / Exceptions
Tightly enclosed or claustrophobic designs (many horror and corridor games) deliberately
deny the long view to keep players disoriented and anxious — the opposite technique on
purpose. Overusing reveals can also spoil surprise; some payoffs land harder when
*unforeshadowed*. And a promised destination that disappoints on arrival (LEVEL-0005's empty
diversion) is worse than never showing it — a shown goal makes a payoff *promise*.

## Implementation (kept separate from the principle)
Frame distant landmarks and future destinations through windows, ridgelines, and
architectural openings; use composition and light (LEVEL-0001) to make them pull the eye.
Reveal locked areas the player will later unlock, so the unlock feels like a returned
promise. Foreshadow big challenges with a glimpse. Make sure every shown destination pays
off on arrival (LEVEL-0005).

## Disagreement
Reveal-and-anticipate (open, motivating, orienting) vs. conceal-for-surprise-or-dread
(enclosed, tense) are opposite tools for opposite feelings; neither is universally right.
And some designers prize unforeshadowed surprises over telegraphed goals. Match the technique
to the intended emotion.

## Notes
A composition technique that also feeds legibility (LEVEL-0002) and the guidance/exploration
balance (LEVEL-0005). Confidence 3 — effective and well-known, but more a strong technique
than a near-universal law, and genre-dependent.

gdc-l1-level-0006 show before you go — use vistas and foreshadowing to plant goals level-design vistas foreshadowing anticipation composition > let the player see a destination before they can reach it. a framed vista of a distant landmark, a glimpse of a locked-off area, or a preview of a coming challenge plants a self-directed goal and builds anticipation — so that arriving later feels earned and meaningful. a goal the player forms themselves is more motivating than one the game assigns. when you frame a striking landmark on the horizon ("i want to get up there") or reveal a barred door ("what's behind that?"), you create desire and a memory that pays off on arrival — the place is already meaningful because the player wanted it before they had it. vistas also do double duty as orientation: a landmark seen from afar becomes the reference point that makes the space legible later (level-0002). and foreshadowing a challenge lets dread or excitement build before the encounter, sharpening the moment. showing-before-going turns traversal into anticipation instead of transit [s-leveldesign-guidance]. open and semi-open spaces, and any moment you want the player to want to reach somewhere. especially powerful at the start of a level (establishing the goal) and before major set pieces. tightly enclosed or claustrophobic designs (many horror and corridor games) deliberately deny the long view to keep players disoriented and anxious — the opposite technique on purpose. overusing reveals can also spoil surprise; some payoffs land harder when unforeshadowed. and a promised destination that disappoints on arrival (level-0005's empty diversion) is worse than never showing it — a shown goal makes a payoff promise. frame distant landmarks and future destinations through windows, ridgelines, and architectural openings; use composition and light (level-0001) to make them pull the eye. reveal locked areas the player will later unlock, so the unlock feels like a returned promise. foreshadow big challenges with a glimpse. make sure every shown destination pays off on arrival (level-0005). reveal-and-anticipate (open, motivating, orienting) vs. conceal-for-surprise-or-dread (enclosed, tense) are opposite tools for opposite feelings; neither is universally right. and some designers prize unforeshadowed surprises over telegraphed goals. match the technique to the intended emotion. a composition technique that also feeds legibility (level-0002) and the guidance/exploration balance (level-0005). confidence 3 — effective and well-known, but more a strong technique than a near-universal law, and genre-dependent.


Let space imply history and story through layout, props, aftermath, and composition, inviting the player to ask "what happened here?" and piece it together themselves. Because players explore rather than being shown, environmental narrative rewards attention — and it must be possible to miss some of it for finding it to feel meaningful.

---
id: GDC-L1-LEVEL-0007
title: Tell story through the environment — let players pull the narrative
layer: L1
domain: LEVEL
subdomain: environmental-storytelling
type: contextual
confidence: 4
status: canonical
tags:
  - environmental-storytelling
  - narrative
  - level-design
  - discovery
  - worldbuilding
related:
  - GDC-L1-DESIGN-0006
  - GDC-L1-LEVEL-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-worch-smith-envstory
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Let space imply history and story through layout, props, aftermath, and composition,
> inviting the player to ask *"what happened here?"* and piece it together themselves.
> Because players explore rather than being shown, environmental narrative rewards
> attention — and it must be *possible to miss* some of it for finding it to feel
> meaningful.

## Rationale
Film and prose *push* the audience's attention where the author wants it; games are
different — the player explores and *pulls* meaning from what they choose to examine
[S-worch-smith-envstory]. Environmental storytelling leverages that: a ransacked room, two
skeletons posed mid-argument, a child's drawing in a soldier's bunk, a barricade that failed
— these invite the player to reconstruct events, and the act of inferring builds far more
investment than being told. Two consequences follow. First, the story lives in the *space*,
so it reaches players who ignore text. Second, and crucially, some of it must be *missable*:
if every player is forced to see every story beat, discovery is hollow — it's the
possibility of missing it that makes finding it feel like the player's own.

## Applies when
Any game with authored space and any desire to convey history, mood, or narrative without
(or alongside) explicit text. Especially powerful for exploration- and atmosphere-driven
games, and for making spaces feel significant before written story exists.

## Does not apply / Exceptions
Some stories need to be *told*, not inferred — critical plot the player must not miss should
not rely solely on missable environmental cues (pair it with explicit narrative). Abstract,
minimalist, or purely mechanical games may have no fiction to embed. And environmental
storytelling is craft-intensive; a rushed version reads as random clutter rather than
implied history.

## Implementation (kept separate from the principle)
Compose scenes that imply a before-and-after: what was this place, what happened, what's
left? Use props, damage, positioning, and juxtaposition as sentences. Layer it — a casual
glance reads mood, a careful look reveals a specific story. Deliberately make the richer
readings optional and rewarding (LEVEL-0005's "every space pays"). Even before written
narrative exists, build "lore-shaped" spaces that *imply* meaning, so curiosity is rewarded
with a sense of significance.

## Disagreement
Embedded/pulled narrative (player-inferred, missable, immersive) vs. delivered/pushed
narrative (authored, guaranteed, controlled) are complementary, not rivals — most games use
both, reserving pushed narrative for must-not-miss plot and pulled narrative for depth,
mood, and reward. The debate is about the *mix*, and how much to trust players to find and
assemble.

## Notes
Confidence 4.

gdc-l1-level-0007 tell story through the environment — let players pull the narrative environmental-storytelling narrative level-design discovery worldbuilding > let space imply history and story through layout, props, aftermath, and composition, inviting the player to ask "what happened here?" and piece it together themselves. because players explore rather than being shown, environmental narrative rewards attention — and it must be possible to miss some of it for finding it to feel meaningful. film and prose push the audience's attention where the author wants it; games are different — the player explores and pulls meaning from what they choose to examine [s-worch-smith-envstory]. environmental storytelling leverages that: a ransacked room, two skeletons posed mid-argument, a child's drawing in a soldier's bunk, a barricade that failed — these invite the player to reconstruct events, and the act of inferring builds far more investment than being told. two consequences follow. first, the story lives in the space, so it reaches players who ignore text. second, and crucially, some of it must be missable: if every player is forced to see every story beat, discovery is hollow — it's the possibility of missing it that makes finding it feel like the player's own. any game with authored space and any desire to convey history, mood, or narrative without (or alongside) explicit text. especially powerful for exploration- and atmosphere-driven games, and for making spaces feel significant before written story exists. some stories need to be told, not inferred — critical plot the player must not miss should not rely solely on missable environmental cues (pair it with explicit narrative). abstract, minimalist, or purely mechanical games may have no fiction to embed. and environmental storytelling is craft-intensive; a rushed version reads as random clutter rather than implied history. compose scenes that imply a before-and-after: what was this place, what happened, what's left? use props, damage, positioning, and juxtaposition as sentences. layer it — a casual glance reads mood, a careful look reveals a specific story. deliberately make the richer readings optional and rewarding (level-0005's "every space pays"). even before written narrative exists, build "lore-shaped" spaces that imply meaning, so curiosity is rewarded with a sense of significance. embedded/pulled narrative (player-inferred, missable, immersive) vs. delivered/pushed narrative (authored, guaranteed, controlled) are complementary, not rivals — most games use both, reserving pushed narrative for must-not-miss plot and pulled narrative for depth, mood, and reward. the debate is about the mix, and how much to trust players to find and assemble. confidence 4.


Combat is shaped as much by the space as by the enemies in it. Cover, elevation, chokepoints, sightlines, hazards, and open ground determine which tactics are viable and how a fight feels. Design encounter spaces to elicit the intended combat — don't drop enemies into neutral rooms and hope.

---
id: GDC-L1-LEVEL-0008
title: Shape encounters through space — the arena is a combat design tool
layer: L1
domain: LEVEL
subdomain: encounter-design
type: contextual
confidence: 4
status: canonical
tags:
  - encounter-design
  - combat
  - space
  - sightlines
  - level-design
related:
  - GDC-L1-DESIGN-0002
  - GDC-L1-LEVEL-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-leveldesign-guidance
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Combat is shaped as much by the *space* as by the enemies in it. Cover, elevation,
> chokepoints, sightlines, hazards, and open ground determine which tactics are viable and
> how a fight feels. Design encounter spaces to *elicit* the intended combat — don't drop
> enemies into neutral rooms and hope.

## Rationale
The same enemies produce entirely different fights depending on the arena: a sniper is
lethal across a long sightline and useless in a cramped corridor; melee rushers are terrifying
in open ground and trivial behind a chokepoint; cover invites peek-and-shoot, elevation
rewards positioning, hazards add a third party to the fight [S-leveldesign-guidance]. So the
space is a primary lever of encounter design — it creates or removes the *interesting
decisions* a fight offers (DESIGN-0002). A well-shaped arena makes players use the mechanics
you want them to use and express the playstyles you're designing for; a shapeless one flattens
every encounter into the same exchange regardless of the enemy roster.

## Applies when
Any game with spatial combat — action, shooters, RPGs, tactics. The more the combat depends
on positioning, the more the space matters.

## Does not apply / Exceptions
Combat systems that are largely space-independent (many turn-based menu battles, some
abstract or arena-agnostic fighters) derive challenge from mechanics rather than geometry.
And space can be *over*-designed — an arena so bristling with cover and hazards that it reads
as a puzzle can undercut a game that wants raw, readable brawls. Match the spatial complexity
to the combat's intent.

## Implementation (kept separate from the principle)
Use sightlines to set engagement range, cover and elevation to create positional decisions, chokepoints to control flow, and hazards to add tension. Vary encounter spaces so fights don't feel identical (feeds pacing, LEVEL-0003). Playtest whether the space actually produces the intended fight.

## Disagreement
Space-driven encounter design (the arena is a core combat variable) vs. system-driven combat
(the mechanics carry the fight, space is secondary) reflects genre: positional/tactical games
lean spatial, abstract/menu combat leans systemic. Both are valid within their traditions.

## Notes
Feeds pacing (LEVEL-0003). Confidence 4.

gdc-l1-level-0008 shape encounters through space — the arena is a combat design tool encounter-design combat space sightlines level-design > combat is shaped as much by the space as by the enemies in it. cover, elevation, chokepoints, sightlines, hazards, and open ground determine which tactics are viable and how a fight feels. design encounter spaces to elicit the intended combat — don't drop enemies into neutral rooms and hope. the same enemies produce entirely different fights depending on the arena: a sniper is lethal across a long sightline and useless in a cramped corridor; melee rushers are terrifying in open ground and trivial behind a chokepoint; cover invites peek-and-shoot, elevation rewards positioning, hazards add a third party to the fight [s-leveldesign-guidance]. so the space is a primary lever of encounter design — it creates or removes the interesting decisions a fight offers (design-0002). a well-shaped arena makes players use the mechanics you want them to use and express the playstyles you're designing for; a shapeless one flattens every encounter into the same exchange regardless of the enemy roster. any game with spatial combat — action, shooters, rpgs, tactics. the more the combat depends on positioning, the more the space matters. combat systems that are largely space-independent (many turn-based menu battles, some abstract or arena-agnostic fighters) derive challenge from mechanics rather than geometry. and space can be over-designed — an arena so bristling with cover and hazards that it reads as a puzzle can undercut a game that wants raw, readable brawls. match the spatial complexity to the combat's intent. use sightlines to set engagement range, cover and elevation to create positional decisions, chokepoints to control flow, and hazards to add tension. vary encounter spaces so fights don't feel identical (feeds pacing, level-0003). playtest whether the space actually produces the intended fight. space-driven encounter design (the arena is a core combat variable) vs. system-driven combat (the mechanics carry the fight, space is secondary) reflects genre: positional/tactical games lean spatial, abstract/menu combat leans systemic. both are valid within their traditions. feeds pacing (level-0003). confidence 4.


A game tells its story two ways at once — through non-interactive narrative (cutscenes, dialogue, text) and through its mechanics (what the player actually does) — and when the two contradict (ludonarrative dissonance), the contradiction undercuts both. Aim for harmony: what the player does should reinforce what the story says.

---
id: GDC-L1-NARR-0001
title: Seek ludonarrative harmony — align what the game says with what it makes you do
layer: L1
domain: NARR
subdomain: ludonarrative
type: contextual
confidence: 4
status: canonical
tags:
  - narrative
  - ludonarrative
  - harmony
  - mechanics
  - theme
related:
  - GDC-L1-DESIGN-0001
  - GDC-L1-SYS-0002
  - GDC-L1-NARR-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-hocking-ludonarrative
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> A game tells its story two ways at once — through non-interactive narrative (cutscenes,
> dialogue, text) and through its **mechanics** (what the player actually does) — and when the
> two contradict (**ludonarrative dissonance**), the contradiction undercuts both. Aim for
> harmony: what the player *does* should reinforce what the story *says*.

## Rationale
Players believe actions over words: a game whose story preaches mercy while its mechanics
reward slaughter teaches the mechanical lesson, and the narrative rings hollow
[S-hocking-ludonarrative]. Mechanics are a rhetorical channel — the systems *argue* for a way
of being in the world — so theme lands hardest when the systems embody it (a game about
isolation that mechanically isolates you, a game about greed that mechanically tempts and
punishes greed). This is DESIGN-0001 (the experience produced is what matters) applied to
narrative: the experience is produced by mechanics as much as by script, and it is authored
second-order through the systems (SYS-0002). Harmony makes the whole game say one coherent
thing; dissonance makes it argue with itself.

## Applies when
Any game with both authored narrative and meaningful mechanics — most story-driven action,
RPG, and adventure games. Sharpest wherever the story asserts a theme the mechanics could
contradict.

## Does not apply / Exceptions
Dissonance can be a *deliberate device*, not only a flaw: intentional ludonarrative tension
can make a point by juxtaposing what the player is told against what they are made to do,
for example to critique control or complicity. Abstract or mechanics-only games have little narrative to harmonize
with. And perfect harmony isn't always the goal — a small dissonance in service of fun (you
kill hundreds in a story about one death) is often accepted as convention. The rule is to make
dissonance a *choice*, not an accident.

## Implementation (kept separate from the principle)
Ask of your core mechanics: what do these systems *teach* and *reward*, and does it match the
story's theme? Where they conflict unintentionally, change the mechanic or the story so they
agree. Where you *want* tension, make it deliberate and legible so players read it as
commentary, not sloppiness. Design theme into systems (SYS-0002), not just into script.

## Disagreement
Harmony-by-default (mechanics and story should agree; dissonance is a flaw to fix) vs.
dissonance-as-device (intentional tension is a legitimate expressive tool). Both are held by
serious designers; the reconciliation is that *unintentional* dissonance is a defect while
*intentional*, legible dissonance can be art.

## Notes
The mechanics-meet-story principle of NARR; an application of DESIGN-0001 and SYS-0002 to
theme. Confidence 4. Its harmony-vs-deliberate-dissonance split is catalogued in
`index/DISAGREEMENTS.md`.

gdc-l1-narr-0001 seek ludonarrative harmony — align what the game says with what it makes you do narrative ludonarrative harmony mechanics theme > a game tells its story two ways at once — through non-interactive narrative (cutscenes, dialogue, text) and through its mechanics (what the player actually does) — and when the two contradict (ludonarrative dissonance), the contradiction undercuts both. aim for harmony: what the player does should reinforce what the story says. players believe actions over words: a game whose story preaches mercy while its mechanics reward slaughter teaches the mechanical lesson, and the narrative rings hollow [s-hocking-ludonarrative]. mechanics are a rhetorical channel — the systems argue for a way of being in the world — so theme lands hardest when the systems embody it (a game about isolation that mechanically isolates you, a game about greed that mechanically tempts and punishes greed). this is design-0001 (the experience produced is what matters) applied to narrative: the experience is produced by mechanics as much as by script, and it is authored second-order through the systems (sys-0002). harmony makes the whole game say one coherent thing; dissonance makes it argue with itself. any game with both authored narrative and meaningful mechanics — most story-driven action, rpg, and adventure games. sharpest wherever the story asserts a theme the mechanics could contradict. dissonance can be a deliberate device, not only a flaw: intentional ludonarrative tension can make a point by juxtaposing what the player is told against what they are made to do, for example to critique control or complicity. abstract or mechanics-only games have little narrative to harmonize with. and perfect harmony isn't always the goal — a small dissonance in service of fun (you kill hundreds in a story about one death) is often accepted as convention. the rule is to make dissonance a choice, not an accident. ask of your core mechanics: what do these systems teach and reward, and does it match the story's theme? where they conflict unintentionally, change the mechanic or the story so they agree. where you want tension, make it deliberate and legible so players read it as commentary, not sloppiness. design theme into systems (sys-0002), not just into script. harmony-by-default (mechanics and story should agree; dissonance is a flaw to fix) vs. dissonance-as-device (intentional tension is a legitimate expressive tool). both are held by serious designers; the reconciliation is that unintentional dissonance is a defect while intentional, legible dissonance can be art. the mechanics-meet-story principle of narr; an application of design-0001 and sys-0002 to theme. confidence 4. its harmony-vs-deliberate-dissonance split is catalogued in index/disagreements.md.


Games are participatory: the player experiences story by acting, not just watching. Design narrative for a participant with agency — account for what they do, react to it, and where it fits, let them help author the story rather than have it delivered to them passively.

---
id: GDC-L1-NARR-0002
title: The player is a co-author, not an audience
layer: L1
domain: NARR
subdomain: player-authored-story
type: contextual
confidence: 4
status: canonical
tags:
  - narrative
  - agency
  - participation
  - player-authored
  - interactivity
related:
  - GDC-L1-DESIGN-0006
  - GDC-L1-NARR-0004
  - GDC-L1-NARR-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-interactive-narrative
  - S-schell-artofgamedesign
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Games are participatory: the player experiences story by *acting*, not just watching. Design
> narrative for a participant with agency — account for what they do, react to it, and where it
> fits, let them help *author* the story rather than have it delivered to them passively.

## Rationale
The defining difference between games and linear media is that the audience acts, and acts
*differently* each time [S-interactive-narrative]. Narrative that ignores this — that treats
the player as a viewer between cutscenes — wastes the medium's unique power and often creates
the passivity it fears (players skip the story they can't affect). Designing for a co-author
means the world acknowledges the player's actions, choices carry consequences the player can
feel (DESIGN-0006, legible agency), and the most memorable "stories" are frequently the ones
players generate themselves through play (an emergent escape, a desperate improvised win). The
strongest game narratives treat the player as the protagonist *doing* the story, not the
spectator being told it.

## Applies when
Any game that wants narrative engagement — most story-driven and role-playing games, and any
game seeking the participatory, "my story" feeling.

## Does not apply / Exceptions
Some games deliberately keep the player a near-passive audience for authored, cinematic
storytelling (linear narrative adventures, "walking simulators" that curate a fixed emotional
journey) — a valid trade of agency for authorial control and craft. And full player authorship
has real costs and risks (incoherence, the player "missing" the intended story) — see the
branching-cost principle (NARR-0004). Co-authorship is a spectrum, not an absolute.

## Implementation (kept separate from the principle)
Make the world react to what the player does, at whatever scale you can afford (from a guard
commenting on your last action to persistent world-state changes). Give consequential choices
legible consequences (DESIGN-0006). Create conditions for emergent player stories (systemic
interactions, SYS-0003). Where you deliver authored story, weave it into play rather than
stopping play to show it (NARR-0003, NARR-0005).

## Disagreement
Participatory/agency-driven narrative (the player co-authors; "my story") vs. authored/curated
narrative (a crafted, controlled arc the player receives) — the immersive-sim and RPG tradition
vs. the cinematic-adventure tradition. Both make great games; the split is the same
agency-vs-authored axis as DESIGN-0006, seen from the narrative side.

## Notes
The participation principle of NARR; an application of DESIGN-0006 (agency) to storytelling,
and the setup for the branching-cost craft (NARR-0004). Confidence 4.

gdc-l1-narr-0002 the player is a co-author, not an audience narrative agency participation player-authored interactivity > games are participatory: the player experiences story by acting, not just watching. design narrative for a participant with agency — account for what they do, react to it, and where it fits, let them help author the story rather than have it delivered to them passively. the defining difference between games and linear media is that the audience acts, and acts differently each time [s-interactive-narrative]. narrative that ignores this — that treats the player as a viewer between cutscenes — wastes the medium's unique power and often creates the passivity it fears (players skip the story they can't affect). designing for a co-author means the world acknowledges the player's actions, choices carry consequences the player can feel (design-0006, legible agency), and the most memorable "stories" are frequently the ones players generate themselves through play (an emergent escape, a desperate improvised win). the strongest game narratives treat the player as the protagonist doing the story, not the spectator being told it. any game that wants narrative engagement — most story-driven and role-playing games, and any game seeking the participatory, "my story" feeling. some games deliberately keep the player a near-passive audience for authored, cinematic storytelling (linear narrative adventures, "walking simulators" that curate a fixed emotional journey) — a valid trade of agency for authorial control and craft. and full player authorship has real costs and risks (incoherence, the player "missing" the intended story) — see the branching-cost principle (narr-0004). co-authorship is a spectrum, not an absolute. make the world react to what the player does, at whatever scale you can afford (from a guard commenting on your last action to persistent world-state changes). give consequential choices legible consequences (design-0006). create conditions for emergent player stories (systemic interactions, sys-0003). where you deliver authored story, weave it into play rather than stopping play to show it (narr-0003, narr-0005). participatory/agency-driven narrative (the player co-authors; "my story") vs. authored/curated narrative (a crafted, controlled arc the player receives) — the immersive-sim and rpg tradition vs. the cinematic-adventure tradition. both make great games; the split is the same agency-vs-authored axis as design-0006, seen from the narrative side. the participation principle of narr; an application of design-0006 (agency) to storytelling, and the setup for the branching-cost craft (narr-0004). confidence 4.


The strongest game narrative is experienced — pulled from the world, the systems, and the player's own actions — rather than told in cutscenes and text dumps. Show through environment, systems, and consequence; reserve delivered exposition for what genuinely must be stated outright.

---
id: GDC-L1-NARR-0003
title: Prefer embedded, experienced narrative over delivered exposition
layer: L1
domain: NARR
subdomain: environmental-narrative
type: contextual
confidence: 4
status: canonical
tags:
  - narrative
  - embedded
  - environmental-storytelling
  - show-dont-tell
  - systemic
related:
  - GDC-L1-LEVEL-0007
  - GDC-L1-NARR-0002
  - GDC-L1-DESIGN-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-worch-smith-envstory
  - S-schell-artofgamedesign
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> The strongest game narrative is *experienced* — pulled from the world, the systems, and the
> player's own actions — rather than *told* in cutscenes and text dumps. Show through
> environment, systems, and consequence; reserve delivered exposition for what genuinely must
> be stated outright.

## Rationale
Because players explore and act rather than sit and receive, story that is *embedded* in what
they do and see lands harder and interrupts less than story that is *delivered* by stopping
the game to tell them [S-worch-smith-envstory]. Environmental storytelling (a ransacked room, a
failed barricade — LEVEL-0007), systemic storytelling (a reputation system that makes towns
react to your deeds), and consequence (the world visibly changed by your choices) all let the
player *infer* and *live* the narrative, which builds more investment than exposition (the
"pull, not push" principle). This is DESIGN-0001 again — the experience is what matters, and an
experienced story is more real to the player than a described one. Delivered exposition still
has its place (some things must simply be told), but it should be the exception, woven into
play rather than walling it off.

## Applies when
Any game conveying story, world, or mood — especially exploration-, immersion-, and
atmosphere-driven games. The more the game trusts the player to look and infer, the more
embedded narrative pays.

## Does not apply / Exceptions
Some narrative must be *delivered* — critical plot the player cannot be allowed to miss, complex
information no environmental cue can carry, or the deliberate power of a well-directed cutscene.
Strongly-authored cinematic games lean harder on delivered narrative by design. And embedded
narrative is craft-intensive and *missable* (NARR-0006) — a rushed version reads as random
clutter, and over-reliance on it can leave players confused about the plot. Balance embedded
depth with enough delivered clarity that the through-line lands.

## Implementation (kept separate from the principle)
Ask what each story beat could be *shown* through space (LEVEL-0007), systems, or consequence
instead of told. Weave necessary exposition into play (environmental readables, ambient
dialogue, in-world objects) rather than dedicated lecture scenes. Reserve cutscenes/text for
what truly needs directing or stating. Layer it so a casual player gets the gist and a curious
one gets the depth (NARR-0006).

## Disagreement
Embedded/experienced narrative (immersive, inferred, low-interruption, missable) vs.
delivered/authored narrative (controlled, guaranteed, directed) — most games mix, reserving
delivery for must-not-miss plot and embedding for depth, mood, and reward. The debate is the
*ratio* and how much to trust players to find and assemble.

## Notes
The general narrative principle for which LEVEL-0007 (environmental storytelling) is the
level-design-specific instance — this is its parent. An application of DESIGN-0001 to story.
Confidence 4.

gdc-l1-narr-0003 prefer embedded, experienced narrative over delivered exposition narrative embedded environmental-storytelling show-dont-tell systemic > the strongest game narrative is experienced — pulled from the world, the systems, and the player's own actions — rather than told in cutscenes and text dumps. show through environment, systems, and consequence; reserve delivered exposition for what genuinely must be stated outright. because players explore and act rather than sit and receive, story that is embedded in what they do and see lands harder and interrupts less than story that is delivered by stopping the game to tell them [s-worch-smith-envstory]. environmental storytelling (a ransacked room, a failed barricade — level-0007), systemic storytelling (a reputation system that makes towns react to your deeds), and consequence (the world visibly changed by your choices) all let the player infer and live the narrative, which builds more investment than exposition (the "pull, not push" principle). this is design-0001 again — the experience is what matters, and an experienced story is more real to the player than a described one. delivered exposition still has its place (some things must simply be told), but it should be the exception, woven into play rather than walling it off. any game conveying story, world, or mood — especially exploration-, immersion-, and atmosphere-driven games. the more the game trusts the player to look and infer, the more embedded narrative pays. some narrative must be delivered — critical plot the player cannot be allowed to miss, complex information no environmental cue can carry, or the deliberate power of a well-directed cutscene. strongly-authored cinematic games lean harder on delivered narrative by design. and embedded narrative is craft-intensive and missable (narr-0006) — a rushed version reads as random clutter, and over-reliance on it can leave players confused about the plot. balance embedded depth with enough delivered clarity that the through-line lands. ask what each story beat could be shown through space (level-0007), systems, or consequence instead of told. weave necessary exposition into play (environmental readables, ambient dialogue, in-world objects) rather than dedicated lecture scenes. reserve cutscenes/text for what truly needs directing or stating. layer it so a casual player gets the gist and a curious one gets the depth (narr-0006). embedded/experienced narrative (immersive, inferred, low-interruption, missable) vs. delivered/authored narrative (controlled, guaranteed, directed) — most games mix, reserving delivery for must-not-miss plot and embedding for depth, mood, and reward. the debate is the ratio and how much to trust players to find and assemble. the general narrative principle for which level-0007 (environmental storytelling) is the level-design-specific instance — this is its parent. an application of design-0001 to story. confidence 4.


Fully branching narrative is combinatorially expensive and mostly unseen by any single player. Get the feeling of agency affordably: reactive storytelling (the world acknowledges choices without wholly branching), convergence and hub-and-spoke structures, and judicious illusion of choice — while keeping the choices that truly matter genuinely consequential.

---
id: GDC-L1-NARR-0004
title: Branching is expensive — buy the feeling of agency efficiently
layer: L1
domain: NARR
subdomain: branching-vs-linear
type: contextual
confidence: 4
status: canonical
tags:
  - narrative
  - branching
  - illusion-of-choice
  - agency
  - cost
related:
  - GDC-L1-DESIGN-0006
  - GDC-L1-NARR-0002
  - GDC-L1-PROTO-0005
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-interactive-narrative
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Fully branching narrative is combinatorially expensive and mostly unseen by any single
> player. Get the *feeling* of agency affordably: reactive storytelling (the world
> acknowledges choices without wholly branching), convergence and hub-and-spoke structures,
> and judicious illusion of choice — while keeping the choices that truly matter genuinely
> consequential.

## Rationale
Every branch that never rejoins multiplies the content you must build, and a player on one
path never sees the others — so naive branching spends enormous effort on story most players
never experience [S-interactive-narrative]. The craft is decoupling the *feeling* of agency
from the *cost* of true divergence. Reactive narrative (NPCs comment on your deeds, the world
reflects your choices) delivers acknowledgment cheaply. **Convergence** — branches that
diverge then rejoin — lets choices feel impactful in the moment while keeping the content
bounded. The **illusion of choice** (options that lead to the same outcome) is a real,
respectable tool when it protects the *feeling* of consequence — though it fails badly if
players notice the seams and feel cheated (DESIGN-0006's warning). The goal is maximum
perceived agency per unit of production, with the genuinely pivotal choices actually branching.

## Applies when
Any choice-driven or narrative game weighing how much real branching to build. Central to RPGs,
narrative adventures, and any "your choices matter" design.

## Does not apply / Exceptions
Some games *do* commit to deep, real branching as their identity (heavily replayable
choice-games, some visual novels) and accept the cost as the point. Purely linear games sidestep
the question entirely (NARR-0002's authored-narrative pole). And illusion of choice, over-used
or clumsily hidden, becomes the *unsatisfying* illusion DESIGN-0006 warns against — the tool
works only while the seams stay invisible.

## Implementation (kept separate from the principle)
Reserve true branching for the few pivotal choices; make everything else *reactive*
(acknowledged, not branched) or *convergent* (diverge then rejoin). Use hub-and-spoke structures
to let players tackle content in their order without exploding the tree. Deploy illusion of
choice where it protects felt consequence, and hide the seams. Be willing to cut branches that
don't earn their cost (PROTO-0005, kill your darlings).

## Disagreement
Deep real branching (maximal agency and replayability, at high and often-unseen cost) vs.
reactive/convergent/illusory structures (efficient perceived agency, bounded content). The
choice-game tradition leans real-branching; most narrative games lean efficient-agency. Both
are valid; the risk to manage is the *noticed* illusion that feels like a cheat.

## Notes
The production-craft complement to NARR-0002 (co-authorship) and DESIGN-0006 (legible agency);
its illusion-of-choice tool sits on DESIGN-0006's exact caution. Confidence 4.

gdc-l1-narr-0004 branching is expensive — buy the feeling of agency efficiently narrative branching illusion-of-choice agency cost > fully branching narrative is combinatorially expensive and mostly unseen by any single player. get the feeling of agency affordably: reactive storytelling (the world acknowledges choices without wholly branching), convergence and hub-and-spoke structures, and judicious illusion of choice — while keeping the choices that truly matter genuinely consequential. every branch that never rejoins multiplies the content you must build, and a player on one path never sees the others — so naive branching spends enormous effort on story most players never experience [s-interactive-narrative]. the craft is decoupling the feeling of agency from the cost of true divergence. reactive narrative (npcs comment on your deeds, the world reflects your choices) delivers acknowledgment cheaply. convergence — branches that diverge then rejoin — lets choices feel impactful in the moment while keeping the content bounded. the illusion of choice (options that lead to the same outcome) is a real, respectable tool when it protects the feeling of consequence — though it fails badly if players notice the seams and feel cheated (design-0006's warning). the goal is maximum perceived agency per unit of production, with the genuinely pivotal choices actually branching. any choice-driven or narrative game weighing how much real branching to build. central to rpgs, narrative adventures, and any "your choices matter" design. some games do commit to deep, real branching as their identity (heavily replayable choice-games, some visual novels) and accept the cost as the point. purely linear games sidestep the question entirely (narr-0002's authored-narrative pole). and illusion of choice, over-used or clumsily hidden, becomes the unsatisfying illusion design-0006 warns against — the tool works only while the seams stay invisible. reserve true branching for the few pivotal choices; make everything else reactive (acknowledged, not branched) or convergent (diverge then rejoin). use hub-and-spoke structures to let players tackle content in their order without exploding the tree. deploy illusion of choice where it protects felt consequence, and hide the seams. be willing to cut branches that don't earn their cost (proto-0005, kill your darlings). deep real branching (maximal agency and replayability, at high and often-unseen cost) vs. reactive/convergent/illusory structures (efficient perceived agency, bounded content). the choice-game tradition leans real-branching; most narrative games lean efficient-agency. both are valid; the risk to manage is the noticed illusion that feels like a cheat. the production-craft complement to narr-0002 (co-authorship) and design-0006 (legible agency); its illusion-of-choice tool sits on design-0006's exact caution. confidence 4.


In games the player controls the clock — they linger, rush, backtrack, wander off, and interrupt — so narrative pacing cannot assume a fixed timeline the way film can. Deliver story in player-controllable, interruptible chunks that survive being paced by the player, and let gameplay and story share a rhythm rather than fight for the player's time.

---
id: GDC-L1-NARR-0005
title: Pace story around player-controlled time
layer: L1
domain: NARR
subdomain: pacing
type: contextual
confidence: 3
status: canonical
tags:
  - narrative
  - pacing
  - interactivity
  - interruptible
related:
  - GDC-L1-LEVEL-0003
  - GDC-L1-AUDIO-0003
  - GDC-L1-NARR-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-schell-artofgamedesign
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> In games the player controls the clock — they linger, rush, backtrack, wander off, and
> interrupt — so narrative pacing cannot assume a fixed timeline the way film can. Deliver
> story in player-controllable, interruptible chunks that survive being paced by the player,
> and let gameplay and story share a rhythm rather than fight for the player's time.

## Rationale
A film runs on the director's clock; a game runs on the player's, and that breaks any narrative
pacing that assumes the audience is moving through at a set rate [S-schell-artofgamedesign]. A
story beat the player triggers three hours late (having explored elsewhere), or misses, or
rushes past, lands wrong if it was written for a fixed cadence. Worse, story that *stops* the
game to deliver itself fights the player's momentum and gets skipped. So narrative pacing in
games is a negotiation with player agency: parcel the story into interruptible units, make beats
robust to being reached out of tempo, and align the story's rhythm with the gameplay's
(the pacing curve of LEVEL-0003, and adaptive audio's response to state, AUDIO-0003) so the two
reinforce rather than interrupt each other.

## Applies when
Any game delivering authored story alongside player-controlled exploration or action —
especially open and semi-open games where the player sets the tempo.

## Does not apply / Exceptions
Tightly linear or on-rails sequences *do* control the clock (a scripted set-piece, a
cutscene) and can pace like film for that stretch — a valid tool used in bursts. Rhythm and
strongly-timed games control tempo by design. The principle bites hardest where the player has
real freedom over pace and place.

## Implementation (kept separate from the principle)
Break narrative into interruptible, self-contained beats rather than long unskippable sequences.
Make story robust to being reached early, late, or out of order (gate the truly
order-dependent beats). Align story rhythm with gameplay pacing (LEVEL-0003) and let systems
like adaptive music (AUDIO-0003) carry emotional pacing that survives player timing. Prefer
weaving story into play over stopping play to tell it (NARR-0003).

## Disagreement
Player-paced narrative (interruptible, robust, non-blocking — respects agency) vs.
author-paced sequences (controlled cadence, cinematic power — at the cost of interrupting the
player). Open games lean player-paced; cinematic games use author-paced bursts. The tension is
control-of-tempo vs. respect-for-agency.

## Notes
The narrative side of pacing — partner to LEVEL-0003 (spatial/intensity pacing) and AUDIO-0003
(adaptive music), all three about rhythm under player-controlled time. Confidence 3: sound and
widely-held, but narrative pacing craft is highly form-dependent.

gdc-l1-narr-0005 pace story around player-controlled time narrative pacing interactivity interruptible > in games the player controls the clock — they linger, rush, backtrack, wander off, and interrupt — so narrative pacing cannot assume a fixed timeline the way film can. deliver story in player-controllable, interruptible chunks that survive being paced by the player, and let gameplay and story share a rhythm rather than fight for the player's time. a film runs on the director's clock; a game runs on the player's, and that breaks any narrative pacing that assumes the audience is moving through at a set rate [s-schell-artofgamedesign]. a story beat the player triggers three hours late (having explored elsewhere), or misses, or rushes past, lands wrong if it was written for a fixed cadence. worse, story that stops the game to deliver itself fights the player's momentum and gets skipped. so narrative pacing in games is a negotiation with player agency: parcel the story into interruptible units, make beats robust to being reached out of tempo, and align the story's rhythm with the gameplay's (the pacing curve of level-0003, and adaptive audio's response to state, audio-0003) so the two reinforce rather than interrupt each other. any game delivering authored story alongside player-controlled exploration or action — especially open and semi-open games where the player sets the tempo. tightly linear or on-rails sequences do control the clock (a scripted set-piece, a cutscene) and can pace like film for that stretch — a valid tool used in bursts. rhythm and strongly-timed games control tempo by design. the principle bites hardest where the player has real freedom over pace and place. break narrative into interruptible, self-contained beats rather than long unskippable sequences. make story robust to being reached early, late, or out of order (gate the truly order-dependent beats). align story rhythm with gameplay pacing (level-0003) and let systems like adaptive music (audio-0003) carry emotional pacing that survives player timing. prefer weaving story into play over stopping play to tell it (narr-0003). player-paced narrative (interruptible, robust, non-blocking — respects agency) vs. author-paced sequences (controlled cadence, cinematic power — at the cost of interrupting the player). open games lean player-paced; cinematic games use author-paced bursts. the tension is control-of-tempo vs. respect-for-agency. the narrative side of pacing — partner to level-0003 (spatial/intensity pacing) and audio-0003 (adaptive music), all three about rhythm under player-controlled time. confidence 3: sound and widely-held, but narrative pacing craft is highly form-dependent.


Believable worlds and characters come from coherent, implied depth — the iceberg — not exhaustive exposition: present a consistent surface and let the player infer the mass beneath. And make much of that depth optional: missable lore and detail reward curiosity precisely because they can be missed.

---
id: GDC-L1-NARR-0006
title: Build worlds by implication — and let players miss things
layer: L1
domain: NARR
subdomain: worldbuilding
type: contextual
confidence: 4
status: canonical
tags:
  - narrative
  - worldbuilding
  - iceberg
  - implication
  - missability
  - discovery
related:
  - GDC-L1-LEVEL-0007
  - GDC-L1-NARR-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-worch-smith-envstory
  - S-schell-artofgamedesign
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Believable worlds and characters come from coherent, *implied* depth — the iceberg — not
> exhaustive exposition: present a consistent surface and let the player infer the mass
> beneath. And make much of that depth **optional**: missable lore and detail reward curiosity
> precisely *because* they can be missed.

## Rationale
A world feels real not when everything is explained but when everything *hangs together* — a
coherent surface implies a consistent, deeper reality the player fills in, and that inference
is more powerful (and cheaper) than spelling it all out [S-schell-artofgamedesign]. Over-
explaining, by contrast, deflates mystery and buries the player in lore. The second half is
just as important: depth that every player is forced through isn't discovery, it's a lecture —
whereas depth the player can *miss* becomes a reward for looking, which is what makes finding
it meaningful ("it has to be possible to miss some things to make finding them meaningful")
[S-worch-smith-envstory]. Optional, missable worldbuilding turns curiosity into its own reward
loop and lets each player build the version of the world they dug for.

## Applies when
Worldbuilding and lore in any game with a setting — RPGs, adventures, exploration and
atmosphere games. Especially powerful where discovery is a core pleasure.

## Does not apply / Exceptions
Critical setup the player must understand to follow the game should *not* be buried in missable
optional lore — essential information needs reliable delivery (NARR-0003's balance). Some genres
want their world fully and explicitly rendered (certain narrative-heavy or educational games).
And "imply depth" still requires the depth to actually be *consistent* — implication over an
incoherent world reads as vagueness, not mystery.

## Implementation (kept separate from the principle)
Design a coherent underlying world and show only its telling surface; let players infer the
rest. Layer lore so a casual player gets the gist and a curious one is rewarded with depth
(pairs with NARR-0003, LEVEL-0007). Make the rich readings *optional and missable* — the reward
for attention. Keep the surface internally consistent so inference has something true to land on.

## Disagreement
Iceberg/implied worldbuilding (evocative, mysterious, rewards inference, missable) vs. fully-
explicit worldbuilding (comprehensive, guaranteed understanding, no gaps). Most games favor
implication for flavor and depth while explicitly delivering the essential through-line; the
debate is how much to withhold and trust the player to infer.

## Notes
Confidence 4.

gdc-l1-narr-0006 build worlds by implication — and let players miss things narrative worldbuilding iceberg implication missability discovery > believable worlds and characters come from coherent, implied depth — the iceberg — not exhaustive exposition: present a consistent surface and let the player infer the mass beneath. and make much of that depth optional: missable lore and detail reward curiosity precisely because they can be missed. a world feels real not when everything is explained but when everything hangs together — a coherent surface implies a consistent, deeper reality the player fills in, and that inference is more powerful (and cheaper) than spelling it all out [s-schell-artofgamedesign]. over- explaining, by contrast, deflates mystery and buries the player in lore. the second half is just as important: depth that every player is forced through isn't discovery, it's a lecture — whereas depth the player can miss becomes a reward for looking, which is what makes finding it meaningful ("it has to be possible to miss some things to make finding them meaningful") [s-worch-smith-envstory]. optional, missable worldbuilding turns curiosity into its own reward loop and lets each player build the version of the world they dug for. worldbuilding and lore in any game with a setting — rpgs, adventures, exploration and atmosphere games. especially powerful where discovery is a core pleasure. critical setup the player must understand to follow the game should not be buried in missable optional lore — essential information needs reliable delivery (narr-0003's balance). some genres want their world fully and explicitly rendered (certain narrative-heavy or educational games). and "imply depth" still requires the depth to actually be consistent — implication over an incoherent world reads as vagueness, not mystery. design a coherent underlying world and show only its telling surface; let players infer the rest. layer lore so a casual player gets the gist and a curious one is rewarded with depth (pairs with narr-0003, level-0007). make the rich readings optional and missable — the reward for attention. keep the surface internally consistent so inference has something true to land on. iceberg/implied worldbuilding (evocative, mysterious, rewards inference, missable) vs. fully- explicit worldbuilding (comprehensive, guaranteed understanding, no gaps). most games favor implication for flavor and depth while explicitly delivering the essential through-line; the debate is how much to withhold and trust the player to infer. confidence 4.


Teach a mechanic when the player needs it, through action, not in a front-loaded wall of text or a mandatory tutorial gauntlet. Introduce one thing at a time, in context, and let the player learn by doing. Information delivered before it's needed overloads working memory and is forgotten before it's used.

---
id: GDC-L1-UX-0001
title: Teach by doing, just in time — not with front-loaded walls of text
layer: L1
domain: UX
subdomain: onboarding-and-tutorials
type: contextual
confidence: 4
status: canonical
tags:
  - ux
  - onboarding
  - tutorials
  - cognitive-load
  - learning
related:
  - GDC-L1-LEVEL-0004
  - GDC-L1-PROG-0005
  - GDC-L1-DESIGN-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-hodent-gamers-brain
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Teach a mechanic *when the player needs it*, through *action*, not in a front-loaded wall
> of text or a mandatory tutorial gauntlet. Introduce one thing at a time, in context, and
> let the player learn by doing. Information delivered before it's needed overloads working
> memory and is forgotten before it's used.

## Rationale
Working memory is small and short-lived, so a tutorial that front-loads a dozen controls
and rules exceeds the player's capacity to hold them — most of it evaporates before the
first real use [S-hodent-gamers-brain]. Learning sticks when it's *active* (the player does
the thing) and *timely* (taught at the moment of need, so it's immediately reinforced by
use). This is the UX/cognitive complement to teaching through space (LEVEL-0004) and the
mastery arc (PROG-0005): those shape *what* order to teach in; this insists on *how* — in
small, contextual, doing-based doses rather than a lecture up front. Fun is learning
(DESIGN-0003), and learning by playing is far more effective (and more fun) than learning by
reading.

## Applies when
Onboarding and the introduction of any mechanic, control, or system. Highest-value in the
opening hour, where first impressions and drop-off are decided.

## Does not apply / Exceptions
Some complexity genuinely needs explicit reference (deep strategy/sim games, complex control
schemes) — the fix there is an *accessible, optional* reference the player can consult, not a
forced lecture. Genre conventions vary: a hardcore sim audience tolerates (even expects) a
manual; a broad-audience game cannot. And "just in time" still needs the teaching to arrive
*before* failure, not after.

## Implementation (kept separate from the principle)
Break teaching into single-concept, in-context moments triggered by need. Prefer showing and doing over telling. Make any necessary text short, skippable, and re-accessible. Avoid the unskippable tutorial wall. Test onboarding with true first-time players and watch where they overload or forget (PLAYTEST-0001/0003).

## Disagreement
Guided just-in-time onboarding (accessible, low-overload) vs. manual/upfront instruction (thorough, suits complex or hardcore games) vs. discovery-first (teach nothing, let players find out).

## Notes
The cognitive/onboarding angle on teaching, complementing the spatial (LEVEL-0004) and
pacing (PROG-0005) angles. Feeds cognitive-load management (UX-0002). Confidence 4.

gdc-l1-ux-0001 teach by doing, just in time — not with front-loaded walls of text ux onboarding tutorials cognitive-load learning > teach a mechanic when the player needs it, through action, not in a front-loaded wall of text or a mandatory tutorial gauntlet. introduce one thing at a time, in context, and let the player learn by doing. information delivered before it's needed overloads working memory and is forgotten before it's used. working memory is small and short-lived, so a tutorial that front-loads a dozen controls and rules exceeds the player's capacity to hold them — most of it evaporates before the first real use [s-hodent-gamers-brain]. learning sticks when it's active (the player does the thing) and timely (taught at the moment of need, so it's immediately reinforced by use). this is the ux/cognitive complement to teaching through space (level-0004) and the mastery arc (prog-0005): those shape what order to teach in; this insists on how — in small, contextual, doing-based doses rather than a lecture up front. fun is learning (design-0003), and learning by playing is far more effective (and more fun) than learning by reading. onboarding and the introduction of any mechanic, control, or system. highest-value in the opening hour, where first impressions and drop-off are decided. some complexity genuinely needs explicit reference (deep strategy/sim games, complex control schemes) — the fix there is an accessible, optional reference the player can consult, not a forced lecture. genre conventions vary: a hardcore sim audience tolerates (even expects) a manual; a broad-audience game cannot. and "just in time" still needs the teaching to arrive before failure, not after. break teaching into single-concept, in-context moments triggered by need. prefer showing and doing over telling. make any necessary text short, skippable, and re-accessible. avoid the unskippable tutorial wall. test onboarding with true first-time players and watch where they overload or forget (playtest-0001/0003). guided just-in-time onboarding (accessible, low-overload) vs. manual/upfront instruction (thorough, suits complex or hardcore games) vs. discovery-first (teach nothing, let players find out). the cognitive/onboarding angle on teaching, complementing the spatial (level-0004) and pacing (prog-0005) angles. feeds cognitive-load management (ux-0002). confidence 4.


Attention and working memory are limited resources — spend them deliberately. Show the player what they need when they need it and no more, and introduce systems and interface gradually (progressive disclosure) rather than all at once. Complexity revealed over time is depth; complexity dumped at once is overload.

---
id: GDC-L1-UX-0002
title: Manage cognitive load — reveal complexity progressively
layer: L1
domain: UX
subdomain: cognitive-load
type: contextual
confidence: 4
status: canonical
tags:
  - ux
  - cognitive-load
  - progressive-disclosure
  - information-hierarchy
  - attention
related:
  - GDC-L1-UX-0001
  - GDC-L1-DESIGN-0005
  - GDC-L1-SYS-0006
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-hodent-gamers-brain
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Attention and working memory are limited resources — spend them deliberately. Show the
> player what they need *when* they need it and no more, and introduce systems and interface
> gradually (progressive disclosure) rather than all at once. Complexity revealed over time
> is depth; complexity dumped at once is overload.

## Rationale
The brain can only attend to and hold so much at once, and exceeding that budget produces
confusion, missed information, and stress rather than mastery [S-hodent-gamers-brain]. The
same total complexity feels completely different depending on delivery: metered out as the
player is ready, it reads as a game with satisfying depth (easy to learn, hard to master —
DESIGN-0005); delivered all at once, it reads as impenetrable. Progressive disclosure — a
UI that starts simple and grows, systems introduced one at a time, advanced options tucked
until relevant — keeps the player inside their cognitive budget while still building toward
real depth. This is also how a legible system (SYS-0006) stays legible even when it's large.

## Applies when
Any game with substantial systems or interface — RPGs, strategy, sims, and especially deep
systemic games. The more total complexity, the more its *pacing* matters.

## Does not apply / Exceptions
Some audiences want the full dashboard immediately (expert-facing tools, hardcore sims where
mastering the information *is* the game). And progressive disclosure can be overdone —
hiding things players need, or gating information so aggressively it becomes patronizing or
obscure. Balance disclosure against the player's genuine need to see.

## Implementation (kept separate from the principle)
Introduce mechanics and UI elements one at a time, unlocking complexity as competence grows (pairs with just-in-time teaching, UX-0001). Use information hierarchy so the most important things dominate attention and secondary detail recedes. Hide advanced options until relevant.

## Disagreement
Progressive disclosure (start simple, reveal over time) vs. full-transparency (show
everything, trust the player) — the latter suits expert audiences and tools; the former suits
broad audiences and deep systems. Also overlaps the transparency⇄mystery axis: how much to
reveal is partly a UX-clarity question and partly a discovery-design choice.

## Notes
The attention-budget principle behind good onboarding (UX-0001) and legible large systems (SYS-0006, DESIGN-0005). Confidence 4.

gdc-l1-ux-0002 manage cognitive load — reveal complexity progressively ux cognitive-load progressive-disclosure information-hierarchy attention > attention and working memory are limited resources — spend them deliberately. show the player what they need when they need it and no more, and introduce systems and interface gradually (progressive disclosure) rather than all at once. complexity revealed over time is depth; complexity dumped at once is overload. the brain can only attend to and hold so much at once, and exceeding that budget produces confusion, missed information, and stress rather than mastery [s-hodent-gamers-brain]. the same total complexity feels completely different depending on delivery: metered out as the player is ready, it reads as a game with satisfying depth (easy to learn, hard to master — design-0005); delivered all at once, it reads as impenetrable. progressive disclosure — a ui that starts simple and grows, systems introduced one at a time, advanced options tucked until relevant — keeps the player inside their cognitive budget while still building toward real depth. this is also how a legible system (sys-0006) stays legible even when it's large. any game with substantial systems or interface — rpgs, strategy, sims, and especially deep systemic games. the more total complexity, the more its pacing matters. some audiences want the full dashboard immediately (expert-facing tools, hardcore sims where mastering the information is the game). and progressive disclosure can be overdone — hiding things players need, or gating information so aggressively it becomes patronizing or obscure. balance disclosure against the player's genuine need to see. introduce mechanics and ui elements one at a time, unlocking complexity as competence grows (pairs with just-in-time teaching, ux-0001). use information hierarchy so the most important things dominate attention and secondary detail recedes. hide advanced options until relevant. progressive disclosure (start simple, reveal over time) vs. full-transparency (show everything, trust the player) — the latter suits expert audiences and tools; the former suits broad audiences and deep systems. also overlaps the transparency⇄mystery axis: how much to reveal is partly a ux-clarity question and partly a discovery-design choice. the attention-budget principle behind good onboarding (ux-0001) and legible large systems (sys-0006, design-0005). confidence 4.


The interface exists to answer the player's questions at a glance: what's happening, what can I do, what just happened, what matters most? Use visual hierarchy — size, contrast, position, color, motion — to rank importance, and give clear feedback for every action. If players have to squint, hunt, or guess, the UI has failed its job.

---
id: GDC-L1-UX-0003
title: Make the interface communicate — readability, hierarchy, and feedback
layer: L1
domain: UX
subdomain: ui-design
type: objective
confidence: 4
status: canonical
tags:
  - ux
  - ui
  - readability
  - information-hierarchy
  - feedback
  - hud
related:
  - GDC-L1-FEEL-0004
  - GDC-L1-SYS-0006
  - GDC-L1-LEVEL-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-hodent-gamers-brain
  - S-norman-doet
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> The interface exists to answer the player's questions at a glance: *what's happening, what
> can I do, what just happened, what matters most?* Use visual hierarchy — size, contrast,
> position, color, motion — to rank importance, and give clear feedback for every action. If
> players have to squint, hunt, or guess, the UI has failed its job.

## Rationale
An interface is a communication channel, and its quality is measured by how quickly and
correctly the player reads it, not by how it looks in a screenshot [S-hodent-gamers-brain].
The eye and brain triage by salience — bright, big, high-contrast, moving things get
attention first — so a UI that doesn't *rank* its elements forces the player to search, which
costs attention that should be on the game (UX-0002). Feedback closes the loop Norman
describes: every action needs a visible, immediate confirmation, or the player can't tell if
it worked [S-norman-doet] (the UI expression of FEEL-0004). Good UI makes the important
legible instantly and the unimportant recede.

## Applies when
All HUD, menu, and interface design, and any moment the game must convey state,
availability, or the result of an action.

## Does not apply / Exceptions
Deliberate minimalism and diegetic/no-HUD design are valid stylistic choices (immersion,
tension, art) — but they don't exempt the game from *communicating*; they just move the
communication into the world (a wounded character's limp instead of a health bar). Some
information is intentionally withheld for tension or discovery (transparency⇄mystery). The
rule is "communicate what the player needs, clearly," not "put everything on a HUD."

## Implementation (kept separate from the principle)
Establish a clear hierarchy: the most important information is the most salient; secondary
detail is quieter. Never encode critical information in color alone (accessibility, UX-0006).
Give immediate, unambiguous feedback for actions and state changes. Test readability with
real players at real speed and viewing distance — if they miss it, redesign the presentation,
not the player. Reduce clutter; every element competes for attention.

## Disagreement
Rich/informative HUD (clarity, low friction) vs. minimal/diegetic UI (immersion, art) is a
stylistic split — but both camps agree the game must *communicate*, differing on *where* and
*how much*. The debate is presentation, not whether to inform.

## Notes
The UI face of legibility — SYS-0006 (systems), LEVEL-0002 (space), and FEEL-0004 (feedback)
all meet here in the interface layer. Confidence 4.

gdc-l1-ux-0003 make the interface communicate — readability, hierarchy, and feedback ux ui readability information-hierarchy feedback hud > the interface exists to answer the player's questions at a glance: what's happening, what can i do, what just happened, what matters most? use visual hierarchy — size, contrast, position, color, motion — to rank importance, and give clear feedback for every action. if players have to squint, hunt, or guess, the ui has failed its job. an interface is a communication channel, and its quality is measured by how quickly and correctly the player reads it, not by how it looks in a screenshot [s-hodent-gamers-brain]. the eye and brain triage by salience — bright, big, high-contrast, moving things get attention first — so a ui that doesn't rank its elements forces the player to search, which costs attention that should be on the game (ux-0002). feedback closes the loop norman describes: every action needs a visible, immediate confirmation, or the player can't tell if it worked [s-norman-doet] (the ui expression of feel-0004). good ui makes the important legible instantly and the unimportant recede. all hud, menu, and interface design, and any moment the game must convey state, availability, or the result of an action. deliberate minimalism and diegetic/no-hud design are valid stylistic choices (immersion, tension, art) — but they don't exempt the game from communicating; they just move the communication into the world (a wounded character's limp instead of a health bar). some information is intentionally withheld for tension or discovery (transparency⇄mystery). the rule is "communicate what the player needs, clearly," not "put everything on a hud." establish a clear hierarchy: the most important information is the most salient; secondary detail is quieter. never encode critical information in color alone (accessibility, ux-0006). give immediate, unambiguous feedback for actions and state changes. test readability with real players at real speed and viewing distance — if they miss it, redesign the presentation, not the player. reduce clutter; every element competes for attention. rich/informative hud (clarity, low friction) vs. minimal/diegetic ui (immersion, art) is a stylistic split — but both camps agree the game must communicate, differing on where and how much. the debate is presentation, not whether to inform. the ui face of legibility — sys-0006 (systems), level-0002 (space), and feel-0004 (feedback) all meet here in the interface layer. confidence 4.


Design so the correct action is obvious and the wrong one is hard. Objects and controls should signal how to use them (affordances and signifiers), controls should map naturally to their effects, and established conventions (WASD to move, red for danger, a button prompt to interact) should be honored unless breaking them clearly pays. Don't make players guess or relearn what they already know.

---
id: GDC-L1-UX-0004
title: Use affordances, signifiers, and conventions — make the right action obvious
layer: L1
domain: UX
subdomain: ui-design
type: contextual
confidence: 4
status: canonical
tags:
  - ux
  - affordances
  - signifiers
  - conventions
  - mapping
  - discoverability
related:
  - GDC-L1-UX-0003
  - GDC-L1-UX-0005
  - GDC-L1-FEEL-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-norman-doet
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Design so the correct action is obvious and the wrong one is hard. Objects and controls
> should signal how to use them (**affordances** and **signifiers**), controls should map
> naturally to their effects, and established **conventions** (WASD to move, red for danger,
> a button prompt to interact) should be honored unless breaking them clearly pays. Don't
> make players guess or relearn what they already know.

## Rationale
Players arrive with a huge library of learned conventions and real-world intuitions, and good
design *leverages* that library rather than fighting it [S-norman-doet]. An affordance is
what an object lets you do; a signifier is the cue that tells the player it's possible — a
ledge that's clearly grabbable, a door that's obviously openable, a highlighted interactable.
Natural mapping (the control relates intuitively to its effect) and honored convention mean
the player transfers existing knowledge instead of learning from scratch, which lowers
cognitive load (UX-0002) and gets them playing sooner. Violating a strong convention without
a reason imposes a relearning tax and a stream of avoidable errors.

## Applies when
Control schemes, interactable objects, UI elements, iconography — anywhere the player must
figure out "what can I do here and how?"

## Does not apply / Exceptions
Breaking convention can be a deliberate, valuable design move — a novel control or interface
that unlocks something conventions can't (motion controls, unique traversal, an
intentionally alien UI). The test is whether the payoff exceeds the relearning cost. Some
signifiers are also deliberately hidden for discovery/puzzle design (a secret is *supposed*
to be non-obvious). Convention is the default to depart from consciously, not a mandate.

## Implementation (kept separate from the principle)
Signal interactivity clearly (highlights, prompts, distinct shapes/materials for
interactables). Map controls to their effects intuitively. Follow platform and genre
conventions for common actions unless you have a real reason not to — and when you break one,
teach the new pattern deliberately (UX-0001). Make illegal or harmful actions hard or
impossible rather than merely discouraged.

## Disagreement
Convention (leverage learned patterns, low friction, fast onboarding) vs. innovation (novel
schemes that enable new experiences at a learning cost) is a real tension. Broad-audience and
usability-first design leans convention; distinctive, mechanic-defining design sometimes earns
the cost of the new. Break conventions on purpose, not by accident.

## Notes
The Norman core of the UX domain; pairs with readable communication (UX-0003), control
ergonomics (UX-0005), and responsiveness (FEEL-0002 — a signified action must also *respond*).
Confidence 4.

gdc-l1-ux-0004 use affordances, signifiers, and conventions — make the right action obvious ux affordances signifiers conventions mapping discoverability > design so the correct action is obvious and the wrong one is hard. objects and controls should signal how to use them (affordances and signifiers), controls should map naturally to their effects, and established conventions (wasd to move, red for danger, a button prompt to interact) should be honored unless breaking them clearly pays. don't make players guess or relearn what they already know. players arrive with a huge library of learned conventions and real-world intuitions, and good design leverages that library rather than fighting it [s-norman-doet]. an affordance is what an object lets you do; a signifier is the cue that tells the player it's possible — a ledge that's clearly grabbable, a door that's obviously openable, a highlighted interactable. natural mapping (the control relates intuitively to its effect) and honored convention mean the player transfers existing knowledge instead of learning from scratch, which lowers cognitive load (ux-0002) and gets them playing sooner. violating a strong convention without a reason imposes a relearning tax and a stream of avoidable errors. control schemes, interactable objects, ui elements, iconography — anywhere the player must figure out "what can i do here and how?" breaking convention can be a deliberate, valuable design move — a novel control or interface that unlocks something conventions can't (motion controls, unique traversal, an intentionally alien ui). the test is whether the payoff exceeds the relearning cost. some signifiers are also deliberately hidden for discovery/puzzle design (a secret is supposed to be non-obvious). convention is the default to depart from consciously, not a mandate. signal interactivity clearly (highlights, prompts, distinct shapes/materials for interactables). map controls to their effects intuitively. follow platform and genre conventions for common actions unless you have a real reason not to — and when you break one, teach the new pattern deliberately (ux-0001). make illegal or harmful actions hard or impossible rather than merely discouraged. convention (leverage learned patterns, low friction, fast onboarding) vs. innovation (novel schemes that enable new experiences at a learning cost) is a real tension. broad-audience and usability-first design leans convention; distinctive, mechanic-defining design sometimes earns the cost of the new. break conventions on purpose, not by accident. the norman core of the ux domain; pairs with readable communication (ux-0003), control ergonomics (ux-0005), and responsiveness (feel-0002 — a signified action must also respond). confidence 4.


Controls live in the body, not just the menu. Map actions to inputs that fit the hand, respect muscle memory, and treat input space as scarce — every binding competes for the player's fingers and memory. Give the most frequent actions the easiest inputs, and never demand more simultaneous inputs than hands can comfortably manage.

---
id: GDC-L1-UX-0005
title: Design controls for the hand — ergonomics, mapping, and button economy
layer: L1
domain: UX
subdomain: control-schemes
type: contextual
confidence: 4
status: canonical
tags:
  - ux
  - controls
  - ergonomics
  - button-economy
  - mapping
  - muscle-memory
related:
  - GDC-L1-UX-0004
  - GDC-L1-FEEL-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-norman-doet
  - S-hodent-gamers-brain
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Controls live in the body, not just the menu. Map actions to inputs that fit the hand,
> respect muscle memory, and treat input space as **scarce** — every binding competes for the
> player's fingers and memory. Give the most frequent actions the easiest inputs, and never
> demand more simultaneous inputs than hands can comfortably manage.

## Rationale
Play is physical: the player's fingers, not their conscious mind, execute most actions once
learned, so the *layout* of controls shapes how the game feels to operate
[S-hodent-gamers-brain]. Frequent actions on awkward inputs cause constant friction and
error; conflicting or overloaded bindings break the muscle memory that skilled play depends
on. Button economy is real — a controller has a fixed, small number of comfortable inputs, so
each new action *costs* one, and adding capability often means *replacing* a binding rather
than piling on another (natural mapping and constraint, per Norman [S-norman-doet]). Designing
for the hand keeps the interface between intent and action invisible, which is the
precondition for good feel (FEEL-0002).

## Applies when
Control-scheme design, input mapping, and any time you add a new player action or ability.
Most acute on controllers (scarce buttons) and for action games (execution matters).

## Does not apply / Exceptions
Input-rich platforms (keyboard+mouse, complex sim setups) have more room and audiences who
accept dense bindings. Some genres intentionally use awkward or demanding controls for effect
(deliberate clumsiness for comedy or tension). And accessibility overrides ergonomic
"defaults" — full remapping (UX-0006) means no single layout must fit every hand.

## Implementation (kept separate from the principle)
Assign the easiest, most reachable inputs to the most frequent actions. Group related actions sensibly, respect platform conventions (UX-0004), and always offer full remapping.

## Disagreement
Minimal/economical control sets (accessible, low cognitive and motor load) vs. rich/expressive
control sets (depth, expert expression, more verbs) — fighting games and sims lean rich;
broad-audience and mobile lean minimal. The scarcity of comfortable inputs is the constraint
both negotiate.

## Notes
Confidence 4.

gdc-l1-ux-0005 design controls for the hand — ergonomics, mapping, and button economy ux controls ergonomics button-economy mapping muscle-memory > controls live in the body, not just the menu. map actions to inputs that fit the hand, respect muscle memory, and treat input space as scarce — every binding competes for the player's fingers and memory. give the most frequent actions the easiest inputs, and never demand more simultaneous inputs than hands can comfortably manage. play is physical: the player's fingers, not their conscious mind, execute most actions once learned, so the layout of controls shapes how the game feels to operate [s-hodent-gamers-brain]. frequent actions on awkward inputs cause constant friction and error; conflicting or overloaded bindings break the muscle memory that skilled play depends on. button economy is real — a controller has a fixed, small number of comfortable inputs, so each new action costs one, and adding capability often means replacing a binding rather than piling on another (natural mapping and constraint, per norman [s-norman-doet]). designing for the hand keeps the interface between intent and action invisible, which is the precondition for good feel (feel-0002). control-scheme design, input mapping, and any time you add a new player action or ability. most acute on controllers (scarce buttons) and for action games (execution matters). input-rich platforms (keyboard+mouse, complex sim setups) have more room and audiences who accept dense bindings. some genres intentionally use awkward or demanding controls for effect (deliberate clumsiness for comedy or tension). and accessibility overrides ergonomic "defaults" — full remapping (ux-0006) means no single layout must fit every hand. assign the easiest, most reachable inputs to the most frequent actions. group related actions sensibly, respect platform conventions (ux-0004), and always offer full remapping. minimal/economical control sets (accessible, low cognitive and motor load) vs. rich/expressive control sets (depth, expert expression, more verbs) — fighting games and sims lean rich; broad-audience and mobile lean minimal. the scarcity of comfortable inputs is the constraint both negotiate. confidence 4.


Build accessibility in from the start, not as a late patch: remappable controls, scalable text, colorblind-safe visuals (never encode information in color alone), subtitles and captions, difficulty/assist options, and toggles for effects like screen shake. Accessibility widens your audience and usually makes the game better for everyone. Plan for it early so core UI, input, audio, and visual systems can support it.

---
id: GDC-L1-UX-0006
title: Treat accessibility as design — and build it in early
layer: L1
domain: UX
subdomain: accessibility
type: contextual
confidence: 4
status: canonical
tags:
  - ux
  - accessibility
  - inclusion
  - player-respect
  - options
related:
  - GDC-L1-FEEL-0006
  - GDC-L1-PROG-0004
  - GDC-L1-UX-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-game-accessibility
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Build accessibility in from the start, not as a late patch: remappable controls, scalable
> text, colorblind-safe visuals (never encode information in color alone), subtitles and
> captions, difficulty/assist options, and toggles for effects like screen shake.
> Accessibility widens your audience and usually makes the game better for everyone.
> Plan for it early so core UI, input, audio, and visual systems can support it.

## Rationale
A large number of players have disabilities — visual, auditory, motor, cognitive — and small,
well-known features remove barriers that exclude them [S-game-accessibility]. Common high-impact
needs include control remapping, scalable text, colorblind-safe information, and strong subtitle
presentation. These are architectural design concerns, not a charity add-on: no color-only
encoding, scalable UI, and a remappable input layer are easier to support when the underlying
systems anticipate them. Accessibility features also routinely help *everyone*
(the "curb-cut effect"): subtitles help players in noisy rooms, remapping helps everyone find
a comfortable layout, a screen-shake toggle helps the motion-sensitive and the easily-nauseated
alike (FEEL-0006). It's an extension of respecting the player (PROG-0004).

## Applies when
From the earliest UI, input, audio, and visual-design decisions onward.

## Does not apply / Exceptions
Not every accessibility feature fits every game, and some interact with core design (a
difficulty/assist mode can conflict with a game whose identity *is* its difficulty — a real
and much-debated tension). Tiny-scope or experimental projects may implement only a focused
set of high-impact essentials. The principle is to *design so accessibility is possible*,
not that every option must ship in every game.

## Implementation (kept separate from the principle)
Plan high-impact basics from day one: full input remapping, scalable/high-contrast
text, no color-only information (add shape/icon/text), subtitles with size and contrast
controls, and effect toggles (screen shake — FEEL-0006). Add difficulty/assist options and
pause-anywhere where they fit. Consult established guidelines and test with players who have
relevant needs. Treat "can everyone who wants to play, play?" as a design question.

## Disagreement
The live debate is narrow but real: **difficulty/assist options** — do they belong in every
game, or does a deliberately punishing game have the right to its difficulty as an
inseparable part of its identity? (The rest of accessibility — remapping, text, color,
captions — enjoys broad consensus.) Even there, most argue assist options rarely harm the
players who ignore them.

## Notes
The inclusion-and-respect principle of UX; directly connects to FEEL-0006 (screen-shake
toggle) and PROG-0004 (respect the player), with a clear ethics/wellbeing dimension.
Confidence 4.

gdc-l1-ux-0006 treat accessibility as design — and build it in early ux accessibility inclusion player-respect options > build accessibility in from the start, not as a late patch: remappable controls, scalable text, colorblind-safe visuals (never encode information in color alone), subtitles and captions, difficulty/assist options, and toggles for effects like screen shake. accessibility widens your audience and usually makes the game better for everyone. plan for it early so core ui, input, audio, and visual systems can support it. a large number of players have disabilities — visual, auditory, motor, cognitive — and small, well-known features remove barriers that exclude them [s-game-accessibility]. common high-impact needs include control remapping, scalable text, colorblind-safe information, and strong subtitle presentation. these are architectural design concerns, not a charity add-on: no color-only encoding, scalable ui, and a remappable input layer are easier to support when the underlying systems anticipate them. accessibility features also routinely help everyone (the "curb-cut effect"): subtitles help players in noisy rooms, remapping helps everyone find a comfortable layout, a screen-shake toggle helps the motion-sensitive and the easily-nauseated alike (feel-0006). it's an extension of respecting the player (prog-0004). from the earliest ui, input, audio, and visual-design decisions onward. not every accessibility feature fits every game, and some interact with core design (a difficulty/assist mode can conflict with a game whose identity is its difficulty — a real and much-debated tension). tiny-scope or experimental projects may implement only a focused set of high-impact essentials. the principle is to design so accessibility is possible, not that every option must ship in every game. plan high-impact basics from day one: full input remapping, scalable/high-contrast text, no color-only information (add shape/icon/text), subtitles with size and contrast controls, and effect toggles (screen shake — feel-0006). add difficulty/assist options and pause-anywhere where they fit. consult established guidelines and test with players who have relevant needs. treat "can everyone who wants to play, play?" as a design question. the live debate is narrow but real: difficulty/assist options — do they belong in every game, or does a deliberately punishing game have the right to its difficulty as an inseparable part of its identity? (the rest of accessibility — remapping, text, color, captions — enjoys broad consensus.) even there, most argue assist options rarely harm the players who ignore them. the inclusion-and-respect principle of ux; directly connects to feel-0006 (screen-shake toggle) and prog-0004 (respect the player), with a clear ethics/wellbeing dimension. confidence 4.


Every menu, load screen, unskippable cutscene, confirmation dialog, and scrap of busywork between the player and the core loop is a tax on engagement. Ruthlessly reduce friction on the path to play. Respect the player's time and attention — get them to the fun and keep them in it.

---
id: GDC-L1-UX-0007
title: Minimize friction between the player and the fun
layer: L1
domain: UX
subdomain: ui-design
type: contextual
confidence: 4
status: canonical
tags:
  - ux
  - friction
  - player-respect
  - flow
  - core-loop
related:
  - GDC-L1-SYS-0001
  - GDC-L1-PROG-0004
  - GDC-L1-FEEL-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-hodent-gamers-brain
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Every menu, load screen, unskippable cutscene, confirmation dialog, and scrap of busywork
> between the player and the core loop is a tax on engagement. Ruthlessly reduce friction on
> the path to play. Respect the player's time and attention — get them to the fun and keep
> them in it.

## Rationale
Engagement is fragile: friction on the way to the fun (long loads, menu mazes, forced
tutorials, needless confirmations, grindy setup) leaks motivation and gives the player exits
[S-hodent-gamers-brain]. The core loop (SYS-0001) is where the value lives, so anything that
delays, interrupts, or clutters the route to it is spending the player's goodwill for no
gameplay return. Minimizing friction is partly respect (PROG-0004 — don't waste the player's
time) and partly practical (a game that's quick to get into and stay in gets played more, and
loses fewer players at each seam). Fast, clean access to play is invisible when done well and
corrosive when ignored.

## Applies when
Boot-to-play flow, menu and inventory design, mission setup, retries and respawns, and any
repeated action on the path to the core loop.

## Does not apply / Exceptions
Not all friction is bad — **deliberate friction** creates weight, ritual, tension, and
meaning: a Souls bonfire's deliberate rest, inventory management *as* gameplay, a slow reload
that raises stakes, a save ritual that makes the world feel consequential. The distinction is
*meaningful* friction (part of the intended experience) vs. *incidental* friction (accidental
tax with no payoff). Cut the incidental; keep the meaningful. Removing all friction can also
flatten pacing (LEVEL-0003 needs rests).

## Implementation (kept separate from the principle)
Audit the path from launch to play and from failure to retry; cut or streamline every step
that isn't earning its place. Reduce load times (or mask them), skip or shorten repeated
cutscenes, trim confirmation dialogs to the genuinely destructive actions, and get respawns
fast. Ask of each bit of friction: does this add to the experience, or just delay it? Keep
the meaningful, cut the rest.

## Disagreement
Frictionless design (respect time, maximize flow, remove obstacles) vs. meaningful-friction
design (weight, ritual, stakes, and downtime as part of the experience). Both are right about
different friction; the craft is telling incidental tax from intentional texture. Hyper-casual
leans frictionless; immersive and deliberate games keep chosen friction.

## Notes
The engagement/respect principle that ties UX to the core loop (SYS-0001) and player respect
(PROG-0004); its meaningful-friction exception connects to pacing (LEVEL-0003) and weight
(FEEL-0008). Confidence 4.

gdc-l1-ux-0007 minimize friction between the player and the fun ux friction player-respect flow core-loop > every menu, load screen, unskippable cutscene, confirmation dialog, and scrap of busywork between the player and the core loop is a tax on engagement. ruthlessly reduce friction on the path to play. respect the player's time and attention — get them to the fun and keep them in it. engagement is fragile: friction on the way to the fun (long loads, menu mazes, forced tutorials, needless confirmations, grindy setup) leaks motivation and gives the player exits [s-hodent-gamers-brain]. the core loop (sys-0001) is where the value lives, so anything that delays, interrupts, or clutters the route to it is spending the player's goodwill for no gameplay return. minimizing friction is partly respect (prog-0004 — don't waste the player's time) and partly practical (a game that's quick to get into and stay in gets played more, and loses fewer players at each seam). fast, clean access to play is invisible when done well and corrosive when ignored. boot-to-play flow, menu and inventory design, mission setup, retries and respawns, and any repeated action on the path to the core loop. not all friction is bad — deliberate friction creates weight, ritual, tension, and meaning: a souls bonfire's deliberate rest, inventory management as gameplay, a slow reload that raises stakes, a save ritual that makes the world feel consequential. the distinction is meaningful friction (part of the intended experience) vs. incidental friction (accidental tax with no payoff). cut the incidental; keep the meaningful. removing all friction can also flatten pacing (level-0003 needs rests). audit the path from launch to play and from failure to retry; cut or streamline every step that isn't earning its place. reduce load times (or mask them), skip or shorten repeated cutscenes, trim confirmation dialogs to the genuinely destructive actions, and get respawns fast. ask of each bit of friction: does this add to the experience, or just delay it? keep the meaningful, cut the rest. frictionless design (respect time, maximize flow, remove obstacles) vs. meaningful-friction design (weight, ritual, stakes, and downtime as part of the experience). both are right about different friction; the craft is telling incidental tax from intentional texture. hyper-casual leans frictionless; immersive and deliberate games keep chosen friction. the engagement/respect principle that ties ux to the core loop (sys-0001) and player respect (prog-0004); its meaningful-friction exception connects to pacing (level-0003) and weight (feel-0008). confidence 4.