The game is the experience it produces in the player — not the intent in the designer's head. Judge every decision by the experience it actually creates, and let observed player experience, not authorial intent, be the final arbiter.

---
id: GDC-L1-DESIGN-0001
title: Design for the player's experience, not the designer's intent
layer: L1
domain: DESIGN
subdomain: player-centric
type: objective
confidence: 5
status: canonical
tags:
  - player-centric
  - mda
  - intent
  - playtest
related:
  - GDC-L1-PLAYTEST-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-schell-artofgamedesign
  - S-hunicke-mda
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> The game *is* the experience it produces in the player — not the intent in the
> designer's head. Judge every decision by the experience it actually creates, and let
> observed player experience, not authorial intent, be the final arbiter.

## Rationale
Players never encounter your intentions; they encounter mechanics, which produce
dynamics, which produce an experience (the MDA framework: Mechanics → Dynamics →
Aesthetics). Designers build from the mechanics end and can *see* their intent;
players receive from the experience end and cannot. This asymmetry means a designer's
confidence that something "should" be fun, clear, or fair is systematically unreliable —
it is contaminated by knowledge the player doesn't have. The only correction is to
treat the produced experience as the ground truth and intent as a hypothesis about it.

## Applies when
Always, but the stakes are highest when evaluating clarity, difficulty, fun, and
emotional response — anywhere your privileged knowledge as the author distorts your
read of what the player will actually feel.

## Does not apply / Exceptions
This governs *evaluation*, not *ambition*. It does not mean designing by committee or
sanding off every rough edge players complain about — players report symptoms, not
cures (see Disagreement). A deliberately hostile or uncomfortable experience is fine
**if that discomfort is the intended experience and it lands**; the principle still
holds because you are judging by the experience produced, not overriding it with intent.

## Implementation (kept separate from the principle)
Externalize the target experience early ("the player should feel *tense and
resourceful*") so it can be tested against reality. Then close the loop with real
players: watch them play without helping, note where their experience diverges from the
target, and treat divergence as a design signal rather than a player error. First-time-
user tests are especially diagnostic because your intent-contamination is strongest
around onboarding.

## Disagreement
Two schools agree on this principle but differ on *how much to weight raw player
reaction*:

- **Player-led / data-driven:** lean hard on playtest and telemetry; if players don't
  have the intended experience, the design is wrong. Strongest for broad-audience,
  usability-sensitive, and live-service games.
- **Auteur / vision-led:** players reliably report *what* feels wrong but are poor at
  prescribing fixes, and chasing every reaction erodes a coherent vision. Strongest for
  strongly-authored, distinctive, or intentionally challenging games.

The synthesis both camps accept: **observed experience is the truth you must respond
to; the designer still owns the response.** Listen to the symptom; own the cure.

## Notes
This is the load-bearing principle under most of the DESIGN and PLAYTEST domains —
much of playtesting exists precisely because of the intent-vs-experience gap. Rated
confidence 5: near-universal agreement across design literature and practice, with the
only live debate being the weighting question captured above, not the core claim.
"MDA" (Mechanics → Dynamics → Aesthetics) is standard design vocabulary; its origin is
in the front-matter sources.

gdc-l1-design-0001 design for the player's experience, not the designer's intent player-centric mda intent playtest > the game is the experience it produces in the player — not the intent in the designer's head. judge every decision by the experience it actually creates, and let observed player experience, not authorial intent, be the final arbiter. players never encounter your intentions; they encounter mechanics, which produce dynamics, which produce an experience (the mda framework: mechanics → dynamics → aesthetics). designers build from the mechanics end and can see their intent; players receive from the experience end and cannot. this asymmetry means a designer's confidence that something "should" be fun, clear, or fair is systematically unreliable — it is contaminated by knowledge the player doesn't have. the only correction is to treat the produced experience as the ground truth and intent as a hypothesis about it. always, but the stakes are highest when evaluating clarity, difficulty, fun, and emotional response — anywhere your privileged knowledge as the author distorts your read of what the player will actually feel. this governs evaluation, not ambition. it does not mean designing by committee or sanding off every rough edge players complain about — players report symptoms, not cures (see disagreement). a deliberately hostile or uncomfortable experience is fine if that discomfort is the intended experience and it lands; the principle still holds because you are judging by the experience produced, not overriding it with intent. externalize the target experience early ("the player should feel tense and resourceful") so it can be tested against reality. then close the loop with real players: watch them play without helping, note where their experience diverges from the target, and treat divergence as a design signal rather than a player error. first-time- user tests are especially diagnostic because your intent-contamination is strongest around onboarding. two schools agree on this principle but differ on how much to weight raw player reaction: - player-led / data-driven: lean hard on playtest and telemetry; if players don't have the intended experience, the design is wrong. strongest for broad-audience, usability-sensitive, and live-service games. - auteur / vision-led: players reliably report what feels wrong but are poor at prescribing fixes, and chasing every reaction erodes a coherent vision. strongest for strongly-authored, distinctive, or intentionally challenging games. the synthesis both camps accept: observed experience is the truth you must respond to; the designer still owns the response. listen to the symptom; own the cure. this is the load-bearing principle under most of the design and playtest domains — much of playtesting exists precisely because of the intent-vs-experience gap. rated confidence 5: near-universal agreement across design literature and practice, with the only live debate being the weighting question captured above, not the core claim. "mda" (mechanics → dynamics → aesthetics) is standard design vocabulary; its origin is in the front-matter sources.


Wherever the game asks the player to choose, make the choice interesting: the outcome must matter, the best option must not be obvious, and every option must carry a real tradeoff. Ruthlessly remove dominant strategies (an option that is always correct) and inconsequential choices (options whose outcomes don't matter) — both are non-decisions wearing a decision's clothes.

---
id: GDC-L1-DESIGN-0002
title: Make the player's choices interesting — real tradeoffs, no dominant option
layer: L1
domain: DESIGN
subdomain: decisions-and-agency
type: objective
confidence: 4
status: canonical
tags:
  - decisions
  - meaningful-choice
  - risk-reward
  - balance
related:
  - GDC-L1-DESIGN-0006
  - GDC-L1-DESIGN-0001
depends_on:
  - GDC-L1-DESIGN-0001
conflicts_with: []
supersedes: []
sources:
  - S-meier-interesting-decisions
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Wherever the game asks the player to choose, make the choice *interesting*: the
> outcome must matter, the best option must not be obvious, and every option must carry
> a real tradeoff. Ruthlessly remove dominant strategies (an option that is always
> correct) and inconsequential choices (options whose outcomes don't matter) — both are
> non-decisions wearing a decision's clothes.

## Rationale
Decision-making is the engine of most gameplay: agency, tension, and replayability all
grow from choices the player actually has to think about. A choice is only interesting
when multiple considerations pull in different directions and the player must apply
judgment [S-meier-interesting-decisions]. Two failure modes destroy this. A **dominant
option** collapses the decision — if A is always best, there was never a choice, just a
correct answer to discover once. An **inconsequential option** collapses it the other
way — if outcomes don't differ or aren't visible, the player has no basis to care.
Interesting decisions require both *real tradeoffs* (choosing A means giving up B) and
*visible consequences* (the player can see that the choice mattered).

## Applies when
Any point of player choice: builds, loadouts, tactics, resource spending, branching
paths, upgrade trees, moment-to-moment combat options. It is the primary lens for
combat, strategy, RPG systems, and progression design.

## Does not apply / Exceptions
This is guidance for the *choices a game contains*, not a claim that every good game is
built on choices. Experiential, narrative, and atmospheric games can be excellent with
few meaningful decisions — their value lives in other domains (NARR, FEEL, aesthetics).
Also, not every choice should be agonizing: low-stakes expressive or cosmetic choices
(character color, base decoration) are legitimately inconsequential by design and
shouldn't be forced into tradeoffs.

## Implementation (kept separate from the principle)
Audit choices for dominance: if playtesters or theory converge on one "correct" build or
tactic, either buff the alternatives, add situational counters (rock-paper-scissors
relationships), or add costs that make the strong option situational. Make consequences
legible — the player must be able to perceive that A led somewhere different from B.
Introduce tradeoffs along orthogonal axes (offense vs. defense, speed vs. power, now vs.
later) so options aren't strictly rankable.

## Disagreement
The famous framing "a game *is* a series of interesting decisions" is contested as a
*definition* of games — walking simulators, toys, and purely narrative works are games
by most accounts yet aren't built on decisions. The design *guidance*, however (when you
do include choices, make them interesting), is near-universally endorsed. This entry
adopts the guidance and rejects the overreach of the definition.

## Notes
Confidence 4: overwhelming practitioner consensus on the guidance; held below 5 by the legitimate "not all games are decisions" scope limit.

gdc-l1-design-0002 make the player's choices interesting — real tradeoffs, no dominant option decisions meaningful-choice risk-reward balance > wherever the game asks the player to choose, make the choice interesting: the outcome must matter, the best option must not be obvious, and every option must carry a real tradeoff. ruthlessly remove dominant strategies (an option that is always correct) and inconsequential choices (options whose outcomes don't matter) — both are non-decisions wearing a decision's clothes. decision-making is the engine of most gameplay: agency, tension, and replayability all grow from choices the player actually has to think about. a choice is only interesting when multiple considerations pull in different directions and the player must apply judgment [s-meier-interesting-decisions]. two failure modes destroy this. a dominant option collapses the decision — if a is always best, there was never a choice, just a correct answer to discover once. an inconsequential option collapses it the other way — if outcomes don't differ or aren't visible, the player has no basis to care. interesting decisions require both real tradeoffs (choosing a means giving up b) and visible consequences (the player can see that the choice mattered). any point of player choice: builds, loadouts, tactics, resource spending, branching paths, upgrade trees, moment-to-moment combat options. it is the primary lens for combat, strategy, rpg systems, and progression design. this is guidance for the choices a game contains, not a claim that every good game is built on choices. experiential, narrative, and atmospheric games can be excellent with few meaningful decisions — their value lives in other domains (narr, feel, aesthetics). also, not every choice should be agonizing: low-stakes expressive or cosmetic choices (character color, base decoration) are legitimately inconsequential by design and shouldn't be forced into tradeoffs. audit choices for dominance: if playtesters or theory converge on one "correct" build or tactic, either buff the alternatives, add situational counters (rock-paper-scissors relationships), or add costs that make the strong option situational. make consequences legible — the player must be able to perceive that a led somewhere different from b. introduce tradeoffs along orthogonal axes (offense vs. defense, speed vs. power, now vs. later) so options aren't strictly rankable. the famous framing "a game is a series of interesting decisions" is contested as a definition of games — walking simulators, toys, and purely narrative works are games by most accounts yet aren't built on decisions. the design guidance, however (when you do include choices, make them interesting), is near-universally endorsed. this entry adopts the guidance and rejects the overreach of the definition. confidence 4: overwhelming practitioner consensus on the guidance; held below 5 by the legitimate "not all games are decisions" scope limit.


A major source of fun is learning — the pleasure of recognizing and mastering patterns. Design so the player is always acquiring and then mastering new patterns; when there is nothing left to learn, mastery turns to boredom, so keep introducing fresh patterns before the old ones are exhausted.

---
id: GDC-L1-DESIGN-0003
title: Fun is learning — feed the player a steady supply of masterable patterns
layer: L1
domain: DESIGN
subdomain: fun-and-motivation
type: contextual
confidence: 3
status: canonical
tags:
  - fun-and-motivation
  - mastery
  - learning
  - pacing
related:
  - GDC-L1-DESIGN-0004
  - GDC-L1-DESIGN-0005
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-koster-theoryoffun
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> A major source of fun is *learning* — the pleasure of recognizing and mastering
> patterns. Design so the player is always acquiring and then mastering new patterns;
> when there is nothing left to learn, mastery turns to boredom, so keep introducing
> fresh patterns before the old ones are exhausted.

## Rationale
The brain rewards pattern-mastery; games that supply "tasty patterns" to learn produce
the specific pleasure often labeled fun, and once a pattern is fully grokked it stops
being interesting [S-koster-theoryoffun]. This reframes fun as a *rate*: not a static
property of the game but a function of how steadily the player is learning. It explains
common failure modes directly — a game that teaches everything in the first hour goes
stale (nothing left to learn), and a game that never lets the player achieve mastery is
merely frustrating (learning never completes). The design target is a sustained cadence
of "new pattern → practice → mastery → new pattern."

## Applies when
Skill-, puzzle-, strategy-, and mastery-driven games, and the learning arc of almost any
game. Strongest as a lens on pacing, content introduction, and long-term retention.

## Does not apply / Exceptions
Learning is *one* engine of fun, not the only one. Social connection, narrative and
emotional payoff, aesthetic pleasure, self-expression, relaxation, and the thrill of
triumph (fiero) are distinct pleasures that don't reduce to pattern-mastery. Games built
primarily on those (social party games, narrative adventures, cozy/relaxation games) are
under-served by treating learning as the whole story. Treat this as a powerful lens, not
a totalizing theory of fun.

## Implementation (kept separate from the principle)
Map the game's learning curve: list the patterns the player must acquire and stagger
their introduction so a new one arrives roughly as the last is being mastered. Use
difficulty and content pacing to keep the learning rate positive (see FLOW, DESIGN-0004).
Watch for "solved" states where an optimal pattern trivializes everything after it — that
is the mastery problem arriving early; answer it with new mechanics, vari, or depth.

## Disagreement
Koster's "fun is learning" is influential but explicitly one theory among several
(contrast taxonomies of player motivation and kinds of fun that enumerate many distinct
pleasures). The disagreement isn't that learning is fun — it plainly is — but whether it
is *the* root of fun. This entry treats it as a high-value lens and defers to
motivation-pluralism where a game's pleasure lies elsewhere.

## Notes
Confidence 3: the mechanism is well-argued and widely cited but is a contested single-cause theory, and rests substantially on one author — raise if corroborated by motivation research during a later sweep.

gdc-l1-design-0003 fun is learning — feed the player a steady supply of masterable patterns fun-and-motivation mastery learning pacing > a major source of fun is learning — the pleasure of recognizing and mastering patterns. design so the player is always acquiring and then mastering new patterns; when there is nothing left to learn, mastery turns to boredom, so keep introducing fresh patterns before the old ones are exhausted. the brain rewards pattern-mastery; games that supply "tasty patterns" to learn produce the specific pleasure often labeled fun, and once a pattern is fully grokked it stops being interesting [s-koster-theoryoffun]. this reframes fun as a rate: not a static property of the game but a function of how steadily the player is learning. it explains common failure modes directly — a game that teaches everything in the first hour goes stale (nothing left to learn), and a game that never lets the player achieve mastery is merely frustrating (learning never completes). the design target is a sustained cadence of "new pattern → practice → mastery → new pattern." skill-, puzzle-, strategy-, and mastery-driven games, and the learning arc of almost any game. strongest as a lens on pacing, content introduction, and long-term retention. learning is one engine of fun, not the only one. social connection, narrative and emotional payoff, aesthetic pleasure, self-expression, relaxation, and the thrill of triumph (fiero) are distinct pleasures that don't reduce to pattern-mastery. games built primarily on those (social party games, narrative adventures, cozy/relaxation games) are under-served by treating learning as the whole story. treat this as a powerful lens, not a totalizing theory of fun. map the game's learning curve: list the patterns the player must acquire and stagger their introduction so a new one arrives roughly as the last is being mastered. use difficulty and content pacing to keep the learning rate positive (see flow, design-0004). watch for "solved" states where an optimal pattern trivializes everything after it — that is the mastery problem arriving early; answer it with new mechanics, vari, or depth. koster's "fun is learning" is influential but explicitly one theory among several (contrast taxonomies of player motivation and kinds of fun that enumerate many distinct pleasures). the disagreement isn't that learning is fun — it plainly is — but whether it is the root of fun. this entry treats it as a high-value lens and defers to motivation-pluralism where a game's pleasure lies elsewhere. confidence 3: the mechanism is well-argued and widely cited but is a contested single-cause theory, and rests substantially on one author — raise if corroborated by motivation research during a later sweep.


Sustained engagement lives in the narrow channel where challenge matches the player's current skill. Because skill rises with play, challenge must rise with it: too much challenge for the skill produces anxiety and frustration; too little produces boredom. Design difficulty as a moving target that tracks the player up the skill curve.

---
id: GDC-L1-DESIGN-0004
title: Keep the player in flow by matching challenge to rising skill
layer: L1
domain: DESIGN
subdomain: fun-and-motivation
type: contextual
confidence: 4
status: canonical
tags:
  - flow
  - difficulty
  - pacing
  - challenge-skill
  - engagement
related:
  - GDC-L1-DESIGN-0003
  - GDC-L1-DESIGN-0005
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-csikszentmihalyi-flow
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Sustained engagement lives in the narrow channel where challenge matches the player's
> current skill. Because skill rises with play, challenge must rise with it: too much
> challenge for the skill produces anxiety and frustration; too little produces boredom.
> Design difficulty as a moving target that tracks the player up the skill curve.

## Rationale
Deep absorption ("flow") occurs when the difficulty of the task is well-aligned to the
performer's ability, bounded on one side by anxiety (challenge exceeds skill) and on the
other by boredom (skill exceeds challenge) [S-csikszentmihalyi-flow]. In games skill is
not static — the player is continuously getting better — so a *fixed* challenge level
slides out of the flow channel: what was engaging becomes trivial as mastery grows.
Keeping the player engaged therefore requires escalating challenge roughly in step with
their improving skill, plus the supporting conditions flow depends on: clear goals and
immediate, unambiguous feedback so the player can tell how they're doing.

## Applies when
Difficulty and pacing design across almost every real-time or skill-based genre —
level progression, enemy scaling, mission design, and the overall difficulty curve.

## Does not apply / Exceptions
Flow is not the only worthwhile experience, and some designs deliberately break it.
Horror wants *anxiety*; a punishing difficulty spike can be a meaningful punctuation or
a rite of passage (many celebrated hard games court frustration on purpose); relaxation
and "cozy" games deliberately keep challenge low and let the player idle below the flow
channel. Deliberate boredom or dread, used for effect, is a valid choice. Also, players
vary widely in skill, which is why fixed curves struggle and options/difficulty settings
exist.

## Implementation (kept separate from the principle)
Build a rising difficulty curve and pace content so new challenge arrives as skill
grows (pairs with DESIGN-0003's cadence of new patterns). Provide clear goals and
immediate feedback so the player can self-correct. Absorb player-to-player skill variance
with difficulty options, dynamic/adaptive difficulty, or self-selected challenge (optional
hard content). Use brief dips below the challenge line intentionally as rest beats, not by
accident.

## Disagreement
Two nuances rather than a hard split. First, whether to keep the player *inside* flow at
all times or to deliberately spike out of it for dramatic effect — both are legitimate;
the answer depends on the intended emotional arc. Second, "flow at all costs" is
critiqued for producing frictionless, forgettable experiences; friction, failure, and
recovery are themselves sources of meaning and pride. Treat flow as the default target
and its deliberate violation as a designed exception.

## Notes
Tightly coupled to DESIGN-0003 (learning) and DESIGN-0005 (accessible depth): flow is
how you *pace* the supply of masterable patterns. Belongs equally to the future PROG
domain (difficulty/mastery curves). Confidence 4: challenge-skill balance is broadly
validated and applied; typed `contextual` because deliberate anti-flow design is common
and valid.

gdc-l1-design-0004 keep the player in flow by matching challenge to rising skill flow difficulty pacing challenge-skill engagement > sustained engagement lives in the narrow channel where challenge matches the player's current skill. because skill rises with play, challenge must rise with it: too much challenge for the skill produces anxiety and frustration; too little produces boredom. design difficulty as a moving target that tracks the player up the skill curve. deep absorption ("flow") occurs when the difficulty of the task is well-aligned to the performer's ability, bounded on one side by anxiety (challenge exceeds skill) and on the other by boredom (skill exceeds challenge) [s-csikszentmihalyi-flow]. in games skill is not static — the player is continuously getting better — so a fixed challenge level slides out of the flow channel: what was engaging becomes trivial as mastery grows. keeping the player engaged therefore requires escalating challenge roughly in step with their improving skill, plus the supporting conditions flow depends on: clear goals and immediate, unambiguous feedback so the player can tell how they're doing. difficulty and pacing design across almost every real-time or skill-based genre — level progression, enemy scaling, mission design, and the overall difficulty curve. flow is not the only worthwhile experience, and some designs deliberately break it. horror wants anxiety; a punishing difficulty spike can be a meaningful punctuation or a rite of passage (many celebrated hard games court frustration on purpose); relaxation and "cozy" games deliberately keep challenge low and let the player idle below the flow channel. deliberate boredom or dread, used for effect, is a valid choice. also, players vary widely in skill, which is why fixed curves struggle and options/difficulty settings exist. build a rising difficulty curve and pace content so new challenge arrives as skill grows (pairs with design-0003's cadence of new patterns). provide clear goals and immediate feedback so the player can self-correct. absorb player-to-player skill variance with difficulty options, dynamic/adaptive difficulty, or self-selected challenge (optional hard content). use brief dips below the challenge line intentionally as rest beats, not by accident. two nuances rather than a hard split. first, whether to keep the player inside flow at all times or to deliberately spike out of it for dramatic effect — both are legitimate; the answer depends on the intended emotional arc. second, "flow at all costs" is critiqued for producing frictionless, forgettable experiences; friction, failure, and recovery are themselves sources of meaning and pride. treat flow as the default target and its deliberate violation as a designed exception. tightly coupled to design-0003 (learning) and design-0005 (accessible depth): flow is how you pace the supply of masterable patterns. belongs equally to the future prog domain (difficulty/mastery curves). confidence 4: challenge-skill balance is broadly validated and applied; typed contextual because deliberate anti-flow design is common and valid.


Aim for a low barrier to entry and a high ceiling of mastery: the game should be easy to start and understand, yet reward deepening skill for a very long time. Reward both the first minute and the hundredth hour.

---
id: GDC-L1-DESIGN-0005
title: Easy to learn, hard to master — pursue depth from a simple surface
layer: L1
domain: DESIGN
subdomain: elegance-and-depth
type: contextual
confidence: 4
status: canonical
tags:
  - depth
  - accessibility
  - emergence
  - mastery
  - elegance
related:
  - GDC-L1-DESIGN-0004
  - GDC-L1-DESIGN-0007
  - GDC-L1-DESIGN-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-bushnell-law
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Aim for a low barrier to entry and a high ceiling of mastery: the game should be easy
> to start and understand, yet reward deepening skill for a very long time. Reward both
> the first minute and the hundredth hour.

## Rationale
An accessible surface lets players in; a high skill ceiling keeps them [S-bushnell-law].
The two are not in tension when depth comes from *interaction* rather than *addition* —
a small set of clear rules that combine into a vast space of situations, strategies, and
edge cases. This is why chess, Go, and the best action and strategy games stay
compelling for decades on rules that fit on a card: initial simplicity gives way to
combinations, counterplay, and mastery that take thousands of hours to exhaust. Depth
bought this way (emergence from few rules) is cheap to teach and rich to master; depth
bought by piling on mechanics is expensive to teach and often shallow.

## Applies when
Broadly, but especially competitive, strategy, action, and any game seeking long
engagement or a wide audience. It is the design ideal behind "elegant" systems.

## Does not apply / Exceptions
Some celebrated games deliberately have a *high* barrier to entry and treat the struggle
to learn as part of the value: deep simulations (e.g. Dwarf Fortress), complex grand
strategy, and games that use opacity and discovery as core experiences (cryptic
progression, "figure it out yourself" design). For a niche, hardcore, or
discovery-driven audience a steep on-ramp can be a feature, not a flaw. The principle is
strongest when breadth of audience or immediate accessibility is a goal; weigh it against
the intended audience.

## Implementation (kept separate from the principle)
Prefer depth from *interacting* systems over depth from *more* systems (see DESIGN-0007
on elegance). Design a gentle on-ramp — teach the core in the first minutes through play
(not manuals), then layer complexity as mastery grows (pairs with flow, DESIGN-0004).
Stress-test the ceiling: can expert play keep discovering new strategies, or does the
system "solve" quickly? Emergent interactions, counterplay, and execution skill all
raise the ceiling.

## Disagreement
The maxim is sometimes overgeneralized into "all games should be easy to learn," which
the discovery/simulation camp rejects: for some experiences, *earning* your
understanding is the point, and an easy surface would cheapen it. The reconciliation:
"easy to learn, hard to master" is the right default for accessibility and reach, but a
deliberately hard-to-learn design is legitimate when difficulty of comprehension is
itself the intended experience.

## Notes
Confidence 4: a foundational industry heuristic; typed `contextual` for the real discovery/simulation exceptions.

gdc-l1-design-0005 easy to learn, hard to master — pursue depth from a simple surface depth accessibility emergence mastery elegance > aim for a low barrier to entry and a high ceiling of mastery: the game should be easy to start and understand, yet reward deepening skill for a very long time. reward both the first minute and the hundredth hour. an accessible surface lets players in; a high skill ceiling keeps them [s-bushnell-law]. the two are not in tension when depth comes from interaction rather than addition — a small set of clear rules that combine into a vast space of situations, strategies, and edge cases. this is why chess, go, and the best action and strategy games stay compelling for decades on rules that fit on a card: initial simplicity gives way to combinations, counterplay, and mastery that take thousands of hours to exhaust. depth bought this way (emergence from few rules) is cheap to teach and rich to master; depth bought by piling on mechanics is expensive to teach and often shallow. broadly, but especially competitive, strategy, action, and any game seeking long engagement or a wide audience. it is the design ideal behind "elegant" systems. some celebrated games deliberately have a high barrier to entry and treat the struggle to learn as part of the value: deep simulations (e.g. dwarf fortress), complex grand strategy, and games that use opacity and discovery as core experiences (cryptic progression, "figure it out yourself" design). for a niche, hardcore, or discovery-driven audience a steep on-ramp can be a feature, not a flaw. the principle is strongest when breadth of audience or immediate accessibility is a goal; weigh it against the intended audience. prefer depth from interacting systems over depth from more systems (see design-0007 on elegance). design a gentle on-ramp — teach the core in the first minutes through play (not manuals), then layer complexity as mastery grows (pairs with flow, design-0004). stress-test the ceiling: can expert play keep discovering new strategies, or does the system "solve" quickly? emergent interactions, counterplay, and execution skill all raise the ceiling. the maxim is sometimes overgeneralized into "all games should be easy to learn," which the discovery/simulation camp rejects: for some experiences, earning your understanding is the point, and an easy surface would cheapen it. the reconciliation: "easy to learn, hard to master" is the right default for accessibility and reach, but a deliberately hard-to-learn design is legitimate when difficulty of comprehension is itself the intended experience. confidence 4: a foundational industry heuristic; typed contextual for the real discovery/simulation exceptions.


Agency is the feeling that your choices author your experience. For it to be real, the player's choices must produce consequences that are legible — perceivable and attributable to the choice. A choice whose effect the player cannot see is, to them, not a choice at all.

---
id: GDC-L1-DESIGN-0006
title: Give the player real agency — choices must produce legible consequences
layer: L1
domain: DESIGN
subdomain: decisions-and-agency
type: contextual
confidence: 4
status: canonical
tags:
  - agency
  - meaningful-choice
  - consequences
  - player-centric
related:
  - GDC-L1-DESIGN-0002
  - GDC-L1-DESIGN-0001
depends_on:
  - GDC-L1-DESIGN-0001
conflicts_with: []
supersedes: []
sources:
  - S-meier-interesting-decisions
  - S-schell-artofgamedesign
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Agency is the feeling that your choices author your experience. For it to be real, the
> player's choices must produce consequences that are *legible* — perceivable and
> attributable to the choice. A choice whose effect the player cannot see is, to them,
> not a choice at all.

## Rationale
Where DESIGN-0002 concerns the quality of an individual decision (tradeoffs, no dominant
option), this concerns agency at the level of the whole experience: does the player feel
authorship? Consequences drive that feeling, but only if the player can *perceive* them
and *attribute* them to their action [S-meier-interesting-decisions]. Invisible or
delayed-beyond-recognition consequences read as randomness or railroading; the player
stops believing their input matters and disengages (ties to DESIGN-0001 — judge by the
experience produced). Legibility is the hinge: the same branching system feels powerful
if consequences are readable and empty if they aren't.

## Applies when
Systems and narratives that promise player authorship: branching stories, faction and
reputation systems, build/character choices, strategic decisions, emergent sandboxes,
and any "your choices matter" pitch.

## Does not apply / Exceptions
Strongly-authored, linear experiences deliberately trade agency for a crafted arc, and
that is a legitimate design — not every game should maximize agency. The *illusion* of
choice is also a real and defensible tool: narrative games often present choices whose
mechanical outcomes converge, trading true branching for emotional agency (the player
felt the weight of choosing) at sustainable production cost. The line to avoid is the
*unsatisfying* illusion — where players notice their choices are hollow and feel
cheated.

## Implementation (kept separate from the principle)
Close the loop between choice and visible outcome: acknowledge choices promptly, and
surface their consequences where the player can connect cause to effect (immediate
feedback for tactical choices; callbacks and changed world-state for narrative ones).
Prefer fewer choices with real, readable consequences over many with imperceptible ones.
When using converging/illusory choice for production reasons, protect the *feeling* of
consequence and avoid exposing the seams.

## Disagreement
Agency-maximalists (systemic/immersive-sim tradition) hold that real, simulated
consequence is worth its high cost and that illusory choice ultimately betrays players.
Authored-experience designers hold that a curated, linear arc — or well-hidden illusion
of choice — often delivers a better and more sustainable experience than sprawling real
branching. Both are right for different games; the deciding factor is whether *authorship*
or *authored arc* is the promise you're making to the player. Keep the promise you make.

## Notes
Pairs with DESIGN-0002 (interesting decisions) as the two halves of choice design:
0002 = are the options interesting; 0006 = does choosing feel consequential. Confidence
4: broad agreement on the legibility requirement; typed `contextual` for the legitimate
linear-authorship and illusion-of-choice exceptions.

gdc-l1-design-0006 give the player real agency — choices must produce legible consequences agency meaningful-choice consequences player-centric > agency is the feeling that your choices author your experience. for it to be real, the player's choices must produce consequences that are legible — perceivable and attributable to the choice. a choice whose effect the player cannot see is, to them, not a choice at all. where design-0002 concerns the quality of an individual decision (tradeoffs, no dominant option), this concerns agency at the level of the whole experience: does the player feel authorship? consequences drive that feeling, but only if the player can perceive them and attribute them to their action [s-meier-interesting-decisions]. invisible or delayed-beyond-recognition consequences read as randomness or railroading; the player stops believing their input matters and disengages (ties to design-0001 — judge by the experience produced). legibility is the hinge: the same branching system feels powerful if consequences are readable and empty if they aren't. systems and narratives that promise player authorship: branching stories, faction and reputation systems, build/character choices, strategic decisions, emergent sandboxes, and any "your choices matter" pitch. strongly-authored, linear experiences deliberately trade agency for a crafted arc, and that is a legitimate design — not every game should maximize agency. the illusion of choice is also a real and defensible tool: narrative games often present choices whose mechanical outcomes converge, trading true branching for emotional agency (the player felt the weight of choosing) at sustainable production cost. the line to avoid is the unsatisfying illusion — where players notice their choices are hollow and feel cheated. close the loop between choice and visible outcome: acknowledge choices promptly, and surface their consequences where the player can connect cause to effect (immediate feedback for tactical choices; callbacks and changed world-state for narrative ones). prefer fewer choices with real, readable consequences over many with imperceptible ones. when using converging/illusory choice for production reasons, protect the feeling of consequence and avoid exposing the seams. agency-maximalists (systemic/immersive-sim tradition) hold that real, simulated consequence is worth its high cost and that illusory choice ultimately betrays players. authored-experience designers hold that a curated, linear arc — or well-hidden illusion of choice — often delivers a better and more sustainable experience than sprawling real branching. both are right for different games; the deciding factor is whether authorship or authored arc is the promise you're making to the player. keep the promise you make. pairs with design-0002 (interesting decisions) as the two halves of choice design: 0002 = are the options interesting; 0006 = does choosing feel consequential. confidence 4: broad agreement on the legibility requirement; typed contextual for the legitimate linear-authorship and illusion-of-choice exceptions.


Favor elegance: get the most meaningful gameplay from the fewest rules. Every mechanic carries a cost — to learn, to build, to balance, to explain — so a mechanic must earn that cost in gameplay value. When a rule doesn't pull its weight, cut it rather than keep it.

---
id: GDC-L1-DESIGN-0007
title: Prize elegance — maximize meaningful gameplay per rule, and cut what doesn't earn its complexity
layer: L1
domain: DESIGN
subdomain: elegance-and-depth
type: stylistic
confidence: 3
status: canonical
tags:
  - elegance
  - depth
  - complexity
  - scope-discipline
  - emergence
related:
  - GDC-L1-DESIGN-0005
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-schell-artofgamedesign
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Favor elegance: get the most meaningful gameplay from the fewest rules. Every mechanic
> carries a cost — to learn, to build, to balance, to explain — so a mechanic must earn
> that cost in gameplay value. When a rule doesn't pull its weight, cut it rather than
> keep it.

## Rationale
Complexity is a budget spent on all sides: the player's cognitive load, the team's
build and balance effort, and the surface area for bugs and exploits. Elegant systems
spend that budget efficiently — a few rules that *interact* generate far more gameplay
than the same number of rules bolted on independently, which is why emergence is the
elegant designer's favorite tool (a small rule set, a large possibility space; see
DESIGN-0005). Cutting a weak mechanic usually *strengthens* the whole, because it lowers
the cost of entry and sharpens what remains. "What can I remove and lose nothing?" is
often a more productive question than "what can I add?"

## Applies when
System and mechanics design, and scope decisions throughout production. Especially
valuable when a design feels bloated, hard to teach, or hard to balance.

## Does not apply / Exceptions
Elegance is a value, not a law — some beloved games are deliberately *baroque*, and
their richness, maximalism, and abundance of interacting systems are the point (sprawling
sims, deep RPGs, systemic sandboxes, "kitchen-sink" designs). There, more systems create
more emergent stories, and aggressive minimalism would drain the appeal. Elegance also
trades against expressive breadth and content variety. This is why it is typed
`stylistic`: reasonable, excellent designers deliberately choose the opposite.

## Implementation (kept separate from the principle)
Pressure-test each mechanic: what does it add that nothing else does, and what would
break if it were removed? Prefer mechanics that interact with existing systems (multiply
value) over isolated ones (add value linearly). Periodically run a subtractive pass —
"kill your darlings" — and cut features that don't earn their complexity. Watch for
mechanics that exist only to prop up other mechanics; collapsing them often simplifies
and improves.

## Disagreement
Genuine, and it is a taste axis, not a correctness one: **minimalist/elegant** design
(few deep systems, ruthless cutting) vs. **maximalist/baroque** design (many interacting
systems, richness through abundance). Both have produced masterpieces. The choice should
follow the game's identity and the audience's appetite for complexity, not a universal
preference — which is exactly why this is `stylistic`.

## Notes
The counterweight to feature creep and a close ally of DESIGN-0005 (depth from simple
rules). Confidence 3 and typed `stylistic`: the *reasoning* is strong, but whether to
prize elegance over richness is a legitimate matter of design taste, so it must not be
stated as an objective rule.

gdc-l1-design-0007 prize elegance — maximize meaningful gameplay per rule, and cut what doesn't earn its complexity elegance depth complexity scope-discipline emergence > favor elegance: get the most meaningful gameplay from the fewest rules. every mechanic carries a cost — to learn, to build, to balance, to explain — so a mechanic must earn that cost in gameplay value. when a rule doesn't pull its weight, cut it rather than keep it. complexity is a budget spent on all sides: the player's cognitive load, the team's build and balance effort, and the surface area for bugs and exploits. elegant systems spend that budget efficiently — a few rules that interact generate far more gameplay than the same number of rules bolted on independently, which is why emergence is the elegant designer's favorite tool (a small rule set, a large possibility space; see design-0005). cutting a weak mechanic usually strengthens the whole, because it lowers the cost of entry and sharpens what remains. "what can i remove and lose nothing?" is often a more productive question than "what can i add?" system and mechanics design, and scope decisions throughout production. especially valuable when a design feels bloated, hard to teach, or hard to balance. elegance is a value, not a law — some beloved games are deliberately baroque, and their richness, maximalism, and abundance of interacting systems are the point (sprawling sims, deep rpgs, systemic sandboxes, "kitchen-sink" designs). there, more systems create more emergent stories, and aggressive minimalism would drain the appeal. elegance also trades against expressive breadth and content variety. this is why it is typed stylistic: reasonable, excellent designers deliberately choose the opposite. pressure-test each mechanic: what does it add that nothing else does, and what would break if it were removed? prefer mechanics that interact with existing systems (multiply value) over isolated ones (add value linearly). periodically run a subtractive pass — "kill your darlings" — and cut features that don't earn their complexity. watch for mechanics that exist only to prop up other mechanics; collapsing them often simplifies and improves. genuine, and it is a taste axis, not a correctness one: minimalist/elegant design (few deep systems, ruthless cutting) vs. maximalist/baroque design (many interacting systems, richness through abundance). both have produced masterpieces. the choice should follow the game's identity and the audience's appetite for complexity, not a universal preference — which is exactly why this is stylistic. the counterweight to feature creep and a close ally of design-0005 (depth from simple rules). confidence 3 and typed stylistic: the reasoning is strong, but whether to prize elegance over richness is a legitimate matter of design taste, so it must not be stated as an objective rule.


Design for a specific player, not an abstract "everyone." Know who the game is for — what they enjoy, expect, and find hard — and let that knowledge inform decisions. A game aimed at everyone usually delights no one; a game that knows its audience can be sharp, coherent, and loved by the people it's for.

---
id: GDC-L1-DESIGN-0008
title: Know your audience — design for a specific player, not "everyone"
layer: L1
domain: DESIGN
subdomain: player-centric
type: contextual
confidence: 4
status: canonical
tags:
  - player-centric
  - audience
  - target-player
  - scope
  - vision
related:
  - GDC-L1-DESIGN-0001
  - GDC-L1-VISION-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-schell-artofgamedesign
first_added: 2026-07-15
last_verified: 2026-07-15
---

## Statement
> Design for a *specific* player, not an abstract "everyone." Know who the game is for — what
> they enjoy, expect, and find hard — and let that knowledge inform decisions. A game aimed at
> everyone usually delights no one; a game that knows its audience can be sharp, coherent, and
> loved by the people it's for.

## Rationale
Every design decision — difficulty, tone, complexity, controls, monetization — has a *right*
answer only relative to who's playing, so "is this good?" is unanswerable without "good for
whom?" [S-schell-artofgamedesign]. Trying to please everyone forces averaging: the game gets
sanded down to offend no one and excite no one, and its decisions pull in incompatible
directions (a game can't be both a hardcore sim and a pick-up-and-play casual game without
becoming incoherent). Knowing the audience is what makes "design for the experience produced"
(DESIGN-0001) actionable — the *intended* experience is intended *for someone*. It also grounds
the vision (VISION-0001) and disciplines scope (you build what your audience needs, not every
possible feature). This is not pandering or market-chasing; it's the basic act of designing for
real people rather than a phantom universal player.

## Applies when
Throughout design, and especially at the outset (who is this for?) and whenever a decision has no
obvious answer — check it against the target player. Foundational to vision, scope, difficulty,
and tone.

## Does not apply / Exceptions
"Know your audience" is not "chase the biggest market" or "give players only what they ask for"
(players report symptoms, not cures — PLAYTEST-0004); a designer can know their audience deeply
and still surprise or challenge them. Personal/art games may be made for an audience of one (the
creator) — that's a valid, known audience, not an absence of one. And a genuinely broad game can
serve a wide audience *if* it understands what that audience shares — breadth done knowingly, not
by averaging blindly.

## Implementation (kept separate from the principle)
Define the target player early (their tastes, skills, expectations, context) and make it explicit (part of the vision, VISION-0001). Check ambiguous decisions against them: would *this* player enjoy this? Use it to set difficulty, complexity, tone, and scope. Validate assumptions with real representative players (PLAYTEST-0006's sampling).

## Disagreement
Audience-first design (coherent, sharp, loved by its people — but narrower reach) vs.
broad-appeal design (bigger market — but risk of averaging into blandness). And how much to give
the known audience what it expects vs. surprise it. The resolution: know the audience deeply, then
decide *deliberately* how much to comfort vs. challenge them — breadth and surprise are choices
made *with* audience knowledge, not substitutes for it.

## Notes
A foundational player-centric principle the corpus implied everywhere but hadn't stated outright (added in the 2026-07-15 audit). Confidence 4.

gdc-l1-design-0008 know your audience — design for a specific player, not "everyone" player-centric audience target-player scope vision > design for a specific player, not an abstract "everyone." know who the game is for — what they enjoy, expect, and find hard — and let that knowledge inform decisions. a game aimed at everyone usually delights no one; a game that knows its audience can be sharp, coherent, and loved by the people it's for. every design decision — difficulty, tone, complexity, controls, monetization — has a right answer only relative to who's playing, so "is this good?" is unanswerable without "good for whom?" [s-schell-artofgamedesign]. trying to please everyone forces averaging: the game gets sanded down to offend no one and excite no one, and its decisions pull in incompatible directions (a game can't be both a hardcore sim and a pick-up-and-play casual game without becoming incoherent). knowing the audience is what makes "design for the experience produced" (design-0001) actionable — the intended experience is intended for someone. it also grounds the vision (vision-0001) and disciplines scope (you build what your audience needs, not every possible feature). this is not pandering or market-chasing; it's the basic act of designing for real people rather than a phantom universal player. throughout design, and especially at the outset (who is this for?) and whenever a decision has no obvious answer — check it against the target player. foundational to vision, scope, difficulty, and tone. "know your audience" is not "chase the biggest market" or "give players only what they ask for" (players report symptoms, not cures — playtest-0004); a designer can know their audience deeply and still surprise or challenge them. personal/art games may be made for an audience of one (the creator) — that's a valid, known audience, not an absence of one. and a genuinely broad game can serve a wide audience if it understands what that audience shares — breadth done knowingly, not by averaging blindly. define the target player early (their tastes, skills, expectations, context) and make it explicit (part of the vision, vision-0001). check ambiguous decisions against them: would this player enjoy this? use it to set difficulty, complexity, tone, and scope. validate assumptions with real representative players (playtest-0006's sampling). audience-first design (coherent, sharp, loved by its people — but narrower reach) vs. broad-appeal design (bigger market — but risk of averaging into blandness). and how much to give the known audience what it expects vs. surprise it. the resolution: know the audience deeply, then decide deliberately how much to comfort vs. challenge them — breadth and surprise are choices made with audience knowledge, not substitutes for it. a foundational player-centric principle the corpus implied everywhere but hadn't stated outright (added in the 2026-07-15 audit). confidence 4.


Game feel is the moment-to-moment sensation of controlling a virtual body in a simulated space, made vivid by polish. Treat it as three interlocking layers you design deliberately — control (real-time input→response), physicality (a space with weight, momentum, and collision), and polish (sensory amplification) — not as an accident that emerges from the rest of the game.

---
id: GDC-L1-FEEL-0001
title: Game feel is real-time control of a virtual body in a simulated space, made vivid by polish
layer: L1
domain: FEEL
subdomain: responsiveness
type: objective
confidence: 5
status: canonical
tags:
  - game-feel
  - definition
  - mda
  - player-centric
related:
  - GDC-L1-FEEL-0002
  - GDC-L1-FEEL-0004
  - GDC-L1-DESIGN-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-swink-gamefeel
  - S-pichlmair-johansen-survey
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Game feel is the moment-to-moment sensation of controlling a virtual body in a
> simulated space, made vivid by polish. Treat it as three interlocking layers you
> design deliberately — **control** (real-time input→response), **physicality** (a
> space with weight, momentum, and collision), and **polish** (sensory amplification) —
> not as an accident that emerges from the rest of the game.

## Rationale
"Feel" sounds ineffable, but it decomposes into three things a designer can actually
tune: real-time control, a simulated space with its own physicality, and the polish that
amplifies interactions [S-swink-gamefeel]. Independent academic synthesis recovers the
same structure under different names — physicality, amplification, support
[S-pichlmair-johansen-survey] — which is strong evidence the decomposition is real and
not just one author's framing. Because the layers are separable, "the controls feel bad"
becomes a diagnosable problem: a defect in one of control, physicality, or polish, each
with its own tools. Naming the layers turns a vague complaint into an addressable bug.

## Applies when
Any game with real-time or near-real-time player control of an avatar, cursor, camera,
or object — platformers, shooters, action, driving, sports, most action-RPGs. It is the
lens for every other FEEL principle.

## Does not apply / Exceptions
Games with no real-time control loop — pure turn-based strategy, most text and
narrative games, asynchronous puzzles — have aesthetics and polish but little "game
feel" in this technical sense. Their satisfaction comes from other domains (DESIGN,
NARR, SYS). Polish still matters; real-time *feel* does not.

## Implementation (kept separate from the principle)
Diagnose feel by layer. Bad **control** → look at latency, input mapping, and
responsiveness (see FEEL-0002/0003). Bad **physicality** → look at acceleration,
momentum, gravity, and collision tuning. Bad **polish** → look at feedback: animation,
particles, sound, camera (see FEEL-0004). Tune each layer in isolation before judging
the whole.

## Disagreement
No meaningful disagreement about the decomposition itself; it is the field's shared
vocabulary. Debate exists only *within* the layers (e.g. how much polish, how much
responsiveness) and is captured in the specific principles below.

## Notes
This is the anchor principle for the FEEL domain — most other FEEL entries are a deeper
cut into one of its three layers. Confidence 5: the foundational text and an independent
academic survey converge on the same decomposition, making this as settled as game-feel
theory gets.

gdc-l1-feel-0001 game feel is real-time control of a virtual body in a simulated space, made vivid by polish game-feel definition mda player-centric > game feel is the moment-to-moment sensation of controlling a virtual body in a simulated space, made vivid by polish. treat it as three interlocking layers you design deliberately — control (real-time input→response), physicality (a space with weight, momentum, and collision), and polish (sensory amplification) — not as an accident that emerges from the rest of the game. "feel" sounds ineffable, but it decomposes into three things a designer can actually tune: real-time control, a simulated space with its own physicality, and the polish that amplifies interactions [s-swink-gamefeel]. independent academic synthesis recovers the same structure under different names — physicality, amplification, support [s-pichlmair-johansen-survey] — which is strong evidence the decomposition is real and not just one author's framing. because the layers are separable, "the controls feel bad" becomes a diagnosable problem: a defect in one of control, physicality, or polish, each with its own tools. naming the layers turns a vague complaint into an addressable bug. any game with real-time or near-real-time player control of an avatar, cursor, camera, or object — platformers, shooters, action, driving, sports, most action-rpgs. it is the lens for every other feel principle. games with no real-time control loop — pure turn-based strategy, most text and narrative games, asynchronous puzzles — have aesthetics and polish but little "game feel" in this technical sense. their satisfaction comes from other domains (design, narr, sys). polish still matters; real-time feel does not. diagnose feel by layer. bad control → look at latency, input mapping, and responsiveness (see feel-0002/0003). bad physicality → look at acceleration, momentum, gravity, and collision tuning. bad polish → look at feedback: animation, particles, sound, camera (see feel-0004). tune each layer in isolation before judging the whole. no meaningful disagreement about the decomposition itself; it is the field's shared vocabulary. debate exists only within the layers (e.g. how much polish, how much responsiveness) and is captured in the specific principles below. this is the anchor principle for the feel domain — most other feel entries are a deeper cut into one of its three layers. confidence 5: the foundational text and an independent academic survey converge on the same decomposition, making this as settled as game-feel theory gets.


The game must register and visibly acknowledge the player's input immediately — ideally on the next frame. Keep end-to-end control latency low enough that the player reads response as continuous with intent, because delayed acknowledgment quickly erodes game feel.

---
id: GDC-L1-FEEL-0002
title: Acknowledge input immediately; keep control latency perceptually tight
layer: L1
domain: FEEL
subdomain: responsiveness
type: objective
confidence: 5
status: canonical
tags:
  - responsiveness
  - latency
  - input
  - measure-dont-guess
related:
  - GDC-L1-FEEL-0001
  - GDC-L1-FEEL-0003
depends_on:
  - GDC-L1-FEEL-0001
conflicts_with:
  - GDC-L1-FEEL-0008
supersedes: []
sources:
  - S-swink-gamefeel
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> The game must register and visibly acknowledge the player's input immediately —
> ideally on the next frame. Keep end-to-end control latency low enough that the player
> reads response as continuous with intent, because delayed acknowledgment quickly erodes game feel.

## Rationale
Control feel lives in a tight loop: the player acts, the game responds, the player
reads the response and acts again. Swink describes roughly 100 ms as an important region
for instant-feeling response, while also emphasizing that acceptable latency varies with
the action and that continuity degrades across a wider range [S-swink-gamefeel]. Latency is
uniquely corrosive because it degrades every single interaction uniformly and cannot be
compensated for by more polish — a beautifully juiced game with sluggish input still
feels bad. Crucially, "acknowledge" is not the same as "resolve": the game can register
the input this frame and start showing *something* (a wind-up, a sound, a flash) even if
the full action takes longer to play out.

## Applies when
Every real-time control action: movement, jumping, firing, camera, menu navigation.
The bar is strictest for high-frequency, skill-expressive actions the player performs
constantly.

## Does not apply / Exceptions
Deliberate, communicated delays that are part of the fantasy (a heavy weapon's
wind-up, a charged attack) are not latency — see FEEL-0008. The distinction: latency is
the game being slow to *hear* you; commitment is the game taking time to *carry out*
what it already heard. The former is always a defect; the latter can be a feature. Also,
some competitive or simulation genres accept higher latency for other guarantees
(rollback vs. delay-based netcode tradeoffs), a networking concern rather than a feel
ideal.

## Implementation (kept separate from the principle)
Measure, don't guess: capture end-to-end latency (photograph or high-speed-capture the
button-to-pixel delay), not just engine frame time. Reduce it by processing input as
early in the frame as possible, avoiding multi-frame input pipelines, and giving
*instant* feedback on press even when the modeled action resolves later. On unavoidable
delays, mask them with immediate secondary feedback (sound, a tiny anticipation pose) so
the player still feels heard on frame one.

## Disagreement
The pure-responsiveness ideal is in tension with deliberately weighty, commitment-heavy
combat (see FEEL-0008). The reconciliation both sides accept: *acknowledgment* latency
should always be minimized; *resolution* time is a design choice. Even Dark Souls
registers your dodge press instantly and buffers it — it just resolves the roll on its
own animation schedule.

## Notes
Confidence 5: universal agreement across action-game practice, plus a measured
perceptual threshold. The `conflicts_with` link to FEEL-0008 is intentional and
productive — see that entry for the full responsiveness-vs-commitment treatment.

gdc-l1-feel-0002 acknowledge input immediately; keep control latency perceptually tight responsiveness latency input measure-dont-guess > the game must register and visibly acknowledge the player's input immediately — ideally on the next frame. keep end-to-end control latency low enough that the player reads response as continuous with intent, because delayed acknowledgment quickly erodes game feel. control feel lives in a tight loop: the player acts, the game responds, the player reads the response and acts again. swink describes roughly 100 ms as an important region for instant-feeling response, while also emphasizing that acceptable latency varies with the action and that continuity degrades across a wider range [s-swink-gamefeel]. latency is uniquely corrosive because it degrades every single interaction uniformly and cannot be compensated for by more polish — a beautifully juiced game with sluggish input still feels bad. crucially, "acknowledge" is not the same as "resolve": the game can register the input this frame and start showing something (a wind-up, a sound, a flash) even if the full action takes longer to play out. every real-time control action: movement, jumping, firing, camera, menu navigation. the bar is strictest for high-frequency, skill-expressive actions the player performs constantly. deliberate, communicated delays that are part of the fantasy (a heavy weapon's wind-up, a charged attack) are not latency — see feel-0008. the distinction: latency is the game being slow to hear you; commitment is the game taking time to carry out what it already heard. the former is always a defect; the latter can be a feature. also, some competitive or simulation genres accept higher latency for other guarantees (rollback vs. delay-based netcode tradeoffs), a networking concern rather than a feel ideal. measure, don't guess: capture end-to-end latency (photograph or high-speed-capture the button-to-pixel delay), not just engine frame time. reduce it by processing input as early in the frame as possible, avoiding multi-frame input pipelines, and giving instant feedback on press even when the modeled action resolves later. on unavoidable delays, mask them with immediate secondary feedback (sound, a tiny anticipation pose) so the player still feels heard on frame one. the pure-responsiveness ideal is in tension with deliberately weighty, commitment-heavy combat (see feel-0008). the reconciliation both sides accept: acknowledgment latency should always be minimized; resolution time is a design choice. even dark souls registers your dodge press instantly and buffers it — it just resolves the roll on its own animation schedule. confidence 5: universal agreement across action-game practice, plus a measured perceptual threshold. the conflictswith link to feel-0008 is intentional and productive — see that entry for the full responsiveness-vs-commitment treatment.


Read what the player meant, not only what they literally pressed. Add small, invisible forgiveness windows — coyote time, input buffering, corner correction — so that near-misses of timing or aim resolve the way the player intended.

---
id: GDC-L1-FEEL-0003
title: Interpret the player's intent, not just their literal input
layer: L1
domain: FEEL
subdomain: input
type: contextual
confidence: 4
status: canonical
tags:
  - input
  - forgiveness
  - player-centric
  - intent
  - accessibility
related:
  - GDC-L1-FEEL-0002
  - GDC-L1-DESIGN-0001
depends_on:
  - GDC-L1-FEEL-0002
conflicts_with: []
supersedes: []
sources:
  - S-thorson-celeste-forgiveness
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Read what the player *meant*, not only what they literally pressed. Add small,
> invisible forgiveness windows — coyote time, input buffering, corner correction — so
> that near-misses of timing or aim resolve the way the player intended.

## Rationale
Human motor timing is imprecise by tens of milliseconds; strict input handling punishes
players for gaps between intent and execution that they never perceive as their own
error — it just feels like the game "didn't work." Forgiveness closes that gap. The
staple techniques [S-thorson-celeste-forgiveness]: coyote time (a jump still fires
briefly after leaving a ledge), jump-input buffering (a jump pressed shortly before
landing still fires on landing), and
corner correction (a head-bonk nudges the avatar around the lip instead of stopping it).
Players don't perceive these as assists; they perceive the controls as "tight." The
deeper principle: the game should be on the player's side, targeting the experience they
intended (ties to DESIGN-0001).

## Applies when
Precision- and timing-critical real-time control, especially platforming, action, and
anything with tight jumps, dashes, or combo timing. Highest value where the skill
expression is in *positioning and timing* rather than in the timing test itself.

## Does not apply / Exceptions
When the strictness *is* the game. Rhythm games, precision-timing challenges, and some
hardcore/competitive designs treat exact timing as the skill being tested; forgiveness
there removes the point. And forgiveness must stay small and consistent — overly generous
or context-varying windows make the game feel mushy, unpredictable, or unfair in the
other direction. Tune to taste and genre.

## Implementation (kept separate from the principle)
Start with short coyote-time and input-buffer windows, then tune them against the game’s
speed, animation, and intended difficulty. Add corner/edge correction where collision would
otherwise reject a clear player intention. Make windows *fixed and predictable*, not adaptive,
so mastery stays learnable. Keep them invisible — if players can point at the assist, it
is probably too large. Always verify by watching real players (playtest), since the
whole point is matching perceived intent.

## Disagreement
Two schools: **forgiveness-first** (Celeste, Super Meat Boy — assume good intent,
tighten feel) vs. **purity-first** (execution-focused and competitive designs — exact
input is the test). Neither is universally right; the deciding question is *whether the
timing itself is the skill you want to measure.* If yes, stay strict; if the timing is
just a tax on the real skill (positioning, decision-making), forgive it.

## Notes
Type is `contextual` precisely because the purity-first exception is real and common.
Confidence 4: strong practitioner consensus for the genres where it applies, with the
genuine genre-dependent exception keeping it below 5.

gdc-l1-feel-0003 interpret the player's intent, not just their literal input input forgiveness player-centric intent accessibility > read what the player meant, not only what they literally pressed. add small, invisible forgiveness windows — coyote time, input buffering, corner correction — so that near-misses of timing or aim resolve the way the player intended. human motor timing is imprecise by tens of milliseconds; strict input handling punishes players for gaps between intent and execution that they never perceive as their own error — it just feels like the game "didn't work." forgiveness closes that gap. the staple techniques [s-thorson-celeste-forgiveness]: coyote time (a jump still fires briefly after leaving a ledge), jump-input buffering (a jump pressed shortly before landing still fires on landing), and corner correction (a head-bonk nudges the avatar around the lip instead of stopping it). players don't perceive these as assists; they perceive the controls as "tight." the deeper principle: the game should be on the player's side, targeting the experience they intended (ties to design-0001). precision- and timing-critical real-time control, especially platforming, action, and anything with tight jumps, dashes, or combo timing. highest value where the skill expression is in positioning and timing rather than in the timing test itself. when the strictness is the game. rhythm games, precision-timing challenges, and some hardcore/competitive designs treat exact timing as the skill being tested; forgiveness there removes the point. and forgiveness must stay small and consistent — overly generous or context-varying windows make the game feel mushy, unpredictable, or unfair in the other direction. tune to taste and genre. start with short coyote-time and input-buffer windows, then tune them against the game’s speed, animation, and intended difficulty. add corner/edge correction where collision would otherwise reject a clear player intention. make windows fixed and predictable, not adaptive, so mastery stays learnable. keep them invisible — if players can point at the assist, it is probably too large. always verify by watching real players (playtest), since the whole point is matching perceived intent. two schools: forgiveness-first (celeste, super meat boy — assume good intent, tighten feel) vs. purity-first (execution-focused and competitive designs — exact input is the test). neither is universally right; the deciding question is whether the timing itself is the skill you want to measure. if yes, stay strict; if the timing is just a tax on the real skill (positioning, decision-making), forgive it. type is contextual precisely because the purity-first exception is real and common. confidence 4: strong practitioner consensus for the genres where it applies, with the genuine genre-dependent exception keeping it below 5.


Wrap every meaningful player action and game event in immediate, layered feedback across multiple senses at once — animation, particles, sound, camera, haptics. A single input should produce a cascade of response ("juice"), so the game feels alive and the player feels powerful and informed.

---
id: GDC-L1-FEEL-0004
title: Amplify every meaningful action with layered, redundant, multi-sensory feedback
layer: L1
domain: FEEL
subdomain: feedback-and-juice
type: objective
confidence: 4
status: canonical
tags:
  - juice
  - feedback
  - polish
  - amplification
  - audio
  - animation
related:
  - GDC-L1-FEEL-0005
  - GDC-L1-FEEL-0006
  - GDC-L1-FEEL-0001
depends_on:
  - GDC-L1-FEEL-0001
conflicts_with: []
supersedes: []
sources:
  - S-jonasson-purho-juice
  - S-nijman-screenshake
  - S-pichlmair-johansen-survey
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Wrap every meaningful player action and game event in immediate, layered feedback
> across multiple senses at once — animation, particles, sound, camera, haptics. A
> single input should produce a cascade of response ("juice"), so the game feels alive
> and the player feels powerful and informed.

## Rationale
Feedback does two jobs simultaneously: it *communicates* (this hit landed, this button
worked, this thing matters) and it *rewards* (the action felt good, do it again). The
effect is demonstrable: take a functional-but-flat game and add a few dozen small
amplifications, and it transforms into something satisfying with zero change to the
underlying mechanics [S-nijman-screenshake] [S-jonasson-purho-juice]. In the academic
framing this is *amplification via juicing* — polish that empowers the player and
provides clarity of feedback by signaling the importance of events
[S-pichlmair-johansen-survey]. Redundancy across senses is deliberate: it makes the
signal robust (a hit you might miss visually you'll catch in sound or shake) and the
reward richer.

## Applies when
Every discrete, meaningful event: hits, kills, pickups, jumps, landings, UI
confirmations, successes and failures. The more important or frequent the event, the
more it earns feedback.

## Does not apply / Exceptions
Juice is amplification, not decoration — feedback on *meaningless* events is noise that
buries the meaningful signal. Restraint-driven aesthetics (quiet, contemplative, horror,
minimalist) deliberately *withhold* feedback for effect, and over-juicing there destroys
the intended mood. Accessibility: excessive flashing/shake can harm some players (see
FEEL-0006). More juice is not monotonically better — see Disagreement.

## Implementation (kept separate from the principle)
Layer, don't pile: for a hit, combine a hit-flash, a particle burst, a punchy sound, a
brief hitstop (FEEL-0005), and a small camera kick (FEEL-0006) — each on a different
sense. Tie feedback intensity to event importance so the channel stays legible. Cheap,
high-impact wins first: sound and a 1–2-frame flash often beat expensive new animation.
Always keep the amplifying feedback from delaying the *acknowledgment* of input
(FEEL-0002).

## Disagreement
"Juice it or lose it" is sometimes over-applied. A well-known counter-position ("resist
the urge to juice it") warns that reflexive, maximal juice can produce sensory overload,
obscure game state, and homogenize the feel of very different games. Synthesis: juice is
a tool in service of *communication and the intended experience*, not an end in itself —
amplify what matters, in the register the game wants, and stop there.

## Notes
Confidence 4: the core claim (amplify meaningful actions with layered feedback) is
near-universal; the deduction from 5 reflects the real "too much juice" failure mode and
mood-driven exceptions. FEEL-0005 and FEEL-0006 are specific, heavily-used techniques
that live under this umbrella.

gdc-l1-feel-0004 amplify every meaningful action with layered, redundant, multi-sensory feedback juice feedback polish amplification audio animation > wrap every meaningful player action and game event in immediate, layered feedback across multiple senses at once — animation, particles, sound, camera, haptics. a single input should produce a cascade of response ("juice"), so the game feels alive and the player feels powerful and informed. feedback does two jobs simultaneously: it communicates (this hit landed, this button worked, this thing matters) and it rewards (the action felt good, do it again). the effect is demonstrable: take a functional-but-flat game and add a few dozen small amplifications, and it transforms into something satisfying with zero change to the underlying mechanics [s-nijman-screenshake] [s-jonasson-purho-juice]. in the academic framing this is amplification via juicing — polish that empowers the player and provides clarity of feedback by signaling the importance of events [s-pichlmair-johansen-survey]. redundancy across senses is deliberate: it makes the signal robust (a hit you might miss visually you'll catch in sound or shake) and the reward richer. every discrete, meaningful event: hits, kills, pickups, jumps, landings, ui confirmations, successes and failures. the more important or frequent the event, the more it earns feedback. juice is amplification, not decoration — feedback on meaningless events is noise that buries the meaningful signal. restraint-driven aesthetics (quiet, contemplative, horror, minimalist) deliberately withhold feedback for effect, and over-juicing there destroys the intended mood. accessibility: excessive flashing/shake can harm some players (see feel-0006). more juice is not monotonically better — see disagreement. layer, don't pile: for a hit, combine a hit-flash, a particle burst, a punchy sound, a brief hitstop (feel-0005), and a small camera kick (feel-0006) — each on a different sense. tie feedback intensity to event importance so the channel stays legible. cheap, high-impact wins first: sound and a 1–2-frame flash often beat expensive new animation. always keep the amplifying feedback from delaying the acknowledgment of input (feel-0002). "juice it or lose it" is sometimes over-applied. a well-known counter-position ("resist the urge to juice it") warns that reflexive, maximal juice can produce sensory overload, obscure game state, and homogenize the feel of very different games. synthesis: juice is a tool in service of communication and the intended experience, not an end in itself — amplify what matters, in the register the game wants, and stop there. confidence 4: the core claim (amplify meaningful actions with layered feedback) is near-universal; the deduction from 5 reflects the real "too much juice" failure mode and mood-driven exceptions. feel-0005 and feel-0006 are specific, heavily-used techniques that live under this umbrella.


On a significant impact, freeze the action for a few frames before resuming. This brief interruption of time ("hitstop" / "hit pause") makes hits read as forceful and weighty far more cheaply and vividly than added animation alone.

---
id: GDC-L1-FEEL-0005
title: Sell impact by briefly interrupting time (hitstop / hit pause)
layer: L1
domain: FEEL
subdomain: feedback-and-juice
type: contextual
confidence: 4
status: canonical
tags:
  - juice
  - impact
  - hitstop
  - feedback
  - combat
related:
  - GDC-L1-FEEL-0004
  - GDC-L1-FEEL-0006
depends_on:
  - GDC-L1-FEEL-0004
conflicts_with: []
supersedes: []
sources:
  - S-nijman-screenshake
  - S-impact-feedback-study
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> On a significant impact, freeze the action for a few frames before resuming. This
> brief interruption of time ("hitstop" / "hit pause") makes hits read as forceful and
> weighty far more cheaply and vividly than added animation alone.

## Rationale
A collision resolved in a single frame is perceptually thin — the eye barely registers
it. Inserting a brief pause [S-nijman-screenshake] holds the moment of contact on screen long enough for
the player to *feel* the collision, and momentarily halts the action so both bodies
register the blow. It exploits perception rather than fidelity: the pause implies
enormous force without simulating it. Time-based effects like this are among the features
that most strongly drive perceived impact in action games [S-impact-feedback-study].

## Applies when
Impacts that should feel heavy: melee hits, powerful shots, hard landings, parries,
finishing blows, big destruction. Scales with the significance of the impact — a light
jab gets a frame or two; a heavy smash gets more.

## Does not apply / Exceptions
Overuse is a real failure: constant or overlong hitstop makes fast combat feel stuttery,
laggy, or unresponsive, and can fight the responsiveness ideal (FEEL-0002) if it stalls
the player's *next* input. Games built on flow and speed (fast movement shooters, some
character-action at high skill) deliberately minimize it. Genres where impacts aren't
the point (most puzzle, strategy, narrative) don't need it.

## Implementation (kept separate from the principle)
Scale pause length to impact magnitude and keep it brief enough that it reads as emphasis,
not a stalled game. Freeze
the striking and struck actors (and often their effects) while ideally letting the
camera and particles keep moving so the frame doesn't feel dead. Let the player's *own*
next input still buffer during the pause so it never reads as latency. Pair with the
other juice layers (flash, sound, shake) landing on the same frame as the freeze.

## Disagreement
Amount is genre-dependent and somewhat stylistic: weighty character-action (heavy
hitstop) vs. high-flow action (minimal hitstop) are both correct for their fantasies.
The invariant is that hitstop must never degrade responsiveness of the *player's* next
action.

## Notes
A specific, high-leverage technique under FEEL-0004. Confidence 4: strongly supported as
effective; typed `contextual` because the right amount — and whether to use it at all —
depends on the game's speed and fantasy.

gdc-l1-feel-0005 sell impact by briefly interrupting time (hitstop / hit pause) juice impact hitstop feedback combat > on a significant impact, freeze the action for a few frames before resuming. this brief interruption of time ("hitstop" / "hit pause") makes hits read as forceful and weighty far more cheaply and vividly than added animation alone. a collision resolved in a single frame is perceptually thin — the eye barely registers it. inserting a brief pause [s-nijman-screenshake] holds the moment of contact on screen long enough for the player to feel the collision, and momentarily halts the action so both bodies register the blow. it exploits perception rather than fidelity: the pause implies enormous force without simulating it. time-based effects like this are among the features that most strongly drive perceived impact in action games [s-impact-feedback-study]. impacts that should feel heavy: melee hits, powerful shots, hard landings, parries, finishing blows, big destruction. scales with the significance of the impact — a light jab gets a frame or two; a heavy smash gets more. overuse is a real failure: constant or overlong hitstop makes fast combat feel stuttery, laggy, or unresponsive, and can fight the responsiveness ideal (feel-0002) if it stalls the player's next input. games built on flow and speed (fast movement shooters, some character-action at high skill) deliberately minimize it. genres where impacts aren't the point (most puzzle, strategy, narrative) don't need it. scale pause length to impact magnitude and keep it brief enough that it reads as emphasis, not a stalled game. freeze the striking and struck actors (and often their effects) while ideally letting the camera and particles keep moving so the frame doesn't feel dead. let the player's own next input still buffer during the pause so it never reads as latency. pair with the other juice layers (flash, sound, shake) landing on the same frame as the freeze. amount is genre-dependent and somewhat stylistic: weighty character-action (heavy hitstop) vs. high-flow action (minimal hitstop) are both correct for their fantasies. the invariant is that hitstop must never degrade responsiveness of the player's next action. a specific, high-leverage technique under feel-0004. confidence 4: strongly supported as effective; typed contextual because the right amount — and whether to use it at all — depends on the game's speed and fantasy.


Move the camera to sell force — screenshake, kicks, punch-in, recoil — because the camera is a sense the player inhabits, so shaking it makes impacts physical. But dose it carefully and expose intensity as a player-controllable setting: unbounded shake becomes noise, harms readability, and excludes some players.

---
id: GDC-L1-FEEL-0006
title: Use camera motion and screenshake to convey force — but dose it and let players control it
layer: L1
domain: FEEL
subdomain: camera
type: contextual
confidence: 4
status: canonical
tags:
  - juice
  - camera
  - screenshake
  - feedback
  - accessibility
related:
  - GDC-L1-FEEL-0004
  - GDC-L1-FEEL-0005
depends_on:
  - GDC-L1-FEEL-0004
conflicts_with: []
supersedes: []
sources:
  - S-nijman-screenshake
  - S-jonasson-purho-juice
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Move the camera to sell force — screenshake, kicks, punch-in, recoil — because the
> camera is a sense the player inhabits, so shaking it makes impacts physical. But dose
> it carefully and expose intensity as a player-controllable setting: unbounded shake
> becomes noise, harms readability, and excludes some players.

## Rationale
The camera is the player's eyes; perturbing it transfers force directly into their
perception, which is why screenshake is one of the most effective and widely-cited juice
techniques [S-nijman-screenshake] [S-jonasson-purho-juice]. But the same power makes it
dangerous:
excessive or constant shake destroys the player's ability to read the game state,
induces motion discomfort or nausea, and can trigger issues for photosensitive and
vestibular-sensitive players. Its strength and its risk are the same property, so it must
be *dosed* and *optional*.

## Applies when
Impacts, explosions, weapon recoil, heavy landings, big events — moments that should feel
physically forceful. Small, brief kicks scaled to event magnitude are the high-value
default.

## Does not apply / Exceptions
Precision-reading contexts (competitive aiming, careful platforming, strategy) want
minimal camera disturbance so state stays legible. Calm or contemplative aesthetics avoid
it. And it is subject to strong accessibility limits — always shippable-off.

## Implementation (kept separate from the principle)
Scale amplitude and duration to event importance; decay quickly; cap the maximum so no
combination of events can stack into an unreadable frame. Prefer directional kicks
(shake *away* from the impact) over random jitter for events with a clear source. Provide
an explicit "screen shake" intensity slider (including off) — now an expected
accessibility option. Combine with hitstop (FEEL-0005) and the other juice layers rather
than relying on shake alone.

## Disagreement
Pro-juice practitioners treat screenshake as near-free game feel; the "resist the urge"
counter-camp warns it is the most over-applied juice technique and the fastest route to
sensory overload and unreadability. Both agree on the resolution captured here: dose to
the event, cap the total, and make it optional. The remaining difference is a stylistic
dial (how punchy the house style is), not a dispute about the guardrails.

## Notes
Confidence 4: effectiveness is well-established; typed `contextual` and held below 5 by
the genuine readability/accessibility exceptions. The player-control-and-cap clause is
the part practitioners most often skip and later regret.

gdc-l1-feel-0006 use camera motion and screenshake to convey force — but dose it and let players control it juice camera screenshake feedback accessibility > move the camera to sell force — screenshake, kicks, punch-in, recoil — because the camera is a sense the player inhabits, so shaking it makes impacts physical. but dose it carefully and expose intensity as a player-controllable setting: unbounded shake becomes noise, harms readability, and excludes some players. the camera is the player's eyes; perturbing it transfers force directly into their perception, which is why screenshake is one of the most effective and widely-cited juice techniques [s-nijman-screenshake] [s-jonasson-purho-juice]. but the same power makes it dangerous: excessive or constant shake destroys the player's ability to read the game state, induces motion discomfort or nausea, and can trigger issues for photosensitive and vestibular-sensitive players. its strength and its risk are the same property, so it must be dosed and optional. impacts, explosions, weapon recoil, heavy landings, big events — moments that should feel physically forceful. small, brief kicks scaled to event magnitude are the high-value default. precision-reading contexts (competitive aiming, careful platforming, strategy) want minimal camera disturbance so state stays legible. calm or contemplative aesthetics avoid it. and it is subject to strong accessibility limits — always shippable-off. scale amplitude and duration to event importance; decay quickly; cap the maximum so no combination of events can stack into an unreadable frame. prefer directional kicks (shake away from the impact) over random jitter for events with a clear source. provide an explicit "screen shake" intensity slider (including off) — now an expected accessibility option. combine with hitstop (feel-0005) and the other juice layers rather than relying on shake alone. pro-juice practitioners treat screenshake as near-free game feel; the "resist the urge" counter-camp warns it is the most over-applied juice technique and the fastest route to sensory overload and unreadability. both agree on the resolution captured here: dose to the event, cap the total, and make it optional. the remaining difference is a stylistic dial (how punchy the house style is), not a dispute about the guardrails. confidence 4: effectiveness is well-established; typed contextual and held below 5 by the genuine readability/accessibility exceptions. the player-control-and-cap clause is the part practitioners most often skip and later regret.


When realism and feel conflict, tune for the sensation you want the player to have, not for physical accuracy. The goal is a body that feels right to control — not a correct simulation.

---
id: GDC-L1-FEEL-0007
title: Tune for the sensation, not physical accuracy
layer: L1
domain: FEEL
subdomain: physicality
type: contextual
confidence: 4
status: canonical
tags:
  - game-feel
  - physicality
  - tuning
  - player-centric
related:
  - GDC-L1-FEEL-0001
  - GDC-L1-FEEL-0003
  - GDC-L1-DESIGN-0001
depends_on:
  - GDC-L1-FEEL-0001
conflicts_with: []
supersedes: []
sources:
  - S-swink-gamefeel
  - S-thorson-celeste-forgiveness
  - S-pichlmair-johansen-survey
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> When realism and feel conflict, tune for the sensation you want the player to have,
> not for physical accuracy. The goal is a body that feels right to control — not a
> correct simulation.

## Rationale
The player experiences the *feeling* of movement, never its equations (ties to
DESIGN-0001: judge by the experience produced). Beloved control famously violates
physics: platformer jumps use asymmetric gravity (rise slower, fall faster) that no real
projectile obeys; characters accelerate to full speed in a frame or two; coyote time
lets you jump from empty air. These "lies" exist because they *feel* better —
controllable, snappy, fair. The whole discipline of game feel treats the sensation as
the tunable target and physical plausibility as merely one input to it
[S-swink-gamefeel] — which is why the craft of shaping physicality is literally named
"tuning": you tune toward a sensation, not toward realism [S-pichlmair-johansen-survey].

## Applies when
Any time simulated movement or physics is in service of *how it feels to play* — which
is most action, platforming, and character control. The more the game is about the joy
of moving, the more feel should win over accuracy.

## Does not apply / Exceptions
Simulation is the point in sim genres — racing sims, flight sims, physics sandboxes,
some sports — where fidelity to real behavior *is* the intended experience and
"improving the feel" by faking physics would betray it. Realism can also be a
deliberate feel target (deliberate heaviness, tank controls for tension). The principle
is "serve the intended sensation," and sometimes the intended sensation is realism.

## Implementation (kept separate from the principle)
Decide the target sensation first ("floaty and forgiving," "heavy and deliberate,"
"snappy and precise"), then tune numbers toward it and discard realism where it fights
the target. Expose feel-critical values (accel, gravity up/down, max speed, friction,
air control) as easily-iterated parameters and tune them by feel in playtest, not by
physical derivation. Keep the *simulated space* internally consistent even when it's
unrealistic, so the player can still build accurate intuitions.

## Disagreement
Feel-first (arcade, platformer, action) vs. simulation-first (sim genres) is a real and
legitimate split, but it is usually a genre choice rather than a live argument: both
camps agree the rule is "serve the intended experience," and simply intend different
experiences. Encoded here as `contextual` for that reason.

## Notes
This is the physicality-layer counterpart to FEEL-0002/0003's control-layer guidance.
Confidence 4: overwhelmingly true for action/arcade design, with the honest and large
sim-genre exception keeping it contextual.

gdc-l1-feel-0007 tune for the sensation, not physical accuracy game-feel physicality tuning player-centric > when realism and feel conflict, tune for the sensation you want the player to have, not for physical accuracy. the goal is a body that feels right to control — not a correct simulation. the player experiences the feeling of movement, never its equations (ties to design-0001: judge by the experience produced). beloved control famously violates physics: platformer jumps use asymmetric gravity (rise slower, fall faster) that no real projectile obeys; characters accelerate to full speed in a frame or two; coyote time lets you jump from empty air. these "lies" exist because they feel better — controllable, snappy, fair. the whole discipline of game feel treats the sensation as the tunable target and physical plausibility as merely one input to it [s-swink-gamefeel] — which is why the craft of shaping physicality is literally named "tuning": you tune toward a sensation, not toward realism [s-pichlmair-johansen-survey]. any time simulated movement or physics is in service of how it feels to play — which is most action, platforming, and character control. the more the game is about the joy of moving, the more feel should win over accuracy. simulation is the point in sim genres — racing sims, flight sims, physics sandboxes, some sports — where fidelity to real behavior is the intended experience and "improving the feel" by faking physics would betray it. realism can also be a deliberate feel target (deliberate heaviness, tank controls for tension). the principle is "serve the intended sensation," and sometimes the intended sensation is realism. decide the target sensation first ("floaty and forgiving," "heavy and deliberate," "snappy and precise"), then tune numbers toward it and discard realism where it fights the target. expose feel-critical values (accel, gravity up/down, max speed, friction, air control) as easily-iterated parameters and tune them by feel in playtest, not by physical derivation. keep the simulated space internally consistent even when it's unrealistic, so the player can still build accurate intuitions. feel-first (arcade, platformer, action) vs. simulation-first (sim genres) is a real and legitimate split, but it is usually a genre choice rather than a live argument: both camps agree the rule is "serve the intended experience," and simply intend different experiences. encoded here as contextual for that reason. this is the physicality-layer counterpart to feel-0002/0003's control-layer guidance. confidence 4: overwhelmingly true for action/arcade design, with the honest and large sim-genre exception keeping it contextual.