{"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","file":"GDC-L1-DESIGN-0001.md","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.","sections":{"Statement":"> The game *is* the experience it produces in the player — not the intent in the\n> designer's head. Judge every decision by the experience it actually creates, and let\n> observed player experience, not authorial intent, be the final arbiter.","Rationale":"Players never encounter your intentions; they encounter mechanics, which produce\ndynamics, which produce an experience (the MDA framework: Mechanics → Dynamics →\nAesthetics). Designers build from the mechanics end and can *see* their intent;\nplayers receive from the experience end and cannot. This asymmetry means a designer's\nconfidence that something \"should\" be fun, clear, or fair is systematically unreliable —\nit is contaminated by knowledge the player doesn't have. The only correction is to\ntreat 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\nemotional response — anywhere your privileged knowledge as the author distorts your\nread of what the player will actually feel.","Does not apply / Exceptions":"This governs *evaluation*, not *ambition*. It does not mean designing by committee or\nsanding off every rough edge players complain about — players report symptoms, not\ncures (see Disagreement). A deliberately hostile or uncomfortable experience is fine\n**if that discomfort is the intended experience and it lands**; the principle still\nholds 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\nresourceful*\") so it can be tested against reality. Then close the loop with real\nplayers: watch them play without helping, note where their experience diverges from the\ntarget, and treat divergence as a design signal rather than a player error. First-time-\nuser tests are especially diagnostic because your intent-contamination is strongest\naround onboarding.","Disagreement":"Two schools agree on this principle but differ on *how much to weight raw player\nreaction*:\n\n- **Player-led / data-driven:** lean hard on playtest and telemetry; if players don't\n  have the intended experience, the design is wrong. Strongest for broad-audience,\n  usability-sensitive, and live-service games.\n- **Auteur / vision-led:** players reliably report *what* feels wrong but are poor at\n  prescribing fixes, and chasing every reaction erodes a coherent vision. Strongest for\n  strongly-authored, distinctive, or intentionally challenging games.\n\nThe synthesis both camps accept: **observed experience is the truth you must respond\nto; 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 —\nmuch of playtesting exists precisely because of the intent-vs-experience gap. Rated\nconfidence 5: near-universal agreement across design literature and practice, with the\nonly live debate being the weighting question captured above, not the core claim.\n\"MDA\" (Mechanics → Dynamics → Aesthetics) is standard design vocabulary; its origin is\nin the front-matter sources."},"rawMarkdown":"---\nid: GDC-L1-DESIGN-0001\ntitle: Design for the player's experience, not the designer's intent\nlayer: L1\ndomain: DESIGN\nsubdomain: player-centric\ntype: objective\nconfidence: 5\nstatus: canonical\ntags:\n  - player-centric\n  - mda\n  - intent\n  - playtest\nrelated:\n  - GDC-L1-PLAYTEST-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schell-artofgamedesign\n  - S-hunicke-mda\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> The game *is* the experience it produces in the player — not the intent in the\n> designer's head. Judge every decision by the experience it actually creates, and let\n> observed player experience, not authorial intent, be the final arbiter.\n\n## Rationale\nPlayers never encounter your intentions; they encounter mechanics, which produce\ndynamics, which produce an experience (the MDA framework: Mechanics → Dynamics →\nAesthetics). Designers build from the mechanics end and can *see* their intent;\nplayers receive from the experience end and cannot. This asymmetry means a designer's\nconfidence that something \"should\" be fun, clear, or fair is systematically unreliable —\nit is contaminated by knowledge the player doesn't have. The only correction is to\ntreat the produced experience as the ground truth and intent as a hypothesis about it.\n\n## Applies when\nAlways, but the stakes are highest when evaluating clarity, difficulty, fun, and\nemotional response — anywhere your privileged knowledge as the author distorts your\nread of what the player will actually feel.\n\n## Does not apply / Exceptions\nThis governs *evaluation*, not *ambition*. It does not mean designing by committee or\nsanding off every rough edge players complain about — players report symptoms, not\ncures (see Disagreement). A deliberately hostile or uncomfortable experience is fine\n**if that discomfort is the intended experience and it lands**; the principle still\nholds because you are judging by the experience produced, not overriding it with intent.\n\n## Implementation (kept separate from the principle)\nExternalize the target experience early (\"the player should feel *tense and\nresourceful*\") so it can be tested against reality. Then close the loop with real\nplayers: watch them play without helping, note where their experience diverges from the\ntarget, and treat divergence as a design signal rather than a player error. First-time-\nuser tests are especially diagnostic because your intent-contamination is strongest\naround onboarding.\n\n## Disagreement\nTwo schools agree on this principle but differ on *how much to weight raw player\nreaction*:\n\n- **Player-led / data-driven:** lean hard on playtest and telemetry; if players don't\n  have the intended experience, the design is wrong. Strongest for broad-audience,\n  usability-sensitive, and live-service games.\n- **Auteur / vision-led:** players reliably report *what* feels wrong but are poor at\n  prescribing fixes, and chasing every reaction erodes a coherent vision. Strongest for\n  strongly-authored, distinctive, or intentionally challenging games.\n\nThe synthesis both camps accept: **observed experience is the truth you must respond\nto; the designer still owns the response.** Listen to the symptom; own the cure.\n\n## Notes\nThis is the load-bearing principle under most of the DESIGN and PLAYTEST domains —\nmuch of playtesting exists precisely because of the intent-vs-experience gap. Rated\nconfidence 5: near-universal agreement across design literature and practice, with the\nonly live debate being the weighting question captured above, not the core claim.\n\"MDA\" (Mechanics → Dynamics → Aesthetics) is standard design vocabulary; its origin is\nin the front-matter sources.\n","searchText":"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."}
{"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","file":"GDC-L1-DESIGN-0002.md","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.","sections":{"Statement":"> Wherever the game asks the player to choose, make the choice *interesting*: the\n> outcome must matter, the best option must not be obvious, and every option must carry\n> a real tradeoff. Ruthlessly remove dominant strategies (an option that is always\n> correct) and inconsequential choices (options whose outcomes don't matter) — both are\n> non-decisions wearing a decision's clothes.","Rationale":"Decision-making is the engine of most gameplay: agency, tension, and replayability all\ngrow from choices the player actually has to think about. A choice is only interesting\nwhen multiple considerations pull in different directions and the player must apply\njudgment [S-meier-interesting-decisions]. Two failure modes destroy this. A **dominant\noption** collapses the decision — if A is always best, there was never a choice, just a\ncorrect answer to discover once. An **inconsequential option** collapses it the other\nway — if outcomes don't differ or aren't visible, the player has no basis to care.\nInteresting decisions require both *real tradeoffs* (choosing A means giving up B) and\n*visible consequences* (the player can see that the choice mattered).","Applies when":"Any point of player choice: builds, loadouts, tactics, resource spending, branching\npaths, upgrade trees, moment-to-moment combat options. It is the primary lens for\ncombat, 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\nbuilt on choices. Experiential, narrative, and atmospheric games can be excellent with\nfew meaningful decisions — their value lives in other domains (NARR, FEEL, aesthetics).\nAlso, not every choice should be agonizing: low-stakes expressive or cosmetic choices\n(character color, base decoration) are legitimately inconsequential by design and\nshouldn'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\ntactic, either buff the alternatives, add situational counters (rock-paper-scissors\nrelationships), or add costs that make the strong option situational. Make consequences\nlegible — the player must be able to perceive that A led somewhere different from B.\nIntroduce tradeoffs along orthogonal axes (offense vs. defense, speed vs. power, now vs.\nlater) so options aren't strictly rankable.","Disagreement":"The famous framing \"a game *is* a series of interesting decisions\" is contested as a\n*definition* of games — walking simulators, toys, and purely narrative works are games\nby most accounts yet aren't built on decisions. The design *guidance*, however (when you\ndo include choices, make them interesting), is near-universally endorsed. This entry\nadopts 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."},"rawMarkdown":"---\nid: GDC-L1-DESIGN-0002\ntitle: Make the player's choices interesting — real tradeoffs, no dominant option\nlayer: L1\ndomain: DESIGN\nsubdomain: decisions-and-agency\ntype: objective\nconfidence: 4\nstatus: canonical\ntags:\n  - decisions\n  - meaningful-choice\n  - risk-reward\n  - balance\nrelated:\n  - GDC-L1-DESIGN-0006\n  - GDC-L1-DESIGN-0001\ndepends_on:\n  - GDC-L1-DESIGN-0001\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-meier-interesting-decisions\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Wherever the game asks the player to choose, make the choice *interesting*: the\n> outcome must matter, the best option must not be obvious, and every option must carry\n> a real tradeoff. Ruthlessly remove dominant strategies (an option that is always\n> correct) and inconsequential choices (options whose outcomes don't matter) — both are\n> non-decisions wearing a decision's clothes.\n\n## Rationale\nDecision-making is the engine of most gameplay: agency, tension, and replayability all\ngrow from choices the player actually has to think about. A choice is only interesting\nwhen multiple considerations pull in different directions and the player must apply\njudgment [S-meier-interesting-decisions]. Two failure modes destroy this. A **dominant\noption** collapses the decision — if A is always best, there was never a choice, just a\ncorrect answer to discover once. An **inconsequential option** collapses it the other\nway — if outcomes don't differ or aren't visible, the player has no basis to care.\nInteresting decisions require both *real tradeoffs* (choosing A means giving up B) and\n*visible consequences* (the player can see that the choice mattered).\n\n## Applies when\nAny point of player choice: builds, loadouts, tactics, resource spending, branching\npaths, upgrade trees, moment-to-moment combat options. It is the primary lens for\ncombat, strategy, RPG systems, and progression design.\n\n## Does not apply / Exceptions\nThis is guidance for the *choices a game contains*, not a claim that every good game is\nbuilt on choices. Experiential, narrative, and atmospheric games can be excellent with\nfew meaningful decisions — their value lives in other domains (NARR, FEEL, aesthetics).\nAlso, not every choice should be agonizing: low-stakes expressive or cosmetic choices\n(character color, base decoration) are legitimately inconsequential by design and\nshouldn't be forced into tradeoffs.\n\n## Implementation (kept separate from the principle)\nAudit choices for dominance: if playtesters or theory converge on one \"correct\" build or\ntactic, either buff the alternatives, add situational counters (rock-paper-scissors\nrelationships), or add costs that make the strong option situational. Make consequences\nlegible — the player must be able to perceive that A led somewhere different from B.\nIntroduce tradeoffs along orthogonal axes (offense vs. defense, speed vs. power, now vs.\nlater) so options aren't strictly rankable.\n\n## Disagreement\nThe famous framing \"a game *is* a series of interesting decisions\" is contested as a\n*definition* of games — walking simulators, toys, and purely narrative works are games\nby most accounts yet aren't built on decisions. The design *guidance*, however (when you\ndo include choices, make them interesting), is near-universally endorsed. This entry\nadopts the guidance and rejects the overreach of the definition.\n\n## Notes\nConfidence 4: overwhelming practitioner consensus on the guidance; held below 5 by the legitimate \"not all games are decisions\" scope limit.\n","searchText":"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."}
{"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","file":"GDC-L1-DESIGN-0003.md","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.","sections":{"Statement":"> A major source of fun is *learning* — the pleasure of recognizing and mastering\n> patterns. Design so the player is always acquiring and then mastering new patterns;\n> when there is nothing left to learn, mastery turns to boredom, so keep introducing\n> fresh patterns before the old ones are exhausted.","Rationale":"The brain rewards pattern-mastery; games that supply \"tasty patterns\" to learn produce\nthe specific pleasure often labeled fun, and once a pattern is fully grokked it stops\nbeing interesting [S-koster-theoryoffun]. This reframes fun as a *rate*: not a static\nproperty of the game but a function of how steadily the player is learning. It explains\ncommon failure modes directly — a game that teaches everything in the first hour goes\nstale (nothing left to learn), and a game that never lets the player achieve mastery is\nmerely frustrating (learning never completes). The design target is a sustained cadence\nof \"new pattern → practice → mastery → new pattern.\"","Applies when":"Skill-, puzzle-, strategy-, and mastery-driven games, and the learning arc of almost any\ngame. 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\nemotional payoff, aesthetic pleasure, self-expression, relaxation, and the thrill of\ntriumph (fiero) are distinct pleasures that don't reduce to pattern-mastery. Games built\nprimarily on those (social party games, narrative adventures, cozy/relaxation games) are\nunder-served by treating learning as the whole story. Treat this as a powerful lens, not\na 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\ntheir introduction so a new one arrives roughly as the last is being mastered. Use\ndifficulty and content pacing to keep the learning rate positive (see FLOW, DESIGN-0004).\nWatch for \"solved\" states where an optimal pattern trivializes everything after it — that\nis 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\n(contrast taxonomies of player motivation and kinds of fun that enumerate many distinct\npleasures). The disagreement isn't that learning is fun — it plainly is — but whether it\nis *the* root of fun. This entry treats it as a high-value lens and defers to\nmotivation-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."},"rawMarkdown":"---\nid: GDC-L1-DESIGN-0003\ntitle: Fun is learning — feed the player a steady supply of masterable patterns\nlayer: L1\ndomain: DESIGN\nsubdomain: fun-and-motivation\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - fun-and-motivation\n  - mastery\n  - learning\n  - pacing\nrelated:\n  - GDC-L1-DESIGN-0004\n  - GDC-L1-DESIGN-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-koster-theoryoffun\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A major source of fun is *learning* — the pleasure of recognizing and mastering\n> patterns. Design so the player is always acquiring and then mastering new patterns;\n> when there is nothing left to learn, mastery turns to boredom, so keep introducing\n> fresh patterns before the old ones are exhausted.\n\n## Rationale\nThe brain rewards pattern-mastery; games that supply \"tasty patterns\" to learn produce\nthe specific pleasure often labeled fun, and once a pattern is fully grokked it stops\nbeing interesting [S-koster-theoryoffun]. This reframes fun as a *rate*: not a static\nproperty of the game but a function of how steadily the player is learning. It explains\ncommon failure modes directly — a game that teaches everything in the first hour goes\nstale (nothing left to learn), and a game that never lets the player achieve mastery is\nmerely frustrating (learning never completes). The design target is a sustained cadence\nof \"new pattern → practice → mastery → new pattern.\"\n\n## Applies when\nSkill-, puzzle-, strategy-, and mastery-driven games, and the learning arc of almost any\ngame. Strongest as a lens on pacing, content introduction, and long-term retention.\n\n## Does not apply / Exceptions\nLearning is *one* engine of fun, not the only one. Social connection, narrative and\nemotional payoff, aesthetic pleasure, self-expression, relaxation, and the thrill of\ntriumph (fiero) are distinct pleasures that don't reduce to pattern-mastery. Games built\nprimarily on those (social party games, narrative adventures, cozy/relaxation games) are\nunder-served by treating learning as the whole story. Treat this as a powerful lens, not\na totalizing theory of fun.\n\n## Implementation (kept separate from the principle)\nMap the game's learning curve: list the patterns the player must acquire and stagger\ntheir introduction so a new one arrives roughly as the last is being mastered. Use\ndifficulty and content pacing to keep the learning rate positive (see FLOW, DESIGN-0004).\nWatch for \"solved\" states where an optimal pattern trivializes everything after it — that\nis the mastery problem arriving early; answer it with new mechanics, vari, or depth.\n\n## Disagreement\nKoster's \"fun is learning\" is influential but explicitly one theory among several\n(contrast taxonomies of player motivation and kinds of fun that enumerate many distinct\npleasures). The disagreement isn't that learning is fun — it plainly is — but whether it\nis *the* root of fun. This entry treats it as a high-value lens and defers to\nmotivation-pluralism where a game's pleasure lies elsewhere.\n\n## Notes\nConfidence 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.\n","searchText":"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."}
{"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","file":"GDC-L1-DESIGN-0004.md","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.","sections":{"Statement":"> Sustained engagement lives in the narrow channel where challenge matches the player's\n> current skill. Because skill rises with play, challenge must rise with it: too much\n> challenge for the skill produces anxiety and frustration; too little produces boredom.\n> 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\nperformer's ability, bounded on one side by anxiety (challenge exceeds skill) and on the\nother by boredom (skill exceeds challenge) [S-csikszentmihalyi-flow]. In games skill is\nnot static — the player is continuously getting better — so a *fixed* challenge level\nslides out of the flow channel: what was engaging becomes trivial as mastery grows.\nKeeping the player engaged therefore requires escalating challenge roughly in step with\ntheir improving skill, plus the supporting conditions flow depends on: clear goals and\nimmediate, 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 —\nlevel 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.\nHorror wants *anxiety*; a punishing difficulty spike can be a meaningful punctuation or\na rite of passage (many celebrated hard games court frustration on purpose); relaxation\nand \"cozy\" games deliberately keep challenge low and let the player idle below the flow\nchannel. Deliberate boredom or dread, used for effect, is a valid choice. Also, players\nvary widely in skill, which is why fixed curves struggle and options/difficulty settings\nexist.","Implementation (kept separate from the principle)":"Build a rising difficulty curve and pace content so new challenge arrives as skill\ngrows (pairs with DESIGN-0003's cadence of new patterns). Provide clear goals and\nimmediate feedback so the player can self-correct. Absorb player-to-player skill variance\nwith difficulty options, dynamic/adaptive difficulty, or self-selected challenge (optional\nhard content). Use brief dips below the challenge line intentionally as rest beats, not by\naccident.","Disagreement":"Two nuances rather than a hard split. First, whether to keep the player *inside* flow at\nall times or to deliberately spike out of it for dramatic effect — both are legitimate;\nthe answer depends on the intended emotional arc. Second, \"flow at all costs\" is\ncritiqued for producing frictionless, forgettable experiences; friction, failure, and\nrecovery are themselves sources of meaning and pride. Treat flow as the default target\nand its deliberate violation as a designed exception.","Notes":"Tightly coupled to DESIGN-0003 (learning) and DESIGN-0005 (accessible depth): flow is\nhow you *pace* the supply of masterable patterns. Belongs equally to the future PROG\ndomain (difficulty/mastery curves). Confidence 4: challenge-skill balance is broadly\nvalidated and applied; typed `contextual` because deliberate anti-flow design is common\nand valid."},"rawMarkdown":"---\nid: GDC-L1-DESIGN-0004\ntitle: Keep the player in flow by matching challenge to rising skill\nlayer: L1\ndomain: DESIGN\nsubdomain: fun-and-motivation\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - flow\n  - difficulty\n  - pacing\n  - challenge-skill\n  - engagement\nrelated:\n  - GDC-L1-DESIGN-0003\n  - GDC-L1-DESIGN-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-csikszentmihalyi-flow\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Sustained engagement lives in the narrow channel where challenge matches the player's\n> current skill. Because skill rises with play, challenge must rise with it: too much\n> challenge for the skill produces anxiety and frustration; too little produces boredom.\n> Design difficulty as a moving target that tracks the player up the skill curve.\n\n## Rationale\nDeep absorption (\"flow\") occurs when the difficulty of the task is well-aligned to the\nperformer's ability, bounded on one side by anxiety (challenge exceeds skill) and on the\nother by boredom (skill exceeds challenge) [S-csikszentmihalyi-flow]. In games skill is\nnot static — the player is continuously getting better — so a *fixed* challenge level\nslides out of the flow channel: what was engaging becomes trivial as mastery grows.\nKeeping the player engaged therefore requires escalating challenge roughly in step with\ntheir improving skill, plus the supporting conditions flow depends on: clear goals and\nimmediate, unambiguous feedback so the player can tell how they're doing.\n\n## Applies when\nDifficulty and pacing design across almost every real-time or skill-based genre —\nlevel progression, enemy scaling, mission design, and the overall difficulty curve.\n\n## Does not apply / Exceptions\nFlow is not the only worthwhile experience, and some designs deliberately break it.\nHorror wants *anxiety*; a punishing difficulty spike can be a meaningful punctuation or\na rite of passage (many celebrated hard games court frustration on purpose); relaxation\nand \"cozy\" games deliberately keep challenge low and let the player idle below the flow\nchannel. Deliberate boredom or dread, used for effect, is a valid choice. Also, players\nvary widely in skill, which is why fixed curves struggle and options/difficulty settings\nexist.\n\n## Implementation (kept separate from the principle)\nBuild a rising difficulty curve and pace content so new challenge arrives as skill\ngrows (pairs with DESIGN-0003's cadence of new patterns). Provide clear goals and\nimmediate feedback so the player can self-correct. Absorb player-to-player skill variance\nwith difficulty options, dynamic/adaptive difficulty, or self-selected challenge (optional\nhard content). Use brief dips below the challenge line intentionally as rest beats, not by\naccident.\n\n## Disagreement\nTwo nuances rather than a hard split. First, whether to keep the player *inside* flow at\nall times or to deliberately spike out of it for dramatic effect — both are legitimate;\nthe answer depends on the intended emotional arc. Second, \"flow at all costs\" is\ncritiqued for producing frictionless, forgettable experiences; friction, failure, and\nrecovery are themselves sources of meaning and pride. Treat flow as the default target\nand its deliberate violation as a designed exception.\n\n## Notes\nTightly coupled to DESIGN-0003 (learning) and DESIGN-0005 (accessible depth): flow is\nhow you *pace* the supply of masterable patterns. Belongs equally to the future PROG\ndomain (difficulty/mastery curves). Confidence 4: challenge-skill balance is broadly\nvalidated and applied; typed `contextual` because deliberate anti-flow design is common\nand valid.\n","searchText":"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."}
{"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","file":"GDC-L1-DESIGN-0005.md","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.","sections":{"Statement":"> Aim for a low barrier to entry and a high ceiling of mastery: the game should be easy\n> to start and understand, yet reward deepening skill for a very long time. Reward both\n> the first minute and the hundredth hour.","Rationale":"An accessible surface lets players in; a high skill ceiling keeps them [S-bushnell-law].\nThe two are not in tension when depth comes from *interaction* rather than *addition* —\na small set of clear rules that combine into a vast space of situations, strategies, and\nedge cases. This is why chess, Go, and the best action and strategy games stay\ncompelling for decades on rules that fit on a card: initial simplicity gives way to\ncombinations, counterplay, and mastery that take thousands of hours to exhaust. Depth\nbought this way (emergence from few rules) is cheap to teach and rich to master; depth\nbought by piling on mechanics is expensive to teach and often shallow.","Applies when":"Broadly, but especially competitive, strategy, action, and any game seeking long\nengagement 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\nto learn as part of the value: deep simulations (e.g. Dwarf Fortress), complex grand\nstrategy, and games that use opacity and discovery as core experiences (cryptic\nprogression, \"figure it out yourself\" design). For a niche, hardcore, or\ndiscovery-driven audience a steep on-ramp can be a feature, not a flaw. The principle is\nstrongest when breadth of audience or immediate accessibility is a goal; weigh it against\nthe intended audience.","Implementation (kept separate from the principle)":"Prefer depth from *interacting* systems over depth from *more* systems (see DESIGN-0007\non elegance). Design a gentle on-ramp — teach the core in the first minutes through play\n(not manuals), then layer complexity as mastery grows (pairs with flow, DESIGN-0004).\nStress-test the ceiling: can expert play keep discovering new strategies, or does the\nsystem \"solve\" quickly? Emergent interactions, counterplay, and execution skill all\nraise the ceiling.","Disagreement":"The maxim is sometimes overgeneralized into \"all games should be easy to learn,\" which\nthe discovery/simulation camp rejects: for some experiences, *earning* your\nunderstanding is the point, and an easy surface would cheapen it. The reconciliation:\n\"easy to learn, hard to master\" is the right default for accessibility and reach, but a\ndeliberately hard-to-learn design is legitimate when difficulty of comprehension is\nitself the intended experience.","Notes":"Confidence 4: a foundational industry heuristic; typed `contextual` for the real discovery/simulation exceptions."},"rawMarkdown":"---\nid: GDC-L1-DESIGN-0005\ntitle: Easy to learn, hard to master — pursue depth from a simple surface\nlayer: L1\ndomain: DESIGN\nsubdomain: elegance-and-depth\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - depth\n  - accessibility\n  - emergence\n  - mastery\n  - elegance\nrelated:\n  - GDC-L1-DESIGN-0004\n  - GDC-L1-DESIGN-0007\n  - GDC-L1-DESIGN-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-bushnell-law\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Aim for a low barrier to entry and a high ceiling of mastery: the game should be easy\n> to start and understand, yet reward deepening skill for a very long time. Reward both\n> the first minute and the hundredth hour.\n\n## Rationale\nAn accessible surface lets players in; a high skill ceiling keeps them [S-bushnell-law].\nThe two are not in tension when depth comes from *interaction* rather than *addition* —\na small set of clear rules that combine into a vast space of situations, strategies, and\nedge cases. This is why chess, Go, and the best action and strategy games stay\ncompelling for decades on rules that fit on a card: initial simplicity gives way to\ncombinations, counterplay, and mastery that take thousands of hours to exhaust. Depth\nbought this way (emergence from few rules) is cheap to teach and rich to master; depth\nbought by piling on mechanics is expensive to teach and often shallow.\n\n## Applies when\nBroadly, but especially competitive, strategy, action, and any game seeking long\nengagement or a wide audience. It is the design ideal behind \"elegant\" systems.\n\n## Does not apply / Exceptions\nSome celebrated games deliberately have a *high* barrier to entry and treat the struggle\nto learn as part of the value: deep simulations (e.g. Dwarf Fortress), complex grand\nstrategy, and games that use opacity and discovery as core experiences (cryptic\nprogression, \"figure it out yourself\" design). For a niche, hardcore, or\ndiscovery-driven audience a steep on-ramp can be a feature, not a flaw. The principle is\nstrongest when breadth of audience or immediate accessibility is a goal; weigh it against\nthe intended audience.\n\n## Implementation (kept separate from the principle)\nPrefer depth from *interacting* systems over depth from *more* systems (see DESIGN-0007\non elegance). Design a gentle on-ramp — teach the core in the first minutes through play\n(not manuals), then layer complexity as mastery grows (pairs with flow, DESIGN-0004).\nStress-test the ceiling: can expert play keep discovering new strategies, or does the\nsystem \"solve\" quickly? Emergent interactions, counterplay, and execution skill all\nraise the ceiling.\n\n## Disagreement\nThe maxim is sometimes overgeneralized into \"all games should be easy to learn,\" which\nthe discovery/simulation camp rejects: for some experiences, *earning* your\nunderstanding is the point, and an easy surface would cheapen it. The reconciliation:\n\"easy to learn, hard to master\" is the right default for accessibility and reach, but a\ndeliberately hard-to-learn design is legitimate when difficulty of comprehension is\nitself the intended experience.\n\n## Notes\nConfidence 4: a foundational industry heuristic; typed `contextual` for the real discovery/simulation exceptions.\n","searchText":"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."}
{"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","file":"GDC-L1-DESIGN-0006.md","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.","sections":{"Statement":"> Agency is the feeling that your choices author your experience. For it to be real, the\n> player's choices must produce consequences that are *legible* — perceivable and\n> attributable to the choice. A choice whose effect the player cannot see is, to them,\n> not a choice at all.","Rationale":"Where DESIGN-0002 concerns the quality of an individual decision (tradeoffs, no dominant\noption), this concerns agency at the level of the whole experience: does the player feel\nauthorship? Consequences drive that feeling, but only if the player can *perceive* them\nand *attribute* them to their action [S-meier-interesting-decisions]. Invisible or\ndelayed-beyond-recognition consequences read as randomness or railroading; the player\nstops believing their input matters and disengages (ties to DESIGN-0001 — judge by the\nexperience produced). Legibility is the hinge: the same branching system feels powerful\nif consequences are readable and empty if they aren't.","Applies when":"Systems and narratives that promise player authorship: branching stories, faction and\nreputation systems, build/character choices, strategic decisions, emergent sandboxes,\nand any \"your choices matter\" pitch.","Does not apply / Exceptions":"Strongly-authored, linear experiences deliberately trade agency for a crafted arc, and\nthat is a legitimate design — not every game should maximize agency. The *illusion* of\nchoice is also a real and defensible tool: narrative games often present choices whose\nmechanical outcomes converge, trading true branching for emotional agency (the player\nfelt the weight of choosing) at sustainable production cost. The line to avoid is the\n*unsatisfying* illusion — where players notice their choices are hollow and feel\ncheated.","Implementation (kept separate from the principle)":"Close the loop between choice and visible outcome: acknowledge choices promptly, and\nsurface their consequences where the player can connect cause to effect (immediate\nfeedback for tactical choices; callbacks and changed world-state for narrative ones).\nPrefer fewer choices with real, readable consequences over many with imperceptible ones.\nWhen using converging/illusory choice for production reasons, protect the *feeling* of\nconsequence and avoid exposing the seams.","Disagreement":"Agency-maximalists (systemic/immersive-sim tradition) hold that real, simulated\nconsequence is worth its high cost and that illusory choice ultimately betrays players.\nAuthored-experience designers hold that a curated, linear arc — or well-hidden illusion\nof choice — often delivers a better and more sustainable experience than sprawling real\nbranching. Both are right for different games; the deciding factor is whether *authorship*\nor *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:\n0002 = are the options interesting; 0006 = does choosing feel consequential. Confidence\n4: broad agreement on the legibility requirement; typed `contextual` for the legitimate\nlinear-authorship and illusion-of-choice exceptions."},"rawMarkdown":"---\nid: GDC-L1-DESIGN-0006\ntitle: Give the player real agency — choices must produce legible consequences\nlayer: L1\ndomain: DESIGN\nsubdomain: decisions-and-agency\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - agency\n  - meaningful-choice\n  - consequences\n  - player-centric\nrelated:\n  - GDC-L1-DESIGN-0002\n  - GDC-L1-DESIGN-0001\ndepends_on:\n  - GDC-L1-DESIGN-0001\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-meier-interesting-decisions\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Agency is the feeling that your choices author your experience. For it to be real, the\n> player's choices must produce consequences that are *legible* — perceivable and\n> attributable to the choice. A choice whose effect the player cannot see is, to them,\n> not a choice at all.\n\n## Rationale\nWhere DESIGN-0002 concerns the quality of an individual decision (tradeoffs, no dominant\noption), this concerns agency at the level of the whole experience: does the player feel\nauthorship? Consequences drive that feeling, but only if the player can *perceive* them\nand *attribute* them to their action [S-meier-interesting-decisions]. Invisible or\ndelayed-beyond-recognition consequences read as randomness or railroading; the player\nstops believing their input matters and disengages (ties to DESIGN-0001 — judge by the\nexperience produced). Legibility is the hinge: the same branching system feels powerful\nif consequences are readable and empty if they aren't.\n\n## Applies when\nSystems and narratives that promise player authorship: branching stories, faction and\nreputation systems, build/character choices, strategic decisions, emergent sandboxes,\nand any \"your choices matter\" pitch.\n\n## Does not apply / Exceptions\nStrongly-authored, linear experiences deliberately trade agency for a crafted arc, and\nthat is a legitimate design — not every game should maximize agency. The *illusion* of\nchoice is also a real and defensible tool: narrative games often present choices whose\nmechanical outcomes converge, trading true branching for emotional agency (the player\nfelt the weight of choosing) at sustainable production cost. The line to avoid is the\n*unsatisfying* illusion — where players notice their choices are hollow and feel\ncheated.\n\n## Implementation (kept separate from the principle)\nClose the loop between choice and visible outcome: acknowledge choices promptly, and\nsurface their consequences where the player can connect cause to effect (immediate\nfeedback for tactical choices; callbacks and changed world-state for narrative ones).\nPrefer fewer choices with real, readable consequences over many with imperceptible ones.\nWhen using converging/illusory choice for production reasons, protect the *feeling* of\nconsequence and avoid exposing the seams.\n\n## Disagreement\nAgency-maximalists (systemic/immersive-sim tradition) hold that real, simulated\nconsequence is worth its high cost and that illusory choice ultimately betrays players.\nAuthored-experience designers hold that a curated, linear arc — or well-hidden illusion\nof choice — often delivers a better and more sustainable experience than sprawling real\nbranching. Both are right for different games; the deciding factor is whether *authorship*\nor *authored arc* is the promise you're making to the player. Keep the promise you make.\n\n## Notes\nPairs with DESIGN-0002 (interesting decisions) as the two halves of choice design:\n0002 = are the options interesting; 0006 = does choosing feel consequential. Confidence\n4: broad agreement on the legibility requirement; typed `contextual` for the legitimate\nlinear-authorship and illusion-of-choice exceptions.\n","searchText":"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."}
{"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","file":"GDC-L1-DESIGN-0007.md","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.","sections":{"Statement":"> Favor elegance: get the most meaningful gameplay from the fewest rules. Every mechanic\n> carries a cost — to learn, to build, to balance, to explain — so a mechanic must earn\n> that cost in gameplay value. When a rule doesn't pull its weight, cut it rather than\n> keep it.","Rationale":"Complexity is a budget spent on all sides: the player's cognitive load, the team's\nbuild and balance effort, and the surface area for bugs and exploits. Elegant systems\nspend that budget efficiently — a few rules that *interact* generate far more gameplay\nthan the same number of rules bolted on independently, which is why emergence is the\nelegant designer's favorite tool (a small rule set, a large possibility space; see\nDESIGN-0005). Cutting a weak mechanic usually *strengthens* the whole, because it lowers\nthe cost of entry and sharpens what remains. \"What can I remove and lose nothing?\" is\noften a more productive question than \"what can I add?\"","Applies when":"System and mechanics design, and scope decisions throughout production. Especially\nvaluable 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\ntheir richness, maximalism, and abundance of interacting systems are the point (sprawling\nsims, deep RPGs, systemic sandboxes, \"kitchen-sink\" designs). There, more systems create\nmore emergent stories, and aggressive minimalism would drain the appeal. Elegance also\ntrades against expressive breadth and content variety. This is why it is typed\n`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\nbreak if it were removed? Prefer mechanics that interact with existing systems (multiply\nvalue) over isolated ones (add value linearly). Periodically run a subtractive pass —\n\"kill your darlings\" — and cut features that don't earn their complexity. Watch for\nmechanics that exist only to prop up other mechanics; collapsing them often simplifies\nand improves.","Disagreement":"Genuine, and it is a taste axis, not a correctness one: **minimalist/elegant** design\n(few deep systems, ruthless cutting) vs. **maximalist/baroque** design (many interacting\nsystems, richness through abundance). Both have produced masterpieces. The choice should\nfollow the game's identity and the audience's appetite for complexity, not a universal\npreference — which is exactly why this is `stylistic`.","Notes":"The counterweight to feature creep and a close ally of DESIGN-0005 (depth from simple\nrules). Confidence 3 and typed `stylistic`: the *reasoning* is strong, but whether to\nprize elegance over richness is a legitimate matter of design taste, so it must not be\nstated as an objective rule."},"rawMarkdown":"---\nid: GDC-L1-DESIGN-0007\ntitle: Prize elegance — maximize meaningful gameplay per rule, and cut what doesn't earn its complexity\nlayer: L1\ndomain: DESIGN\nsubdomain: elegance-and-depth\ntype: stylistic\nconfidence: 3\nstatus: canonical\ntags:\n  - elegance\n  - depth\n  - complexity\n  - scope-discipline\n  - emergence\nrelated:\n  - GDC-L1-DESIGN-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Favor elegance: get the most meaningful gameplay from the fewest rules. Every mechanic\n> carries a cost — to learn, to build, to balance, to explain — so a mechanic must earn\n> that cost in gameplay value. When a rule doesn't pull its weight, cut it rather than\n> keep it.\n\n## Rationale\nComplexity is a budget spent on all sides: the player's cognitive load, the team's\nbuild and balance effort, and the surface area for bugs and exploits. Elegant systems\nspend that budget efficiently — a few rules that *interact* generate far more gameplay\nthan the same number of rules bolted on independently, which is why emergence is the\nelegant designer's favorite tool (a small rule set, a large possibility space; see\nDESIGN-0005). Cutting a weak mechanic usually *strengthens* the whole, because it lowers\nthe cost of entry and sharpens what remains. \"What can I remove and lose nothing?\" is\noften a more productive question than \"what can I add?\"\n\n## Applies when\nSystem and mechanics design, and scope decisions throughout production. Especially\nvaluable when a design feels bloated, hard to teach, or hard to balance.\n\n## Does not apply / Exceptions\nElegance is a value, not a law — some beloved games are deliberately *baroque*, and\ntheir richness, maximalism, and abundance of interacting systems are the point (sprawling\nsims, deep RPGs, systemic sandboxes, \"kitchen-sink\" designs). There, more systems create\nmore emergent stories, and aggressive minimalism would drain the appeal. Elegance also\ntrades against expressive breadth and content variety. This is why it is typed\n`stylistic`: reasonable, excellent designers deliberately choose the opposite.\n\n## Implementation (kept separate from the principle)\nPressure-test each mechanic: what does it add that nothing else does, and what would\nbreak if it were removed? Prefer mechanics that interact with existing systems (multiply\nvalue) over isolated ones (add value linearly). Periodically run a subtractive pass —\n\"kill your darlings\" — and cut features that don't earn their complexity. Watch for\nmechanics that exist only to prop up other mechanics; collapsing them often simplifies\nand improves.\n\n## Disagreement\nGenuine, and it is a taste axis, not a correctness one: **minimalist/elegant** design\n(few deep systems, ruthless cutting) vs. **maximalist/baroque** design (many interacting\nsystems, richness through abundance). Both have produced masterpieces. The choice should\nfollow the game's identity and the audience's appetite for complexity, not a universal\npreference — which is exactly why this is `stylistic`.\n\n## Notes\nThe counterweight to feature creep and a close ally of DESIGN-0005 (depth from simple\nrules). Confidence 3 and typed `stylistic`: the *reasoning* is strong, but whether to\nprize elegance over richness is a legitimate matter of design taste, so it must not be\nstated as an objective rule.\n","searchText":"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."}
{"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","file":"GDC-L1-DESIGN-0008.md","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.","sections":{"Statement":"> Design for a *specific* player, not an abstract \"everyone.\" Know who the game is for — what\n> they enjoy, expect, and find hard — and let that knowledge inform decisions. A game aimed at\n> everyone usually delights no one; a game that knows its audience can be sharp, coherent, and\n> loved by the people it's for.","Rationale":"Every design decision — difficulty, tone, complexity, controls, monetization — has a *right*\nanswer only relative to who's playing, so \"is this good?\" is unanswerable without \"good for\nwhom?\" [S-schell-artofgamedesign]. Trying to please everyone forces averaging: the game gets\nsanded down to offend no one and excite no one, and its decisions pull in incompatible\ndirections (a game can't be both a hardcore sim and a pick-up-and-play casual game without\nbecoming incoherent). Knowing the audience is what makes \"design for the experience produced\"\n(DESIGN-0001) actionable — the *intended* experience is intended *for someone*. It also grounds\nthe vision (VISION-0001) and disciplines scope (you build what your audience needs, not every\npossible feature). This is not pandering or market-chasing; it's the basic act of designing for\nreal 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\nobvious answer — check it against the target player. Foundational to vision, scope, difficulty,\nand tone.","Does not apply / Exceptions":"\"Know your audience\" is not \"chase the biggest market\" or \"give players only what they ask for\"\n(players report symptoms, not cures — PLAYTEST-0004); a designer can know their audience deeply\nand still surprise or challenge them. Personal/art games may be made for an audience of one (the\ncreator) — that's a valid, known audience, not an absence of one. And a genuinely broad game can\nserve a wide audience *if* it understands what that audience shares — breadth done knowingly, not\nby 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.\nbroad-appeal design (bigger market — but risk of averaging into blandness). And how much to give\nthe known audience what it expects vs. surprise it. The resolution: know the audience deeply, then\ndecide *deliberately* how much to comfort vs. challenge them — breadth and surprise are choices\nmade *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."},"rawMarkdown":"---\nid: GDC-L1-DESIGN-0008\ntitle: Know your audience — design for a specific player, not \"everyone\"\nlayer: L1\ndomain: DESIGN\nsubdomain: player-centric\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - player-centric\n  - audience\n  - target-player\n  - scope\n  - vision\nrelated:\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-VISION-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-15\nlast_verified: 2026-07-15\n---\n\n## Statement\n> Design for a *specific* player, not an abstract \"everyone.\" Know who the game is for — what\n> they enjoy, expect, and find hard — and let that knowledge inform decisions. A game aimed at\n> everyone usually delights no one; a game that knows its audience can be sharp, coherent, and\n> loved by the people it's for.\n\n## Rationale\nEvery design decision — difficulty, tone, complexity, controls, monetization — has a *right*\nanswer only relative to who's playing, so \"is this good?\" is unanswerable without \"good for\nwhom?\" [S-schell-artofgamedesign]. Trying to please everyone forces averaging: the game gets\nsanded down to offend no one and excite no one, and its decisions pull in incompatible\ndirections (a game can't be both a hardcore sim and a pick-up-and-play casual game without\nbecoming incoherent). Knowing the audience is what makes \"design for the experience produced\"\n(DESIGN-0001) actionable — the *intended* experience is intended *for someone*. It also grounds\nthe vision (VISION-0001) and disciplines scope (you build what your audience needs, not every\npossible feature). This is not pandering or market-chasing; it's the basic act of designing for\nreal people rather than a phantom universal player.\n\n## Applies when\nThroughout design, and especially at the outset (who is this for?) and whenever a decision has no\nobvious answer — check it against the target player. Foundational to vision, scope, difficulty,\nand tone.\n\n## Does not apply / Exceptions\n\"Know your audience\" is not \"chase the biggest market\" or \"give players only what they ask for\"\n(players report symptoms, not cures — PLAYTEST-0004); a designer can know their audience deeply\nand still surprise or challenge them. Personal/art games may be made for an audience of one (the\ncreator) — that's a valid, known audience, not an absence of one. And a genuinely broad game can\nserve a wide audience *if* it understands what that audience shares — breadth done knowingly, not\nby averaging blindly.\n\n## Implementation (kept separate from the principle)\nDefine 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).\n\n## Disagreement\nAudience-first design (coherent, sharp, loved by its people — but narrower reach) vs.\nbroad-appeal design (bigger market — but risk of averaging into blandness). And how much to give\nthe known audience what it expects vs. surprise it. The resolution: know the audience deeply, then\ndecide *deliberately* how much to comfort vs. challenge them — breadth and surprise are choices\nmade *with* audience knowledge, not substitutes for it.\n\n## Notes\nA foundational player-centric principle the corpus implied everywhere but hadn't stated outright (added in the 2026-07-15 audit). Confidence 4.\n","searchText":"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."}
{"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","file":"GDC-L1-FEEL-0001.md","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.","sections":{"Statement":"> Game feel is the moment-to-moment sensation of controlling a virtual body in a\n> simulated space, made vivid by polish. Treat it as three interlocking layers you\n> design deliberately — **control** (real-time input→response), **physicality** (a\n> space with weight, momentum, and collision), and **polish** (sensory amplification) —\n> 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\ntune: real-time control, a simulated space with its own physicality, and the polish that\namplifies interactions [S-swink-gamefeel]. Independent academic synthesis recovers the\nsame structure under different names — physicality, amplification, support\n[S-pichlmair-johansen-survey] — which is strong evidence the decomposition is real and\nnot just one author's framing. Because the layers are separable, \"the controls feel bad\"\nbecomes a diagnosable problem: a defect in one of control, physicality, or polish, each\nwith 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,\nor object — platformers, shooters, action, driving, sports, most action-RPGs. It is the\nlens for every other FEEL principle.","Does not apply / Exceptions":"Games with no real-time control loop — pure turn-based strategy, most text and\nnarrative games, asynchronous puzzles — have aesthetics and polish but little \"game\nfeel\" in this technical sense. Their satisfaction comes from other domains (DESIGN,\nNARR, 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\nresponsiveness (see FEEL-0002/0003). Bad **physicality** → look at acceleration,\nmomentum, gravity, and collision tuning. Bad **polish** → look at feedback: animation,\nparticles, sound, camera (see FEEL-0004). Tune each layer in isolation before judging\nthe whole.","Disagreement":"No meaningful disagreement about the decomposition itself; it is the field's shared\nvocabulary. Debate exists only *within* the layers (e.g. how much polish, how much\nresponsiveness) 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\ncut into one of its three layers. Confidence 5: the foundational text and an independent\nacademic survey converge on the same decomposition, making this as settled as game-feel\ntheory gets."},"rawMarkdown":"---\nid: GDC-L1-FEEL-0001\ntitle: Game feel is real-time control of a virtual body in a simulated space, made vivid by polish\nlayer: L1\ndomain: FEEL\nsubdomain: responsiveness\ntype: objective\nconfidence: 5\nstatus: canonical\ntags:\n  - game-feel\n  - definition\n  - mda\n  - player-centric\nrelated:\n  - GDC-L1-FEEL-0002\n  - GDC-L1-FEEL-0004\n  - GDC-L1-DESIGN-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-swink-gamefeel\n  - S-pichlmair-johansen-survey\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Game feel is the moment-to-moment sensation of controlling a virtual body in a\n> simulated space, made vivid by polish. Treat it as three interlocking layers you\n> design deliberately — **control** (real-time input→response), **physicality** (a\n> space with weight, momentum, and collision), and **polish** (sensory amplification) —\n> not as an accident that emerges from the rest of the game.\n\n## Rationale\n\"Feel\" sounds ineffable, but it decomposes into three things a designer can actually\ntune: real-time control, a simulated space with its own physicality, and the polish that\namplifies interactions [S-swink-gamefeel]. Independent academic synthesis recovers the\nsame structure under different names — physicality, amplification, support\n[S-pichlmair-johansen-survey] — which is strong evidence the decomposition is real and\nnot just one author's framing. Because the layers are separable, \"the controls feel bad\"\nbecomes a diagnosable problem: a defect in one of control, physicality, or polish, each\nwith its own tools. Naming the layers turns a vague complaint into an addressable bug.\n\n## Applies when\nAny game with real-time or near-real-time player control of an avatar, cursor, camera,\nor object — platformers, shooters, action, driving, sports, most action-RPGs. It is the\nlens for every other FEEL principle.\n\n## Does not apply / Exceptions\nGames with no real-time control loop — pure turn-based strategy, most text and\nnarrative games, asynchronous puzzles — have aesthetics and polish but little \"game\nfeel\" in this technical sense. Their satisfaction comes from other domains (DESIGN,\nNARR, SYS). Polish still matters; real-time *feel* does not.\n\n## Implementation (kept separate from the principle)\nDiagnose feel by layer. Bad **control** → look at latency, input mapping, and\nresponsiveness (see FEEL-0002/0003). Bad **physicality** → look at acceleration,\nmomentum, gravity, and collision tuning. Bad **polish** → look at feedback: animation,\nparticles, sound, camera (see FEEL-0004). Tune each layer in isolation before judging\nthe whole.\n\n## Disagreement\nNo meaningful disagreement about the decomposition itself; it is the field's shared\nvocabulary. Debate exists only *within* the layers (e.g. how much polish, how much\nresponsiveness) and is captured in the specific principles below.\n\n## Notes\nThis is the anchor principle for the FEEL domain — most other FEEL entries are a deeper\ncut into one of its three layers. Confidence 5: the foundational text and an independent\nacademic survey converge on the same decomposition, making this as settled as game-feel\ntheory gets.\n","searchText":"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."}
{"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","file":"GDC-L1-FEEL-0002.md","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.","sections":{"Statement":"> The game must register and visibly acknowledge the player's input immediately —\n> ideally on the next frame. Keep end-to-end control latency low enough that the player\n> 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\nreads the response and acts again. Swink describes roughly 100 ms as an important region\nfor instant-feeling response, while also emphasizing that acceptable latency varies with\nthe action and that continuity degrades across a wider range [S-swink-gamefeel]. Latency is\nuniquely corrosive because it degrades every single interaction uniformly and cannot be\ncompensated for by more polish — a beautifully juiced game with sluggish input still\nfeels bad. Crucially, \"acknowledge\" is not the same as \"resolve\": the game can register\nthe input this frame and start showing *something* (a wind-up, a sound, a flash) even if\nthe full action takes longer to play out.","Applies when":"Every real-time control action: movement, jumping, firing, camera, menu navigation.\nThe bar is strictest for high-frequency, skill-expressive actions the player performs\nconstantly.","Does not apply / Exceptions":"Deliberate, communicated delays that are part of the fantasy (a heavy weapon's\nwind-up, a charged attack) are not latency — see FEEL-0008. The distinction: latency is\nthe game being slow to *hear* you; commitment is the game taking time to *carry out*\nwhat it already heard. The former is always a defect; the latter can be a feature. Also,\nsome competitive or simulation genres accept higher latency for other guarantees\n(rollback vs. delay-based netcode tradeoffs), a networking concern rather than a feel\nideal.","Implementation (kept separate from the principle)":"Measure, don't guess: capture end-to-end latency (photograph or high-speed-capture the\nbutton-to-pixel delay), not just engine frame time. Reduce it by processing input as\nearly in the frame as possible, avoiding multi-frame input pipelines, and giving\n*instant* feedback on press even when the modeled action resolves later. On unavoidable\ndelays, mask them with immediate secondary feedback (sound, a tiny anticipation pose) so\nthe player still feels heard on frame one.","Disagreement":"The pure-responsiveness ideal is in tension with deliberately weighty, commitment-heavy\ncombat (see FEEL-0008). The reconciliation both sides accept: *acknowledgment* latency\nshould always be minimized; *resolution* time is a design choice. Even Dark Souls\nregisters your dodge press instantly and buffers it — it just resolves the roll on its\nown animation schedule.","Notes":"Confidence 5: universal agreement across action-game practice, plus a measured\nperceptual threshold. The `conflicts_with` link to FEEL-0008 is intentional and\nproductive — see that entry for the full responsiveness-vs-commitment treatment."},"rawMarkdown":"---\nid: GDC-L1-FEEL-0002\ntitle: Acknowledge input immediately; keep control latency perceptually tight\nlayer: L1\ndomain: FEEL\nsubdomain: responsiveness\ntype: objective\nconfidence: 5\nstatus: canonical\ntags:\n  - responsiveness\n  - latency\n  - input\n  - measure-dont-guess\nrelated:\n  - GDC-L1-FEEL-0001\n  - GDC-L1-FEEL-0003\ndepends_on:\n  - GDC-L1-FEEL-0001\nconflicts_with:\n  - GDC-L1-FEEL-0008\nsupersedes: []\nsources:\n  - S-swink-gamefeel\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> The game must register and visibly acknowledge the player's input immediately —\n> ideally on the next frame. Keep end-to-end control latency low enough that the player\n> reads response as continuous with intent, because delayed acknowledgment quickly erodes game feel.\n\n## Rationale\nControl feel lives in a tight loop: the player acts, the game responds, the player\nreads the response and acts again. Swink describes roughly 100 ms as an important region\nfor instant-feeling response, while also emphasizing that acceptable latency varies with\nthe action and that continuity degrades across a wider range [S-swink-gamefeel]. Latency is\nuniquely corrosive because it degrades every single interaction uniformly and cannot be\ncompensated for by more polish — a beautifully juiced game with sluggish input still\nfeels bad. Crucially, \"acknowledge\" is not the same as \"resolve\": the game can register\nthe input this frame and start showing *something* (a wind-up, a sound, a flash) even if\nthe full action takes longer to play out.\n\n## Applies when\nEvery real-time control action: movement, jumping, firing, camera, menu navigation.\nThe bar is strictest for high-frequency, skill-expressive actions the player performs\nconstantly.\n\n## Does not apply / Exceptions\nDeliberate, communicated delays that are part of the fantasy (a heavy weapon's\nwind-up, a charged attack) are not latency — see FEEL-0008. The distinction: latency is\nthe game being slow to *hear* you; commitment is the game taking time to *carry out*\nwhat it already heard. The former is always a defect; the latter can be a feature. Also,\nsome competitive or simulation genres accept higher latency for other guarantees\n(rollback vs. delay-based netcode tradeoffs), a networking concern rather than a feel\nideal.\n\n## Implementation (kept separate from the principle)\nMeasure, don't guess: capture end-to-end latency (photograph or high-speed-capture the\nbutton-to-pixel delay), not just engine frame time. Reduce it by processing input as\nearly in the frame as possible, avoiding multi-frame input pipelines, and giving\n*instant* feedback on press even when the modeled action resolves later. On unavoidable\ndelays, mask them with immediate secondary feedback (sound, a tiny anticipation pose) so\nthe player still feels heard on frame one.\n\n## Disagreement\nThe pure-responsiveness ideal is in tension with deliberately weighty, commitment-heavy\ncombat (see FEEL-0008). The reconciliation both sides accept: *acknowledgment* latency\nshould always be minimized; *resolution* time is a design choice. Even Dark Souls\nregisters your dodge press instantly and buffers it — it just resolves the roll on its\nown animation schedule.\n\n## Notes\nConfidence 5: universal agreement across action-game practice, plus a measured\nperceptual threshold. The `conflicts_with` link to FEEL-0008 is intentional and\nproductive — see that entry for the full responsiveness-vs-commitment treatment.\n","searchText":"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."}
{"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","file":"GDC-L1-FEEL-0003.md","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.","sections":{"Statement":"> Read what the player *meant*, not only what they literally pressed. Add small,\n> invisible forgiveness windows — coyote time, input buffering, corner correction — so\n> 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\nplayers for gaps between intent and execution that they never perceive as their own\nerror — it just feels like the game \"didn't work.\" Forgiveness closes that gap. The\nstaple techniques [S-thorson-celeste-forgiveness]: coyote time (a jump still fires\nbriefly after leaving a ledge), jump-input buffering (a jump pressed shortly before\nlanding still fires on landing), and\ncorner correction (a head-bonk nudges the avatar around the lip instead of stopping it).\nPlayers don't perceive these as assists; they perceive the controls as \"tight.\" The\ndeeper principle: the game should be on the player's side, targeting the experience they\nintended (ties to DESIGN-0001).","Applies when":"Precision- and timing-critical real-time control, especially platforming, action, and\nanything with tight jumps, dashes, or combo timing. Highest value where the skill\nexpression 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\nhardcore/competitive designs treat exact timing as the skill being tested; forgiveness\nthere removes the point. And forgiveness must stay small and consistent — overly generous\nor context-varying windows make the game feel mushy, unpredictable, or unfair in the\nother 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\nspeed, animation, and intended difficulty. Add corner/edge correction where collision would\notherwise reject a clear player intention. Make windows *fixed and predictable*, not adaptive,\nso mastery stays learnable. Keep them invisible — if players can point at the assist, it\nis probably too large. Always verify by watching real players (playtest), since the\nwhole point is matching perceived intent.","Disagreement":"Two schools: **forgiveness-first** (Celeste, Super Meat Boy — assume good intent,\ntighten feel) vs. **purity-first** (execution-focused and competitive designs — exact\ninput is the test). Neither is universally right; the deciding question is *whether the\ntiming itself is the skill you want to measure.* If yes, stay strict; if the timing is\njust 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.\nConfidence 4: strong practitioner consensus for the genres where it applies, with the\ngenuine genre-dependent exception keeping it below 5."},"rawMarkdown":"---\nid: GDC-L1-FEEL-0003\ntitle: Interpret the player's intent, not just their literal input\nlayer: L1\ndomain: FEEL\nsubdomain: input\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - input\n  - forgiveness\n  - player-centric\n  - intent\n  - accessibility\nrelated:\n  - GDC-L1-FEEL-0002\n  - GDC-L1-DESIGN-0001\ndepends_on:\n  - GDC-L1-FEEL-0002\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-thorson-celeste-forgiveness\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Read what the player *meant*, not only what they literally pressed. Add small,\n> invisible forgiveness windows — coyote time, input buffering, corner correction — so\n> that near-misses of timing or aim resolve the way the player intended.\n\n## Rationale\nHuman motor timing is imprecise by tens of milliseconds; strict input handling punishes\nplayers for gaps between intent and execution that they never perceive as their own\nerror — it just feels like the game \"didn't work.\" Forgiveness closes that gap. The\nstaple techniques [S-thorson-celeste-forgiveness]: coyote time (a jump still fires\nbriefly after leaving a ledge), jump-input buffering (a jump pressed shortly before\nlanding still fires on landing), and\ncorner correction (a head-bonk nudges the avatar around the lip instead of stopping it).\nPlayers don't perceive these as assists; they perceive the controls as \"tight.\" The\ndeeper principle: the game should be on the player's side, targeting the experience they\nintended (ties to DESIGN-0001).\n\n## Applies when\nPrecision- and timing-critical real-time control, especially platforming, action, and\nanything with tight jumps, dashes, or combo timing. Highest value where the skill\nexpression is in *positioning and timing* rather than in the timing test itself.\n\n## Does not apply / Exceptions\nWhen the strictness *is* the game. Rhythm games, precision-timing challenges, and some\nhardcore/competitive designs treat exact timing as the skill being tested; forgiveness\nthere removes the point. And forgiveness must stay small and consistent — overly generous\nor context-varying windows make the game feel mushy, unpredictable, or unfair in the\nother direction. Tune to taste and genre.\n\n## Implementation (kept separate from the principle)\nStart with short coyote-time and input-buffer windows, then tune them against the game’s\nspeed, animation, and intended difficulty. Add corner/edge correction where collision would\notherwise reject a clear player intention. Make windows *fixed and predictable*, not adaptive,\nso mastery stays learnable. Keep them invisible — if players can point at the assist, it\nis probably too large. Always verify by watching real players (playtest), since the\nwhole point is matching perceived intent.\n\n## Disagreement\nTwo schools: **forgiveness-first** (Celeste, Super Meat Boy — assume good intent,\ntighten feel) vs. **purity-first** (execution-focused and competitive designs — exact\ninput is the test). Neither is universally right; the deciding question is *whether the\ntiming itself is the skill you want to measure.* If yes, stay strict; if the timing is\njust a tax on the real skill (positioning, decision-making), forgive it.\n\n## Notes\nType is `contextual` precisely because the purity-first exception is real and common.\nConfidence 4: strong practitioner consensus for the genres where it applies, with the\ngenuine genre-dependent exception keeping it below 5.\n","searchText":"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."}
{"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","file":"GDC-L1-FEEL-0004.md","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.","sections":{"Statement":"> Wrap every meaningful player action and game event in immediate, layered feedback\n> across multiple senses at once — animation, particles, sound, camera, haptics. A\n> single input should produce a cascade of response (\"juice\"), so the game feels alive\n> and the player feels powerful and informed.","Rationale":"Feedback does two jobs simultaneously: it *communicates* (this hit landed, this button\nworked, this thing matters) and it *rewards* (the action felt good, do it again). The\neffect is demonstrable: take a functional-but-flat game and add a few dozen small\namplifications, and it transforms into something satisfying with zero change to the\nunderlying mechanics [S-nijman-screenshake] [S-jonasson-purho-juice]. In the academic\nframing this is *amplification via juicing* — polish that empowers the player and\nprovides clarity of feedback by signaling the importance of events\n[S-pichlmair-johansen-survey]. Redundancy across senses is deliberate: it makes the\nsignal robust (a hit you might miss visually you'll catch in sound or shake) and the\nreward richer.","Applies when":"Every discrete, meaningful event: hits, kills, pickups, jumps, landings, UI\nconfirmations, successes and failures. The more important or frequent the event, the\nmore it earns feedback.","Does not apply / Exceptions":"Juice is amplification, not decoration — feedback on *meaningless* events is noise that\nburies the meaningful signal. Restraint-driven aesthetics (quiet, contemplative, horror,\nminimalist) deliberately *withhold* feedback for effect, and over-juicing there destroys\nthe intended mood. Accessibility: excessive flashing/shake can harm some players (see\nFEEL-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\nbrief hitstop (FEEL-0005), and a small camera kick (FEEL-0006) — each on a different\nsense. Tie feedback intensity to event importance so the channel stays legible. Cheap,\nhigh-impact wins first: sound and a 1–2-frame flash often beat expensive new animation.\nAlways keep the amplifying feedback from delaying the *acknowledgment* of input\n(FEEL-0002).","Disagreement":"\"Juice it or lose it\" is sometimes over-applied. A well-known counter-position (\"resist\nthe urge to juice it\") warns that reflexive, maximal juice can produce sensory overload,\nobscure game state, and homogenize the feel of very different games. Synthesis: juice is\na tool in service of *communication and the intended experience*, not an end in itself —\namplify what matters, in the register the game wants, and stop there.","Notes":"Confidence 4: the core claim (amplify meaningful actions with layered feedback) is\nnear-universal; the deduction from 5 reflects the real \"too much juice\" failure mode and\nmood-driven exceptions. FEEL-0005 and FEEL-0006 are specific, heavily-used techniques\nthat live under this umbrella."},"rawMarkdown":"---\nid: GDC-L1-FEEL-0004\ntitle: Amplify every meaningful action with layered, redundant, multi-sensory feedback\nlayer: L1\ndomain: FEEL\nsubdomain: feedback-and-juice\ntype: objective\nconfidence: 4\nstatus: canonical\ntags:\n  - juice\n  - feedback\n  - polish\n  - amplification\n  - audio\n  - animation\nrelated:\n  - GDC-L1-FEEL-0005\n  - GDC-L1-FEEL-0006\n  - GDC-L1-FEEL-0001\ndepends_on:\n  - GDC-L1-FEEL-0001\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-jonasson-purho-juice\n  - S-nijman-screenshake\n  - S-pichlmair-johansen-survey\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Wrap every meaningful player action and game event in immediate, layered feedback\n> across multiple senses at once — animation, particles, sound, camera, haptics. A\n> single input should produce a cascade of response (\"juice\"), so the game feels alive\n> and the player feels powerful and informed.\n\n## Rationale\nFeedback does two jobs simultaneously: it *communicates* (this hit landed, this button\nworked, this thing matters) and it *rewards* (the action felt good, do it again). The\neffect is demonstrable: take a functional-but-flat game and add a few dozen small\namplifications, and it transforms into something satisfying with zero change to the\nunderlying mechanics [S-nijman-screenshake] [S-jonasson-purho-juice]. In the academic\nframing this is *amplification via juicing* — polish that empowers the player and\nprovides clarity of feedback by signaling the importance of events\n[S-pichlmair-johansen-survey]. Redundancy across senses is deliberate: it makes the\nsignal robust (a hit you might miss visually you'll catch in sound or shake) and the\nreward richer.\n\n## Applies when\nEvery discrete, meaningful event: hits, kills, pickups, jumps, landings, UI\nconfirmations, successes and failures. The more important or frequent the event, the\nmore it earns feedback.\n\n## Does not apply / Exceptions\nJuice is amplification, not decoration — feedback on *meaningless* events is noise that\nburies the meaningful signal. Restraint-driven aesthetics (quiet, contemplative, horror,\nminimalist) deliberately *withhold* feedback for effect, and over-juicing there destroys\nthe intended mood. Accessibility: excessive flashing/shake can harm some players (see\nFEEL-0006). More juice is not monotonically better — see Disagreement.\n\n## Implementation (kept separate from the principle)\nLayer, don't pile: for a hit, combine a hit-flash, a particle burst, a punchy sound, a\nbrief hitstop (FEEL-0005), and a small camera kick (FEEL-0006) — each on a different\nsense. Tie feedback intensity to event importance so the channel stays legible. Cheap,\nhigh-impact wins first: sound and a 1–2-frame flash often beat expensive new animation.\nAlways keep the amplifying feedback from delaying the *acknowledgment* of input\n(FEEL-0002).\n\n## Disagreement\n\"Juice it or lose it\" is sometimes over-applied. A well-known counter-position (\"resist\nthe urge to juice it\") warns that reflexive, maximal juice can produce sensory overload,\nobscure game state, and homogenize the feel of very different games. Synthesis: juice is\na tool in service of *communication and the intended experience*, not an end in itself —\namplify what matters, in the register the game wants, and stop there.\n\n## Notes\nConfidence 4: the core claim (amplify meaningful actions with layered feedback) is\nnear-universal; the deduction from 5 reflects the real \"too much juice\" failure mode and\nmood-driven exceptions. FEEL-0005 and FEEL-0006 are specific, heavily-used techniques\nthat live under this umbrella.\n","searchText":"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."}
{"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","file":"GDC-L1-FEEL-0005.md","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.","sections":{"Statement":"> On a significant impact, freeze the action for a few frames before resuming. This\n> brief interruption of time (\"hitstop\" / \"hit pause\") makes hits read as forceful and\n> 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\nit. Inserting a brief pause [S-nijman-screenshake] holds the moment of contact on screen long enough for\nthe player to *feel* the collision, and momentarily halts the action so both bodies\nregister the blow. It exploits perception rather than fidelity: the pause implies\nenormous force without simulating it. Time-based effects like this are among the features\nthat 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,\nfinishing blows, big destruction. Scales with the significance of the impact — a light\njab 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,\nlaggy, or unresponsive, and can fight the responsiveness ideal (FEEL-0002) if it stalls\nthe player's *next* input. Games built on flow and speed (fast movement shooters, some\ncharacter-action at high skill) deliberately minimize it. Genres where impacts aren't\nthe 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,\nnot a stalled game. Freeze\nthe striking and struck actors (and often their effects) while ideally letting the\ncamera and particles keep moving so the frame doesn't feel dead. Let the player's *own*\nnext input still buffer during the pause so it never reads as latency. Pair with the\nother 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\nhitstop) vs. high-flow action (minimal hitstop) are both correct for their fantasies.\nThe invariant is that hitstop must never degrade responsiveness of the *player's* next\naction.","Notes":"A specific, high-leverage technique under FEEL-0004. Confidence 4: strongly supported as\neffective; typed `contextual` because the right amount — and whether to use it at all —\ndepends on the game's speed and fantasy."},"rawMarkdown":"---\nid: GDC-L1-FEEL-0005\ntitle: Sell impact by briefly interrupting time (hitstop / hit pause)\nlayer: L1\ndomain: FEEL\nsubdomain: feedback-and-juice\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - juice\n  - impact\n  - hitstop\n  - feedback\n  - combat\nrelated:\n  - GDC-L1-FEEL-0004\n  - GDC-L1-FEEL-0006\ndepends_on:\n  - GDC-L1-FEEL-0004\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-nijman-screenshake\n  - S-impact-feedback-study\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> On a significant impact, freeze the action for a few frames before resuming. This\n> brief interruption of time (\"hitstop\" / \"hit pause\") makes hits read as forceful and\n> weighty far more cheaply and vividly than added animation alone.\n\n## Rationale\nA collision resolved in a single frame is perceptually thin — the eye barely registers\nit. Inserting a brief pause [S-nijman-screenshake] holds the moment of contact on screen long enough for\nthe player to *feel* the collision, and momentarily halts the action so both bodies\nregister the blow. It exploits perception rather than fidelity: the pause implies\nenormous force without simulating it. Time-based effects like this are among the features\nthat most strongly drive perceived impact in action games [S-impact-feedback-study].\n\n## Applies when\nImpacts that should feel heavy: melee hits, powerful shots, hard landings, parries,\nfinishing blows, big destruction. Scales with the significance of the impact — a light\njab gets a frame or two; a heavy smash gets more.\n\n## Does not apply / Exceptions\nOveruse is a real failure: constant or overlong hitstop makes fast combat feel stuttery,\nlaggy, or unresponsive, and can fight the responsiveness ideal (FEEL-0002) if it stalls\nthe player's *next* input. Games built on flow and speed (fast movement shooters, some\ncharacter-action at high skill) deliberately minimize it. Genres where impacts aren't\nthe point (most puzzle, strategy, narrative) don't need it.\n\n## Implementation (kept separate from the principle)\nScale pause length to impact magnitude and keep it brief enough that it reads as emphasis,\nnot a stalled game. Freeze\nthe striking and struck actors (and often their effects) while ideally letting the\ncamera and particles keep moving so the frame doesn't feel dead. Let the player's *own*\nnext input still buffer during the pause so it never reads as latency. Pair with the\nother juice layers (flash, sound, shake) landing on the same frame as the freeze.\n\n## Disagreement\nAmount is genre-dependent and somewhat stylistic: weighty character-action (heavy\nhitstop) vs. high-flow action (minimal hitstop) are both correct for their fantasies.\nThe invariant is that hitstop must never degrade responsiveness of the *player's* next\naction.\n\n## Notes\nA specific, high-leverage technique under FEEL-0004. Confidence 4: strongly supported as\neffective; typed `contextual` because the right amount — and whether to use it at all —\ndepends on the game's speed and fantasy.\n","searchText":"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."}
{"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","file":"GDC-L1-FEEL-0006.md","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.","sections":{"Statement":"> Move the camera to sell force — screenshake, kicks, punch-in, recoil — because the\n> camera is a sense the player inhabits, so shaking it makes impacts physical. But dose\n> it carefully and expose intensity as a player-controllable setting: unbounded shake\n> becomes noise, harms readability, and excludes some players.","Rationale":"The camera is the player's eyes; perturbing it transfers force directly into their\nperception, which is why screenshake is one of the most effective and widely-cited juice\ntechniques [S-nijman-screenshake] [S-jonasson-purho-juice]. But the same power makes it\ndangerous:\nexcessive or constant shake destroys the player's ability to read the game state,\ninduces motion discomfort or nausea, and can trigger issues for photosensitive and\nvestibular-sensitive players. Its strength and its risk are the same property, so it must\nbe *dosed* and *optional*.","Applies when":"Impacts, explosions, weapon recoil, heavy landings, big events — moments that should feel\nphysically forceful. Small, brief kicks scaled to event magnitude are the high-value\ndefault.","Does not apply / Exceptions":"Precision-reading contexts (competitive aiming, careful platforming, strategy) want\nminimal camera disturbance so state stays legible. Calm or contemplative aesthetics avoid\nit. 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\ncombination of events can stack into an unreadable frame. Prefer directional kicks\n(shake *away* from the impact) over random jitter for events with a clear source. Provide\nan explicit \"screen shake\" intensity slider (including off) — now an expected\naccessibility option. Combine with hitstop (FEEL-0005) and the other juice layers rather\nthan relying on shake alone.","Disagreement":"Pro-juice practitioners treat screenshake as near-free game feel; the \"resist the urge\"\ncounter-camp warns it is the most over-applied juice technique and the fastest route to\nsensory overload and unreadability. Both agree on the resolution captured here: dose to\nthe event, cap the total, and make it optional. The remaining difference is a stylistic\ndial (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\nthe genuine readability/accessibility exceptions. The player-control-and-cap clause is\nthe part practitioners most often skip and later regret."},"rawMarkdown":"---\nid: GDC-L1-FEEL-0006\ntitle: Use camera motion and screenshake to convey force — but dose it and let players control it\nlayer: L1\ndomain: FEEL\nsubdomain: camera\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - juice\n  - camera\n  - screenshake\n  - feedback\n  - accessibility\nrelated:\n  - GDC-L1-FEEL-0004\n  - GDC-L1-FEEL-0005\ndepends_on:\n  - GDC-L1-FEEL-0004\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-nijman-screenshake\n  - S-jonasson-purho-juice\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Move the camera to sell force — screenshake, kicks, punch-in, recoil — because the\n> camera is a sense the player inhabits, so shaking it makes impacts physical. But dose\n> it carefully and expose intensity as a player-controllable setting: unbounded shake\n> becomes noise, harms readability, and excludes some players.\n\n## Rationale\nThe camera is the player's eyes; perturbing it transfers force directly into their\nperception, which is why screenshake is one of the most effective and widely-cited juice\ntechniques [S-nijman-screenshake] [S-jonasson-purho-juice]. But the same power makes it\ndangerous:\nexcessive or constant shake destroys the player's ability to read the game state,\ninduces motion discomfort or nausea, and can trigger issues for photosensitive and\nvestibular-sensitive players. Its strength and its risk are the same property, so it must\nbe *dosed* and *optional*.\n\n## Applies when\nImpacts, explosions, weapon recoil, heavy landings, big events — moments that should feel\nphysically forceful. Small, brief kicks scaled to event magnitude are the high-value\ndefault.\n\n## Does not apply / Exceptions\nPrecision-reading contexts (competitive aiming, careful platforming, strategy) want\nminimal camera disturbance so state stays legible. Calm or contemplative aesthetics avoid\nit. And it is subject to strong accessibility limits — always shippable-off.\n\n## Implementation (kept separate from the principle)\nScale amplitude and duration to event importance; decay quickly; cap the maximum so no\ncombination of events can stack into an unreadable frame. Prefer directional kicks\n(shake *away* from the impact) over random jitter for events with a clear source. Provide\nan explicit \"screen shake\" intensity slider (including off) — now an expected\naccessibility option. Combine with hitstop (FEEL-0005) and the other juice layers rather\nthan relying on shake alone.\n\n## Disagreement\nPro-juice practitioners treat screenshake as near-free game feel; the \"resist the urge\"\ncounter-camp warns it is the most over-applied juice technique and the fastest route to\nsensory overload and unreadability. Both agree on the resolution captured here: dose to\nthe event, cap the total, and make it optional. The remaining difference is a stylistic\ndial (how punchy the house style is), not a dispute about the guardrails.\n\n## Notes\nConfidence 4: effectiveness is well-established; typed `contextual` and held below 5 by\nthe genuine readability/accessibility exceptions. The player-control-and-cap clause is\nthe part practitioners most often skip and later regret.\n","searchText":"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."}
{"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","file":"GDC-L1-FEEL-0007.md","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.","sections":{"Statement":"> When realism and feel conflict, tune for the sensation you want the player to have,\n> not for physical accuracy. The goal is a body that feels right to control — not a\n> correct simulation.","Rationale":"The player experiences the *feeling* of movement, never its equations (ties to\nDESIGN-0001: judge by the experience produced). Beloved control famously violates\nphysics: platformer jumps use asymmetric gravity (rise slower, fall faster) that no real\nprojectile obeys; characters accelerate to full speed in a frame or two; coyote time\nlets you jump from empty air. These \"lies\" exist because they *feel* better —\ncontrollable, snappy, fair. The whole discipline of game feel treats the sensation as\nthe tunable target and physical plausibility as merely one input to it\n[S-swink-gamefeel] — which is why the craft of shaping physicality is literally named\n\"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\nis most action, platforming, and character control. The more the game is about the joy\nof 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,\nsome sports — where fidelity to real behavior *is* the intended experience and\n\"improving the feel\" by faking physics would betray it. Realism can also be a\ndeliberate feel target (deliberate heaviness, tank controls for tension). The principle\nis \"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,\"\n\"snappy and precise\"), then tune numbers toward it and discard realism where it fights\nthe target. Expose feel-critical values (accel, gravity up/down, max speed, friction,\nair control) as easily-iterated parameters and tune them by feel in playtest, not by\nphysical derivation. Keep the *simulated space* internally consistent even when it's\nunrealistic, so the player can still build accurate intuitions.","Disagreement":"Feel-first (arcade, platformer, action) vs. simulation-first (sim genres) is a real and\nlegitimate split, but it is usually a genre choice rather than a live argument: both\ncamps agree the rule is \"serve the intended experience,\" and simply intend different\nexperiences. Encoded here as `contextual` for that reason.","Notes":"This is the physicality-layer counterpart to FEEL-0002/0003's control-layer guidance.\nConfidence 4: overwhelmingly true for action/arcade design, with the honest and large\nsim-genre exception keeping it contextual."},"rawMarkdown":"---\nid: GDC-L1-FEEL-0007\ntitle: Tune for the sensation, not physical accuracy\nlayer: L1\ndomain: FEEL\nsubdomain: physicality\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - game-feel\n  - physicality\n  - tuning\n  - player-centric\nrelated:\n  - GDC-L1-FEEL-0001\n  - GDC-L1-FEEL-0003\n  - GDC-L1-DESIGN-0001\ndepends_on:\n  - GDC-L1-FEEL-0001\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-swink-gamefeel\n  - S-thorson-celeste-forgiveness\n  - S-pichlmair-johansen-survey\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> When realism and feel conflict, tune for the sensation you want the player to have,\n> not for physical accuracy. The goal is a body that feels right to control — not a\n> correct simulation.\n\n## Rationale\nThe player experiences the *feeling* of movement, never its equations (ties to\nDESIGN-0001: judge by the experience produced). Beloved control famously violates\nphysics: platformer jumps use asymmetric gravity (rise slower, fall faster) that no real\nprojectile obeys; characters accelerate to full speed in a frame or two; coyote time\nlets you jump from empty air. These \"lies\" exist because they *feel* better —\ncontrollable, snappy, fair. The whole discipline of game feel treats the sensation as\nthe tunable target and physical plausibility as merely one input to it\n[S-swink-gamefeel] — which is why the craft of shaping physicality is literally named\n\"tuning\": you tune toward a sensation, not toward realism [S-pichlmair-johansen-survey].\n\n## Applies when\nAny time simulated movement or physics is in service of *how it feels to play* — which\nis most action, platforming, and character control. The more the game is about the joy\nof moving, the more feel should win over accuracy.\n\n## Does not apply / Exceptions\nSimulation is the point in sim genres — racing sims, flight sims, physics sandboxes,\nsome sports — where fidelity to real behavior *is* the intended experience and\n\"improving the feel\" by faking physics would betray it. Realism can also be a\ndeliberate feel target (deliberate heaviness, tank controls for tension). The principle\nis \"serve the intended sensation,\" and sometimes the intended sensation is realism.\n\n## Implementation (kept separate from the principle)\nDecide the target sensation first (\"floaty and forgiving,\" \"heavy and deliberate,\"\n\"snappy and precise\"), then tune numbers toward it and discard realism where it fights\nthe target. Expose feel-critical values (accel, gravity up/down, max speed, friction,\nair control) as easily-iterated parameters and tune them by feel in playtest, not by\nphysical derivation. Keep the *simulated space* internally consistent even when it's\nunrealistic, so the player can still build accurate intuitions.\n\n## Disagreement\nFeel-first (arcade, platformer, action) vs. simulation-first (sim genres) is a real and\nlegitimate split, but it is usually a genre choice rather than a live argument: both\ncamps agree the rule is \"serve the intended experience,\" and simply intend different\nexperiences. Encoded here as `contextual` for that reason.\n\n## Notes\nThis is the physicality-layer counterpart to FEEL-0002/0003's control-layer guidance.\nConfidence 4: overwhelmingly true for action/arcade design, with the honest and large\nsim-genre exception keeping it contextual.\n","searchText":"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."}
{"id":"GDC-L1-FEEL-0008","title":"Place the game deliberately on the responsiveness–commitment axis","layer":"L1","domain":"FEEL","subdomain":"responsiveness","type":"contextual","confidence":4,"status":"canonical","tags":["responsiveness","commitment","weight","combat","risk-reward"],"related":["GDC-L1-FEEL-0001","GDC-L1-FEEL-0007","GDC-L1-ANIM-0002","GDC-L1-ANIM-0004"],"depends_on":["GDC-L1-FEEL-0001"],"conflicts_with":["GDC-L1-FEEL-0002"],"supersedes":[],"sources":["S-swink-gamefeel","S-cooper-game-anim"],"first_added":"2026-07-14","last_verified":"2026-07-15","file":"GDC-L1-FEEL-0008.md","statement":"How long an action takes to resolve once committed — its wind-up, follow-through, and cancelability — is a primary design lever, not a bug to minimize. Choose the game's position on the axis from \"instantly cancelable and snappy\" to \"fully committed and weighty\" deliberately, to serve the intended fantasy and risk/reward.","sections":{"Statement":"> How long an action takes to *resolve* once committed — its wind-up, follow-through,\n> and cancelability — is a primary design lever, not a bug to minimize. Choose the\n> game's position on the axis from \"instantly cancelable and snappy\" to \"fully committed\n> and weighty\" deliberately, to serve the intended fantasy and risk/reward.","Rationale":"Responsiveness (FEEL-0002) says the game must *hear* you instantly. This principle is\nabout how fast it *acts* — and here more speed is not always better. Commitment —\nanimations that must play out, actions you can't cancel — is what creates weight,\nconsequence, and readable risk/reward, and it is implemented as **animation priority**:\nan action holds control until a designated frame, a lever the animator controls\n[S-cooper-game-anim]. Deliberate attack and dodge commitment (as in weapon-based\nsouls-likes, or Monster Hunter's extreme swing commitment) is core to the tension and\nmastery of such combat. That \"heavy\" feel is\n*designed*, not a latency defect: the player is heard instantly (input is registered and\nbuffered) but the modeled action honors its own timing. Position on this axis defines\nwhole combat identities: twitch-cancelable character-action vs. deliberate weapon-based\nsouls-likes.","Applies when":"Any game with meaningful action timing, especially combat, and anywhere risk/reward\nshould come from committing to actions. The choice sets the game's core rhythm.","Does not apply / Exceptions":"Games whose fantasy is pure speed and flow (fast movement shooters, hyper-agile\ncharacter-action) legitimately sit at the fully-responsive end and minimize commitment.\nThere is no universally correct point — only a correct point *for a given intended feel*.","Implementation (kept separate from the principle)":"Separate the two latencies explicitly: always acknowledge input on frame one (buffer it,\nshow anticipation), then resolve on the action's designed schedule. Tune wind-up,\nactive, recovery, and cancel windows as first-class combat parameters. Use committed\nrecovery frames as the currency of risk (whiffing a heavy attack should hurt). If\nplayers report the game feeling \"laggy,\" diagnose whether it's true acknowledgment\nlatency (a defect — fix per FEEL-0002) or commitment they're reading as lag (a feature —\ncommunicate it better via anticipation and telegraphing).","Disagreement":"This is the domain's central productive tension, and it is why this entry\n`conflicts_with` FEEL-0002:\n\n- **Responsiveness-maximalist:** every frame of delay is an enemy; the avatar should be\n  a frictionless extension of the player (platformers, twitch shooters, Devil May\n  Cry–style flow).\n- **Commitment-maximalist:** weight, consequence, and deliberate pacing require actions\n  that can't be instantly taken back (Souls games, Monster Hunter, fighting-game\n  recovery frames).\n\n**Reconciliation (both accept):** the conflict dissolves once you split *acknowledgment*\nlatency from *resolution* time. Acknowledgment should always be near-instant (FEEL-0002\nholds absolutely); resolution time is the dial this principle governs. A great weighty\ngame and a great snappy game both register your input on frame one — they differ only in\nhow long the world takes to answer.","Notes":"The `conflicts_with: FEEL-0002` edge is deliberate and is the pilot's demonstration of\nhow the constitution preserves and *resolves* disagreement rather than flattening it. Its\nanimation-domain expressions are ANIM-0002 (responsiveness beats fidelity / cancel windows)\nand ANIM-0004 (root-motion vs. code-driven). Confidence 4. *(2026-07-15: the weak community\nsource was retired and replaced with Cooper's* Game Anim*, a proper primary for the\nanimation-priority/commitment mechanism.)*"},"rawMarkdown":"---\nid: GDC-L1-FEEL-0008\ntitle: Place the game deliberately on the responsiveness–commitment axis\nlayer: L1\ndomain: FEEL\nsubdomain: responsiveness\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - responsiveness\n  - commitment\n  - weight\n  - combat\n  - risk-reward\nrelated:\n  - GDC-L1-FEEL-0001\n  - GDC-L1-FEEL-0007\n  - GDC-L1-ANIM-0002\n  - GDC-L1-ANIM-0004\ndepends_on:\n  - GDC-L1-FEEL-0001\nconflicts_with:\n  - GDC-L1-FEEL-0002\nsupersedes: []\nsources:\n  - S-swink-gamefeel\n  - S-cooper-game-anim\nfirst_added: 2026-07-14\nlast_verified: 2026-07-15\n---\n\n## Statement\n> How long an action takes to *resolve* once committed — its wind-up, follow-through,\n> and cancelability — is a primary design lever, not a bug to minimize. Choose the\n> game's position on the axis from \"instantly cancelable and snappy\" to \"fully committed\n> and weighty\" deliberately, to serve the intended fantasy and risk/reward.\n\n## Rationale\nResponsiveness (FEEL-0002) says the game must *hear* you instantly. This principle is\nabout how fast it *acts* — and here more speed is not always better. Commitment —\nanimations that must play out, actions you can't cancel — is what creates weight,\nconsequence, and readable risk/reward, and it is implemented as **animation priority**:\nan action holds control until a designated frame, a lever the animator controls\n[S-cooper-game-anim]. Deliberate attack and dodge commitment (as in weapon-based\nsouls-likes, or Monster Hunter's extreme swing commitment) is core to the tension and\nmastery of such combat. That \"heavy\" feel is\n*designed*, not a latency defect: the player is heard instantly (input is registered and\nbuffered) but the modeled action honors its own timing. Position on this axis defines\nwhole combat identities: twitch-cancelable character-action vs. deliberate weapon-based\nsouls-likes.\n\n## Applies when\nAny game with meaningful action timing, especially combat, and anywhere risk/reward\nshould come from committing to actions. The choice sets the game's core rhythm.\n\n## Does not apply / Exceptions\nGames whose fantasy is pure speed and flow (fast movement shooters, hyper-agile\ncharacter-action) legitimately sit at the fully-responsive end and minimize commitment.\nThere is no universally correct point — only a correct point *for a given intended feel*.\n\n## Implementation (kept separate from the principle)\nSeparate the two latencies explicitly: always acknowledge input on frame one (buffer it,\nshow anticipation), then resolve on the action's designed schedule. Tune wind-up,\nactive, recovery, and cancel windows as first-class combat parameters. Use committed\nrecovery frames as the currency of risk (whiffing a heavy attack should hurt). If\nplayers report the game feeling \"laggy,\" diagnose whether it's true acknowledgment\nlatency (a defect — fix per FEEL-0002) or commitment they're reading as lag (a feature —\ncommunicate it better via anticipation and telegraphing).\n\n## Disagreement\nThis is the domain's central productive tension, and it is why this entry\n`conflicts_with` FEEL-0002:\n\n- **Responsiveness-maximalist:** every frame of delay is an enemy; the avatar should be\n  a frictionless extension of the player (platformers, twitch shooters, Devil May\n  Cry–style flow).\n- **Commitment-maximalist:** weight, consequence, and deliberate pacing require actions\n  that can't be instantly taken back (Souls games, Monster Hunter, fighting-game\n  recovery frames).\n\n**Reconciliation (both accept):** the conflict dissolves once you split *acknowledgment*\nlatency from *resolution* time. Acknowledgment should always be near-instant (FEEL-0002\nholds absolutely); resolution time is the dial this principle governs. A great weighty\ngame and a great snappy game both register your input on frame one — they differ only in\nhow long the world takes to answer.\n\n## Notes\nThe `conflicts_with: FEEL-0002` edge is deliberate and is the pilot's demonstration of\nhow the constitution preserves and *resolves* disagreement rather than flattening it. Its\nanimation-domain expressions are ANIM-0002 (responsiveness beats fidelity / cancel windows)\nand ANIM-0004 (root-motion vs. code-driven). Confidence 4. *(2026-07-15: the weak community\nsource was retired and replaced with Cooper's* Game Anim*, a proper primary for the\nanimation-priority/commitment mechanism.)*\n","searchText":"gdc-l1-feel-0008 place the game deliberately on the responsiveness–commitment axis responsiveness commitment weight combat risk-reward > how long an action takes to resolve once committed — its wind-up, follow-through, and cancelability — is a primary design lever, not a bug to minimize. choose the game's position on the axis from \"instantly cancelable and snappy\" to \"fully committed and weighty\" deliberately, to serve the intended fantasy and risk/reward. responsiveness (feel-0002) says the game must hear you instantly. this principle is about how fast it acts — and here more speed is not always better. commitment — animations that must play out, actions you can't cancel — is what creates weight, consequence, and readable risk/reward, and it is implemented as animation priority: an action holds control until a designated frame, a lever the animator controls [s-cooper-game-anim]. deliberate attack and dodge commitment (as in weapon-based souls-likes, or monster hunter's extreme swing commitment) is core to the tension and mastery of such combat. that \"heavy\" feel is designed, not a latency defect: the player is heard instantly (input is registered and buffered) but the modeled action honors its own timing. position on this axis defines whole combat identities: twitch-cancelable character-action vs. deliberate weapon-based souls-likes. any game with meaningful action timing, especially combat, and anywhere risk/reward should come from committing to actions. the choice sets the game's core rhythm. games whose fantasy is pure speed and flow (fast movement shooters, hyper-agile character-action) legitimately sit at the fully-responsive end and minimize commitment. there is no universally correct point — only a correct point for a given intended feel. separate the two latencies explicitly: always acknowledge input on frame one (buffer it, show anticipation), then resolve on the action's designed schedule. tune wind-up, active, recovery, and cancel windows as first-class combat parameters. use committed recovery frames as the currency of risk (whiffing a heavy attack should hurt). if players report the game feeling \"laggy,\" diagnose whether it's true acknowledgment latency (a defect — fix per feel-0002) or commitment they're reading as lag (a feature — communicate it better via anticipation and telegraphing). this is the domain's central productive tension, and it is why this entry conflictswith feel-0002: - responsiveness-maximalist: every frame of delay is an enemy; the avatar should be a frictionless extension of the player (platformers, twitch shooters, devil may cry–style flow). - commitment-maximalist: weight, consequence, and deliberate pacing require actions that can't be instantly taken back (souls games, monster hunter, fighting-game recovery frames). reconciliation (both accept): the conflict dissolves once you split acknowledgment latency from resolution time. acknowledgment should always be near-instant (feel-0002 holds absolutely); resolution time is the dial this principle governs. a great weighty game and a great snappy game both register your input on frame one — they differ only in how long the world takes to answer. the conflictswith: feel-0002 edge is deliberate and is the pilot's demonstration of how the constitution preserves and resolves disagreement rather than flattening it. its animation-domain expressions are anim-0002 (responsiveness beats fidelity / cancel windows) and anim-0004 (root-motion vs. code-driven). confidence 4. (2026-07-15: the weak community source was retired and replaced with cooper's game anim, a proper primary for the animation-priority/commitment mechanism.)"}
{"id":"GDC-L1-SYS-0001","title":"Build around a core loop and make it satisfying in isolation","layer":"L1","domain":"SYS","subdomain":"core-loop","type":"objective","confidence":4,"status":"canonical","tags":["core-loop","iteration","prototyping","systems-thinking"],"related":["GDC-L1-FEEL-0001","GDC-L1-DESIGN-0003","GDC-L1-SYS-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-cook-loops-arcs","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-SYS-0001.md","statement":"Identify the core loop — the tight cycle of action, simulation, and feedback the player repeats most often — and make it satisfying on its own, before layering content, progression, or meta-systems on top. If the core loop isn't fun in isolation, nothing built on it will be.","sections":{"Statement":"> Identify the core loop — the tight cycle of action, simulation, and feedback the\n> player repeats most often — and make it satisfying on its own, before layering\n> content, progression, or meta-systems on top. If the core loop isn't fun in isolation,\n> nothing built on it will be.","Rationale":"Play is structured as nested loops, and the innermost loop is executed thousands of\ntimes across a playthrough [S-cook-loops-arcs]. Because it repeats so often, any deficit\nin the core loop compounds: a moment that is merely \"fine\" the first time becomes tedious\nthe thousandth. Conversely, a core loop that is intrinsically satisfying carries the game\neven when surrounding systems are thin. Everything outside the loop — progression,\nnarrative, content variety — exists to *feed, vary, and frame* the loop, not to\nsubstitute for it. This is why prototypes should prove the loop first.","Applies when":"Any game with a repeated central activity — which is nearly all of them (shooting/moving,\nmatching, building, negotiating, exploring). It is the first thing to prototype and the\nlast thing you can afford to get wrong.","Does not apply / Exceptions":"Highly authored, one-shot experiences (some narrative and art games) may have no single\ndominant loop, distributing their value across unique moments instead. Even there,\nmicro-loops exist (read → choose → see consequence), but the \"perfect the core loop\nfirst\" emphasis is weaker when repetition isn't the point.","Implementation (kept separate from the principle)":"Name the core loop explicitly (\"aim → shoot → react → reposition\"). Prototype it in\ngreybox with no content and ask: is this fun for five minutes with nothing else? Tune its\nfeel (see FEEL domain) before building progression around it. Layer secondary loops\n(session, meta, social) only once the core holds. If playtesters get bored fast, fix the\nloop, not the content.","Disagreement":"No serious disagreement that a strong core loop matters; debate is only about how much a\nbrilliant surrounding structure can carry a mediocre loop (rarely far) — an argument that\nresolves in this principle's favor for replay-driven games.","Notes":"The core loop is where SYS, FEEL, and DESIGN meet: FEEL-0001 governs how the loop *feels* moment-to-moment, DESIGN-0003 governs how it *teaches*, and this principle governs its primacy. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-SYS-0001\ntitle: Build around a core loop and make it satisfying in isolation\nlayer: L1\ndomain: SYS\nsubdomain: core-loop\ntype: objective\nconfidence: 4\nstatus: canonical\ntags:\n  - core-loop\n  - iteration\n  - prototyping\n  - systems-thinking\nrelated:\n  - GDC-L1-FEEL-0001\n  - GDC-L1-DESIGN-0003\n  - GDC-L1-SYS-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-cook-loops-arcs\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Identify the core loop — the tight cycle of action, simulation, and feedback the\n> player repeats most often — and make it satisfying on its own, before layering\n> content, progression, or meta-systems on top. If the core loop isn't fun in isolation,\n> nothing built on it will be.\n\n## Rationale\nPlay is structured as nested loops, and the innermost loop is executed thousands of\ntimes across a playthrough [S-cook-loops-arcs]. Because it repeats so often, any deficit\nin the core loop compounds: a moment that is merely \"fine\" the first time becomes tedious\nthe thousandth. Conversely, a core loop that is intrinsically satisfying carries the game\neven when surrounding systems are thin. Everything outside the loop — progression,\nnarrative, content variety — exists to *feed, vary, and frame* the loop, not to\nsubstitute for it. This is why prototypes should prove the loop first.\n\n## Applies when\nAny game with a repeated central activity — which is nearly all of them (shooting/moving,\nmatching, building, negotiating, exploring). It is the first thing to prototype and the\nlast thing you can afford to get wrong.\n\n## Does not apply / Exceptions\nHighly authored, one-shot experiences (some narrative and art games) may have no single\ndominant loop, distributing their value across unique moments instead. Even there,\nmicro-loops exist (read → choose → see consequence), but the \"perfect the core loop\nfirst\" emphasis is weaker when repetition isn't the point.\n\n## Implementation (kept separate from the principle)\nName the core loop explicitly (\"aim → shoot → react → reposition\"). Prototype it in\ngreybox with no content and ask: is this fun for five minutes with nothing else? Tune its\nfeel (see FEEL domain) before building progression around it. Layer secondary loops\n(session, meta, social) only once the core holds. If playtesters get bored fast, fix the\nloop, not the content.\n\n## Disagreement\nNo serious disagreement that a strong core loop matters; debate is only about how much a\nbrilliant surrounding structure can carry a mediocre loop (rarely far) — an argument that\nresolves in this principle's favor for replay-driven games.\n\n## Notes\nThe core loop is where SYS, FEEL, and DESIGN meet: FEEL-0001 governs how the loop *feels* moment-to-moment, DESIGN-0003 governs how it *teaches*, and this principle governs its primacy. Confidence 4.\n","searchText":"gdc-l1-sys-0001 build around a core loop and make it satisfying in isolation core-loop iteration prototyping systems-thinking > identify the core loop — the tight cycle of action, simulation, and feedback the player repeats most often — and make it satisfying on its own, before layering content, progression, or meta-systems on top. if the core loop isn't fun in isolation, nothing built on it will be. play is structured as nested loops, and the innermost loop is executed thousands of times across a playthrough [s-cook-loops-arcs]. because it repeats so often, any deficit in the core loop compounds: a moment that is merely \"fine\" the first time becomes tedious the thousandth. conversely, a core loop that is intrinsically satisfying carries the game even when surrounding systems are thin. everything outside the loop — progression, narrative, content variety — exists to feed, vary, and frame the loop, not to substitute for it. this is why prototypes should prove the loop first. any game with a repeated central activity — which is nearly all of them (shooting/moving, matching, building, negotiating, exploring). it is the first thing to prototype and the last thing you can afford to get wrong. highly authored, one-shot experiences (some narrative and art games) may have no single dominant loop, distributing their value across unique moments instead. even there, micro-loops exist (read → choose → see consequence), but the \"perfect the core loop first\" emphasis is weaker when repetition isn't the point. name the core loop explicitly (\"aim → shoot → react → reposition\"). prototype it in greybox with no content and ask: is this fun for five minutes with nothing else? tune its feel (see feel domain) before building progression around it. layer secondary loops (session, meta, social) only once the core holds. if playtesters get bored fast, fix the loop, not the content. no serious disagreement that a strong core loop matters; debate is only about how much a brilliant surrounding structure can carry a mediocre loop (rarely far) — an argument that resolves in this principle's favor for replay-driven games. the core loop is where sys, feel, and design meet: feel-0001 governs how the loop feels moment-to-moment, design-0003 governs how it teaches, and this principle governs its primacy. confidence 4."}
{"id":"GDC-L1-SYS-0002","title":"Design second-order — author the rules, not the outcomes","layer":"L1","domain":"SYS","subdomain":"systems-thinking","type":"objective","confidence":5,"status":"canonical","tags":["systems-thinking","second-order-design","emergence","mda"],"related":["GDC-L1-DESIGN-0001","GDC-L1-SYS-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-salen-zimmerman-rulesofplay","S-hunicke-mda"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-SYS-0002.md","statement":"A game designer cannot directly design play — only the rules that give rise to it. Treat the system as the object you author and the player's experience as a second-order effect you steer indirectly, by tuning rules, incentives, and feedback and then observing what emerges.","sections":{"Statement":"> A game designer cannot directly design play — only the rules that give rise to it.\n> Treat the *system* as the object you author and the player's experience as a\n> second-order effect you steer indirectly, by tuning rules, incentives, and feedback and\n> then observing what emerges.","Rationale":"Designers work at the mechanics end of the chain; players receive the aesthetics end, and\nthe dynamics in between are produced by play, not authored directly [S-hunicke-mda]. This\nis the \"second-order design problem\": experience is created only indirectly\n[S-salen-zimmerman-rulesofplay]. The practical consequence is humility and method — you\npropose rules, the system and its players dispose, and you learn what you actually built\nby watching it run (which is why this depends on judging by the experience produced,\nDESIGN-0001). Designers who forget this try to script outcomes and are repeatedly\nsurprised when players route around their intentions.","Applies when":"All systemic design: rules, economies, AI, progression, multiplayer. The more systemic\nand less scripted the game, the more this dominates.","Does not apply / Exceptions":"Not an exception so much as a boundary: the more heavily *authored* and linear a moment\nis (a scripted set-piece, a cutscene), the more directly the designer controls the\nexperience and the less second-order it is. Even then, the player's *response* remains\nsecond-order — you author the stimulus, not the feeling.","Implementation (kept separate from the principle)":"Design incentives and constraints, then playtest to discover the actual dynamics; expect\nsurprises and treat them as data. Build tunable systems with exposed parameters so you can\nsteer emergent behavior without rewriting. Ask \"what will players do with this?\" not \"what\ndo I want players to do?\" Instrument and observe (telemetry, playtests) because you cannot\ndeduce second-order behavior from first principles alone.","Disagreement":"Foundational and essentially uncontested as a description of how design works; it is the\nconceptual basis of systemic and emergent design. No credible counter-position.","Notes":"The theoretical backbone of the whole SYS domain and a direct partner to DESIGN-0001.\nConfidence 5."},"rawMarkdown":"---\nid: GDC-L1-SYS-0002\ntitle: Design second-order — author the rules, not the outcomes\nlayer: L1\ndomain: SYS\nsubdomain: systems-thinking\ntype: objective\nconfidence: 5\nstatus: canonical\ntags:\n  - systems-thinking\n  - second-order-design\n  - emergence\n  - mda\nrelated:\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-SYS-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-salen-zimmerman-rulesofplay\n  - S-hunicke-mda\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A game designer cannot directly design play — only the rules that give rise to it.\n> Treat the *system* as the object you author and the player's experience as a\n> second-order effect you steer indirectly, by tuning rules, incentives, and feedback and\n> then observing what emerges.\n\n## Rationale\nDesigners work at the mechanics end of the chain; players receive the aesthetics end, and\nthe dynamics in between are produced by play, not authored directly [S-hunicke-mda]. This\nis the \"second-order design problem\": experience is created only indirectly\n[S-salen-zimmerman-rulesofplay]. The practical consequence is humility and method — you\npropose rules, the system and its players dispose, and you learn what you actually built\nby watching it run (which is why this depends on judging by the experience produced,\nDESIGN-0001). Designers who forget this try to script outcomes and are repeatedly\nsurprised when players route around their intentions.\n\n## Applies when\nAll systemic design: rules, economies, AI, progression, multiplayer. The more systemic\nand less scripted the game, the more this dominates.\n\n## Does not apply / Exceptions\nNot an exception so much as a boundary: the more heavily *authored* and linear a moment\nis (a scripted set-piece, a cutscene), the more directly the designer controls the\nexperience and the less second-order it is. Even then, the player's *response* remains\nsecond-order — you author the stimulus, not the feeling.\n\n## Implementation (kept separate from the principle)\nDesign incentives and constraints, then playtest to discover the actual dynamics; expect\nsurprises and treat them as data. Build tunable systems with exposed parameters so you can\nsteer emergent behavior without rewriting. Ask \"what will players do with this?\" not \"what\ndo I want players to do?\" Instrument and observe (telemetry, playtests) because you cannot\ndeduce second-order behavior from first principles alone.\n\n## Disagreement\nFoundational and essentially uncontested as a description of how design works; it is the\nconceptual basis of systemic and emergent design. No credible counter-position.\n\n## Notes\nThe theoretical backbone of the whole SYS domain and a direct partner to DESIGN-0001.\nConfidence 5.\n","searchText":"gdc-l1-sys-0002 design second-order — author the rules, not the outcomes systems-thinking second-order-design emergence mda > a game designer cannot directly design play — only the rules that give rise to it. treat the system as the object you author and the player's experience as a second-order effect you steer indirectly, by tuning rules, incentives, and feedback and then observing what emerges. designers work at the mechanics end of the chain; players receive the aesthetics end, and the dynamics in between are produced by play, not authored directly [s-hunicke-mda]. this is the \"second-order design problem\": experience is created only indirectly [s-salen-zimmerman-rulesofplay]. the practical consequence is humility and method — you propose rules, the system and its players dispose, and you learn what you actually built by watching it run (which is why this depends on judging by the experience produced, design-0001). designers who forget this try to script outcomes and are repeatedly surprised when players route around their intentions. all systemic design: rules, economies, ai, progression, multiplayer. the more systemic and less scripted the game, the more this dominates. not an exception so much as a boundary: the more heavily authored and linear a moment is (a scripted set-piece, a cutscene), the more directly the designer controls the experience and the less second-order it is. even then, the player's response remains second-order — you author the stimulus, not the feeling. design incentives and constraints, then playtest to discover the actual dynamics; expect surprises and treat them as data. build tunable systems with exposed parameters so you can steer emergent behavior without rewriting. ask \"what will players do with this?\" not \"what do i want players to do?\" instrument and observe (telemetry, playtests) because you cannot deduce second-order behavior from first principles alone. foundational and essentially uncontested as a description of how design works; it is the conceptual basis of systemic and emergent design. no credible counter-position. the theoretical backbone of the whole sys domain and a direct partner to design-0001. confidence 5."}
{"id":"GDC-L1-SYS-0003","title":"Seek depth through emergence — few rules interacting, not enumerated content","layer":"L1","domain":"SYS","subdomain":"emergence","type":"contextual","confidence":4,"status":"canonical","tags":["emergence","depth","systems-thinking","replayability"],"related":["GDC-L1-DESIGN-0005","GDC-L1-DESIGN-0007","GDC-L1-SYS-0002"],"depends_on":["GDC-L1-SYS-0002"],"conflicts_with":[],"supersedes":[],"sources":["S-salen-zimmerman-rulesofplay","S-adams-dormans-mechanics"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-SYS-0003.md","statement":"Prefer depth that emerges from a few rules interacting over depth authored case-by-case. Emergence — the productive disconnect between simple rules and complex play — yields replayability and player-authored stories that hand-placed content can't match. But emergence must be cultivated and bounded, because the same interactions that create richness also create exploits and chaos.","sections":{"Statement":"> Prefer depth that *emerges* from a few rules interacting over depth authored\n> case-by-case. Emergence — the productive disconnect between simple rules and complex\n> play — yields replayability and player-authored stories that hand-placed content can't\n> match. But emergence must be cultivated and bounded, because the same interactions that\n> create richness also create exploits and chaos.","Rationale":"Emergence is unplanned pattern arising from within a system: a gap between the simplicity\nof the rules and the complexity of what they produce [S-salen-zimmerman-rulesofplay]. It\nis the most *efficient* form of depth — a small, teachable rule set generating a vast\npossibility space (compare DESIGN-0005, easy to learn / hard to master). It is also the\nleast *controllable*: interacting systems produce outcomes the designer never\nenumerated, including degenerate ones. So emergence is not \"free depth\" — it is depth\ntraded against predictability, requiring cultivation (designing rules that interact\nrichly) and bounding (constraints that keep emergence fun rather than broken)\n[S-adams-dormans-mechanics].","Applies when":"Systemic games, sandboxes, strategy, simulation, immersive sims, roguelikes — anywhere\nreplayability and player expression matter more than precisely-paced authored moments.","Does not apply / Exceptions":"Authored, curated experiences deliberately choose *scripted* depth for the control it\ngives over pacing, difficulty, and narrative beats. A tightly-tuned linear campaign or a\nhandcrafted puzzle sequence trades the possibility space of emergence for precision and\nguaranteed quality of each moment — a legitimate and often superior choice for\nstory-driven or set-piece games. Emergence also raises balancing and QA cost sharply.","Implementation (kept separate from the principle)":"Favor mechanics that interact with many others over isolated one-off mechanics (see\nSYS-0005 orthogonality — interaction, not redundancy). Design a few strong, general rules\nrather than many narrow ones. Then *bound* the emergence: playtest for degenerate\nstrategies (SYS-0007) and add constraints that prune the unfun branches without killing\nthe fun ones. Expect to discover the real game by watching it played (SYS-0002).","Disagreement":"The central axis of systems design: **emergent/systemic** design (few deep interacting\nrules; possibility space; player-authored stories) vs. **authored/curated** design (many\ncrafted, controlled moments; precise pacing). Both produce masterpieces; the choice is\nabout whether you want *possibility* or *control*. Most real games blend the two —\nemergent core loop inside an authored frame. Typed `contextual` for exactly this reason.","Notes":"Sits between DESIGN-0005 (accessible depth) and DESIGN-0007 (elegance) on the design side and SYS-0005/0007 on the systems side. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-SYS-0003\ntitle: Seek depth through emergence — few rules interacting, not enumerated content\nlayer: L1\ndomain: SYS\nsubdomain: emergence\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - emergence\n  - depth\n  - systems-thinking\n  - replayability\nrelated:\n  - GDC-L1-DESIGN-0005\n  - GDC-L1-DESIGN-0007\n  - GDC-L1-SYS-0002\ndepends_on:\n  - GDC-L1-SYS-0002\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-salen-zimmerman-rulesofplay\n  - S-adams-dormans-mechanics\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Prefer depth that *emerges* from a few rules interacting over depth authored\n> case-by-case. Emergence — the productive disconnect between simple rules and complex\n> play — yields replayability and player-authored stories that hand-placed content can't\n> match. But emergence must be cultivated and bounded, because the same interactions that\n> create richness also create exploits and chaos.\n\n## Rationale\nEmergence is unplanned pattern arising from within a system: a gap between the simplicity\nof the rules and the complexity of what they produce [S-salen-zimmerman-rulesofplay]. It\nis the most *efficient* form of depth — a small, teachable rule set generating a vast\npossibility space (compare DESIGN-0005, easy to learn / hard to master). It is also the\nleast *controllable*: interacting systems produce outcomes the designer never\nenumerated, including degenerate ones. So emergence is not \"free depth\" — it is depth\ntraded against predictability, requiring cultivation (designing rules that interact\nrichly) and bounding (constraints that keep emergence fun rather than broken)\n[S-adams-dormans-mechanics].\n\n## Applies when\nSystemic games, sandboxes, strategy, simulation, immersive sims, roguelikes — anywhere\nreplayability and player expression matter more than precisely-paced authored moments.\n\n## Does not apply / Exceptions\nAuthored, curated experiences deliberately choose *scripted* depth for the control it\ngives over pacing, difficulty, and narrative beats. A tightly-tuned linear campaign or a\nhandcrafted puzzle sequence trades the possibility space of emergence for precision and\nguaranteed quality of each moment — a legitimate and often superior choice for\nstory-driven or set-piece games. Emergence also raises balancing and QA cost sharply.\n\n## Implementation (kept separate from the principle)\nFavor mechanics that interact with many others over isolated one-off mechanics (see\nSYS-0005 orthogonality — interaction, not redundancy). Design a few strong, general rules\nrather than many narrow ones. Then *bound* the emergence: playtest for degenerate\nstrategies (SYS-0007) and add constraints that prune the unfun branches without killing\nthe fun ones. Expect to discover the real game by watching it played (SYS-0002).\n\n## Disagreement\nThe central axis of systems design: **emergent/systemic** design (few deep interacting\nrules; possibility space; player-authored stories) vs. **authored/curated** design (many\ncrafted, controlled moments; precise pacing). Both produce masterpieces; the choice is\nabout whether you want *possibility* or *control*. Most real games blend the two —\nemergent core loop inside an authored frame. Typed `contextual` for exactly this reason.\n\n## Notes\nSits between DESIGN-0005 (accessible depth) and DESIGN-0007 (elegance) on the design side and SYS-0005/0007 on the systems side. Confidence 4.\n","searchText":"gdc-l1-sys-0003 seek depth through emergence — few rules interacting, not enumerated content emergence depth systems-thinking replayability > prefer depth that emerges from a few rules interacting over depth authored case-by-case. emergence — the productive disconnect between simple rules and complex play — yields replayability and player-authored stories that hand-placed content can't match. but emergence must be cultivated and bounded, because the same interactions that create richness also create exploits and chaos. emergence is unplanned pattern arising from within a system: a gap between the simplicity of the rules and the complexity of what they produce [s-salen-zimmerman-rulesofplay]. it is the most efficient form of depth — a small, teachable rule set generating a vast possibility space (compare design-0005, easy to learn / hard to master). it is also the least controllable: interacting systems produce outcomes the designer never enumerated, including degenerate ones. so emergence is not \"free depth\" — it is depth traded against predictability, requiring cultivation (designing rules that interact richly) and bounding (constraints that keep emergence fun rather than broken) [s-adams-dormans-mechanics]. systemic games, sandboxes, strategy, simulation, immersive sims, roguelikes — anywhere replayability and player expression matter more than precisely-paced authored moments. authored, curated experiences deliberately choose scripted depth for the control it gives over pacing, difficulty, and narrative beats. a tightly-tuned linear campaign or a handcrafted puzzle sequence trades the possibility space of emergence for precision and guaranteed quality of each moment — a legitimate and often superior choice for story-driven or set-piece games. emergence also raises balancing and qa cost sharply. favor mechanics that interact with many others over isolated one-off mechanics (see sys-0005 orthogonality — interaction, not redundancy). design a few strong, general rules rather than many narrow ones. then bound the emergence: playtest for degenerate strategies (sys-0007) and add constraints that prune the unfun branches without killing the fun ones. expect to discover the real game by watching it played (sys-0002). the central axis of systems design: emergent/systemic design (few deep interacting rules; possibility space; player-authored stories) vs. authored/curated design (many crafted, controlled moments; precise pacing). both produce masterpieces; the choice is about whether you want possibility or control. most real games blend the two — emergent core loop inside an authored frame. typed contextual for exactly this reason. sits between design-0005 (accessible depth) and design-0007 (elegance) on the design side and sys-0005/0007 on the systems side. confidence 4."}
{"id":"GDC-L1-SYS-0004","title":"Know your feedback loops — positive loops amplify, negative loops stabilize","layer":"L1","domain":"SYS","subdomain":"feedback-loops","type":"objective","confidence":4,"status":"canonical","tags":["feedback-loops","balance","pacing","systems-thinking"],"related":["GDC-L1-DESIGN-0004","GDC-L1-SYS-0008","GDC-L1-SYS-0007"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-adams-dormans-mechanics"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-SYS-0004.md","statement":"Every dynamic system contains feedback loops, and you must know which ones yours creates. Positive (reinforcing) loops amplify a lead — they accelerate outcomes, snowball advantages, and shorten games. Negative (balancing) loops resist change — they stabilize, enable comebacks, and prolong games. Deploy each deliberately; an unnoticed loop will shape your game whether you designed it or not.","sections":{"Statement":"> Every dynamic system contains feedback loops, and you must know which ones yours\n> creates. **Positive (reinforcing)** loops amplify a lead — they accelerate outcomes,\n> snowball advantages, and shorten games. **Negative (balancing)** loops resist change —\n> they stabilize, enable comebacks, and prolong games. Deploy each deliberately; an\n> unnoticed loop will shape your game whether you designed it or not.","Rationale":"Feedback loops are the deep structure that determines a game's pacing and fairness\n[S-adams-dormans-mechanics]. A positive loop (the winner gains resources that help them\nwin more) makes outcomes decisive and can feel thrilling — or hopeless, once a lead is\ninsurmountable. A negative loop (trailing players get help, leaders get friction) keeps\neveryone in contention and games close — or can feel like it punishes skill and rewards\nmediocrity. Neither is good or bad in itself; each is a tool with a characteristic effect\non drama and duration. The failure is having them by accident: runaway snowballs and\nmushy stalemates are usually *unintended* feedback loops.","Applies when":"Any system with accumulating state: economies, scoring, combat, progression, and\nespecially competitive multiplayer where loop effects are felt most sharply.","Does not apply / Exceptions":"No exception to *understanding* your loops; the contextual part is *how much* of each to\nuse. High-positive-feedback designs (decisive, snowbally) suit short, dramatic matches;\nhigh-negative-feedback designs (catch-up, rubber-banding) suit accessible, everyone-stays-\nin-it experiences. Purely authored/linear content has weaker loop dynamics.","Implementation (kept separate from the principle)":"Diagram resource flows and mark each loop's polarity (economy-modeling tools make this\nvisible). Use positive feedback to resolve games that would otherwise stall; use negative\nfeedback to prevent early leads from becoming boring runaways — but keep catch-up\n*legible* and skill-respecting so it doesn't feel like theft. Test late-game states\nspecifically: is a modest lead already unbeatable (too much positive), or is skill\nirrelevant to the finish (too much negative)?","Disagreement":"Real and mostly about negative feedback / catch-up mechanics: competitive purists resist\nrubber-banding because it dampens skill expression; accessibility- and drama-focused\ndesigners favor it because it keeps all players engaged to the end. Both are right for\ntheir goals; the deciding question is whether the design prioritizes *skill differentiation*\nor *sustained tension for everyone*.","Notes":"Closely tied to SYS-0008 (feedback loops live inside the internal economy) and SYS-0007\n(positive loops are what make optimization snowball). Bridges to DESIGN-0004 (loops shape\nthe difficulty/flow curve). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-SYS-0004\ntitle: Know your feedback loops — positive loops amplify, negative loops stabilize\nlayer: L1\ndomain: SYS\nsubdomain: feedback-loops\ntype: objective\nconfidence: 4\nstatus: canonical\ntags:\n  - feedback-loops\n  - balance\n  - pacing\n  - systems-thinking\nrelated:\n  - GDC-L1-DESIGN-0004\n  - GDC-L1-SYS-0008\n  - GDC-L1-SYS-0007\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-adams-dormans-mechanics\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Every dynamic system contains feedback loops, and you must know which ones yours\n> creates. **Positive (reinforcing)** loops amplify a lead — they accelerate outcomes,\n> snowball advantages, and shorten games. **Negative (balancing)** loops resist change —\n> they stabilize, enable comebacks, and prolong games. Deploy each deliberately; an\n> unnoticed loop will shape your game whether you designed it or not.\n\n## Rationale\nFeedback loops are the deep structure that determines a game's pacing and fairness\n[S-adams-dormans-mechanics]. A positive loop (the winner gains resources that help them\nwin more) makes outcomes decisive and can feel thrilling — or hopeless, once a lead is\ninsurmountable. A negative loop (trailing players get help, leaders get friction) keeps\neveryone in contention and games close — or can feel like it punishes skill and rewards\nmediocrity. Neither is good or bad in itself; each is a tool with a characteristic effect\non drama and duration. The failure is having them by accident: runaway snowballs and\nmushy stalemates are usually *unintended* feedback loops.\n\n## Applies when\nAny system with accumulating state: economies, scoring, combat, progression, and\nespecially competitive multiplayer where loop effects are felt most sharply.\n\n## Does not apply / Exceptions\nNo exception to *understanding* your loops; the contextual part is *how much* of each to\nuse. High-positive-feedback designs (decisive, snowbally) suit short, dramatic matches;\nhigh-negative-feedback designs (catch-up, rubber-banding) suit accessible, everyone-stays-\nin-it experiences. Purely authored/linear content has weaker loop dynamics.\n\n## Implementation (kept separate from the principle)\nDiagram resource flows and mark each loop's polarity (economy-modeling tools make this\nvisible). Use positive feedback to resolve games that would otherwise stall; use negative\nfeedback to prevent early leads from becoming boring runaways — but keep catch-up\n*legible* and skill-respecting so it doesn't feel like theft. Test late-game states\nspecifically: is a modest lead already unbeatable (too much positive), or is skill\nirrelevant to the finish (too much negative)?\n\n## Disagreement\nReal and mostly about negative feedback / catch-up mechanics: competitive purists resist\nrubber-banding because it dampens skill expression; accessibility- and drama-focused\ndesigners favor it because it keeps all players engaged to the end. Both are right for\ntheir goals; the deciding question is whether the design prioritizes *skill differentiation*\nor *sustained tension for everyone*.\n\n## Notes\nClosely tied to SYS-0008 (feedback loops live inside the internal economy) and SYS-0007\n(positive loops are what make optimization snowball). Bridges to DESIGN-0004 (loops shape\nthe difficulty/flow curve). Confidence 4.\n","searchText":"gdc-l1-sys-0004 know your feedback loops — positive loops amplify, negative loops stabilize feedback-loops balance pacing systems-thinking > every dynamic system contains feedback loops, and you must know which ones yours creates. positive (reinforcing) loops amplify a lead — they accelerate outcomes, snowball advantages, and shorten games. negative (balancing) loops resist change — they stabilize, enable comebacks, and prolong games. deploy each deliberately; an unnoticed loop will shape your game whether you designed it or not. feedback loops are the deep structure that determines a game's pacing and fairness [s-adams-dormans-mechanics]. a positive loop (the winner gains resources that help them win more) makes outcomes decisive and can feel thrilling — or hopeless, once a lead is insurmountable. a negative loop (trailing players get help, leaders get friction) keeps everyone in contention and games close — or can feel like it punishes skill and rewards mediocrity. neither is good or bad in itself; each is a tool with a characteristic effect on drama and duration. the failure is having them by accident: runaway snowballs and mushy stalemates are usually unintended feedback loops. any system with accumulating state: economies, scoring, combat, progression, and especially competitive multiplayer where loop effects are felt most sharply. no exception to understanding your loops; the contextual part is how much of each to use. high-positive-feedback designs (decisive, snowbally) suit short, dramatic matches; high-negative-feedback designs (catch-up, rubber-banding) suit accessible, everyone-stays- in-it experiences. purely authored/linear content has weaker loop dynamics. diagram resource flows and mark each loop's polarity (economy-modeling tools make this visible). use positive feedback to resolve games that would otherwise stall; use negative feedback to prevent early leads from becoming boring runaways — but keep catch-up legible and skill-respecting so it doesn't feel like theft. test late-game states specifically: is a modest lead already unbeatable (too much positive), or is skill irrelevant to the finish (too much negative)? real and mostly about negative feedback / catch-up mechanics: competitive purists resist rubber-banding because it dampens skill expression; accessibility- and drama-focused designers favor it because it keeps all players engaged to the end. both are right for their goals; the deciding question is whether the design prioritizes skill differentiation or sustained tension for everyone. closely tied to sys-0008 (feedback loops live inside the internal economy) and sys-0007 (positive loops are what make optimization snowball). bridges to design-0004 (loops shape the difficulty/flow curve). confidence 4."}
{"id":"GDC-L1-SYS-0005","title":"Make systems orthogonal — each earns its place by doing something no other does","layer":"L1","domain":"SYS","subdomain":"complexity-management","type":"contextual","confidence":3,"status":"canonical","tags":["orthogonality","elegance","complexity-management","depth"],"related":["GDC-L1-DESIGN-0007","GDC-L1-DESIGN-0002","GDC-L1-SYS-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-adams-dormans-mechanics","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-SYS-0005.md","statement":"Each system, mechanic, or unit should occupy a distinct role that nothing else fills. When two elements do substantially the same job, one is redundant — merge them, cut one, or differentiate them. Orthogonality maximizes depth per unit of complexity and keeps the player's choices meaningful.","sections":{"Statement":"> Each system, mechanic, or unit should occupy a distinct role that nothing else fills.\n> When two elements do substantially the same job, one is redundant — merge them, cut\n> one, or differentiate them. Orthogonality maximizes depth per unit of complexity and\n> keeps the player's choices meaningful.","Rationale":"Redundant systems are a double cost: they add complexity (to learn, build, balance) while\n*subtracting* meaning, because overlapping options collapse into a dominant one (the\nstrictly-better version wins) or an arbitrary one (indistinguishable, so the choice\ndoesn't matter) — both failure modes from DESIGN-0002. Orthogonal design gives each\nelement a unique axis of purpose, so every system pulls its weight and every choice\nbetween systems is a real tradeoff. This is the systems-level expression of elegance\n(DESIGN-0007): not fewest systems for their own sake, but *no wasted* systems.","Applies when":"Designing sets of parallel elements: weapons, unit rosters, character classes, resource\ntypes, upgrade paths, verbs. Especially valuable when a design feels bloated or when\nplayers ignore large parts of it.","Does not apply / Exceptions":"Deliberate redundancy has uses: overlapping options can serve *expression* and *comfort*\n(different-feeling tools that reach similar outcomes let players pick a style), and some\ngenres value abundance and horizontal variety over strict differentiation. Sidegrades that\nare mechanically similar but aesthetically distinct are a legitimate design. So\northogonality is a strong default, not an absolute — hence `contextual`.","Implementation (kept separate from the principle)":"For each element ask: what does this do that no other element does? If the answer is\n\"nothing,\" differentiate it (give it a unique niche), merge it, or cut it. Map elements\non their functional axes and look for clusters occupying the same point. Prefer giving a\nweak-but-redundant option a *distinct tradeoff* over simply buffing it into a new dominant\nchoice.","Disagreement":"Tension with variety-and-expression design: minimalist orthogonality (every option\nmechanically distinct) vs. expressive abundance (many similar-feeling options for\nplayer self-expression and comfort). Both are valid; competitive and elegance-focused\ndesign leans orthogonal, while sandbox and expression-focused design tolerates more\noverlap.","Notes":"The systems-level companion to DESIGN-0007 (elegance) and DESIGN-0002 (interesting decisions). Confidence 3 — a sound and widely-taught heuristic, but genuinely qualified by expression-driven design."},"rawMarkdown":"---\nid: GDC-L1-SYS-0005\ntitle: Make systems orthogonal — each earns its place by doing something no other does\nlayer: L1\ndomain: SYS\nsubdomain: complexity-management\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - orthogonality\n  - elegance\n  - complexity-management\n  - depth\nrelated:\n  - GDC-L1-DESIGN-0007\n  - GDC-L1-DESIGN-0002\n  - GDC-L1-SYS-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-adams-dormans-mechanics\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Each system, mechanic, or unit should occupy a distinct role that nothing else fills.\n> When two elements do substantially the same job, one is redundant — merge them, cut\n> one, or differentiate them. Orthogonality maximizes depth per unit of complexity and\n> keeps the player's choices meaningful.\n\n## Rationale\nRedundant systems are a double cost: they add complexity (to learn, build, balance) while\n*subtracting* meaning, because overlapping options collapse into a dominant one (the\nstrictly-better version wins) or an arbitrary one (indistinguishable, so the choice\ndoesn't matter) — both failure modes from DESIGN-0002. Orthogonal design gives each\nelement a unique axis of purpose, so every system pulls its weight and every choice\nbetween systems is a real tradeoff. This is the systems-level expression of elegance\n(DESIGN-0007): not fewest systems for their own sake, but *no wasted* systems.\n\n## Applies when\nDesigning sets of parallel elements: weapons, unit rosters, character classes, resource\ntypes, upgrade paths, verbs. Especially valuable when a design feels bloated or when\nplayers ignore large parts of it.\n\n## Does not apply / Exceptions\nDeliberate redundancy has uses: overlapping options can serve *expression* and *comfort*\n(different-feeling tools that reach similar outcomes let players pick a style), and some\ngenres value abundance and horizontal variety over strict differentiation. Sidegrades that\nare mechanically similar but aesthetically distinct are a legitimate design. So\northogonality is a strong default, not an absolute — hence `contextual`.\n\n## Implementation (kept separate from the principle)\nFor each element ask: what does this do that no other element does? If the answer is\n\"nothing,\" differentiate it (give it a unique niche), merge it, or cut it. Map elements\non their functional axes and look for clusters occupying the same point. Prefer giving a\nweak-but-redundant option a *distinct tradeoff* over simply buffing it into a new dominant\nchoice.\n\n## Disagreement\nTension with variety-and-expression design: minimalist orthogonality (every option\nmechanically distinct) vs. expressive abundance (many similar-feeling options for\nplayer self-expression and comfort). Both are valid; competitive and elegance-focused\ndesign leans orthogonal, while sandbox and expression-focused design tolerates more\noverlap.\n\n## Notes\nThe systems-level companion to DESIGN-0007 (elegance) and DESIGN-0002 (interesting decisions). Confidence 3 — a sound and widely-taught heuristic, but genuinely qualified by expression-driven design.\n","searchText":"gdc-l1-sys-0005 make systems orthogonal — each earns its place by doing something no other does orthogonality elegance complexity-management depth > each system, mechanic, or unit should occupy a distinct role that nothing else fills. when two elements do substantially the same job, one is redundant — merge them, cut one, or differentiate them. orthogonality maximizes depth per unit of complexity and keeps the player's choices meaningful. redundant systems are a double cost: they add complexity (to learn, build, balance) while subtracting meaning, because overlapping options collapse into a dominant one (the strictly-better version wins) or an arbitrary one (indistinguishable, so the choice doesn't matter) — both failure modes from design-0002. orthogonal design gives each element a unique axis of purpose, so every system pulls its weight and every choice between systems is a real tradeoff. this is the systems-level expression of elegance (design-0007): not fewest systems for their own sake, but no wasted systems. designing sets of parallel elements: weapons, unit rosters, character classes, resource types, upgrade paths, verbs. especially valuable when a design feels bloated or when players ignore large parts of it. deliberate redundancy has uses: overlapping options can serve expression and comfort (different-feeling tools that reach similar outcomes let players pick a style), and some genres value abundance and horizontal variety over strict differentiation. sidegrades that are mechanically similar but aesthetically distinct are a legitimate design. so orthogonality is a strong default, not an absolute — hence contextual. for each element ask: what does this do that no other element does? if the answer is \"nothing,\" differentiate it (give it a unique niche), merge it, or cut it. map elements on their functional axes and look for clusters occupying the same point. prefer giving a weak-but-redundant option a distinct tradeoff over simply buffing it into a new dominant choice. tension with variety-and-expression design: minimalist orthogonality (every option mechanically distinct) vs. expressive abundance (many similar-feeling options for player self-expression and comfort). both are valid; competitive and elegance-focused design leans orthogonal, while sandbox and expression-focused design tolerates more overlap. the systems-level companion to design-0007 (elegance) and design-0002 (interesting decisions). confidence 3 — a sound and widely-taught heuristic, but genuinely qualified by expression-driven design."}
{"id":"GDC-L1-SYS-0006","title":"Make systems legible — expose enough state for players to form and test hypotheses","layer":"L1","domain":"SYS","subdomain":"systems-thinking","type":"contextual","confidence":4,"status":"canonical","tags":["legibility","feedback","systems-thinking","player-centric","learning"],"related":["GDC-L1-DESIGN-0006","GDC-L1-DESIGN-0003","GDC-L1-FEEL-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-salen-zimmerman-rulesofplay"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-SYS-0006.md","statement":"Players can only engage a system they can read. Surface enough of a system's state and behavior for players to build a mental model, form hypotheses, and see the results of their actions. A system whose cause-and-effect the player cannot perceive produces confusion or superstition, not depth.","sections":{"Statement":"> Players can only engage a system they can read. Surface enough of a system's state and\n> behavior for players to build a mental model, form hypotheses, and see the results of\n> their actions. A system whose cause-and-effect the player cannot perceive produces\n> confusion or superstition, not depth.","Rationale":"Meaningful play requires that the relationship between action and outcome be\n*discernible* and *integrated* — the player must be able to perceive what their action\ndid and how it fits the larger game [S-salen-zimmerman-rulesofplay]. Depth that the\nplayer can't observe is, functionally, not depth: they can't reason about it, so they\ncan't make skillful decisions, and they can't *learn* (which breaks DESIGN-0003, since\nlearning requires readable feedback). When systems are opaque, players fall back on\nguesswork and ritual — attributing outcomes to the wrong causes — and the richest\nunderlying model goes to waste.","Applies when":"Any system the player is expected to master: combat, economy, crafting, AI behavior,\nprogression. The bar rises with how central the system is to skillful play.","Does not apply / Exceptions":"Deliberate opacity is a legitimate tool. Survival, horror, mystery, and discovery-driven\ngames hide systems on purpose — the *not knowing* creates dread, curiosity, or the joy of\nfiguring it out. The key distinction: you may hide the *rule*, but you should still expose\nenough *feedback* that players can learn by experiment. Hidden answer, visible\nconsequences. Fully hiding both rule and feedback produces frustration, not mystery.","Implementation (kept separate from the principle)":"Give systems clear feedback (see FEEL-0004): show what changed and, where appropriate,\nwhy. Prefer readable representations (numbers, states, tells) for systems meant to be\nmastered. When intentionally hiding a rule, compensate with rich observable consequences\nso the player can still test hypotheses. Playtest for superstition — if players\nconsistently misattribute cause and effect, legibility is too low.","Disagreement":"Transparency vs. mystery is a real design axis. Systems-mastery designs (strategy,\nfighting games, sims) push toward maximum legibility; discovery- and atmosphere-driven\ndesigns deliberately obscure. The reconciliation most designers accept: match legibility\nto whether the system is meant to be *mastered* (expose it) or *discovered/feared* (hide\nthe rule, keep the feedback).","Notes":""},"rawMarkdown":"---\nid: GDC-L1-SYS-0006\ntitle: Make systems legible — expose enough state for players to form and test hypotheses\nlayer: L1\ndomain: SYS\nsubdomain: systems-thinking\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - legibility\n  - feedback\n  - systems-thinking\n  - player-centric\n  - learning\nrelated:\n  - GDC-L1-DESIGN-0006\n  - GDC-L1-DESIGN-0003\n  - GDC-L1-FEEL-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-salen-zimmerman-rulesofplay\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Players can only engage a system they can read. Surface enough of a system's state and\n> behavior for players to build a mental model, form hypotheses, and see the results of\n> their actions. A system whose cause-and-effect the player cannot perceive produces\n> confusion or superstition, not depth.\n\n## Rationale\nMeaningful play requires that the relationship between action and outcome be\n*discernible* and *integrated* — the player must be able to perceive what their action\ndid and how it fits the larger game [S-salen-zimmerman-rulesofplay]. Depth that the\nplayer can't observe is, functionally, not depth: they can't reason about it, so they\ncan't make skillful decisions, and they can't *learn* (which breaks DESIGN-0003, since\nlearning requires readable feedback). When systems are opaque, players fall back on\nguesswork and ritual — attributing outcomes to the wrong causes — and the richest\nunderlying model goes to waste.\n\n## Applies when\nAny system the player is expected to master: combat, economy, crafting, AI behavior,\nprogression. The bar rises with how central the system is to skillful play.\n\n## Does not apply / Exceptions\nDeliberate opacity is a legitimate tool. Survival, horror, mystery, and discovery-driven\ngames hide systems on purpose — the *not knowing* creates dread, curiosity, or the joy of\nfiguring it out. The key distinction: you may hide the *rule*, but you should still expose\nenough *feedback* that players can learn by experiment. Hidden answer, visible\nconsequences. Fully hiding both rule and feedback produces frustration, not mystery.\n\n## Implementation (kept separate from the principle)\nGive systems clear feedback (see FEEL-0004): show what changed and, where appropriate,\nwhy. Prefer readable representations (numbers, states, tells) for systems meant to be\nmastered. When intentionally hiding a rule, compensate with rich observable consequences\nso the player can still test hypotheses. Playtest for superstition — if players\nconsistently misattribute cause and effect, legibility is too low.\n\n## Disagreement\nTransparency vs. mystery is a real design axis. Systems-mastery designs (strategy,\nfighting games, sims) push toward maximum legibility; discovery- and atmosphere-driven\ndesigns deliberately obscure. The reconciliation most designers accept: match legibility\nto whether the system is meant to be *mastered* (expose it) or *discovered/feared* (hide\nthe rule, keep the feedback).\n\n## Notes\n","searchText":"gdc-l1-sys-0006 make systems legible — expose enough state for players to form and test hypotheses legibility feedback systems-thinking player-centric learning > players can only engage a system they can read. surface enough of a system's state and behavior for players to build a mental model, form hypotheses, and see the results of their actions. a system whose cause-and-effect the player cannot perceive produces confusion or superstition, not depth. meaningful play requires that the relationship between action and outcome be discernible and integrated — the player must be able to perceive what their action did and how it fits the larger game [s-salen-zimmerman-rulesofplay]. depth that the player can't observe is, functionally, not depth: they can't reason about it, so they can't make skillful decisions, and they can't learn (which breaks design-0003, since learning requires readable feedback). when systems are opaque, players fall back on guesswork and ritual — attributing outcomes to the wrong causes — and the richest underlying model goes to waste. any system the player is expected to master: combat, economy, crafting, ai behavior, progression. the bar rises with how central the system is to skillful play. deliberate opacity is a legitimate tool. survival, horror, mystery, and discovery-driven games hide systems on purpose — the not knowing creates dread, curiosity, or the joy of figuring it out. the key distinction: you may hide the rule, but you should still expose enough feedback that players can learn by experiment. hidden answer, visible consequences. fully hiding both rule and feedback produces frustration, not mystery. give systems clear feedback (see feel-0004): show what changed and, where appropriate, why. prefer readable representations (numbers, states, tells) for systems meant to be mastered. when intentionally hiding a rule, compensate with rich observable consequences so the player can still test hypotheses. playtest for superstition — if players consistently misattribute cause and effect, legibility is too low. transparency vs. mystery is a real design axis. systems-mastery designs (strategy, fighting games, sims) push toward maximum legibility; discovery- and atmosphere-driven designs deliberately obscure. the reconciliation most designers accept: match legibility to whether the system is meant to be mastered (expose it) or discovered/feared (hide the rule, keep the feedback)."}
{"id":"GDC-L1-SYS-0007","title":"Players optimize the fun out — protect the experience from degenerate strategies","layer":"L1","domain":"SYS","subdomain":"systems-thinking","type":"contextual","confidence":4,"status":"canonical","tags":["degenerate-strategy","dominant-strategy","balance","player-centric"],"related":["GDC-L1-DESIGN-0002","GDC-L1-SYS-0004","GDC-L1-SYS-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-soren-johnson-optimize","S-meier-interesting-decisions"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-SYS-0007.md","statement":"Given the opportunity, players will optimize the fun out of a game — they will find and repeat the most efficient path even when it makes their own experience worse. Anticipate degenerate and dominant strategies, and shape constraints and incentives so that the fun path stays the effective path. Part of the designer's job is to protect players from themselves.","sections":{"Statement":"> Given the opportunity, players will optimize the fun out of a game — they will find and\n> repeat the most efficient path even when it makes their own experience worse. Anticipate\n> degenerate and dominant strategies, and shape constraints and incentives so that the fun\n> path stays the effective path. Part of the designer's job is to protect players from\n> themselves.","Rationale":"Players under challenge seek efficiency, and once a clearly-best strategy exists, many\nwill grind it regardless of enjoyment, then experience the resulting monotony as the\ngame's fault [S-soren-johnson-optimize]. A designer cannot rely on players to\nself-restrain toward fun; the incentive gradient wins. This is why \"protecting the player\nfrom themselves\" is a real responsibility [S-meier-interesting-decisions]. The lever is\nthe *incentive structure*: if the optimal action is also boring, players will take it and\nsuffer — so the design must ensure the engaging way to play is also (at least\ncompetitively) the rewarding way.","Applies when":"Any game with optimizable systems and a persistent player incentive to win, progress, or\naccumulate — RPG builds, strategy, competitive play, progression and grind systems,\neconomies.","Does not apply / Exceptions":"Some games make optimization *itself* the fun: incremental/idle games, min-max sandboxes,\nand puzzle-optimization games are *about* finding the efficient path, and there the\noptimization pressure is the point rather than a threat. The principle inverts there —\ngive players a rich optimization space rather than protecting them from it. Elsewhere,\nbeware over-constraining: railroading players away from all efficiency can feel\npatronizing.","Implementation (kept separate from the principle)":"Hunt for dominant strategies in playtest and remove them (buff alternatives, add costs,\nintroduce situational counters — see DESIGN-0002). Avoid incentive structures that reward\ntedium (e.g. grinding a safe, dull action for optimal returns); make the exciting option\nalso the rewarding one. Watch feedback loops (SYS-0004): positive loops are what let a\nsingle optimal strategy snowball into the only strategy. Use soft constraints (diminishing\nreturns, variety incentives) to keep the fun path competitive.","Disagreement":"Mostly about *how much* to intervene. Systemic-freedom advocates warn that\nover-protecting players removes agency and the satisfaction of finding your own path;\nexperience-protection advocates note that unchecked optimization reliably flattens games.\nThe synthesis: shape incentives so the fun path is viable, but don't wall off exploration\nentirely — protect the experience, don't confiscate the agency.","Notes":"The systems-level enforcement mechanism behind DESIGN-0002 (interesting decisions). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-SYS-0007\ntitle: Players optimize the fun out — protect the experience from degenerate strategies\nlayer: L1\ndomain: SYS\nsubdomain: systems-thinking\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - degenerate-strategy\n  - dominant-strategy\n  - balance\n  - player-centric\nrelated:\n  - GDC-L1-DESIGN-0002\n  - GDC-L1-SYS-0004\n  - GDC-L1-SYS-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-soren-johnson-optimize\n  - S-meier-interesting-decisions\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Given the opportunity, players will optimize the fun out of a game — they will find and\n> repeat the most efficient path even when it makes their own experience worse. Anticipate\n> degenerate and dominant strategies, and shape constraints and incentives so that the fun\n> path stays the effective path. Part of the designer's job is to protect players from\n> themselves.\n\n## Rationale\nPlayers under challenge seek efficiency, and once a clearly-best strategy exists, many\nwill grind it regardless of enjoyment, then experience the resulting monotony as the\ngame's fault [S-soren-johnson-optimize]. A designer cannot rely on players to\nself-restrain toward fun; the incentive gradient wins. This is why \"protecting the player\nfrom themselves\" is a real responsibility [S-meier-interesting-decisions]. The lever is\nthe *incentive structure*: if the optimal action is also boring, players will take it and\nsuffer — so the design must ensure the engaging way to play is also (at least\ncompetitively) the rewarding way.\n\n## Applies when\nAny game with optimizable systems and a persistent player incentive to win, progress, or\naccumulate — RPG builds, strategy, competitive play, progression and grind systems,\neconomies.\n\n## Does not apply / Exceptions\nSome games make optimization *itself* the fun: incremental/idle games, min-max sandboxes,\nand puzzle-optimization games are *about* finding the efficient path, and there the\noptimization pressure is the point rather than a threat. The principle inverts there —\ngive players a rich optimization space rather than protecting them from it. Elsewhere,\nbeware over-constraining: railroading players away from all efficiency can feel\npatronizing.\n\n## Implementation (kept separate from the principle)\nHunt for dominant strategies in playtest and remove them (buff alternatives, add costs,\nintroduce situational counters — see DESIGN-0002). Avoid incentive structures that reward\ntedium (e.g. grinding a safe, dull action for optimal returns); make the exciting option\nalso the rewarding one. Watch feedback loops (SYS-0004): positive loops are what let a\nsingle optimal strategy snowball into the only strategy. Use soft constraints (diminishing\nreturns, variety incentives) to keep the fun path competitive.\n\n## Disagreement\nMostly about *how much* to intervene. Systemic-freedom advocates warn that\nover-protecting players removes agency and the satisfaction of finding your own path;\nexperience-protection advocates note that unchecked optimization reliably flattens games.\nThe synthesis: shape incentives so the fun path is viable, but don't wall off exploration\nentirely — protect the experience, don't confiscate the agency.\n\n## Notes\nThe systems-level enforcement mechanism behind DESIGN-0002 (interesting decisions). Confidence 4.\n","searchText":"gdc-l1-sys-0007 players optimize the fun out — protect the experience from degenerate strategies degenerate-strategy dominant-strategy balance player-centric > given the opportunity, players will optimize the fun out of a game — they will find and repeat the most efficient path even when it makes their own experience worse. anticipate degenerate and dominant strategies, and shape constraints and incentives so that the fun path stays the effective path. part of the designer's job is to protect players from themselves. players under challenge seek efficiency, and once a clearly-best strategy exists, many will grind it regardless of enjoyment, then experience the resulting monotony as the game's fault [s-soren-johnson-optimize]. a designer cannot rely on players to self-restrain toward fun; the incentive gradient wins. this is why \"protecting the player from themselves\" is a real responsibility [s-meier-interesting-decisions]. the lever is the incentive structure: if the optimal action is also boring, players will take it and suffer — so the design must ensure the engaging way to play is also (at least competitively) the rewarding way. any game with optimizable systems and a persistent player incentive to win, progress, or accumulate — rpg builds, strategy, competitive play, progression and grind systems, economies. some games make optimization itself the fun: incremental/idle games, min-max sandboxes, and puzzle-optimization games are about finding the efficient path, and there the optimization pressure is the point rather than a threat. the principle inverts there — give players a rich optimization space rather than protecting them from it. elsewhere, beware over-constraining: railroading players away from all efficiency can feel patronizing. hunt for dominant strategies in playtest and remove them (buff alternatives, add costs, introduce situational counters — see design-0002). avoid incentive structures that reward tedium (e.g. grinding a safe, dull action for optimal returns); make the exciting option also the rewarding one. watch feedback loops (sys-0004): positive loops are what let a single optimal strategy snowball into the only strategy. use soft constraints (diminishing returns, variety incentives) to keep the fun path competitive. mostly about how much to intervene. systemic-freedom advocates warn that over-protecting players removes agency and the satisfaction of finding your own path; experience-protection advocates note that unchecked optimization reliably flattens games. the synthesis: shape incentives so the fun path is viable, but don't wall off exploration entirely — protect the experience, don't confiscate the agency. the systems-level enforcement mechanism behind design-0002 (interesting decisions). confidence 4."}
{"id":"GDC-L1-SYS-0008","title":"Model resources as an internal economy — mind the sources, sinks, and flows","layer":"L1","domain":"SYS","subdomain":"interlocking-systems","type":"objective","confidence":4,"status":"canonical","tags":["internal-economy","resources","pacing","balance","systems-thinking"],"related":["GDC-L1-SYS-0004","GDC-L1-DESIGN-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-adams-dormans-mechanics"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-SYS-0008.md","statement":"Treat every resource in the game — currency, health, ammo, time, XP, materials — as part of an internal economy of sources (where resources enter), sinks (where they leave), and converters (where one becomes another). The rates of flow through this economy govern pacing, difficulty, and progression; many problems that look like content problems are actually flow problems.","sections":{"Statement":"> Treat every resource in the game — currency, health, ammo, time, XP, materials — as\n> part of an internal economy of **sources** (where resources enter), **sinks** (where\n> they leave), and **converters** (where one becomes another). The *rates of flow* through\n> this economy govern pacing, difficulty, and progression; many problems that look like\n> content problems are actually flow problems.","Rationale":"An internal economy is the connective tissue that turns isolated mechanics into a\nsystem, and its structure — the balance of sources against sinks — is what generates\nchallenge and paces progression [S-adams-dormans-mechanics]. When a game feels too easy,\ntoo grindy, too rich, or too starved, the cause is usually an imbalance in flow: a source\noutpacing its sinks (runaway accumulation, trivialized challenge) or sinks outpacing\nsources (starvation, grind). Seeing resources as an economy makes these diagnosable and\ntunable at the level of *rates*, rather than as a pile of unrelated numbers.","Applies when":"Any game with accumulating or spent resources — which is almost all of them. Essential\nfor RPGs, strategy, survival, simulation, and any game with progression or crafting.","Does not apply / Exceptions":"Games with minimal or no resource accumulation (pure skill/action games, many puzzle\ngames) have thin economies where this lens adds little. Even there, \"attention\" and\n\"time\" can be modeled as resources, but the framework earns its keep only when flows are\nsubstantial.","Implementation (kept separate from the principle)":"Enumerate each resource's sources, sinks, and converters, and reason about *rates*, not\njust totals. Model or diagram the flows (economy-simulation tools exist for this) to spot\nrunaway accumulation or starvation before players do. Tune pacing by adjusting flow rates\nrather than bolting on content. Watch for feedback loops inside the economy (SYS-0004),\nwhere a resource feeds a source of itself and snowballs.","Disagreement":"No serious disagreement on the framework's usefulness where economies are substantial;\ndebate lives one level down (how much scarcity, how fast progression) and belongs to the\nECON and BAL domains.","Notes":"Partners with SYS-0004 (feedback loops are the dynamics *of* the economy) and bridges to the future ECON and BAL domains, which will treat currencies, scarcity, and tuning in depth. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-SYS-0008\ntitle: Model resources as an internal economy — mind the sources, sinks, and flows\nlayer: L1\ndomain: SYS\nsubdomain: interlocking-systems\ntype: objective\nconfidence: 4\nstatus: canonical\ntags:\n  - internal-economy\n  - resources\n  - pacing\n  - balance\n  - systems-thinking\nrelated:\n  - GDC-L1-SYS-0004\n  - GDC-L1-DESIGN-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-adams-dormans-mechanics\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Treat every resource in the game — currency, health, ammo, time, XP, materials — as\n> part of an internal economy of **sources** (where resources enter), **sinks** (where\n> they leave), and **converters** (where one becomes another). The *rates of flow* through\n> this economy govern pacing, difficulty, and progression; many problems that look like\n> content problems are actually flow problems.\n\n## Rationale\nAn internal economy is the connective tissue that turns isolated mechanics into a\nsystem, and its structure — the balance of sources against sinks — is what generates\nchallenge and paces progression [S-adams-dormans-mechanics]. When a game feels too easy,\ntoo grindy, too rich, or too starved, the cause is usually an imbalance in flow: a source\noutpacing its sinks (runaway accumulation, trivialized challenge) or sinks outpacing\nsources (starvation, grind). Seeing resources as an economy makes these diagnosable and\ntunable at the level of *rates*, rather than as a pile of unrelated numbers.\n\n## Applies when\nAny game with accumulating or spent resources — which is almost all of them. Essential\nfor RPGs, strategy, survival, simulation, and any game with progression or crafting.\n\n## Does not apply / Exceptions\nGames with minimal or no resource accumulation (pure skill/action games, many puzzle\ngames) have thin economies where this lens adds little. Even there, \"attention\" and\n\"time\" can be modeled as resources, but the framework earns its keep only when flows are\nsubstantial.\n\n## Implementation (kept separate from the principle)\nEnumerate each resource's sources, sinks, and converters, and reason about *rates*, not\njust totals. Model or diagram the flows (economy-simulation tools exist for this) to spot\nrunaway accumulation or starvation before players do. Tune pacing by adjusting flow rates\nrather than bolting on content. Watch for feedback loops inside the economy (SYS-0004),\nwhere a resource feeds a source of itself and snowballs.\n\n## Disagreement\nNo serious disagreement on the framework's usefulness where economies are substantial;\ndebate lives one level down (how much scarcity, how fast progression) and belongs to the\nECON and BAL domains.\n\n## Notes\nPartners with SYS-0004 (feedback loops are the dynamics *of* the economy) and bridges to the future ECON and BAL domains, which will treat currencies, scarcity, and tuning in depth. Confidence 4.\n","searchText":"gdc-l1-sys-0008 model resources as an internal economy — mind the sources, sinks, and flows internal-economy resources pacing balance systems-thinking > treat every resource in the game — currency, health, ammo, time, xp, materials — as part of an internal economy of sources (where resources enter), sinks (where they leave), and converters (where one becomes another). the rates of flow through this economy govern pacing, difficulty, and progression; many problems that look like content problems are actually flow problems. an internal economy is the connective tissue that turns isolated mechanics into a system, and its structure — the balance of sources against sinks — is what generates challenge and paces progression [s-adams-dormans-mechanics]. when a game feels too easy, too grindy, too rich, or too starved, the cause is usually an imbalance in flow: a source outpacing its sinks (runaway accumulation, trivialized challenge) or sinks outpacing sources (starvation, grind). seeing resources as an economy makes these diagnosable and tunable at the level of rates, rather than as a pile of unrelated numbers. any game with accumulating or spent resources — which is almost all of them. essential for rpgs, strategy, survival, simulation, and any game with progression or crafting. games with minimal or no resource accumulation (pure skill/action games, many puzzle games) have thin economies where this lens adds little. even there, \"attention\" and \"time\" can be modeled as resources, but the framework earns its keep only when flows are substantial. enumerate each resource's sources, sinks, and converters, and reason about rates, not just totals. model or diagram the flows (economy-simulation tools exist for this) to spot runaway accumulation or starvation before players do. tune pacing by adjusting flow rates rather than bolting on content. watch for feedback loops inside the economy (sys-0004), where a resource feeds a source of itself and snowballs. no serious disagreement on the framework's usefulness where economies are substantial; debate lives one level down (how much scarcity, how fast progression) and belongs to the econ and bal domains. partners with sys-0004 (feedback loops are the dynamics of the economy) and bridges to the future econ and bal domains, which will treat currencies, scarcity, and tuning in depth. confidence 4."}
{"id":"GDC-L1-PROG-0001","title":"Design the power curve deliberately — pace growth against challenge","layer":"L1","domain":"PROG","subdomain":"pacing-of-power","type":"contextual","confidence":4,"status":"canonical","tags":["progression","power-curve","pacing","flow","difficulty"],"related":["GDC-L1-DESIGN-0004","GDC-L1-PROG-0005","GDC-L1-SYS-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-csikszentmihalyi-flow","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROG-0001.md","statement":"Treat the rate at which the player's power grows relative to challenge as a designed curve, not an accident. If power grows too slowly, progress feels absent; too quickly, and the game becomes a cakewalk. Pace power so the player stays near the edge of their ability.","sections":{"Statement":"> Treat the rate at which the player's power grows *relative to challenge* as a designed\n> curve, not an accident. If power grows too slowly, progress feels absent; too quickly,\n> and the game becomes a cakewalk. Pace power so the player stays near the edge of their\n> ability.","Rationale":"Progression only feels good in relation to challenge: the same +10% damage is thrilling\nagainst a wall the player was stuck on and meaningless against trivial enemies. Because\nengagement lives in the band where challenge matches ability (flow, DESIGN-0004), the\n*gap* between the player's rising power and the game's rising challenge is the real design\nobject [S-csikszentmihalyi-flow]. Left unmanaged, that gap drifts: content built for an\nearly power level trivializes once power outpaces it, and positive feedback loops\n(SYS-0004) can make a modest lead snowball into runaway dominance. A deliberately shaped\npower curve keeps the player perpetually \"almost overpowered, then challenged again.\"","Applies when":"Any game with character or player growth over time — RPGs, action games, roguelikes,\nprogression-driven games. The longer the progression and the more power accrues, the more\nthis matters.","Does not apply / Exceptions":"Games with little or flat progression (many competitive, arcade, or puzzle games) hold\npower roughly constant and derive difficulty from content and player skill instead. And a\nperfectly smooth curve isn't always the goal: deliberate power *spikes* (a burst of\npower-fantasy after a hard stretch) and difficulty *walls* (a gate that demands mastery)\nare valid pacing tools — the point is that they're chosen, not accidental.","Implementation (kept separate from the principle)":"Model both curves — player power and content/enemy power — and look at their gap over\ntime, not either alone. Tune so the gap oscillates within the flow band rather than\ntrending to trivial or brutal. Distinguish vertical growth (raw strength for tougher\nchallenges) from horizontal growth (new options and variety); many games pace both. Watch\nfor runaway positive feedback (SYS-0004) flattening the late game (see PROG-0006).","Disagreement":"Steady-curve design (smooth, predictable growth) vs. punctuated design (deliberate spikes\nand valleys for drama) are both legitimate; the choice follows the intended emotional\nrhythm. Neither \"always keep it smooth\" nor \"always spike it\" is universally right.","Notes":"The pacing backbone of the PROG domain; it is DESIGN-0004 (flow) extended across the whole\nprogression, and it interacts with SYS-0004 (feedback loops) in the late game. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROG-0001\ntitle: Design the power curve deliberately — pace growth against challenge\nlayer: L1\ndomain: PROG\nsubdomain: pacing-of-power\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - progression\n  - power-curve\n  - pacing\n  - flow\n  - difficulty\nrelated:\n  - GDC-L1-DESIGN-0004\n  - GDC-L1-PROG-0005\n  - GDC-L1-SYS-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-csikszentmihalyi-flow\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Treat the rate at which the player's power grows *relative to challenge* as a designed\n> curve, not an accident. If power grows too slowly, progress feels absent; too quickly,\n> and the game becomes a cakewalk. Pace power so the player stays near the edge of their\n> ability.\n\n## Rationale\nProgression only feels good in relation to challenge: the same +10% damage is thrilling\nagainst a wall the player was stuck on and meaningless against trivial enemies. Because\nengagement lives in the band where challenge matches ability (flow, DESIGN-0004), the\n*gap* between the player's rising power and the game's rising challenge is the real design\nobject [S-csikszentmihalyi-flow]. Left unmanaged, that gap drifts: content built for an\nearly power level trivializes once power outpaces it, and positive feedback loops\n(SYS-0004) can make a modest lead snowball into runaway dominance. A deliberately shaped\npower curve keeps the player perpetually \"almost overpowered, then challenged again.\"\n\n## Applies when\nAny game with character or player growth over time — RPGs, action games, roguelikes,\nprogression-driven games. The longer the progression and the more power accrues, the more\nthis matters.\n\n## Does not apply / Exceptions\nGames with little or flat progression (many competitive, arcade, or puzzle games) hold\npower roughly constant and derive difficulty from content and player skill instead. And a\nperfectly smooth curve isn't always the goal: deliberate power *spikes* (a burst of\npower-fantasy after a hard stretch) and difficulty *walls* (a gate that demands mastery)\nare valid pacing tools — the point is that they're chosen, not accidental.\n\n## Implementation (kept separate from the principle)\nModel both curves — player power and content/enemy power — and look at their gap over\ntime, not either alone. Tune so the gap oscillates within the flow band rather than\ntrending to trivial or brutal. Distinguish vertical growth (raw strength for tougher\nchallenges) from horizontal growth (new options and variety); many games pace both. Watch\nfor runaway positive feedback (SYS-0004) flattening the late game (see PROG-0006).\n\n## Disagreement\nSteady-curve design (smooth, predictable growth) vs. punctuated design (deliberate spikes\nand valleys for drama) are both legitimate; the choice follows the intended emotional\nrhythm. Neither \"always keep it smooth\" nor \"always spike it\" is universally right.\n\n## Notes\nThe pacing backbone of the PROG domain; it is DESIGN-0004 (flow) extended across the whole\nprogression, and it interacts with SYS-0004 (feedback loops) in the late game. Confidence 4.\n","searchText":"gdc-l1-prog-0001 design the power curve deliberately — pace growth against challenge progression power-curve pacing flow difficulty > treat the rate at which the player's power grows relative to challenge as a designed curve, not an accident. if power grows too slowly, progress feels absent; too quickly, and the game becomes a cakewalk. pace power so the player stays near the edge of their ability. progression only feels good in relation to challenge: the same +10% damage is thrilling against a wall the player was stuck on and meaningless against trivial enemies. because engagement lives in the band where challenge matches ability (flow, design-0004), the gap between the player's rising power and the game's rising challenge is the real design object [s-csikszentmihalyi-flow]. left unmanaged, that gap drifts: content built for an early power level trivializes once power outpaces it, and positive feedback loops (sys-0004) can make a modest lead snowball into runaway dominance. a deliberately shaped power curve keeps the player perpetually \"almost overpowered, then challenged again.\" any game with character or player growth over time — rpgs, action games, roguelikes, progression-driven games. the longer the progression and the more power accrues, the more this matters. games with little or flat progression (many competitive, arcade, or puzzle games) hold power roughly constant and derive difficulty from content and player skill instead. and a perfectly smooth curve isn't always the goal: deliberate power spikes (a burst of power-fantasy after a hard stretch) and difficulty walls (a gate that demands mastery) are valid pacing tools — the point is that they're chosen, not accidental. model both curves — player power and content/enemy power — and look at their gap over time, not either alone. tune so the gap oscillates within the flow band rather than trending to trivial or brutal. distinguish vertical growth (raw strength for tougher challenges) from horizontal growth (new options and variety); many games pace both. watch for runaway positive feedback (sys-0004) flattening the late game (see prog-0006). steady-curve design (smooth, predictable growth) vs. punctuated design (deliberate spikes and valleys for drama) are both legitimate; the choice follows the intended emotional rhythm. neither \"always keep it smooth\" nor \"always spike it\" is universally right. the pacing backbone of the prog domain; it is design-0004 (flow) extended across the whole progression, and it interacts with sys-0004 (feedback loops) in the late game. confidence 4."}
{"id":"GDC-L1-PROG-0002","title":"Decide the mix of player skill and character power","layer":"L1","domain":"PROG","subdomain":"skill-vs-power","type":"contextual","confidence":4,"status":"canonical","tags":["progression","skill-vs-power","mastery","rpg","action"],"related":["GDC-L1-DESIGN-0002","GDC-L1-PROG-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROG-0002.md","statement":"\"Getting better\" can come from two sources: the player improving (execution, knowledge, timing) or the character growing (stats, gear, unlocks). Decide the intended blend deliberately — it determines whether mastery is earned at the controller or accumulated on the character sheet.","sections":{"Statement":"> \"Getting better\" can come from two sources: the **player** improving (execution,\n> knowledge, timing) or the **character** growing (stats, gear, unlocks). Decide the\n> intended blend deliberately — it determines whether mastery is earned at the controller\n> or accumulated on the character sheet.","Rationale":"The two sources feel completely different. Player-skill progression rewards practice —\nmuscle memory, pattern recognition, better decisions — and is satisfying because *you*\ngot better [S-schell-artofgamedesign]. Character-power progression rewards investment —\ntime, resources, choices — and is satisfying because your avatar can now do what it\ncouldn't. Games sit somewhere on this axis, and the position shapes everything:\ndifficulty tuning, how failure feels, whether a stuck player should grind or improve, and\nwho the game is for. Leaving it unexamined produces incoherence — e.g. a game that asks\nfor twitch skill but lets players out-level every challenge, satisfying neither the action\nplayer nor the RPG player.","Applies when":"Any game with progression and any real-time challenge — action-RPGs especially, where the\ntwo sources are most in tension.","Does not apply / Exceptions":"Pure-skill games (fighting games, most competitive shooters) deliberately sit at the\nplayer-skill pole with little character power; pure-build games and idle/incremental games\nsit near the character-power pole with little execution demand. Both extremes are\ncoherent; the danger is an *unintended* muddle in the middle.","Implementation (kept separate from the principle)":"Decide, per system, whether a challenge should be beaten by getting better or by getting stronger — and make the game's answer consistent so a stuck player knows what to do.","Disagreement":"Action tradition (player skill is the point; character power should never trivialize\nexecution) vs. RPG tradition (character growth is the fantasy; the sheet, not the thumbs,\nshould decide outcomes). Both are valid design goals; the axis position is a defining\nchoice, not a mistake.","Notes":"Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROG-0002\ntitle: Decide the mix of player skill and character power\nlayer: L1\ndomain: PROG\nsubdomain: skill-vs-power\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - progression\n  - skill-vs-power\n  - mastery\n  - rpg\n  - action\nrelated:\n  - GDC-L1-DESIGN-0002\n  - GDC-L1-PROG-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> \"Getting better\" can come from two sources: the **player** improving (execution,\n> knowledge, timing) or the **character** growing (stats, gear, unlocks). Decide the\n> intended blend deliberately — it determines whether mastery is earned at the controller\n> or accumulated on the character sheet.\n\n## Rationale\nThe two sources feel completely different. Player-skill progression rewards practice —\nmuscle memory, pattern recognition, better decisions — and is satisfying because *you*\ngot better [S-schell-artofgamedesign]. Character-power progression rewards investment —\ntime, resources, choices — and is satisfying because your avatar can now do what it\ncouldn't. Games sit somewhere on this axis, and the position shapes everything:\ndifficulty tuning, how failure feels, whether a stuck player should grind or improve, and\nwho the game is for. Leaving it unexamined produces incoherence — e.g. a game that asks\nfor twitch skill but lets players out-level every challenge, satisfying neither the action\nplayer nor the RPG player.\n\n## Applies when\nAny game with progression and any real-time challenge — action-RPGs especially, where the\ntwo sources are most in tension.\n\n## Does not apply / Exceptions\nPure-skill games (fighting games, most competitive shooters) deliberately sit at the\nplayer-skill pole with little character power; pure-build games and idle/incremental games\nsit near the character-power pole with little execution demand. Both extremes are\ncoherent; the danger is an *unintended* muddle in the middle.\n\n## Implementation (kept separate from the principle)\nDecide, per system, whether a challenge should be beaten by getting better or by getting stronger — and make the game's answer consistent so a stuck player knows what to do.\n\n## Disagreement\nAction tradition (player skill is the point; character power should never trivialize\nexecution) vs. RPG tradition (character growth is the fantasy; the sheet, not the thumbs,\nshould decide outcomes). Both are valid design goals; the axis position is a defining\nchoice, not a mistake.\n\n## Notes\nConfidence 4.\n","searchText":"gdc-l1-prog-0002 decide the mix of player skill and character power progression skill-vs-power mastery rpg action > \"getting better\" can come from two sources: the player improving (execution, knowledge, timing) or the character growing (stats, gear, unlocks). decide the intended blend deliberately — it determines whether mastery is earned at the controller or accumulated on the character sheet. the two sources feel completely different. player-skill progression rewards practice — muscle memory, pattern recognition, better decisions — and is satisfying because you got better [s-schell-artofgamedesign]. character-power progression rewards investment — time, resources, choices — and is satisfying because your avatar can now do what it couldn't. games sit somewhere on this axis, and the position shapes everything: difficulty tuning, how failure feels, whether a stuck player should grind or improve, and who the game is for. leaving it unexamined produces incoherence — e.g. a game that asks for twitch skill but lets players out-level every challenge, satisfying neither the action player nor the rpg player. any game with progression and any real-time challenge — action-rpgs especially, where the two sources are most in tension. pure-skill games (fighting games, most competitive shooters) deliberately sit at the player-skill pole with little character power; pure-build games and idle/incremental games sit near the character-power pole with little execution demand. both extremes are coherent; the danger is an unintended muddle in the middle. decide, per system, whether a challenge should be beaten by getting better or by getting stronger — and make the game's answer consistent so a stuck player knows what to do. action tradition (player skill is the point; character power should never trivialize execution) vs. rpg tradition (character growth is the fantasy; the sheet, not the thumbs, should decide outcomes). both are valid design goals; the axis position is a defining choice, not a mistake. confidence 4."}
{"id":"GDC-L1-PROG-0003","title":"Reward the behavior you want — legibly and proportionately","layer":"L1","domain":"PROG","subdomain":"reward-schedules","type":"contextual","confidence":4,"status":"canonical","tags":["progression","rewards","incentives","legibility","balance"],"related":["GDC-L1-SYS-0007","GDC-L1-DESIGN-0006","GDC-L1-PROG-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-schell-artofgamedesign","S-soren-johnson-optimize"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROG-0003.md","statement":"Rewards teach. Players learn to do whatever the game rewards, so reward the behavior you actually want to see. Make each reward legible (the player understands what earned it) and proportionate (greater effort or skill earns greater payoff). Misaligned rewards train the fun out of the game.","sections":{"Statement":"> Rewards teach. Players learn to do whatever the game rewards, so reward the behavior you\n> actually want to see. Make each reward **legible** (the player understands what earned\n> it) and **proportionate** (greater effort or skill earns greater payoff). Misaligned\n> rewards train the fun out of the game.","Rationale":"A reward is a signal that says \"do more of that.\" If the most-rewarded action is boring,\nsafe, or degenerate, players will gravitate to it and then blame the game for the tedium\n(the optimization pressure of SYS-0007). So the reward structure must point at the\nexperience you want: reward bold play if you want bold play, exploration if you want\nexploration, mastery if you want mastery. Legibility matters because a reward the player\ncan't attribute to an action can't reinforce that action — it reads as randomness (compare\nDESIGN-0006, legible consequences). Proportionality matters because rewards that don't\nscale with effort either trivialize achievement or feel unfair.","Applies when":"Any system that grants progress, loot, currency, unlocks, or score — i.e. most\nprogression and economy design.","Does not apply / Exceptions":"Deliberate randomness has a place (varicrity and surprise; see PROG-0004), so \"legible\"\nmeans the player understands the *rules of the reward*, not that every drop is\ndeterministic. And not every action needs a reward — over-rewarding trivial actions\ncreates noise that drowns the signals that matter (compare FEEL-0004 on feedback). Some\ncosmetic or expressive rewards are intentionally disproportionate to effort and that's\nfine.","Implementation (kept separate from the principle)":"Audit what your game actually rewards versus what you want it to encourage, and realign the\ngaps. Make the earning rule visible or discoverable. Scale payoff to effort/skill/risk so\nthe exciting path is also the rewarding path (this is the incentive lever behind SYS-0007).\nWatch for accidental incentives — a reward attached to a boring-but-optimal action is a bug.","Disagreement":"How *tightly* to couple reward to desired behavior is debated: tight coupling steers\nplayers cleanly but can feel manipulative or grindy; loose coupling preserves freedom but\nlets degenerate strategies flourish. Balances differ by genre and by how much the game\ntrusts player-driven goals.","Notes":"The constructive counterpart to SYS-0007 (players optimize the fun out): SYS-0007 warns of\nthe failure, this says how to steer incentives so the fun path stays rewarding. Leads into\nPROG-0004 (intrinsic vs. extrinsic). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROG-0003\ntitle: Reward the behavior you want — legibly and proportionately\nlayer: L1\ndomain: PROG\nsubdomain: reward-schedules\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - progression\n  - rewards\n  - incentives\n  - legibility\n  - balance\nrelated:\n  - GDC-L1-SYS-0007\n  - GDC-L1-DESIGN-0006\n  - GDC-L1-PROG-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schell-artofgamedesign\n  - S-soren-johnson-optimize\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Rewards teach. Players learn to do whatever the game rewards, so reward the behavior you\n> actually want to see. Make each reward **legible** (the player understands what earned\n> it) and **proportionate** (greater effort or skill earns greater payoff). Misaligned\n> rewards train the fun out of the game.\n\n## Rationale\nA reward is a signal that says \"do more of that.\" If the most-rewarded action is boring,\nsafe, or degenerate, players will gravitate to it and then blame the game for the tedium\n(the optimization pressure of SYS-0007). So the reward structure must point at the\nexperience you want: reward bold play if you want bold play, exploration if you want\nexploration, mastery if you want mastery. Legibility matters because a reward the player\ncan't attribute to an action can't reinforce that action — it reads as randomness (compare\nDESIGN-0006, legible consequences). Proportionality matters because rewards that don't\nscale with effort either trivialize achievement or feel unfair.\n\n## Applies when\nAny system that grants progress, loot, currency, unlocks, or score — i.e. most\nprogression and economy design.\n\n## Does not apply / Exceptions\nDeliberate randomness has a place (varicrity and surprise; see PROG-0004), so \"legible\"\nmeans the player understands the *rules of the reward*, not that every drop is\ndeterministic. And not every action needs a reward — over-rewarding trivial actions\ncreates noise that drowns the signals that matter (compare FEEL-0004 on feedback). Some\ncosmetic or expressive rewards are intentionally disproportionate to effort and that's\nfine.\n\n## Implementation (kept separate from the principle)\nAudit what your game actually rewards versus what you want it to encourage, and realign the\ngaps. Make the earning rule visible or discoverable. Scale payoff to effort/skill/risk so\nthe exciting path is also the rewarding path (this is the incentive lever behind SYS-0007).\nWatch for accidental incentives — a reward attached to a boring-but-optimal action is a bug.\n\n## Disagreement\nHow *tightly* to couple reward to desired behavior is debated: tight coupling steers\nplayers cleanly but can feel manipulative or grindy; loose coupling preserves freedom but\nlets degenerate strategies flourish. Balances differ by genre and by how much the game\ntrusts player-driven goals.\n\n## Notes\nThe constructive counterpart to SYS-0007 (players optimize the fun out): SYS-0007 warns of\nthe failure, this says how to steer incentives so the fun path stays rewarding. Leads into\nPROG-0004 (intrinsic vs. extrinsic). Confidence 4.\n","searchText":"gdc-l1-prog-0003 reward the behavior you want — legibly and proportionately progression rewards incentives legibility balance > rewards teach. players learn to do whatever the game rewards, so reward the behavior you actually want to see. make each reward legible (the player understands what earned it) and proportionate (greater effort or skill earns greater payoff). misaligned rewards train the fun out of the game. a reward is a signal that says \"do more of that.\" if the most-rewarded action is boring, safe, or degenerate, players will gravitate to it and then blame the game for the tedium (the optimization pressure of sys-0007). so the reward structure must point at the experience you want: reward bold play if you want bold play, exploration if you want exploration, mastery if you want mastery. legibility matters because a reward the player can't attribute to an action can't reinforce that action — it reads as randomness (compare design-0006, legible consequences). proportionality matters because rewards that don't scale with effort either trivialize achievement or feel unfair. any system that grants progress, loot, currency, unlocks, or score — i.e. most progression and economy design. deliberate randomness has a place (varicrity and surprise; see prog-0004), so \"legible\" means the player understands the rules of the reward, not that every drop is deterministic. and not every action needs a reward — over-rewarding trivial actions creates noise that drowns the signals that matter (compare feel-0004 on feedback). some cosmetic or expressive rewards are intentionally disproportionate to effort and that's fine. audit what your game actually rewards versus what you want it to encourage, and realign the gaps. make the earning rule visible or discoverable. scale payoff to effort/skill/risk so the exciting path is also the rewarding path (this is the incentive lever behind sys-0007). watch for accidental incentives — a reward attached to a boring-but-optimal action is a bug. how tightly to couple reward to desired behavior is debated: tight coupling steers players cleanly but can feel manipulative or grindy; loose coupling preserves freedom but lets degenerate strategies flourish. balances differ by genre and by how much the game trusts player-driven goals. the constructive counterpart to sys-0007 (players optimize the fun out): sys-0007 warns of the failure, this says how to steer incentives so the fun path stays rewarding. leads into prog-0004 (intrinsic vs. extrinsic). confidence 4."}
{"id":"GDC-L1-PROG-0004","title":"Favor intrinsic progression over extrinsic treadmills","layer":"L1","domain":"PROG","subdomain":"reward-schedules","type":"stylistic","confidence":3,"status":"canonical","tags":["progression","intrinsic-motivation","ethics","player-respect","grind"],"related":["GDC-L1-PROG-0003","GDC-L1-DESIGN-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-reward-schedules","S-koster-theoryoffun"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROG-0004.md","statement":"Prefer progression that deepens genuine engagement — new abilities, meaningful choices, real mastery — over manufactured treadmills that rely on compulsion loops (grind, unpredictable reward schedules) to retain players. Let rewards sit on top of intrinsically fun play, not substitute for it.","sections":{"Statement":"> Prefer progression that deepens genuine engagement — new abilities, meaningful choices,\n> real mastery — over manufactured treadmills that rely on compulsion loops (grind,\n> unpredictable reward schedules) to retain players. Let rewards sit *on top of*\n> intrinsically fun play, not substitute for it.","Rationale":"Reward-schedule techniques rooted in operant conditioning (variable-ratio \"slot machine\"\nloops) reliably drive time-on-task, but they engage *extrinsic* motivation — playing for\nthe payout rather than the play [S-reward-schedules]. The overjustification effect warns\nof the trap: rewarding an activity that was intrinsically fun can make players re-attribute\ntheir behavior to the reward, so when the reward thins out, so does the enjoyment. A\ngame sustained mainly by compulsion loops is fragile and, past a point, works against the\nplayer's own interests. Intrinsic progression — getting to *do* new and interesting things,\nmastering real skills (DESIGN-0003) — is more durable and treats the player as someone to\ndelight rather than to retain. Notably, unpredictable rewards can be used *respectfully*\nwhen they're a bonus on top of already-fun play rather than a gate that play must pass\nthrough.","Applies when":"Any progression, reward, or retention design — and especially anywhere monetization or\nengagement metrics tempt the team toward compulsion mechanics.","Does not apply / Exceptions":"Some pleasure genuinely *is* the loop: idle/incremental games and collectathons are\nopenly about the satisfying tick of accumulation, and players choose them for exactly\nthat. Variable rewards, used as surprise-and-delight on top of fun play, are a legitimate\nand beloved tool (loot, crits). The line this principle draws is against progression that\n*depends* on compulsion because the underlying play isn't carrying it.","Implementation (kept separate from the principle)":"Build the intrinsically fun loop first (PROTO-0001, find the fun) and add rewards as\namplifiers on top of it, not as the reason to keep playing. Apply the removal test: *would\nplayers still enjoy this loop if the rewards were stripped out?* If not, the play isn't\ncarrying itself and no reward schedule will fix that honestly. When using variable/random\nrewards, make them a bonus layered over already-fun play rather than a gate play must pass\nthrough. Watch engagement/retention metrics but don't optimize them at the experience's\nexpense (the PROG-0003 / PLAYTEST-0005 caution against chasing a proxy). Be especially wary\nof compulsion patterns (FOMO timers, mandatory daily logins, loss-aversion hooks) — use them\nonly where they genuinely serve the player, not merely the metric.","Disagreement":"This is a real values split, so it is typed `stylistic`. The engagement-optimization case\n(as its proponents make it): retention and monetization are legitimate business goals,\nreinforcement schedules are well-understood and effective, and players opt in freely — a\ngame that keeps people playing is succeeding. The player-respect/wellbeing case: compulsion\nloops can exploit rather than serve, erode intrinsic enjoyment (overjustification), and\nrisk the player's time and wellbeing; a game should earn engagement through fun, not\nmanufacture it. This constitution leans toward the respect side, but presents both because\nreasonable, successful developers land in different places.","Notes":"Confidence 3: the mechanisms (overjustification, reinforcement schedules) are well-established, but *how much* to weigh engagement vs. respect is a genuine, unresolved values question."},"rawMarkdown":"---\nid: GDC-L1-PROG-0004\ntitle: Favor intrinsic progression over extrinsic treadmills\nlayer: L1\ndomain: PROG\nsubdomain: reward-schedules\ntype: stylistic\nconfidence: 3\nstatus: canonical\ntags:\n  - progression\n  - intrinsic-motivation\n  - ethics\n  - player-respect\n  - grind\nrelated:\n  - GDC-L1-PROG-0003\n  - GDC-L1-DESIGN-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-reward-schedules\n  - S-koster-theoryoffun\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Prefer progression that deepens genuine engagement — new abilities, meaningful choices,\n> real mastery — over manufactured treadmills that rely on compulsion loops (grind,\n> unpredictable reward schedules) to retain players. Let rewards sit *on top of*\n> intrinsically fun play, not substitute for it.\n\n## Rationale\nReward-schedule techniques rooted in operant conditioning (variable-ratio \"slot machine\"\nloops) reliably drive time-on-task, but they engage *extrinsic* motivation — playing for\nthe payout rather than the play [S-reward-schedules]. The overjustification effect warns\nof the trap: rewarding an activity that was intrinsically fun can make players re-attribute\ntheir behavior to the reward, so when the reward thins out, so does the enjoyment. A\ngame sustained mainly by compulsion loops is fragile and, past a point, works against the\nplayer's own interests. Intrinsic progression — getting to *do* new and interesting things,\nmastering real skills (DESIGN-0003) — is more durable and treats the player as someone to\ndelight rather than to retain. Notably, unpredictable rewards can be used *respectfully*\nwhen they're a bonus on top of already-fun play rather than a gate that play must pass\nthrough.\n\n## Applies when\nAny progression, reward, or retention design — and especially anywhere monetization or\nengagement metrics tempt the team toward compulsion mechanics.\n\n## Does not apply / Exceptions\nSome pleasure genuinely *is* the loop: idle/incremental games and collectathons are\nopenly about the satisfying tick of accumulation, and players choose them for exactly\nthat. Variable rewards, used as surprise-and-delight on top of fun play, are a legitimate\nand beloved tool (loot, crits). The line this principle draws is against progression that\n*depends* on compulsion because the underlying play isn't carrying it.\n\n## Implementation (kept separate from the principle)\nBuild the intrinsically fun loop first (PROTO-0001, find the fun) and add rewards as\namplifiers on top of it, not as the reason to keep playing. Apply the removal test: *would\nplayers still enjoy this loop if the rewards were stripped out?* If not, the play isn't\ncarrying itself and no reward schedule will fix that honestly. When using variable/random\nrewards, make them a bonus layered over already-fun play rather than a gate play must pass\nthrough. Watch engagement/retention metrics but don't optimize them at the experience's\nexpense (the PROG-0003 / PLAYTEST-0005 caution against chasing a proxy). Be especially wary\nof compulsion patterns (FOMO timers, mandatory daily logins, loss-aversion hooks) — use them\nonly where they genuinely serve the player, not merely the metric.\n\n## Disagreement\nThis is a real values split, so it is typed `stylistic`. The engagement-optimization case\n(as its proponents make it): retention and monetization are legitimate business goals,\nreinforcement schedules are well-understood and effective, and players opt in freely — a\ngame that keeps people playing is succeeding. The player-respect/wellbeing case: compulsion\nloops can exploit rather than serve, erode intrinsic enjoyment (overjustification), and\nrisk the player's time and wellbeing; a game should earn engagement through fun, not\nmanufacture it. This constitution leans toward the respect side, but presents both because\nreasonable, successful developers land in different places.\n\n## Notes\nConfidence 3: the mechanisms (overjustification, reinforcement schedules) are well-established, but *how much* to weigh engagement vs. respect is a genuine, unresolved values question.\n","searchText":"gdc-l1-prog-0004 favor intrinsic progression over extrinsic treadmills progression intrinsic-motivation ethics player-respect grind > prefer progression that deepens genuine engagement — new abilities, meaningful choices, real mastery — over manufactured treadmills that rely on compulsion loops (grind, unpredictable reward schedules) to retain players. let rewards sit on top of intrinsically fun play, not substitute for it. reward-schedule techniques rooted in operant conditioning (variable-ratio \"slot machine\" loops) reliably drive time-on-task, but they engage extrinsic motivation — playing for the payout rather than the play [s-reward-schedules]. the overjustification effect warns of the trap: rewarding an activity that was intrinsically fun can make players re-attribute their behavior to the reward, so when the reward thins out, so does the enjoyment. a game sustained mainly by compulsion loops is fragile and, past a point, works against the player's own interests. intrinsic progression — getting to do new and interesting things, mastering real skills (design-0003) — is more durable and treats the player as someone to delight rather than to retain. notably, unpredictable rewards can be used respectfully when they're a bonus on top of already-fun play rather than a gate that play must pass through. any progression, reward, or retention design — and especially anywhere monetization or engagement metrics tempt the team toward compulsion mechanics. some pleasure genuinely is the loop: idle/incremental games and collectathons are openly about the satisfying tick of accumulation, and players choose them for exactly that. variable rewards, used as surprise-and-delight on top of fun play, are a legitimate and beloved tool (loot, crits). the line this principle draws is against progression that depends on compulsion because the underlying play isn't carrying it. build the intrinsically fun loop first (proto-0001, find the fun) and add rewards as amplifiers on top of it, not as the reason to keep playing. apply the removal test: would players still enjoy this loop if the rewards were stripped out? if not, the play isn't carrying itself and no reward schedule will fix that honestly. when using variable/random rewards, make them a bonus layered over already-fun play rather than a gate play must pass through. watch engagement/retention metrics but don't optimize them at the experience's expense (the prog-0003 / playtest-0005 caution against chasing a proxy). be especially wary of compulsion patterns (fomo timers, mandatory daily logins, loss-aversion hooks) — use them only where they genuinely serve the player, not merely the metric. this is a real values split, so it is typed stylistic. the engagement-optimization case (as its proponents make it): retention and monetization are legitimate business goals, reinforcement schedules are well-understood and effective, and players opt in freely — a game that keeps people playing is succeeding. the player-respect/wellbeing case: compulsion loops can exploit rather than serve, erode intrinsic enjoyment (overjustification), and risk the player's time and wellbeing; a game should earn engagement through fun, not manufacture it. this constitution leans toward the respect side, but presents both because reasonable, successful developers land in different places. confidence 3: the mechanisms (overjustification, reinforcement schedules) are well-established, but how much to weigh engagement vs. respect is a genuine, unresolved values question."}
{"id":"GDC-L1-PROG-0005","title":"Introduce complexity in four beats — introduce, develop, twist, conclude","layer":"L1","domain":"PROG","subdomain":"mastery-curve","type":"contextual","confidence":4,"status":"canonical","tags":["progression","mastery-curve","teaching","level-design","pacing"],"related":["GDC-L1-DESIGN-0003","GDC-L1-DESIGN-0004","GDC-L1-PROG-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-mark-brown-4step"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROG-0005.md","statement":"Introduce each new mechanic in a structured arc: introduce it in a safe, low-stakes setting; develop it by adding complexity; twist it through an unexpected use; then conclude with a final payoff or demonstration. Stagger introductions so the player is always learning something new as they finish mastering the last.","sections":{"Statement":"> Introduce each new mechanic in a structured arc: **introduce** it in a safe, low-stakes\n> setting; **develop** it by adding complexity; **twist** it through an unexpected use;\n> then **conclude** with a final payoff or demonstration. Stagger introductions so the player is always\n> learning something new as they finish mastering the last.","Rationale":"The four-step structure described by Mark Brown (introduce → develop → twist → conclusion,\nrelated to the Kishōtenketsu narrative shape) is an effective arc for turning a new mechanic into understanding in\nminutes [S-mark-brown-4step]. Each step does a specific job: the safe introduction lets\nthe player fail and learn without punishment; development builds competence through added\ncomplexity; the twist forces genuine understanding (not just memorized inputs) by\nrecontextualizing the mechanic; and the conclusion pays off the learning, often through a\nconfident final showcase. This is the concrete, teachable pacing of \"fun is learning\"\n(DESIGN-0003) and keeps the player inside flow (DESIGN-0004) — always stretched, never\nlost.","Applies when":"Introducing any new mechanic, tool, enemy, or system — level design, tutorial design, and\nthe overall sequencing of what the game teaches when.","Does not apply / Exceptions":"Not every mechanic needs the full four beats — trivial additions can be introduced in passing. Open/emergent games may teach through systems and experimentation rather than authored arcs.","Implementation (kept separate from the principle)":"For each new mechanic, sketch the four beats: a safe first encounter, a complication, a\nrecontextualizing twist, and a concluding payoff. Space new-mechanic introductions so the\nlearning load stays steady (pairs with the power curve, PROG-0001). Reuse the arc\nfractally — within a level, an area, and the whole game. Where the game's identity is\ndiscovery, consider hiding the \"teach\" step and letting the world imply it.","Disagreement":"Authored teaching (structured arcs, guided) vs. discovery teaching (unguided, figure-it-out)\nis a real split — the former maximizes clarity and reach, the latter maximizes the pleasure\nof insight and suits systemic/mystery designs. The four-step arc is the strong default for\naccessibility; discovery-first games consciously trade it away.","Notes":"The teaching/pacing counterpart to DESIGN-0003 (fun is learning) and DESIGN-0004 (flow), and it directly informs LEVEL/encounter design. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROG-0005\ntitle: Introduce complexity in four beats — introduce, develop, twist, conclude\nlayer: L1\ndomain: PROG\nsubdomain: mastery-curve\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - progression\n  - mastery-curve\n  - teaching\n  - level-design\n  - pacing\nrelated:\n  - GDC-L1-DESIGN-0003\n  - GDC-L1-DESIGN-0004\n  - GDC-L1-PROG-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-mark-brown-4step\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Introduce each new mechanic in a structured arc: **introduce** it in a safe, low-stakes\n> setting; **develop** it by adding complexity; **twist** it through an unexpected use;\n> then **conclude** with a final payoff or demonstration. Stagger introductions so the player is always\n> learning something new as they finish mastering the last.\n\n## Rationale\nThe four-step structure described by Mark Brown (introduce → develop → twist → conclusion,\nrelated to the Kishōtenketsu narrative shape) is an effective arc for turning a new mechanic into understanding in\nminutes [S-mark-brown-4step]. Each step does a specific job: the safe introduction lets\nthe player fail and learn without punishment; development builds competence through added\ncomplexity; the twist forces genuine understanding (not just memorized inputs) by\nrecontextualizing the mechanic; and the conclusion pays off the learning, often through a\nconfident final showcase. This is the concrete, teachable pacing of \"fun is learning\"\n(DESIGN-0003) and keeps the player inside flow (DESIGN-0004) — always stretched, never\nlost.\n\n## Applies when\nIntroducing any new mechanic, tool, enemy, or system — level design, tutorial design, and\nthe overall sequencing of what the game teaches when.\n\n## Does not apply / Exceptions\nNot every mechanic needs the full four beats — trivial additions can be introduced in passing. Open/emergent games may teach through systems and experimentation rather than authored arcs.\n\n## Implementation (kept separate from the principle)\nFor each new mechanic, sketch the four beats: a safe first encounter, a complication, a\nrecontextualizing twist, and a concluding payoff. Space new-mechanic introductions so the\nlearning load stays steady (pairs with the power curve, PROG-0001). Reuse the arc\nfractally — within a level, an area, and the whole game. Where the game's identity is\ndiscovery, consider hiding the \"teach\" step and letting the world imply it.\n\n## Disagreement\nAuthored teaching (structured arcs, guided) vs. discovery teaching (unguided, figure-it-out)\nis a real split — the former maximizes clarity and reach, the latter maximizes the pleasure\nof insight and suits systemic/mystery designs. The four-step arc is the strong default for\naccessibility; discovery-first games consciously trade it away.\n\n## Notes\nThe teaching/pacing counterpart to DESIGN-0003 (fun is learning) and DESIGN-0004 (flow), and it directly informs LEVEL/encounter design. Confidence 4.\n","searchText":"gdc-l1-prog-0005 introduce complexity in four beats — introduce, develop, twist, conclude progression mastery-curve teaching level-design pacing > introduce each new mechanic in a structured arc: introduce it in a safe, low-stakes setting; develop it by adding complexity; twist it through an unexpected use; then conclude with a final payoff or demonstration. stagger introductions so the player is always learning something new as they finish mastering the last. the four-step structure described by mark brown (introduce → develop → twist → conclusion, related to the kishōtenketsu narrative shape) is an effective arc for turning a new mechanic into understanding in minutes [s-mark-brown-4step]. each step does a specific job: the safe introduction lets the player fail and learn without punishment; development builds competence through added complexity; the twist forces genuine understanding (not just memorized inputs) by recontextualizing the mechanic; and the conclusion pays off the learning, often through a confident final showcase. this is the concrete, teachable pacing of \"fun is learning\" (design-0003) and keeps the player inside flow (design-0004) — always stretched, never lost. introducing any new mechanic, tool, enemy, or system — level design, tutorial design, and the overall sequencing of what the game teaches when. not every mechanic needs the full four beats — trivial additions can be introduced in passing. open/emergent games may teach through systems and experimentation rather than authored arcs. for each new mechanic, sketch the four beats: a safe first encounter, a complication, a recontextualizing twist, and a concluding payoff. space new-mechanic introductions so the learning load stays steady (pairs with the power curve, prog-0001). reuse the arc fractally — within a level, an area, and the whole game. where the game's identity is discovery, consider hiding the \"teach\" step and letting the world imply it. authored teaching (structured arcs, guided) vs. discovery teaching (unguided, figure-it-out) is a real split — the former maximizes clarity and reach, the latter maximizes the pleasure of insight and suits systemic/mystery designs. the four-step arc is the strong default for accessibility; discovery-first games consciously trade it away. the teaching/pacing counterpart to design-0003 (fun is learning) and design-0004 (flow), and it directly informs level/encounter design. confidence 4."}
{"id":"GDC-L1-PROG-0006","title":"Design the mastery ceiling and endgame explicitly","layer":"L1","domain":"PROG","subdomain":"mastery-curve","type":"contextual","confidence":3,"status":"canonical","tags":["progression","endgame","mastery-ceiling","balance","retention"],"related":["GDC-L1-DESIGN-0005","GDC-L1-SYS-0004","GDC-L1-PROG-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-koster-theoryoffun"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROG-0006.md","statement":"Decide what the top of progression looks like before you need it: where power converges, what expert play consists of, and whether the late game is a power fantasy or a tight skill test. An unplanned endgame collapses into trivialized challenge (runaway power) or a content cliff (nothing left to master).","sections":{"Statement":"> Decide what the *top* of progression looks like before you need it: where power\n> converges, what expert play consists of, and whether the late game is a power fantasy or\n> a tight skill test. An unplanned endgame collapses into trivialized challenge (runaway\n> power) or a content cliff (nothing left to master).","Rationale":"Progression has an end state whether or not you designed one, and the two default failures\nare predictable. If power keeps compounding unchecked (a positive feedback loop, SYS-0004),\nthe late game trivializes — every challenge falls over, and the mastery that made the game\nfun evaporates (Koster's \"mastery problem\": once a pattern is fully solved, it stops being\nfun) [S-koster-theoryoffun]. If instead the game simply runs out of new patterns, players\nhit a content cliff and leave. Designing the ceiling deliberately means choosing which of\ntwo satisfying end states you want — the earned power fantasy (you *are* strong now, and\nthat's the reward) or sustained skill expression (power converges so mastery stays about\nplay) — and shaping the curve toward it.","Applies when":"Any game long enough to have a late game or endgame — RPGs, live-service, roguelikes,\nprogression-heavy games. Most acute where power compounds.","Does not apply / Exceptions":"Short or session-based games without a meaningful late game don't need an endgame design.\nDeliberate power-fantasy finales (the game *wants* you to feel unstoppable at the end) are\na valid choice, not a failure — the point is that trivialization is chosen and framed as a\nreward, not stumbled into.","Implementation (kept separate from the principle)":"Decide early whether late-game power converges (caps, diminishing returns, scaling\nchallenge) or crescendos (an intentional power fantasy). Guard against runaway positive\nfeedback (SYS-0004) if you want convergence. Plan a source of continued mastery for the\ntop end — new patterns, higher-skill content, or horizontal variety — so expert players\nstill have somewhere to go (compare DESIGN-0005, high skill ceiling).","Disagreement":"Convergent endgame (keep power in check so skill and challenge stay meaningful) vs.\ncrescendo endgame (let power run so the finale is a cathartic power fantasy) are both\nlegitimate, opposite answers. The right one depends on whether the game's late-game\npleasure is *expression* or *dominance*.","Notes":"The top-of-curve companion to PROG-0001 (pacing) and DESIGN-0005 (accessible depth / high\nceiling), and it's where SYS-0004's runaway positive feedback most often bites. Confidence\n3 — sound reasoning, but endgame design is highly genre-dependent and less settled than the\nearlier-curve principles."},"rawMarkdown":"---\nid: GDC-L1-PROG-0006\ntitle: Design the mastery ceiling and endgame explicitly\nlayer: L1\ndomain: PROG\nsubdomain: mastery-curve\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - progression\n  - endgame\n  - mastery-ceiling\n  - balance\n  - retention\nrelated:\n  - GDC-L1-DESIGN-0005\n  - GDC-L1-SYS-0004\n  - GDC-L1-PROG-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-koster-theoryoffun\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Decide what the *top* of progression looks like before you need it: where power\n> converges, what expert play consists of, and whether the late game is a power fantasy or\n> a tight skill test. An unplanned endgame collapses into trivialized challenge (runaway\n> power) or a content cliff (nothing left to master).\n\n## Rationale\nProgression has an end state whether or not you designed one, and the two default failures\nare predictable. If power keeps compounding unchecked (a positive feedback loop, SYS-0004),\nthe late game trivializes — every challenge falls over, and the mastery that made the game\nfun evaporates (Koster's \"mastery problem\": once a pattern is fully solved, it stops being\nfun) [S-koster-theoryoffun]. If instead the game simply runs out of new patterns, players\nhit a content cliff and leave. Designing the ceiling deliberately means choosing which of\ntwo satisfying end states you want — the earned power fantasy (you *are* strong now, and\nthat's the reward) or sustained skill expression (power converges so mastery stays about\nplay) — and shaping the curve toward it.\n\n## Applies when\nAny game long enough to have a late game or endgame — RPGs, live-service, roguelikes,\nprogression-heavy games. Most acute where power compounds.\n\n## Does not apply / Exceptions\nShort or session-based games without a meaningful late game don't need an endgame design.\nDeliberate power-fantasy finales (the game *wants* you to feel unstoppable at the end) are\na valid choice, not a failure — the point is that trivialization is chosen and framed as a\nreward, not stumbled into.\n\n## Implementation (kept separate from the principle)\nDecide early whether late-game power converges (caps, diminishing returns, scaling\nchallenge) or crescendos (an intentional power fantasy). Guard against runaway positive\nfeedback (SYS-0004) if you want convergence. Plan a source of continued mastery for the\ntop end — new patterns, higher-skill content, or horizontal variety — so expert players\nstill have somewhere to go (compare DESIGN-0005, high skill ceiling).\n\n## Disagreement\nConvergent endgame (keep power in check so skill and challenge stay meaningful) vs.\ncrescendo endgame (let power run so the finale is a cathartic power fantasy) are both\nlegitimate, opposite answers. The right one depends on whether the game's late-game\npleasure is *expression* or *dominance*.\n\n## Notes\nThe top-of-curve companion to PROG-0001 (pacing) and DESIGN-0005 (accessible depth / high\nceiling), and it's where SYS-0004's runaway positive feedback most often bites. Confidence\n3 — sound reasoning, but endgame design is highly genre-dependent and less settled than the\nearlier-curve principles.\n","searchText":"gdc-l1-prog-0006 design the mastery ceiling and endgame explicitly progression endgame mastery-ceiling balance retention > decide what the top of progression looks like before you need it: where power converges, what expert play consists of, and whether the late game is a power fantasy or a tight skill test. an unplanned endgame collapses into trivialized challenge (runaway power) or a content cliff (nothing left to master). progression has an end state whether or not you designed one, and the two default failures are predictable. if power keeps compounding unchecked (a positive feedback loop, sys-0004), the late game trivializes — every challenge falls over, and the mastery that made the game fun evaporates (koster's \"mastery problem\": once a pattern is fully solved, it stops being fun) [s-koster-theoryoffun]. if instead the game simply runs out of new patterns, players hit a content cliff and leave. designing the ceiling deliberately means choosing which of two satisfying end states you want — the earned power fantasy (you are strong now, and that's the reward) or sustained skill expression (power converges so mastery stays about play) — and shaping the curve toward it. any game long enough to have a late game or endgame — rpgs, live-service, roguelikes, progression-heavy games. most acute where power compounds. short or session-based games without a meaningful late game don't need an endgame design. deliberate power-fantasy finales (the game wants you to feel unstoppable at the end) are a valid choice, not a failure — the point is that trivialization is chosen and framed as a reward, not stumbled into. decide early whether late-game power converges (caps, diminishing returns, scaling challenge) or crescendos (an intentional power fantasy). guard against runaway positive feedback (sys-0004) if you want convergence. plan a source of continued mastery for the top end — new patterns, higher-skill content, or horizontal variety — so expert players still have somewhere to go (compare design-0005, high skill ceiling). convergent endgame (keep power in check so skill and challenge stay meaningful) vs. crescendo endgame (let power run so the finale is a cathartic power fantasy) are both legitimate, opposite answers. the right one depends on whether the game's late-game pleasure is expression or dominance. the top-of-curve companion to prog-0001 (pacing) and design-0005 (accessible depth / high ceiling), and it's where sys-0004's runaway positive feedback most often bites. confidence 3 — sound reasoning, but endgame design is highly genre-dependent and less settled than the earlier-curve principles."}
{"id":"GDC-L1-ECON-0001","title":"Balance faucets against drains — the flow, not the total, defines the economy","layer":"L1","domain":"ECON","subdomain":"faucets-and-drains","type":"contextual","confidence":4,"status":"canonical","tags":["economy","faucets","drains","sources","sinks","flow"],"related":["GDC-L1-SYS-0008","GDC-L1-SYS-0004","GDC-L1-ECON-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-economy-design","S-adams-dormans-mechanics"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ECON-0001.md","statement":"A game economy is defined by its faucets (sources that create resources) and its drains (sinks that destroy them). Its health is a matter of flow: sinks must remove resources at a rate matched to what faucets generate. Watch the rates, not the stockpiles.","sections":{"Statement":"> A game economy is defined by its **faucets** (sources that create resources) and its\n> **drains** (sinks that destroy them). Its health is a matter of *flow*: sinks must remove\n> resources at a rate matched to what faucets generate. Watch the **rates**, not the\n> stockpiles.","Rationale":"Resources in a game are created from nothing at faucets (quest rewards, loot, minigames)\nand, ideally, destroyed at sinks (repair costs, consumables, fees) [S-economy-design]. What\ndetermines whether the economy stays healthy is the *balance of flows* — if faucets pour in\nfaster than sinks drain out, resources accumulate, purchasing power falls, and the currency\ninflates toward worthlessness (ECON-0004); if sinks over-drain, players feel starved. This is\nthe economy-specific deepening of SYS-0008 (model resources as an internal economy): SYS-0008\nsays treat resources as sources/sinks/converters; this says the *tuning target* is the flow\nrate through them, and it interacts directly with feedback loops (SYS-0004 — a faucet that\nscales with wealth is a positive loop that accelerates inflation). Designers who watch only\nthe current totals miss the trend that will break the economy weeks later.","Applies when":"Any game with accumulating resources — RPGs, MMOs, survival, city-builders, strategy,\neconomy sims, and most progression systems. The larger and longer-lived the resource pools,\nthe more flow balance dominates.","Does not apply / Exceptions":"Games with tiny or no persistent economies (most arcade, action, puzzle) don't need\nflow modeling. Deliberately inflationary designs exist (idle/incremental games are *about*\nnumbers exploding — there the \"economy\" is the spectacle of growth, and control comes from\nscaling costs alongside, not from stable purchasing power). Short, closed-loop economies\n(one playthrough, no persistence) tolerate looser balance.","Implementation (kept separate from the principle)":"Enumerate every faucet and drain and estimate its rate; model the net flow over time (economy\n-simulation tools help) rather than eyeballing current balances. Watch for faucets that scale\nwith player wealth, count, or game age — those are inflation engines (ECON-0004). Tune by\nadjusting rates, and prefer adding/strengthening sinks (ECON-0003) over throttling the fun of\nfaucets. Instrument the live economy (telemetry — PLAYTEST-0005) to catch drift early.","Disagreement":"Little on the flow model itself; debate is about how *tightly* to control the economy —\nstable-purchasing-power design (MMO-style, fight inflation hard) vs. deliberately\ninflationary growth (idle games, where the exploding numbers are the point). The choice\nfollows whether stable value or the spectacle of growth is the goal.","Notes":"The economy-craft deepening of SYS-0008, and tightly coupled to SYS-0004 (feedback loops are\nthe dynamics of the flow). The parent of the more specific ECON principles (sinks, inflation,\ncurrencies). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-ECON-0001\ntitle: Balance faucets against drains — the flow, not the total, defines the economy\nlayer: L1\ndomain: ECON\nsubdomain: faucets-and-drains\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - economy\n  - faucets\n  - drains\n  - sources\n  - sinks\n  - flow\nrelated:\n  - GDC-L1-SYS-0008\n  - GDC-L1-SYS-0004\n  - GDC-L1-ECON-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-economy-design\n  - S-adams-dormans-mechanics\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A game economy is defined by its **faucets** (sources that create resources) and its\n> **drains** (sinks that destroy them). Its health is a matter of *flow*: sinks must remove\n> resources at a rate matched to what faucets generate. Watch the **rates**, not the\n> stockpiles.\n\n## Rationale\nResources in a game are created from nothing at faucets (quest rewards, loot, minigames)\nand, ideally, destroyed at sinks (repair costs, consumables, fees) [S-economy-design]. What\ndetermines whether the economy stays healthy is the *balance of flows* — if faucets pour in\nfaster than sinks drain out, resources accumulate, purchasing power falls, and the currency\ninflates toward worthlessness (ECON-0004); if sinks over-drain, players feel starved. This is\nthe economy-specific deepening of SYS-0008 (model resources as an internal economy): SYS-0008\nsays treat resources as sources/sinks/converters; this says the *tuning target* is the flow\nrate through them, and it interacts directly with feedback loops (SYS-0004 — a faucet that\nscales with wealth is a positive loop that accelerates inflation). Designers who watch only\nthe current totals miss the trend that will break the economy weeks later.\n\n## Applies when\nAny game with accumulating resources — RPGs, MMOs, survival, city-builders, strategy,\neconomy sims, and most progression systems. The larger and longer-lived the resource pools,\nthe more flow balance dominates.\n\n## Does not apply / Exceptions\nGames with tiny or no persistent economies (most arcade, action, puzzle) don't need\nflow modeling. Deliberately inflationary designs exist (idle/incremental games are *about*\nnumbers exploding — there the \"economy\" is the spectacle of growth, and control comes from\nscaling costs alongside, not from stable purchasing power). Short, closed-loop economies\n(one playthrough, no persistence) tolerate looser balance.\n\n## Implementation (kept separate from the principle)\nEnumerate every faucet and drain and estimate its rate; model the net flow over time (economy\n-simulation tools help) rather than eyeballing current balances. Watch for faucets that scale\nwith player wealth, count, or game age — those are inflation engines (ECON-0004). Tune by\nadjusting rates, and prefer adding/strengthening sinks (ECON-0003) over throttling the fun of\nfaucets. Instrument the live economy (telemetry — PLAYTEST-0005) to catch drift early.\n\n## Disagreement\nLittle on the flow model itself; debate is about how *tightly* to control the economy —\nstable-purchasing-power design (MMO-style, fight inflation hard) vs. deliberately\ninflationary growth (idle games, where the exploding numbers are the point). The choice\nfollows whether stable value or the spectacle of growth is the goal.\n\n## Notes\nThe economy-craft deepening of SYS-0008, and tightly coupled to SYS-0004 (feedback loops are\nthe dynamics of the flow). The parent of the more specific ECON principles (sinks, inflation,\ncurrencies). Confidence 4.\n","searchText":"gdc-l1-econ-0001 balance faucets against drains — the flow, not the total, defines the economy economy faucets drains sources sinks flow > a game economy is defined by its faucets (sources that create resources) and its drains (sinks that destroy them). its health is a matter of flow: sinks must remove resources at a rate matched to what faucets generate. watch the rates, not the stockpiles. resources in a game are created from nothing at faucets (quest rewards, loot, minigames) and, ideally, destroyed at sinks (repair costs, consumables, fees) [s-economy-design]. what determines whether the economy stays healthy is the balance of flows — if faucets pour in faster than sinks drain out, resources accumulate, purchasing power falls, and the currency inflates toward worthlessness (econ-0004); if sinks over-drain, players feel starved. this is the economy-specific deepening of sys-0008 (model resources as an internal economy): sys-0008 says treat resources as sources/sinks/converters; this says the tuning target is the flow rate through them, and it interacts directly with feedback loops (sys-0004 — a faucet that scales with wealth is a positive loop that accelerates inflation). designers who watch only the current totals miss the trend that will break the economy weeks later. any game with accumulating resources — rpgs, mmos, survival, city-builders, strategy, economy sims, and most progression systems. the larger and longer-lived the resource pools, the more flow balance dominates. games with tiny or no persistent economies (most arcade, action, puzzle) don't need flow modeling. deliberately inflationary designs exist (idle/incremental games are about numbers exploding — there the \"economy\" is the spectacle of growth, and control comes from scaling costs alongside, not from stable purchasing power). short, closed-loop economies (one playthrough, no persistence) tolerate looser balance. enumerate every faucet and drain and estimate its rate; model the net flow over time (economy -simulation tools help) rather than eyeballing current balances. watch for faucets that scale with player wealth, count, or game age — those are inflation engines (econ-0004). tune by adjusting rates, and prefer adding/strengthening sinks (econ-0003) over throttling the fun of faucets. instrument the live economy (telemetry — playtest-0005) to catch drift early. little on the flow model itself; debate is about how tightly to control the economy — stable-purchasing-power design (mmo-style, fight inflation hard) vs. deliberately inflationary growth (idle games, where the exploding numbers are the point). the choice follows whether stable value or the spectacle of growth is the goal. the economy-craft deepening of sys-0008, and tightly coupled to sys-0004 (feedback loops are the dynamics of the flow). the parent of the more specific econ principles (sinks, inflation, currencies). confidence 4."}
{"id":"GDC-L1-ECON-0002","title":"Scarcity creates value and decisions","layer":"L1","domain":"ECON","subdomain":"scarcity","type":"contextual","confidence":4,"status":"canonical","tags":["economy","scarcity","value","decisions","resources"],"related":["GDC-L1-DESIGN-0002","GDC-L1-BAL-0002","GDC-L1-ECON-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-economy-design"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ECON-0002.md","statement":"A resource matters only when it is scarce enough to force choices. Abundance trivializes — if you can have everything, there's nothing to decide; over-scarcity frustrates and paralyzes. Tune scarcity so that spending a resource is a real tradeoff.","sections":{"Statement":"> A resource matters only when it is scarce enough to force choices. Abundance trivializes —\n> if you can have everything, there's nothing to decide; over-scarcity frustrates and\n> paralyzes. Tune scarcity so that spending a resource is a real tradeoff.","Rationale":"Value is a function of scarcity: a resource the player has in unlimited supply carries no\nweight, so decisions about it are hollow (buy everything, use freely, feel nothing)\n[S-economy-design]. Meaningful resource decisions — *this potion now or save it? this upgrade\nor that one?* — only exist when having one thing means forgoing another, which requires\nscarcity. This is DESIGN-0002 (interesting decisions) expressed through economics: scarcity is\nwhat makes a spending choice a genuine tradeoff rather than a formality, and it's what gives\nrewards their emotional weight. But the dial has two bad ends — abundance drains meaning, and\ncrushing scarcity produces frustration, hoarding (players too afraid to spend), and analysis\nparalysis. The craft is finding the tension in between.","Applies when":"Any resource the player accumulates and spends — currency, consumables, materials, action\neconomy, time. Central to RPG, survival, strategy, and roguellike design.","Does not apply / Exceptions":"Some resources are *meant* to be abundant — a resource that exists to be spent freely for\nexpressive or comfort reasons (cosmetic currency, generous ammo in a power-fantasy shooter)\nshouldn't be artificially starved. Power-fantasy and relaxation designs deliberately loosen\nscarcity. And scarcity that's too tight in a *learning* context (early game) can gate players\nout; scarcity often tightens as mastery grows.","Implementation (kept separate from the principle)":"Tune each resource's scarcity to the weight you want its decisions to carry — tighter for\nresources meant to create tension, looser for those meant to enable expression. Watch for\nhoarding (a sign of either too much scarcity or unclear value) and for trivializing abundance\n(a sign of weak sinks — ECON-0003). Scarcity and the faucet/drain balance (ECON-0001) are the\nsame dial seen from two angles.","Disagreement":"Tight scarcity (tension, meaningful decisions, survival stakes) vs. generous abundance (power\nfantasy, expression, low friction) — both are valid depending on whether the resource is meant\nto create *tension* or enable *freedom*. Over-scarcity's frustration and abundance's\nmeaninglessness are the two failure modes to steer between.","Notes":"The value-and-decision rationale beneath the flow model (ECON-0001) and a direct economic\nexpression of DESIGN-0002 (interesting decisions) and BAL-0002 (meaningful choice). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-ECON-0002\ntitle: Scarcity creates value and decisions\nlayer: L1\ndomain: ECON\nsubdomain: scarcity\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - economy\n  - scarcity\n  - value\n  - decisions\n  - resources\nrelated:\n  - GDC-L1-DESIGN-0002\n  - GDC-L1-BAL-0002\n  - GDC-L1-ECON-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-economy-design\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A resource matters only when it is scarce enough to force choices. Abundance trivializes —\n> if you can have everything, there's nothing to decide; over-scarcity frustrates and\n> paralyzes. Tune scarcity so that spending a resource is a real tradeoff.\n\n## Rationale\nValue is a function of scarcity: a resource the player has in unlimited supply carries no\nweight, so decisions about it are hollow (buy everything, use freely, feel nothing)\n[S-economy-design]. Meaningful resource decisions — *this potion now or save it? this upgrade\nor that one?* — only exist when having one thing means forgoing another, which requires\nscarcity. This is DESIGN-0002 (interesting decisions) expressed through economics: scarcity is\nwhat makes a spending choice a genuine tradeoff rather than a formality, and it's what gives\nrewards their emotional weight. But the dial has two bad ends — abundance drains meaning, and\ncrushing scarcity produces frustration, hoarding (players too afraid to spend), and analysis\nparalysis. The craft is finding the tension in between.\n\n## Applies when\nAny resource the player accumulates and spends — currency, consumables, materials, action\neconomy, time. Central to RPG, survival, strategy, and roguellike design.\n\n## Does not apply / Exceptions\nSome resources are *meant* to be abundant — a resource that exists to be spent freely for\nexpressive or comfort reasons (cosmetic currency, generous ammo in a power-fantasy shooter)\nshouldn't be artificially starved. Power-fantasy and relaxation designs deliberately loosen\nscarcity. And scarcity that's too tight in a *learning* context (early game) can gate players\nout; scarcity often tightens as mastery grows.\n\n## Implementation (kept separate from the principle)\nTune each resource's scarcity to the weight you want its decisions to carry — tighter for\nresources meant to create tension, looser for those meant to enable expression. Watch for\nhoarding (a sign of either too much scarcity or unclear value) and for trivializing abundance\n(a sign of weak sinks — ECON-0003). Scarcity and the faucet/drain balance (ECON-0001) are the\nsame dial seen from two angles.\n\n## Disagreement\nTight scarcity (tension, meaningful decisions, survival stakes) vs. generous abundance (power\nfantasy, expression, low friction) — both are valid depending on whether the resource is meant\nto create *tension* or enable *freedom*. Over-scarcity's frustration and abundance's\nmeaninglessness are the two failure modes to steer between.\n\n## Notes\nThe value-and-decision rationale beneath the flow model (ECON-0001) and a direct economic\nexpression of DESIGN-0002 (interesting decisions) and BAL-0002 (meaningful choice). Confidence 4.\n","searchText":"gdc-l1-econ-0002 scarcity creates value and decisions economy scarcity value decisions resources > a resource matters only when it is scarce enough to force choices. abundance trivializes — if you can have everything, there's nothing to decide; over-scarcity frustrates and paralyzes. tune scarcity so that spending a resource is a real tradeoff. value is a function of scarcity: a resource the player has in unlimited supply carries no weight, so decisions about it are hollow (buy everything, use freely, feel nothing) [s-economy-design]. meaningful resource decisions — this potion now or save it? this upgrade or that one? — only exist when having one thing means forgoing another, which requires scarcity. this is design-0002 (interesting decisions) expressed through economics: scarcity is what makes a spending choice a genuine tradeoff rather than a formality, and it's what gives rewards their emotional weight. but the dial has two bad ends — abundance drains meaning, and crushing scarcity produces frustration, hoarding (players too afraid to spend), and analysis paralysis. the craft is finding the tension in between. any resource the player accumulates and spends — currency, consumables, materials, action economy, time. central to rpg, survival, strategy, and roguellike design. some resources are meant to be abundant — a resource that exists to be spent freely for expressive or comfort reasons (cosmetic currency, generous ammo in a power-fantasy shooter) shouldn't be artificially starved. power-fantasy and relaxation designs deliberately loosen scarcity. and scarcity that's too tight in a learning context (early game) can gate players out; scarcity often tightens as mastery grows. tune each resource's scarcity to the weight you want its decisions to carry — tighter for resources meant to create tension, looser for those meant to enable expression. watch for hoarding (a sign of either too much scarcity or unclear value) and for trivializing abundance (a sign of weak sinks — econ-0003). scarcity and the faucet/drain balance (econ-0001) are the same dial seen from two angles. tight scarcity (tension, meaningful decisions, survival stakes) vs. generous abundance (power fantasy, expression, low friction) — both are valid depending on whether the resource is meant to create tension or enable freedom. over-scarcity's frustration and abundance's meaninglessness are the two failure modes to steer between. the value-and-decision rationale beneath the flow model (econ-0001) and a direct economic expression of design-0002 (interesting decisions) and bal-0002 (meaningful choice). confidence 4."}
{"id":"GDC-L1-ECON-0003","title":"Design sinks deliberately — the missing half of most economies","layer":"L1","domain":"ECON","subdomain":"sources-and-sinks","type":"contextual","confidence":4,"status":"canonical","tags":["economy","sinks","drains","inflation","spending"],"related":["GDC-L1-ECON-0001","GDC-L1-ECON-0004","GDC-L1-ECON-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-economy-design"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ECON-0003.md","statement":"Most economy problems are missing or weak sinks. Faucets are easy and fun to add — rewards feel good to give — while sinks (compelling reasons to spend or destroy resources) are harder to design and routinely neglected, which is why inflation and hoarding are the default failure states. Design sinks as carefully as sources.","sections":{"Statement":"> Most economy problems are missing or weak **sinks**. Faucets are easy and fun to add —\n> rewards feel good to give — while sinks (compelling reasons to *spend* or *destroy*\n> resources) are harder to design and routinely neglected, which is why inflation and\n> hoarding are the default failure states. Design sinks as carefully as sources.","Rationale":"There is an asymmetry in how economies get built: giving players resources is rewarding and\ngets attention, so faucets proliferate, while sinks — which take resources *away* — feel less\ngenerous and get under-designed [S-economy-design]. The result is predictable: resources\naccumulate faster than they leave, the currency inflates (ECON-0004), and a rich player has\nnothing worth buying. The fix is to treat sinks as first-class design: give players things\nthey genuinely *want* to spend on, so draining resources feels like a choice they make, not a\ntax. And distinguish sink types — a **hard sink** destroys value (repair costs, consumables,\nfees) and truly fights inflation; a **soft sink** merely *transfers* value between players\n(buying from another player) and does *not* remove it from the economy. When you need to\ncontrol inflation, you need hard sinks.","Applies when":"Any accumulating economy, especially persistent and multiplayer ones (MMOs, live-service,\neconomy sims) where resources pile up over months and inflation compounds.","Does not apply / Exceptions":"Short, non-persistent economies (one playthrough) can tolerate weak sinks — there's not\nenough time for inflation to bite. Deliberately generous power-fantasy designs may want few\nsinks. And sinks must be *attractive*, not punitive — a sink players resent (arbitrary decay,\npunitive taxes) drains fun along with resources; the goal is desirable spending, not\nconfiscation.","Implementation (kept separate from the principle)":"Audit the ratio of faucets to sinks in your design — if faucets outnumber compelling sinks,\nthat's the bug. Add sinks players *want* to use (aspirational purchases, upgrades,\ncustomization, consumables, services). Favor hard sinks (destroy value) where inflation is a\nrisk; know that player-to-player trade is a soft sink that doesn't help. Scale sink cost with\nplayer wealth so the rich have somewhere to spend (a \"gold sink\").","Disagreement":"Little that sinks are necessary; the nuance is *how* to drain — attractive, aspirational\nsinks (players want to spend) vs. structural sinks (decay, taxes, upkeep that players may\nresent). Aspirational sinks preserve fun; structural sinks are reliable but can feel punitive.\nMost healthy economies use both, weighted toward the aspirational.","Notes":"The most commonly-neglected half of the faucet/drain balance (ECON-0001) and the direct lever\nagainst inflation (ECON-0004). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-ECON-0003\ntitle: Design sinks deliberately — the missing half of most economies\nlayer: L1\ndomain: ECON\nsubdomain: sources-and-sinks\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - economy\n  - sinks\n  - drains\n  - inflation\n  - spending\nrelated:\n  - GDC-L1-ECON-0001\n  - GDC-L1-ECON-0004\n  - GDC-L1-ECON-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-economy-design\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Most economy problems are missing or weak **sinks**. Faucets are easy and fun to add —\n> rewards feel good to give — while sinks (compelling reasons to *spend* or *destroy*\n> resources) are harder to design and routinely neglected, which is why inflation and\n> hoarding are the default failure states. Design sinks as carefully as sources.\n\n## Rationale\nThere is an asymmetry in how economies get built: giving players resources is rewarding and\ngets attention, so faucets proliferate, while sinks — which take resources *away* — feel less\ngenerous and get under-designed [S-economy-design]. The result is predictable: resources\naccumulate faster than they leave, the currency inflates (ECON-0004), and a rich player has\nnothing worth buying. The fix is to treat sinks as first-class design: give players things\nthey genuinely *want* to spend on, so draining resources feels like a choice they make, not a\ntax. And distinguish sink types — a **hard sink** destroys value (repair costs, consumables,\nfees) and truly fights inflation; a **soft sink** merely *transfers* value between players\n(buying from another player) and does *not* remove it from the economy. When you need to\ncontrol inflation, you need hard sinks.\n\n## Applies when\nAny accumulating economy, especially persistent and multiplayer ones (MMOs, live-service,\neconomy sims) where resources pile up over months and inflation compounds.\n\n## Does not apply / Exceptions\nShort, non-persistent economies (one playthrough) can tolerate weak sinks — there's not\nenough time for inflation to bite. Deliberately generous power-fantasy designs may want few\nsinks. And sinks must be *attractive*, not punitive — a sink players resent (arbitrary decay,\npunitive taxes) drains fun along with resources; the goal is desirable spending, not\nconfiscation.\n\n## Implementation (kept separate from the principle)\nAudit the ratio of faucets to sinks in your design — if faucets outnumber compelling sinks,\nthat's the bug. Add sinks players *want* to use (aspirational purchases, upgrades,\ncustomization, consumables, services). Favor hard sinks (destroy value) where inflation is a\nrisk; know that player-to-player trade is a soft sink that doesn't help. Scale sink cost with\nplayer wealth so the rich have somewhere to spend (a \"gold sink\").\n\n## Disagreement\nLittle that sinks are necessary; the nuance is *how* to drain — attractive, aspirational\nsinks (players want to spend) vs. structural sinks (decay, taxes, upkeep that players may\nresent). Aspirational sinks preserve fun; structural sinks are reliable but can feel punitive.\nMost healthy economies use both, weighted toward the aspirational.\n\n## Notes\nThe most commonly-neglected half of the faucet/drain balance (ECON-0001) and the direct lever\nagainst inflation (ECON-0004). Confidence 4.\n","searchText":"gdc-l1-econ-0003 design sinks deliberately — the missing half of most economies economy sinks drains inflation spending > most economy problems are missing or weak sinks. faucets are easy and fun to add — rewards feel good to give — while sinks (compelling reasons to spend or destroy resources) are harder to design and routinely neglected, which is why inflation and hoarding are the default failure states. design sinks as carefully as sources. there is an asymmetry in how economies get built: giving players resources is rewarding and gets attention, so faucets proliferate, while sinks — which take resources away — feel less generous and get under-designed [s-economy-design]. the result is predictable: resources accumulate faster than they leave, the currency inflates (econ-0004), and a rich player has nothing worth buying. the fix is to treat sinks as first-class design: give players things they genuinely want to spend on, so draining resources feels like a choice they make, not a tax. and distinguish sink types — a hard sink destroys value (repair costs, consumables, fees) and truly fights inflation; a soft sink merely transfers value between players (buying from another player) and does not remove it from the economy. when you need to control inflation, you need hard sinks. any accumulating economy, especially persistent and multiplayer ones (mmos, live-service, economy sims) where resources pile up over months and inflation compounds. short, non-persistent economies (one playthrough) can tolerate weak sinks — there's not enough time for inflation to bite. deliberately generous power-fantasy designs may want few sinks. and sinks must be attractive, not punitive — a sink players resent (arbitrary decay, punitive taxes) drains fun along with resources; the goal is desirable spending, not confiscation. audit the ratio of faucets to sinks in your design — if faucets outnumber compelling sinks, that's the bug. add sinks players want to use (aspirational purchases, upgrades, customization, consumables, services). favor hard sinks (destroy value) where inflation is a risk; know that player-to-player trade is a soft sink that doesn't help. scale sink cost with player wealth so the rich have somewhere to spend (a \"gold sink\"). little that sinks are necessary; the nuance is how to drain — attractive, aspirational sinks (players want to spend) vs. structural sinks (decay, taxes, upkeep that players may resent). aspirational sinks preserve fun; structural sinks are reliable but can feel punitive. most healthy economies use both, weighted toward the aspirational. the most commonly-neglected half of the faucet/drain balance (econ-0001) and the direct lever against inflation (econ-0004). confidence 4."}
{"id":"GDC-L1-ECON-0004","title":"Guard against inflation and runaway accumulation","layer":"L1","domain":"ECON","subdomain":"inflation","type":"contextual","confidence":4,"status":"canonical","tags":["economy","inflation","runaway","feedback-loops","money-supply"],"related":["GDC-L1-SYS-0004","GDC-L1-PROG-0006","GDC-L1-ECON-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-economy-design","S-adams-dormans-mechanics"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ECON-0004.md","statement":"Unchecked faucets — and positive feedback loops that scale rewards with the wealth or progress a player already has — cause inflation: currency loses value, stockpiles pile up, and spending stops mattering. Monitor the money supply and drain the excess. The symptom looks like \"the content got trivial,\" but the cause is economic.","sections":{"Statement":"> Unchecked faucets — and positive feedback loops that scale rewards with the wealth or\n> progress a player already has — cause **inflation**: currency loses value, stockpiles pile\n> up, and spending stops mattering. Monitor the money supply and drain the excess. The\n> symptom looks like \"the content got trivial,\" but the cause is economic.","Rationale":"Inflation is the natural end state of an economy whose faucets outpace its sinks, and it's\nmade worse by feedback: if wealthier players earn *faster* (a positive loop — SYS-0004), the\nmoney supply grows super-linearly and value collapses [S-economy-design]. Its damage is\ninsidious because it disguises itself — designers see rewards feeling meaningless, prices\nfeeling trivial, new players unable to afford anything a veteran casually owns, and reach for\ncontent or difficulty fixes when the real cause is too much currency chasing too few sinks.\nThis is the economic face of runaway positive feedback (SYS-0004) and of the unplanned power\ncurve (PROG-0006): unchecked accumulation trivializes the game whether the resource is gold or\nraw power.","Applies when":"Persistent and long-lived economies especially — MMOs, live-service, economy sims — and any\ngame where resources accumulate across a long play horizon.","Does not apply / Exceptions":"Idle/incremental games are *deliberately* inflationary — the exploding numbers are the\nappeal, and they control it by scaling *costs* alongside income rather than by stabilizing\nvalue. Short, non-persistent economies rarely inflate meaningfully. Mild, managed inflation\ncan even be healthy (it pressures players to keep engaging with the economy rather than\nsitting on a hoard).","Implementation (kept separate from the principle)":"Track the total money supply and prices over time, not just per-player balances (telemetry —\nPLAYTEST-0005). Avoid or dampen faucets that scale with wealth/progress (SYS-0004). Keep hard\nsinks (ECON-0003) sized to the money being generated, and scale sink costs with wealth so the\nrichest players still drain. Treat \"rewards feel meaningless\" as a possible economy signal,\nnot just a tuning-numbers one.","Disagreement":"Stable-value design (fight inflation to keep purchasing power and new-player viability) vs.\nmanaged-inflation or deliberately-inflationary design (idle games; or mild inflation used to\nkeep players economically active). The right stance depends on whether stable value or growth-\nas-spectacle serves the game.","Notes":"The economic form of SYS-0004 (runaway positive feedback) and PROG-0006 (runaway power); its\nprimary countermeasure is deliberate sinks (ECON-0003). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-ECON-0004\ntitle: Guard against inflation and runaway accumulation\nlayer: L1\ndomain: ECON\nsubdomain: inflation\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - economy\n  - inflation\n  - runaway\n  - feedback-loops\n  - money-supply\nrelated:\n  - GDC-L1-SYS-0004\n  - GDC-L1-PROG-0006\n  - GDC-L1-ECON-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-economy-design\n  - S-adams-dormans-mechanics\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Unchecked faucets — and positive feedback loops that scale rewards with the wealth or\n> progress a player already has — cause **inflation**: currency loses value, stockpiles pile\n> up, and spending stops mattering. Monitor the money supply and drain the excess. The\n> symptom looks like \"the content got trivial,\" but the cause is economic.\n\n## Rationale\nInflation is the natural end state of an economy whose faucets outpace its sinks, and it's\nmade worse by feedback: if wealthier players earn *faster* (a positive loop — SYS-0004), the\nmoney supply grows super-linearly and value collapses [S-economy-design]. Its damage is\ninsidious because it disguises itself — designers see rewards feeling meaningless, prices\nfeeling trivial, new players unable to afford anything a veteran casually owns, and reach for\ncontent or difficulty fixes when the real cause is too much currency chasing too few sinks.\nThis is the economic face of runaway positive feedback (SYS-0004) and of the unplanned power\ncurve (PROG-0006): unchecked accumulation trivializes the game whether the resource is gold or\nraw power.\n\n## Applies when\nPersistent and long-lived economies especially — MMOs, live-service, economy sims — and any\ngame where resources accumulate across a long play horizon.\n\n## Does not apply / Exceptions\nIdle/incremental games are *deliberately* inflationary — the exploding numbers are the\nappeal, and they control it by scaling *costs* alongside income rather than by stabilizing\nvalue. Short, non-persistent economies rarely inflate meaningfully. Mild, managed inflation\ncan even be healthy (it pressures players to keep engaging with the economy rather than\nsitting on a hoard).\n\n## Implementation (kept separate from the principle)\nTrack the total money supply and prices over time, not just per-player balances (telemetry —\nPLAYTEST-0005). Avoid or dampen faucets that scale with wealth/progress (SYS-0004). Keep hard\nsinks (ECON-0003) sized to the money being generated, and scale sink costs with wealth so the\nrichest players still drain. Treat \"rewards feel meaningless\" as a possible economy signal,\nnot just a tuning-numbers one.\n\n## Disagreement\nStable-value design (fight inflation to keep purchasing power and new-player viability) vs.\nmanaged-inflation or deliberately-inflationary design (idle games; or mild inflation used to\nkeep players economically active). The right stance depends on whether stable value or growth-\nas-spectacle serves the game.\n\n## Notes\nThe economic form of SYS-0004 (runaway positive feedback) and PROG-0006 (runaway power); its\nprimary countermeasure is deliberate sinks (ECON-0003). Confidence 4.\n","searchText":"gdc-l1-econ-0004 guard against inflation and runaway accumulation economy inflation runaway feedback-loops money-supply > unchecked faucets — and positive feedback loops that scale rewards with the wealth or progress a player already has — cause inflation: currency loses value, stockpiles pile up, and spending stops mattering. monitor the money supply and drain the excess. the symptom looks like \"the content got trivial,\" but the cause is economic. inflation is the natural end state of an economy whose faucets outpace its sinks, and it's made worse by feedback: if wealthier players earn faster (a positive loop — sys-0004), the money supply grows super-linearly and value collapses [s-economy-design]. its damage is insidious because it disguises itself — designers see rewards feeling meaningless, prices feeling trivial, new players unable to afford anything a veteran casually owns, and reach for content or difficulty fixes when the real cause is too much currency chasing too few sinks. this is the economic face of runaway positive feedback (sys-0004) and of the unplanned power curve (prog-0006): unchecked accumulation trivializes the game whether the resource is gold or raw power. persistent and long-lived economies especially — mmos, live-service, economy sims — and any game where resources accumulate across a long play horizon. idle/incremental games are deliberately inflationary — the exploding numbers are the appeal, and they control it by scaling costs alongside income rather than by stabilizing value. short, non-persistent economies rarely inflate meaningfully. mild, managed inflation can even be healthy (it pressures players to keep engaging with the economy rather than sitting on a hoard). track the total money supply and prices over time, not just per-player balances (telemetry — playtest-0005). avoid or dampen faucets that scale with wealth/progress (sys-0004). keep hard sinks (econ-0003) sized to the money being generated, and scale sink costs with wealth so the richest players still drain. treat \"rewards feel meaningless\" as a possible economy signal, not just a tuning-numbers one. stable-value design (fight inflation to keep purchasing power and new-player viability) vs. managed-inflation or deliberately-inflationary design (idle games; or mild inflation used to keep players economically active). the right stance depends on whether stable value or growth- as-spectacle serves the game. the economic form of sys-0004 (runaway positive feedback) and prog-0006 (runaway power); its primary countermeasure is deliberate sinks (econ-0003). confidence 4."}
{"id":"GDC-L1-ECON-0005","title":"Give each currency a distinct purpose","layer":"L1","domain":"ECON","subdomain":"currencies","type":"contextual","confidence":3,"status":"canonical","tags":["economy","currencies","orthogonality","elegance"],"related":["GDC-L1-SYS-0005","GDC-L1-DESIGN-0007","GDC-L1-ECON-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-economy-design"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ECON-0005.md","statement":"Each currency or resource type should have a clear, distinct role. When multiple currencies collapse into one fungible pile — same sources, same uses — they add complexity without meaning. Separate currencies to segment the economy and create distinct decisions, but only add a currency that earns its place.","sections":{"Statement":"> Each currency or resource type should have a clear, distinct role. When multiple currencies\n> collapse into one fungible pile — same sources, same uses — they add complexity without\n> meaning. Separate currencies to segment the economy and create distinct decisions, but only\n> add a currency that earns its place.","Rationale":"Multiple currencies are a tool for *segmenting* an economy: a currency earned only one way and\nspent only on one thing creates a separate, controllable sub-economy with its own faucets and\nsinks (ECON-0001) — which is why games use distinct currencies for, say, routine spending vs.\nrare aspirational purchases vs. time-gated progression. But the tool is often misused: piling\non currencies that are acquired and spent interchangeably just multiplies the UI and the\nplayer's mental load without adding a single real decision. This is orthogonality (SYS-0005)\nand elegance (DESIGN-0007) applied to economics: each currency must do something no other does,\nor it shouldn't exist. Distinct currencies also let you protect one economy from another's\ninflation (a premium or progression currency insulated from the grindable one).","Applies when":"Designing the set of currencies/resources — most acute in RPGs, live-service, and F2P games\nthat tend to accumulate many currencies over time.","Does not apply / Exceptions":"Many games are better with a *single* clean currency — added currencies are only worth it when\nsegmentation genuinely helps, and a proliferation of currencies is a common, real design smell\n(confusing, grindy, opaque). Some multi-currency systems in live games exist for monetization\nsegmentation rather than player benefit (a MON/ethics concern, not a pure economy one). Default\nto fewer currencies; add one only when it earns a distinct role.","Implementation (kept separate from the principle)":"For each currency, state its unique role: how it's earned, what it buys, and why it isn't just\nthe main currency. If two currencies share sources and sinks, merge them. Use separate\ncurrencies deliberately to insulate economies from each other's inflation, to gate progression,\nor to separate routine from aspirational spending — not by accident. Watch the UI/cognitive\ncost (UX-0002) that each currency adds.","Disagreement":"Single-currency simplicity (clean, legible, fewer sinks to balance) vs. multi-currency\nsegmentation (controllable sub-economies, insulated inflation, distinct decisions — at the cost\nof complexity and, sometimes, monetization-driven confusion). Lean simple; segment only where\nit pays.","Notes":"The economic expression of orthogonality (SYS-0005) and elegance (DESIGN-0007) — no redundant\ncurrencies. Confidence 3: a sound heuristic, but \"how many currencies\" is genuinely\ngame-dependent and often distorted by monetization pressures."},"rawMarkdown":"---\nid: GDC-L1-ECON-0005\ntitle: Give each currency a distinct purpose\nlayer: L1\ndomain: ECON\nsubdomain: currencies\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - economy\n  - currencies\n  - orthogonality\n  - elegance\nrelated:\n  - GDC-L1-SYS-0005\n  - GDC-L1-DESIGN-0007\n  - GDC-L1-ECON-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-economy-design\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Each currency or resource type should have a clear, distinct role. When multiple currencies\n> collapse into one fungible pile — same sources, same uses — they add complexity without\n> meaning. Separate currencies to segment the economy and create distinct decisions, but only\n> add a currency that earns its place.\n\n## Rationale\nMultiple currencies are a tool for *segmenting* an economy: a currency earned only one way and\nspent only on one thing creates a separate, controllable sub-economy with its own faucets and\nsinks (ECON-0001) — which is why games use distinct currencies for, say, routine spending vs.\nrare aspirational purchases vs. time-gated progression. But the tool is often misused: piling\non currencies that are acquired and spent interchangeably just multiplies the UI and the\nplayer's mental load without adding a single real decision. This is orthogonality (SYS-0005)\nand elegance (DESIGN-0007) applied to economics: each currency must do something no other does,\nor it shouldn't exist. Distinct currencies also let you protect one economy from another's\ninflation (a premium or progression currency insulated from the grindable one).\n\n## Applies when\nDesigning the set of currencies/resources — most acute in RPGs, live-service, and F2P games\nthat tend to accumulate many currencies over time.\n\n## Does not apply / Exceptions\nMany games are better with a *single* clean currency — added currencies are only worth it when\nsegmentation genuinely helps, and a proliferation of currencies is a common, real design smell\n(confusing, grindy, opaque). Some multi-currency systems in live games exist for monetization\nsegmentation rather than player benefit (a MON/ethics concern, not a pure economy one). Default\nto fewer currencies; add one only when it earns a distinct role.\n\n## Implementation (kept separate from the principle)\nFor each currency, state its unique role: how it's earned, what it buys, and why it isn't just\nthe main currency. If two currencies share sources and sinks, merge them. Use separate\ncurrencies deliberately to insulate economies from each other's inflation, to gate progression,\nor to separate routine from aspirational spending — not by accident. Watch the UI/cognitive\ncost (UX-0002) that each currency adds.\n\n## Disagreement\nSingle-currency simplicity (clean, legible, fewer sinks to balance) vs. multi-currency\nsegmentation (controllable sub-economies, insulated inflation, distinct decisions — at the cost\nof complexity and, sometimes, monetization-driven confusion). Lean simple; segment only where\nit pays.\n\n## Notes\nThe economic expression of orthogonality (SYS-0005) and elegance (DESIGN-0007) — no redundant\ncurrencies. Confidence 3: a sound heuristic, but \"how many currencies\" is genuinely\ngame-dependent and often distorted by monetization pressures.\n","searchText":"gdc-l1-econ-0005 give each currency a distinct purpose economy currencies orthogonality elegance > each currency or resource type should have a clear, distinct role. when multiple currencies collapse into one fungible pile — same sources, same uses — they add complexity without meaning. separate currencies to segment the economy and create distinct decisions, but only add a currency that earns its place. multiple currencies are a tool for segmenting an economy: a currency earned only one way and spent only on one thing creates a separate, controllable sub-economy with its own faucets and sinks (econ-0001) — which is why games use distinct currencies for, say, routine spending vs. rare aspirational purchases vs. time-gated progression. but the tool is often misused: piling on currencies that are acquired and spent interchangeably just multiplies the ui and the player's mental load without adding a single real decision. this is orthogonality (sys-0005) and elegance (design-0007) applied to economics: each currency must do something no other does, or it shouldn't exist. distinct currencies also let you protect one economy from another's inflation (a premium or progression currency insulated from the grindable one). designing the set of currencies/resources — most acute in rpgs, live-service, and f2p games that tend to accumulate many currencies over time. many games are better with a single clean currency — added currencies are only worth it when segmentation genuinely helps, and a proliferation of currencies is a common, real design smell (confusing, grindy, opaque). some multi-currency systems in live games exist for monetization segmentation rather than player benefit (a mon/ethics concern, not a pure economy one). default to fewer currencies; add one only when it earns a distinct role. for each currency, state its unique role: how it's earned, what it buys, and why it isn't just the main currency. if two currencies share sources and sinks, merge them. use separate currencies deliberately to insulate economies from each other's inflation, to gate progression, or to separate routine from aspirational spending — not by accident. watch the ui/cognitive cost (ux-0002) that each currency adds. single-currency simplicity (clean, legible, fewer sinks to balance) vs. multi-currency segmentation (controllable sub-economies, insulated inflation, distinct decisions — at the cost of complexity and, sometimes, monetization-driven confusion). lean simple; segment only where it pays. the economic expression of orthogonality (sys-0005) and elegance (design-0007) — no redundant currencies. confidence 3: a sound heuristic, but \"how many currencies\" is genuinely game-dependent and often distorted by monetization pressures."}
{"id":"GDC-L1-ECON-0006","title":"Player-driven economies are emergent systems — design the rules, not the transactions","layer":"L1","domain":"ECON","subdomain":"trade","type":"contextual","confidence":3,"status":"canonical","tags":["economy","player-driven","markets","trade","emergence"],"related":["GDC-L1-SYS-0002","GDC-L1-SYS-0007","GDC-L1-SYS-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-economy-design","S-adams-dormans-mechanics"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ECON-0006.md","statement":"The moment players can trade, a market emerges with its own dynamics — pricing, arbitrage, hoarding, speculation, and real-money-trading pressure — that no designer authored. Design the rules and constraints and let the economy emerge (second-order design), then watch for and curb degenerate outcomes.","sections":{"Statement":"> The moment players can trade, a **market emerges** with its own dynamics — pricing,\n> arbitrage, hoarding, speculation, and real-money-trading pressure — that no designer\n> authored. Design the *rules and constraints* and let the economy emerge (second-order\n> design), then watch for and curb degenerate outcomes.","Rationale":"A player-driven economy is a system, not a set of transactions: once players set prices and\ntrade freely, aggregate behavior produces phenomena you didn't script — supply and demand\ncurves, price bubbles, cornered markets, botting and farming, and real-money trading — exactly\nthe kind of unplanned complexity that emergence (SYS-0003) predicts [S-economy-design]. So you\ncan't design the outcomes directly; you design the *rules* (what's tradeable, transaction\ncosts, market structure, information visibility) and the economy self-organizes around them\n(second-order design, SYS-0002). And because players optimize relentlessly (SYS-0007), a\nplayer-run economy will find and exploit every inefficiency — so the designer's ongoing job is\nto watch the emergent market and intervene against the degenerate cases (runaway inflation,\nexploitative farming, RMT that corrodes the game) without trying to micromanage prices.","Applies when":"Any game with meaningful player-to-player trading or markets — MMOs, trading-heavy multiplayer,\neconomy sims with player exchange.","Does not apply / Exceptions":"Closed/authored economies (single-player, or multiplayer with no trading) have no emergent\nmarket — the designer controls all prices and flows directly, which is simpler and more\ncontrollable. Many games deliberately forbid or tightly constrain trade precisely to *avoid*\nthe emergent-market headaches (bind-on-pickup items, no player trading). Choosing a closed\neconomy is a legitimate way to sidestep this entire problem.","Implementation (kept separate from the principle)":"Decide first whether you even want a player-driven economy — the control cost is high. If you\ndo, design the market's rules (tradeable set, fees as sinks — ECON-0003, information you\nexpose) and expect to *observe and adjust* rather than dictate (telemetry, live-ops).\nAnticipate optimization and exploitation (SYS-0007): botting, arbitrage, RMT. Build hard sinks\nand transaction costs into the market to fight inflation and skim froth.","Disagreement":"Open/player-driven economy (rich emergent trading, player-authored value, but hard to control\nand prone to exploitation) vs. closed/authored economy (fully controllable, simpler, but no\nemergent market life). Sandbox and MMO design leans open; tightly-tuned and single-player design\nleans closed. It's a fundamental structural choice, not a tuning knob.","Notes":"Where ECON meets emergence (SYS-0003), second-order design (SYS-0002), and the optimization\npressure of SYS-0007. Confidence 3: the phenomena are well-established, but player-economy design\nis a specialized, high-variance discipline. Confidence would rise with dedicated MMO-economy\nsources."},"rawMarkdown":"---\nid: GDC-L1-ECON-0006\ntitle: Player-driven economies are emergent systems — design the rules, not the transactions\nlayer: L1\ndomain: ECON\nsubdomain: trade\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - economy\n  - player-driven\n  - markets\n  - trade\n  - emergence\nrelated:\n  - GDC-L1-SYS-0002\n  - GDC-L1-SYS-0007\n  - GDC-L1-SYS-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-economy-design\n  - S-adams-dormans-mechanics\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> The moment players can trade, a **market emerges** with its own dynamics — pricing,\n> arbitrage, hoarding, speculation, and real-money-trading pressure — that no designer\n> authored. Design the *rules and constraints* and let the economy emerge (second-order\n> design), then watch for and curb degenerate outcomes.\n\n## Rationale\nA player-driven economy is a system, not a set of transactions: once players set prices and\ntrade freely, aggregate behavior produces phenomena you didn't script — supply and demand\ncurves, price bubbles, cornered markets, botting and farming, and real-money trading — exactly\nthe kind of unplanned complexity that emergence (SYS-0003) predicts [S-economy-design]. So you\ncan't design the outcomes directly; you design the *rules* (what's tradeable, transaction\ncosts, market structure, information visibility) and the economy self-organizes around them\n(second-order design, SYS-0002). And because players optimize relentlessly (SYS-0007), a\nplayer-run economy will find and exploit every inefficiency — so the designer's ongoing job is\nto watch the emergent market and intervene against the degenerate cases (runaway inflation,\nexploitative farming, RMT that corrodes the game) without trying to micromanage prices.\n\n## Applies when\nAny game with meaningful player-to-player trading or markets — MMOs, trading-heavy multiplayer,\neconomy sims with player exchange.\n\n## Does not apply / Exceptions\nClosed/authored economies (single-player, or multiplayer with no trading) have no emergent\nmarket — the designer controls all prices and flows directly, which is simpler and more\ncontrollable. Many games deliberately forbid or tightly constrain trade precisely to *avoid*\nthe emergent-market headaches (bind-on-pickup items, no player trading). Choosing a closed\neconomy is a legitimate way to sidestep this entire problem.\n\n## Implementation (kept separate from the principle)\nDecide first whether you even want a player-driven economy — the control cost is high. If you\ndo, design the market's rules (tradeable set, fees as sinks — ECON-0003, information you\nexpose) and expect to *observe and adjust* rather than dictate (telemetry, live-ops).\nAnticipate optimization and exploitation (SYS-0007): botting, arbitrage, RMT. Build hard sinks\nand transaction costs into the market to fight inflation and skim froth.\n\n## Disagreement\nOpen/player-driven economy (rich emergent trading, player-authored value, but hard to control\nand prone to exploitation) vs. closed/authored economy (fully controllable, simpler, but no\nemergent market life). Sandbox and MMO design leans open; tightly-tuned and single-player design\nleans closed. It's a fundamental structural choice, not a tuning knob.\n\n## Notes\nWhere ECON meets emergence (SYS-0003), second-order design (SYS-0002), and the optimization\npressure of SYS-0007. Confidence 3: the phenomena are well-established, but player-economy design\nis a specialized, high-variance discipline. Confidence would rise with dedicated MMO-economy\nsources.\n","searchText":"gdc-l1-econ-0006 player-driven economies are emergent systems — design the rules, not the transactions economy player-driven markets trade emergence > the moment players can trade, a market emerges with its own dynamics — pricing, arbitrage, hoarding, speculation, and real-money-trading pressure — that no designer authored. design the rules and constraints and let the economy emerge (second-order design), then watch for and curb degenerate outcomes. a player-driven economy is a system, not a set of transactions: once players set prices and trade freely, aggregate behavior produces phenomena you didn't script — supply and demand curves, price bubbles, cornered markets, botting and farming, and real-money trading — exactly the kind of unplanned complexity that emergence (sys-0003) predicts [s-economy-design]. so you can't design the outcomes directly; you design the rules (what's tradeable, transaction costs, market structure, information visibility) and the economy self-organizes around them (second-order design, sys-0002). and because players optimize relentlessly (sys-0007), a player-run economy will find and exploit every inefficiency — so the designer's ongoing job is to watch the emergent market and intervene against the degenerate cases (runaway inflation, exploitative farming, rmt that corrodes the game) without trying to micromanage prices. any game with meaningful player-to-player trading or markets — mmos, trading-heavy multiplayer, economy sims with player exchange. closed/authored economies (single-player, or multiplayer with no trading) have no emergent market — the designer controls all prices and flows directly, which is simpler and more controllable. many games deliberately forbid or tightly constrain trade precisely to avoid the emergent-market headaches (bind-on-pickup items, no player trading). choosing a closed economy is a legitimate way to sidestep this entire problem. decide first whether you even want a player-driven economy — the control cost is high. if you do, design the market's rules (tradeable set, fees as sinks — econ-0003, information you expose) and expect to observe and adjust rather than dictate (telemetry, live-ops). anticipate optimization and exploitation (sys-0007): botting, arbitrage, rmt. build hard sinks and transaction costs into the market to fight inflation and skim froth. open/player-driven economy (rich emergent trading, player-authored value, but hard to control and prone to exploitation) vs. closed/authored economy (fully controllable, simpler, but no emergent market life). sandbox and mmo design leans open; tightly-tuned and single-player design leans closed. it's a fundamental structural choice, not a tuning knob. where econ meets emergence (sys-0003), second-order design (sys-0002), and the optimization pressure of sys-0007. confidence 3: the phenomena are well-established, but player-economy design is a specialized, high-variance discipline. confidence would rise with dedicated mmo-economy sources."}
{"id":"GDC-L1-BAL-0001","title":"Decide what balance is for before you tune","layer":"L1","domain":"BAL","subdomain":"balance-philosophy","type":"contextual","confidence":4,"status":"canonical","tags":["balance","philosophy","fairness","intent"],"related":["GDC-L1-BAL-0006","GDC-L1-DESIGN-0001","GDC-L1-BAL-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-schell-artofgamedesign","S-schreiber-balance"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-BAL-0001.md","statement":"\"Balanced\" is meaningless without a goal. Decide what balance serves — competitive integrity, viable variety, a power fantasy, a difficulty target, a fair economy — because different goals demand opposite tuning. Balance toward the intended experience, not toward an abstract notion of \"fairness.\"","sections":{"Statement":"> \"Balanced\" is meaningless without a goal. Decide *what* balance serves — competitive\n> integrity, viable variety, a power fantasy, a difficulty target, a fair economy — because\n> different goals demand opposite tuning. Balance toward the intended experience, not toward\n> an abstract notion of \"fairness.\"","Rationale":"Balance is not one thing; it's a family of goals that often conflict, and the word hides\nwhich one you mean [S-schell-artofgamedesign]. Tuning a competitive game so every option is\nviable at expert level is a completely different job from tuning a power-fantasy RPG (where\nthe player is *supposed* to become overwhelmingly strong) or a co-op game (where balance\nmeans everyone contributes) or a horror game (where \"unfair\" is the point). Chasing generic\n\"fairness\" without naming the target produces incoherent results — nerfing something that\nwas doing exactly what the design wanted, or \"balancing\" the fun out of a deliberately\nlopsided moment. Naming the goal (this is DESIGN-0001 applied to numbers: balance for the\nexperience produced) turns tuning from vague fiddling into aimed work.","Applies when":"Before and during any balance pass, and any time someone says something is \"unbalanced\" —\nthe first question is \"relative to what goal?\"","Does not apply / Exceptions":"Not an exception so much as a caution: even within one game, different subsystems may have\ndifferent balance goals (the competitive PvP mode vs. the power-fantasy campaign), so\n\"decide what balance is for\" is per-context, not one global answer. And some games\ngenuinely want *imbalance* as an experience (asymmetric horror, David-vs-Goliath), which is\na legitimate goal, not a failure to balance.","Implementation (kept separate from the principle)":"State the balance goal for each system explicitly (e.g. \"all five archetypes should be\nviable for a full playthrough\" vs. \"the mage should feel strongest late\"). Judge tuning\nchanges against that goal, not against a reflex toward parity. Recognize when a subsystem's\ngoal differs from the game's and tune it on its own terms. Revisit the goal if the design\nshifts.","Disagreement":"Balance-as-fairness (parity, competitive integrity) vs. balance-as-experience (tune toward\nthe intended feeling, even if \"unfair\") is the philosophical split under the whole domain.\nCompetitive games lean fairness; single-player and authored experiences lean experience.\nThis principle says: pick your meaning deliberately.","Notes":"The framing principle of the BAL domain — everything else (dominant strategies, symmetry,\nmethods) is *how*; this is *toward what*. Directly an application of DESIGN-0001. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-BAL-0001\ntitle: Decide what balance is for before you tune\nlayer: L1\ndomain: BAL\nsubdomain: balance-philosophy\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - balance\n  - philosophy\n  - fairness\n  - intent\nrelated:\n  - GDC-L1-BAL-0006\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-BAL-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schell-artofgamedesign\n  - S-schreiber-balance\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> \"Balanced\" is meaningless without a goal. Decide *what* balance serves — competitive\n> integrity, viable variety, a power fantasy, a difficulty target, a fair economy — because\n> different goals demand opposite tuning. Balance toward the intended experience, not toward\n> an abstract notion of \"fairness.\"\n\n## Rationale\nBalance is not one thing; it's a family of goals that often conflict, and the word hides\nwhich one you mean [S-schell-artofgamedesign]. Tuning a competitive game so every option is\nviable at expert level is a completely different job from tuning a power-fantasy RPG (where\nthe player is *supposed* to become overwhelmingly strong) or a co-op game (where balance\nmeans everyone contributes) or a horror game (where \"unfair\" is the point). Chasing generic\n\"fairness\" without naming the target produces incoherent results — nerfing something that\nwas doing exactly what the design wanted, or \"balancing\" the fun out of a deliberately\nlopsided moment. Naming the goal (this is DESIGN-0001 applied to numbers: balance for the\nexperience produced) turns tuning from vague fiddling into aimed work.\n\n## Applies when\nBefore and during any balance pass, and any time someone says something is \"unbalanced\" —\nthe first question is \"relative to what goal?\"\n\n## Does not apply / Exceptions\nNot an exception so much as a caution: even within one game, different subsystems may have\ndifferent balance goals (the competitive PvP mode vs. the power-fantasy campaign), so\n\"decide what balance is for\" is per-context, not one global answer. And some games\ngenuinely want *imbalance* as an experience (asymmetric horror, David-vs-Goliath), which is\na legitimate goal, not a failure to balance.\n\n## Implementation (kept separate from the principle)\nState the balance goal for each system explicitly (e.g. \"all five archetypes should be\nviable for a full playthrough\" vs. \"the mage should feel strongest late\"). Judge tuning\nchanges against that goal, not against a reflex toward parity. Recognize when a subsystem's\ngoal differs from the game's and tune it on its own terms. Revisit the goal if the design\nshifts.\n\n## Disagreement\nBalance-as-fairness (parity, competitive integrity) vs. balance-as-experience (tune toward\nthe intended feeling, even if \"unfair\") is the philosophical split under the whole domain.\nCompetitive games lean fairness; single-player and authored experiences lean experience.\nThis principle says: pick your meaning deliberately.\n\n## Notes\nThe framing principle of the BAL domain — everything else (dominant strategies, symmetry,\nmethods) is *how*; this is *toward what*. Directly an application of DESIGN-0001. Confidence 4.\n","searchText":"gdc-l1-bal-0001 decide what balance is for before you tune balance philosophy fairness intent > \"balanced\" is meaningless without a goal. decide what balance serves — competitive integrity, viable variety, a power fantasy, a difficulty target, a fair economy — because different goals demand opposite tuning. balance toward the intended experience, not toward an abstract notion of \"fairness.\" balance is not one thing; it's a family of goals that often conflict, and the word hides which one you mean [s-schell-artofgamedesign]. tuning a competitive game so every option is viable at expert level is a completely different job from tuning a power-fantasy rpg (where the player is supposed to become overwhelmingly strong) or a co-op game (where balance means everyone contributes) or a horror game (where \"unfair\" is the point). chasing generic \"fairness\" without naming the target produces incoherent results — nerfing something that was doing exactly what the design wanted, or \"balancing\" the fun out of a deliberately lopsided moment. naming the goal (this is design-0001 applied to numbers: balance for the experience produced) turns tuning from vague fiddling into aimed work. before and during any balance pass, and any time someone says something is \"unbalanced\" — the first question is \"relative to what goal?\" not an exception so much as a caution: even within one game, different subsystems may have different balance goals (the competitive pvp mode vs. the power-fantasy campaign), so \"decide what balance is for\" is per-context, not one global answer. and some games genuinely want imbalance as an experience (asymmetric horror, david-vs-goliath), which is a legitimate goal, not a failure to balance. state the balance goal for each system explicitly (e.g. \"all five archetypes should be viable for a full playthrough\" vs. \"the mage should feel strongest late\"). judge tuning changes against that goal, not against a reflex toward parity. recognize when a subsystem's goal differs from the game's and tune it on its own terms. revisit the goal if the design shifts. balance-as-fairness (parity, competitive integrity) vs. balance-as-experience (tune toward the intended feeling, even if \"unfair\") is the philosophical split under the whole domain. competitive games lean fairness; single-player and authored experiences lean experience. this principle says: pick your meaning deliberately. the framing principle of the bal domain — everything else (dominant strategies, symmetry, methods) is how; this is toward what. directly an application of design-0001. confidence 4."}
{"id":"GDC-L1-BAL-0002","title":"Hunt down dominant strategies; protect viable diversity","layer":"L1","domain":"BAL","subdomain":"dominant-strategies","type":"contextual","confidence":4,"status":"canonical","tags":["balance","dominant-strategy","viable-diversity","degenerate-strategy"],"related":["GDC-L1-SYS-0007","GDC-L1-DESIGN-0002","GDC-L1-BAL-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-sirlin-balance","S-schreiber-balance","S-meier-interesting-decisions"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-BAL-0002.md","statement":"A dominant strategy — one option that is simply best — collapses choice: once found, everyone uses it, and the rest of the design becomes decoration. The central balance goal is that many options remain viable, especially in expert play. Hunt down and remove always-best options; success is a rich space of reasonable choices, not one correct answer.","sections":{"Statement":"> A **dominant strategy** — one option that is simply best — collapses choice: once found,\n> everyone uses it, and the rest of the design becomes decoration. The central balance goal\n> is that *many options remain viable*, especially in expert play. Hunt down and remove\n> always-best options; success is a rich space of reasonable choices, not one correct answer.","Rationale":"Once a single strategy dominates, informed players converge on it and the game's apparent\ndepth evaporates — a roster of \"many characters\" or \"many builds\" is a lie if only one is\nworth picking [S-sirlin-balance]. This is the balance-craft enforcement of two principles\nalready in the constitution: interesting decisions require no dominant option (DESIGN-0002),\nand players will optimize the fun out of a game by finding and repeating the best strategy\n(SYS-0007). \"Viable diversity\" is the concrete target Sirlin names: a large number of the\navailable options should be reasonable choices, particularly at high skill. Balance work is,\nin large part, the ongoing hunt for the current dominant option and the act of pulling it\nback into the viable pack.","Applies when":"Any game with options that can be compared and optimized — builds, characters, weapons,\ntactics, deck archetypes, upgrade paths. Sharpest in competitive and highly-optimized games,\nbut it applies to single-player build variety too.","Does not apply / Exceptions":"Perfect parity is neither achievable nor always desirable (see BAL-0006 and the\nperfect-imbalance debate) — the goal is *viable diversity*, not identical power. Some\nsingle-player games happily let players find an overpowered build as a reward for system\nmastery (the \"break the game\" pleasure), where the dominant strategy is a feature the player\nearned. And a *temporary* dominant strategy that a healthy metagame will answer is different\nfrom a permanent one.","Implementation (kept separate from the principle)":"Actively look for the current best option (playtest, telemetry, expert feedback — BAL-0005)\nand rein it in, rather than waiting for players to find it. Prefer bringing weak options up\nto bringing the strong one down where it preserves fun. Give options situational strengths\nand counters (BAL-0004) so \"best\" is context-dependent. Measure viability by *expert* play,\nwhere dominance shows most clearly.","Disagreement":"\"Kill dominant strategies for viable diversity\" (Sirlin) is broadly held, but two live\ntensions qualify it: whether to chase parity at all (perfect-imbalance camp says slight\ndominance keeps the meta fresh — BAL-0006), and whether single-player games should even\nprevent players from finding a dominant \"break-the-game\" build (many say let them).","Notes":"The BAL-domain enforcement of DESIGN-0002 (interesting decisions) and SYS-0007 (optimize the fun out). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-BAL-0002\ntitle: Hunt down dominant strategies; protect viable diversity\nlayer: L1\ndomain: BAL\nsubdomain: dominant-strategies\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - balance\n  - dominant-strategy\n  - viable-diversity\n  - degenerate-strategy\nrelated:\n  - GDC-L1-SYS-0007\n  - GDC-L1-DESIGN-0002\n  - GDC-L1-BAL-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-sirlin-balance\n  - S-schreiber-balance\n  - S-meier-interesting-decisions\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A **dominant strategy** — one option that is simply best — collapses choice: once found,\n> everyone uses it, and the rest of the design becomes decoration. The central balance goal\n> is that *many options remain viable*, especially in expert play. Hunt down and remove\n> always-best options; success is a rich space of reasonable choices, not one correct answer.\n\n## Rationale\nOnce a single strategy dominates, informed players converge on it and the game's apparent\ndepth evaporates — a roster of \"many characters\" or \"many builds\" is a lie if only one is\nworth picking [S-sirlin-balance]. This is the balance-craft enforcement of two principles\nalready in the constitution: interesting decisions require no dominant option (DESIGN-0002),\nand players will optimize the fun out of a game by finding and repeating the best strategy\n(SYS-0007). \"Viable diversity\" is the concrete target Sirlin names: a large number of the\navailable options should be reasonable choices, particularly at high skill. Balance work is,\nin large part, the ongoing hunt for the current dominant option and the act of pulling it\nback into the viable pack.\n\n## Applies when\nAny game with options that can be compared and optimized — builds, characters, weapons,\ntactics, deck archetypes, upgrade paths. Sharpest in competitive and highly-optimized games,\nbut it applies to single-player build variety too.\n\n## Does not apply / Exceptions\nPerfect parity is neither achievable nor always desirable (see BAL-0006 and the\nperfect-imbalance debate) — the goal is *viable diversity*, not identical power. Some\nsingle-player games happily let players find an overpowered build as a reward for system\nmastery (the \"break the game\" pleasure), where the dominant strategy is a feature the player\nearned. And a *temporary* dominant strategy that a healthy metagame will answer is different\nfrom a permanent one.\n\n## Implementation (kept separate from the principle)\nActively look for the current best option (playtest, telemetry, expert feedback — BAL-0005)\nand rein it in, rather than waiting for players to find it. Prefer bringing weak options up\nto bringing the strong one down where it preserves fun. Give options situational strengths\nand counters (BAL-0004) so \"best\" is context-dependent. Measure viability by *expert* play,\nwhere dominance shows most clearly.\n\n## Disagreement\n\"Kill dominant strategies for viable diversity\" (Sirlin) is broadly held, but two live\ntensions qualify it: whether to chase parity at all (perfect-imbalance camp says slight\ndominance keeps the meta fresh — BAL-0006), and whether single-player games should even\nprevent players from finding a dominant \"break-the-game\" build (many say let them).\n\n## Notes\nThe BAL-domain enforcement of DESIGN-0002 (interesting decisions) and SYS-0007 (optimize the fun out). Confidence 4.\n","searchText":"gdc-l1-bal-0002 hunt down dominant strategies; protect viable diversity balance dominant-strategy viable-diversity degenerate-strategy > a dominant strategy — one option that is simply best — collapses choice: once found, everyone uses it, and the rest of the design becomes decoration. the central balance goal is that many options remain viable, especially in expert play. hunt down and remove always-best options; success is a rich space of reasonable choices, not one correct answer. once a single strategy dominates, informed players converge on it and the game's apparent depth evaporates — a roster of \"many characters\" or \"many builds\" is a lie if only one is worth picking [s-sirlin-balance]. this is the balance-craft enforcement of two principles already in the constitution: interesting decisions require no dominant option (design-0002), and players will optimize the fun out of a game by finding and repeating the best strategy (sys-0007). \"viable diversity\" is the concrete target sirlin names: a large number of the available options should be reasonable choices, particularly at high skill. balance work is, in large part, the ongoing hunt for the current dominant option and the act of pulling it back into the viable pack. any game with options that can be compared and optimized — builds, characters, weapons, tactics, deck archetypes, upgrade paths. sharpest in competitive and highly-optimized games, but it applies to single-player build variety too. perfect parity is neither achievable nor always desirable (see bal-0006 and the perfect-imbalance debate) — the goal is viable diversity, not identical power. some single-player games happily let players find an overpowered build as a reward for system mastery (the \"break the game\" pleasure), where the dominant strategy is a feature the player earned. and a temporary dominant strategy that a healthy metagame will answer is different from a permanent one. actively look for the current best option (playtest, telemetry, expert feedback — bal-0005) and rein it in, rather than waiting for players to find it. prefer bringing weak options up to bringing the strong one down where it preserves fun. give options situational strengths and counters (bal-0004) so \"best\" is context-dependent. measure viability by expert play, where dominance shows most clearly. \"kill dominant strategies for viable diversity\" (sirlin) is broadly held, but two live tensions qualify it: whether to chase parity at all (perfect-imbalance camp says slight dominance keeps the meta fresh — bal-0006), and whether single-player games should even prevent players from finding a dominant \"break-the-game\" build (many say let them). the bal-domain enforcement of design-0002 (interesting decisions) and sys-0007 (optimize the fun out). confidence 4."}
{"id":"GDC-L1-BAL-0003","title":"Symmetry is safe; asymmetry is rich but must be earned through testing","layer":"L1","domain":"BAL","subdomain":"symmetry-vs-asymmetry","type":"contextual","confidence":4,"status":"canonical","tags":["balance","symmetry","asymmetry","playtesting","variety"],"related":["GDC-L1-BAL-0002","GDC-L1-PLAYTEST-0005","GDC-L1-BAL-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-schreiber-balance"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-BAL-0003.md","statement":"Symmetric design (all sides given identical options) is fair by construction but often bland and limits variety. Asymmetric design (different options with different strengths) is far richer and more expressive — but it is not fair by construction and must be balanced through extensive playtesting and data. The more asymmetric the game, the more testing balance demands.","sections":{"Statement":"> **Symmetric** design (all sides given identical options) is fair by construction but often\n> bland and limits variety. **Asymmetric** design (different options with different strengths)\n> is far richer and more expressive — but it is *not* fair by construction and must be\n> balanced through extensive playtesting and data. The more asymmetric the game, the more\n> testing balance demands.","Rationale":"Symmetry buys fairness cheaply: if everyone has the same tools, no one can complain the sides\nare unequal (chess is nearly symmetric — the main asymmetry is who moves first)\n[S-schreiber-balance]. But symmetry also caps variety and can feel sterile — every mirror\nmatch is the same match. Asymmetry (distinct factions, classes, characters, decks) is where\nrichness, identity, and replayability live, but each added difference multiplies the\ninteractions you must balance, and none of it is guaranteed fair — it has to be *discovered*\nto be fair through play and data. Schreiber's rule is the practical takeaway: asymmetry and\nrequired-playtesting scale together, so the expressive choice is also the expensive one.","Applies when":"Choosing and tuning any set of distinct options — factions, classes, characters, races,\ndecks, loadouts. The design decision (how asymmetric to be) is upstream of the balance cost.","Does not apply / Exceptions":"Symmetry isn't automatically boring — positional and emergent asymmetry (chess, Go) generate\nenormous depth from symmetric starts. And some asymmetric games embrace *deliberate*\nimbalance as identity (asymmetric-horror, 1-vs-many), where \"fair\" isn't the goal (BAL-0001).\nSmall or resource-constrained teams may choose more symmetry precisely to avoid the balancing\nburden — a legitimate scope decision.","Implementation (kept separate from the principle)":"Decide how much asymmetry the game's identity needs, and budget the playtesting/data work to\nmatch (BAL-0005) — don't ship heavy asymmetry you can't afford to balance. Use quantification\n(cost curves, comparable stats) to get asymmetric options into the same rough range, then\nlean on extensive expert play to find the real imbalances numbers miss. Prefer situational,\ncounter-based asymmetry (BAL-0004) so options differ in *kind*, keeping many viable.","Disagreement":"Symmetry (fair, cheaper to balance, can feel sterile) vs. asymmetry (rich, expressive,\nexpensive and never fair-by-default) is a core design/balance tradeoff. Competitive-fairness\npurists and small teams lean symmetric; variety- and identity-driven designs lean asymmetric\nand pay the testing cost.","Notes":"Sets the balance *cost* of a variety decision, and points at the methods (BAL-0005) and\nstructure (BAL-0004, counterplay) that make asymmetry tractable. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-BAL-0003\ntitle: Symmetry is safe; asymmetry is rich but must be earned through testing\nlayer: L1\ndomain: BAL\nsubdomain: symmetry-vs-asymmetry\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - balance\n  - symmetry\n  - asymmetry\n  - playtesting\n  - variety\nrelated:\n  - GDC-L1-BAL-0002\n  - GDC-L1-PLAYTEST-0005\n  - GDC-L1-BAL-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schreiber-balance\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> **Symmetric** design (all sides given identical options) is fair by construction but often\n> bland and limits variety. **Asymmetric** design (different options with different strengths)\n> is far richer and more expressive — but it is *not* fair by construction and must be\n> balanced through extensive playtesting and data. The more asymmetric the game, the more\n> testing balance demands.\n\n## Rationale\nSymmetry buys fairness cheaply: if everyone has the same tools, no one can complain the sides\nare unequal (chess is nearly symmetric — the main asymmetry is who moves first)\n[S-schreiber-balance]. But symmetry also caps variety and can feel sterile — every mirror\nmatch is the same match. Asymmetry (distinct factions, classes, characters, decks) is where\nrichness, identity, and replayability live, but each added difference multiplies the\ninteractions you must balance, and none of it is guaranteed fair — it has to be *discovered*\nto be fair through play and data. Schreiber's rule is the practical takeaway: asymmetry and\nrequired-playtesting scale together, so the expressive choice is also the expensive one.\n\n## Applies when\nChoosing and tuning any set of distinct options — factions, classes, characters, races,\ndecks, loadouts. The design decision (how asymmetric to be) is upstream of the balance cost.\n\n## Does not apply / Exceptions\nSymmetry isn't automatically boring — positional and emergent asymmetry (chess, Go) generate\nenormous depth from symmetric starts. And some asymmetric games embrace *deliberate*\nimbalance as identity (asymmetric-horror, 1-vs-many), where \"fair\" isn't the goal (BAL-0001).\nSmall or resource-constrained teams may choose more symmetry precisely to avoid the balancing\nburden — a legitimate scope decision.\n\n## Implementation (kept separate from the principle)\nDecide how much asymmetry the game's identity needs, and budget the playtesting/data work to\nmatch (BAL-0005) — don't ship heavy asymmetry you can't afford to balance. Use quantification\n(cost curves, comparable stats) to get asymmetric options into the same rough range, then\nlean on extensive expert play to find the real imbalances numbers miss. Prefer situational,\ncounter-based asymmetry (BAL-0004) so options differ in *kind*, keeping many viable.\n\n## Disagreement\nSymmetry (fair, cheaper to balance, can feel sterile) vs. asymmetry (rich, expressive,\nexpensive and never fair-by-default) is a core design/balance tradeoff. Competitive-fairness\npurists and small teams lean symmetric; variety- and identity-driven designs lean asymmetric\nand pay the testing cost.\n\n## Notes\nSets the balance *cost* of a variety decision, and points at the methods (BAL-0005) and\nstructure (BAL-0004, counterplay) that make asymmetry tractable. Confidence 4.\n","searchText":"gdc-l1-bal-0003 symmetry is safe; asymmetry is rich but must be earned through testing balance symmetry asymmetry playtesting variety > symmetric design (all sides given identical options) is fair by construction but often bland and limits variety. asymmetric design (different options with different strengths) is far richer and more expressive — but it is not fair by construction and must be balanced through extensive playtesting and data. the more asymmetric the game, the more testing balance demands. symmetry buys fairness cheaply: if everyone has the same tools, no one can complain the sides are unequal (chess is nearly symmetric — the main asymmetry is who moves first) [s-schreiber-balance]. but symmetry also caps variety and can feel sterile — every mirror match is the same match. asymmetry (distinct factions, classes, characters, decks) is where richness, identity, and replayability live, but each added difference multiplies the interactions you must balance, and none of it is guaranteed fair — it has to be discovered to be fair through play and data. schreiber's rule is the practical takeaway: asymmetry and required-playtesting scale together, so the expressive choice is also the expensive one. choosing and tuning any set of distinct options — factions, classes, characters, races, decks, loadouts. the design decision (how asymmetric to be) is upstream of the balance cost. symmetry isn't automatically boring — positional and emergent asymmetry (chess, go) generate enormous depth from symmetric starts. and some asymmetric games embrace deliberate imbalance as identity (asymmetric-horror, 1-vs-many), where \"fair\" isn't the goal (bal-0001). small or resource-constrained teams may choose more symmetry precisely to avoid the balancing burden — a legitimate scope decision. decide how much asymmetry the game's identity needs, and budget the playtesting/data work to match (bal-0005) — don't ship heavy asymmetry you can't afford to balance. use quantification (cost curves, comparable stats) to get asymmetric options into the same rough range, then lean on extensive expert play to find the real imbalances numbers miss. prefer situational, counter-based asymmetry (bal-0004) so options differ in kind, keeping many viable. symmetry (fair, cheaper to balance, can feel sterile) vs. asymmetry (rich, expressive, expensive and never fair-by-default) is a core design/balance tradeoff. competitive-fairness purists and small teams lean symmetric; variety- and identity-driven designs lean asymmetric and pay the testing cost. sets the balance cost of a variety decision, and points at the methods (bal-0005) and structure (bal-0004, counterplay) that make asymmetry tractable. confidence 4."}
{"id":"GDC-L1-BAL-0004","title":"Balance through counterplay and situational strength, not raw parity","layer":"L1","domain":"BAL","subdomain":"numbers-and-curves","type":"contextual","confidence":4,"status":"canonical","tags":["balance","counterplay","intransitive","rock-paper-scissors","viable-diversity"],"related":["GDC-L1-DESIGN-0002","GDC-L1-BAL-0002","GDC-L1-BAL-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-schreiber-balance","S-sirlin-balance"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-BAL-0004.md","statement":"Options don't need equal power to be balanced — they need answers and contexts. An intransitive (rock-paper-scissors) structure and situational strengths keep many options viable without forcing everything to the same number, and they create interesting decisions: when to pick or play what.","sections":{"Statement":"> Options don't need *equal power* to be balanced — they need *answers* and *contexts*. An\n> intransitive (rock-paper-scissors) structure and situational strengths keep many options\n> viable without forcing everything to the same number, and they create interesting decisions:\n> *when* to pick or play what.","Rationale":"Balancing purely by raw power (making everything numerically equal — a \"transitive\" tuning)\ntends toward sameness and is brittle: the moment one option edges ahead, it dominates\n(BAL-0002). Intransitive balance sidesteps this: if A beats B, B beats C, and C beats A, then\nno option is universally best — each is strong in some matchups and weak in others, so the\ninteresting decision becomes *reading the situation and choosing accordingly*\n[S-schreiber-balance]. Situational strength generalizes this: an option can be powerful in\nits niche and weak outside it, staying viable without being universally strong. This is\nDESIGN-0002 (interesting decisions) realized through balance structure — the choice matters\nbecause context decides the winner, not a stat sheet.","Applies when":"Any set of competing options where you want many to stay viable — units, characters, weapons,\ntactics, tools. Especially valuable where pure numeric parity would flatten variety.","Does not apply / Exceptions":"Hard rock-paper-scissors can feel arbitrary or \"unfair\" if a player is *forced* into a losing\nmatchup with no agency (pre-commitment RPS with no adaptation is frustrating) — counterplay\nworks best when players can *respond* (swap, adapt, outplay) rather than being locked into a\npredetermined loss. And some games do want largely transitive, \"bigger number\" progression\n(power fantasy, PvE scaling), where counter-structures aren't the point. Situational strength\nalso needs the situations to actually arise in play.","Implementation (kept separate from the principle)":"Give options distinct niches and answers rather than tuning them to identical power. Build\nintransitive relationships where matchups matter, but let players adapt within a match so a\nbad matchup is a challenge, not a sentence. Combine with asymmetry (BAL-0003) — counter-based\ndifferences are how you make many distinct options viable at once (BAL-0002).","Disagreement":"Counterplay/intransitive balance (many viable options, decisions are contextual) vs. flat\nparity or transitive power (simpler, but tends toward sameness or dominance). And hard RPS\nwithout player agency is itself contested as frustrating. The craft is counters the player\ncan *respond* to.","Notes":"The structural technique that makes viable diversity (BAL-0002) and asymmetry (BAL-0003)\nachievable, and a direct expression of DESIGN-0002 (interesting decisions). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-BAL-0004\ntitle: Balance through counterplay and situational strength, not raw parity\nlayer: L1\ndomain: BAL\nsubdomain: numbers-and-curves\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - balance\n  - counterplay\n  - intransitive\n  - rock-paper-scissors\n  - viable-diversity\nrelated:\n  - GDC-L1-DESIGN-0002\n  - GDC-L1-BAL-0002\n  - GDC-L1-BAL-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schreiber-balance\n  - S-sirlin-balance\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Options don't need *equal power* to be balanced — they need *answers* and *contexts*. An\n> intransitive (rock-paper-scissors) structure and situational strengths keep many options\n> viable without forcing everything to the same number, and they create interesting decisions:\n> *when* to pick or play what.\n\n## Rationale\nBalancing purely by raw power (making everything numerically equal — a \"transitive\" tuning)\ntends toward sameness and is brittle: the moment one option edges ahead, it dominates\n(BAL-0002). Intransitive balance sidesteps this: if A beats B, B beats C, and C beats A, then\nno option is universally best — each is strong in some matchups and weak in others, so the\ninteresting decision becomes *reading the situation and choosing accordingly*\n[S-schreiber-balance]. Situational strength generalizes this: an option can be powerful in\nits niche and weak outside it, staying viable without being universally strong. This is\nDESIGN-0002 (interesting decisions) realized through balance structure — the choice matters\nbecause context decides the winner, not a stat sheet.\n\n## Applies when\nAny set of competing options where you want many to stay viable — units, characters, weapons,\ntactics, tools. Especially valuable where pure numeric parity would flatten variety.\n\n## Does not apply / Exceptions\nHard rock-paper-scissors can feel arbitrary or \"unfair\" if a player is *forced* into a losing\nmatchup with no agency (pre-commitment RPS with no adaptation is frustrating) — counterplay\nworks best when players can *respond* (swap, adapt, outplay) rather than being locked into a\npredetermined loss. And some games do want largely transitive, \"bigger number\" progression\n(power fantasy, PvE scaling), where counter-structures aren't the point. Situational strength\nalso needs the situations to actually arise in play.\n\n## Implementation (kept separate from the principle)\nGive options distinct niches and answers rather than tuning them to identical power. Build\nintransitive relationships where matchups matter, but let players adapt within a match so a\nbad matchup is a challenge, not a sentence. Combine with asymmetry (BAL-0003) — counter-based\ndifferences are how you make many distinct options viable at once (BAL-0002).\n\n## Disagreement\nCounterplay/intransitive balance (many viable options, decisions are contextual) vs. flat\nparity or transitive power (simpler, but tends toward sameness or dominance). And hard RPS\nwithout player agency is itself contested as frustrating. The craft is counters the player\ncan *respond* to.\n\n## Notes\nThe structural technique that makes viable diversity (BAL-0002) and asymmetry (BAL-0003)\nachievable, and a direct expression of DESIGN-0002 (interesting decisions). Confidence 4.\n","searchText":"gdc-l1-bal-0004 balance through counterplay and situational strength, not raw parity balance counterplay intransitive rock-paper-scissors viable-diversity > options don't need equal power to be balanced — they need answers and contexts. an intransitive (rock-paper-scissors) structure and situational strengths keep many options viable without forcing everything to the same number, and they create interesting decisions: when to pick or play what. balancing purely by raw power (making everything numerically equal — a \"transitive\" tuning) tends toward sameness and is brittle: the moment one option edges ahead, it dominates (bal-0002). intransitive balance sidesteps this: if a beats b, b beats c, and c beats a, then no option is universally best — each is strong in some matchups and weak in others, so the interesting decision becomes reading the situation and choosing accordingly [s-schreiber-balance]. situational strength generalizes this: an option can be powerful in its niche and weak outside it, staying viable without being universally strong. this is design-0002 (interesting decisions) realized through balance structure — the choice matters because context decides the winner, not a stat sheet. any set of competing options where you want many to stay viable — units, characters, weapons, tactics, tools. especially valuable where pure numeric parity would flatten variety. hard rock-paper-scissors can feel arbitrary or \"unfair\" if a player is forced into a losing matchup with no agency (pre-commitment rps with no adaptation is frustrating) — counterplay works best when players can respond (swap, adapt, outplay) rather than being locked into a predetermined loss. and some games do want largely transitive, \"bigger number\" progression (power fantasy, pve scaling), where counter-structures aren't the point. situational strength also needs the situations to actually arise in play. give options distinct niches and answers rather than tuning them to identical power. build intransitive relationships where matchups matter, but let players adapt within a match so a bad matchup is a challenge, not a sentence. combine with asymmetry (bal-0003) — counter-based differences are how you make many distinct options viable at once (bal-0002). counterplay/intransitive balance (many viable options, decisions are contextual) vs. flat parity or transitive power (simpler, but tends toward sameness or dominance). and hard rps without player agency is itself contested as frustrating. the craft is counters the player can respond to. the structural technique that makes viable diversity (bal-0002) and asymmetry (bal-0003) achievable, and a direct expression of design-0002 (interesting decisions). confidence 4."}
{"id":"GDC-L1-BAL-0005","title":"Tune with data and math; decide with play","layer":"L1","domain":"BAL","subdomain":"tuning-methods","type":"contextual","confidence":4,"status":"canonical","tags":["balance","tuning","quantification","telemetry","playtest","measure"],"related":["GDC-L1-PLAYTEST-0005","GDC-L1-PERF-0001","GDC-L1-PLAYTEST-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-schreiber-balance"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-BAL-0005.md","statement":"Use quantification — cost curves, spreadsheets, telemetry, win-rates — to reason about balance systematically and to flag outliers. But make the final call by play: math finds what's suspicious; playing decides what's fun and fair. The harder quantities are to compare, the more you must lean on playtesting.","sections":{"Statement":"> Use quantification — cost curves, spreadsheets, telemetry, win-rates — to reason about\n> balance systematically and to *flag* outliers. But make the final call by *play*: math\n> finds what's suspicious; playing decides what's fun and fair. The harder quantities are to\n> compare, the more you must lean on playtesting.","Rationale":"Numbers are indispensable for balance at scale: a cost curve lets you price a hundred items\nconsistently, and telemetry surfaces the option with a 70% pick rate you'd never spot by feel\n[S-schreiber-balance]. But numbers also lie by omission — they can't fully capture how an\noption *feels*, how it interacts with everything else, or whether a statistically-fine option\nis miserable to play against. So the two methods are complementary: quantify to narrow the\nsearch and catch outliers, then *play* to judge. Schreiber's own caveat — the harder direct\ncomparison is, the more playtesting you need — captures the balance: math scales, play judges,\nand the murkier the math, the more the judgment falls to play. This is the balance-specific\nform of \"measure, don't guess\" (PERF-0001) fused with \"watch behavior, not just numbers\"\n(PLAYTEST-0005).","Applies when":"Any balance pass, at any scale — from pricing a single item to tuning a live competitive\nroster. Data-heavy at large scale; play-heavy where interactions are complex or subjective.","Does not apply / Exceptions":"Tiny option sets can be balanced almost entirely by play (no spreadsheet needed for three\nweapons). Conversely, at massive scale (live-service with millions of matches) telemetry\ncarries more weight — though even there, the numbers point and humans still decide (PROG-0004's\nwarning against optimizing the metric instead of the experience applies). Pure faith in either\nextreme — spreadsheet-only or vibes-only — fails.","Implementation (kept separate from the principle)":"Build a cost/value model so options are priced consistently, and instrument the game to see\npick rates, win rates, and drop-off (PLAYTEST-0005). Use both to *find* imbalances; then\nplaytest the flagged cases and decide by experience, not by the number alone. Where quantities\nresist comparison, weight playtesting more. Keep before/after data so you can tell a change\nhelped.","Disagreement":"Data-driven balance (quantify, trust metrics, A/B test) vs. designer-judgment balance (play,\nfeel, expert intuition). Data scales and catches blind spots; judgment captures fun and\ncontext that numbers miss. The synthesis — data flags, play decides — is what most balance\ndesigners converge on; the debate is the *weighting*, which shifts with scale and how\nmeasurable the game is.","Notes":"The methods principle of BAL, unifying the \"measure, don't guess\" thread (PERF-0001,\nPLAYTEST-0001/0005) with the reality that balance is ultimately a judgment about experience.\nConfidence 4."},"rawMarkdown":"---\nid: GDC-L1-BAL-0005\ntitle: Tune with data and math; decide with play\nlayer: L1\ndomain: BAL\nsubdomain: tuning-methods\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - balance\n  - tuning\n  - quantification\n  - telemetry\n  - playtest\n  - measure\nrelated:\n  - GDC-L1-PLAYTEST-0005\n  - GDC-L1-PERF-0001\n  - GDC-L1-PLAYTEST-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schreiber-balance\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Use quantification — cost curves, spreadsheets, telemetry, win-rates — to reason about\n> balance systematically and to *flag* outliers. But make the final call by *play*: math\n> finds what's suspicious; playing decides what's fun and fair. The harder quantities are to\n> compare, the more you must lean on playtesting.\n\n## Rationale\nNumbers are indispensable for balance at scale: a cost curve lets you price a hundred items\nconsistently, and telemetry surfaces the option with a 70% pick rate you'd never spot by feel\n[S-schreiber-balance]. But numbers also lie by omission — they can't fully capture how an\noption *feels*, how it interacts with everything else, or whether a statistically-fine option\nis miserable to play against. So the two methods are complementary: quantify to narrow the\nsearch and catch outliers, then *play* to judge. Schreiber's own caveat — the harder direct\ncomparison is, the more playtesting you need — captures the balance: math scales, play judges,\nand the murkier the math, the more the judgment falls to play. This is the balance-specific\nform of \"measure, don't guess\" (PERF-0001) fused with \"watch behavior, not just numbers\"\n(PLAYTEST-0005).\n\n## Applies when\nAny balance pass, at any scale — from pricing a single item to tuning a live competitive\nroster. Data-heavy at large scale; play-heavy where interactions are complex or subjective.\n\n## Does not apply / Exceptions\nTiny option sets can be balanced almost entirely by play (no spreadsheet needed for three\nweapons). Conversely, at massive scale (live-service with millions of matches) telemetry\ncarries more weight — though even there, the numbers point and humans still decide (PROG-0004's\nwarning against optimizing the metric instead of the experience applies). Pure faith in either\nextreme — spreadsheet-only or vibes-only — fails.\n\n## Implementation (kept separate from the principle)\nBuild a cost/value model so options are priced consistently, and instrument the game to see\npick rates, win rates, and drop-off (PLAYTEST-0005). Use both to *find* imbalances; then\nplaytest the flagged cases and decide by experience, not by the number alone. Where quantities\nresist comparison, weight playtesting more. Keep before/after data so you can tell a change\nhelped.\n\n## Disagreement\nData-driven balance (quantify, trust metrics, A/B test) vs. designer-judgment balance (play,\nfeel, expert intuition). Data scales and catches blind spots; judgment captures fun and\ncontext that numbers miss. The synthesis — data flags, play decides — is what most balance\ndesigners converge on; the debate is the *weighting*, which shifts with scale and how\nmeasurable the game is.\n\n## Notes\nThe methods principle of BAL, unifying the \"measure, don't guess\" thread (PERF-0001,\nPLAYTEST-0001/0005) with the reality that balance is ultimately a judgment about experience.\nConfidence 4.\n","searchText":"gdc-l1-bal-0005 tune with data and math; decide with play balance tuning quantification telemetry playtest measure > use quantification — cost curves, spreadsheets, telemetry, win-rates — to reason about balance systematically and to flag outliers. but make the final call by play: math finds what's suspicious; playing decides what's fun and fair. the harder quantities are to compare, the more you must lean on playtesting. numbers are indispensable for balance at scale: a cost curve lets you price a hundred items consistently, and telemetry surfaces the option with a 70% pick rate you'd never spot by feel [s-schreiber-balance]. but numbers also lie by omission — they can't fully capture how an option feels, how it interacts with everything else, or whether a statistically-fine option is miserable to play against. so the two methods are complementary: quantify to narrow the search and catch outliers, then play to judge. schreiber's own caveat — the harder direct comparison is, the more playtesting you need — captures the balance: math scales, play judges, and the murkier the math, the more the judgment falls to play. this is the balance-specific form of \"measure, don't guess\" (perf-0001) fused with \"watch behavior, not just numbers\" (playtest-0005). any balance pass, at any scale — from pricing a single item to tuning a live competitive roster. data-heavy at large scale; play-heavy where interactions are complex or subjective. tiny option sets can be balanced almost entirely by play (no spreadsheet needed for three weapons). conversely, at massive scale (live-service with millions of matches) telemetry carries more weight — though even there, the numbers point and humans still decide (prog-0004's warning against optimizing the metric instead of the experience applies). pure faith in either extreme — spreadsheet-only or vibes-only — fails. build a cost/value model so options are priced consistently, and instrument the game to see pick rates, win rates, and drop-off (playtest-0005). use both to find imbalances; then playtest the flagged cases and decide by experience, not by the number alone. where quantities resist comparison, weight playtesting more. keep before/after data so you can tell a change helped. data-driven balance (quantify, trust metrics, a/b test) vs. designer-judgment balance (play, feel, expert intuition). data scales and catches blind spots; judgment captures fun and context that numbers miss. the synthesis — data flags, play decides — is what most balance designers converge on; the debate is the weighting, which shifts with scale and how measurable the game is. the methods principle of bal, unifying the \"measure, don't guess\" thread (perf-0001, playtest-0001/0005) with the reality that balance is ultimately a judgment about experience. confidence 4."}
{"id":"GDC-L1-BAL-0006","title":"Balance for fun and perceived fairness, not just mathematical parity","layer":"L1","domain":"BAL","subdomain":"balance-philosophy","type":"stylistic","confidence":3,"status":"canonical","tags":["balance","perceived-fairness","fun","perfect-imbalance","metagame"],"related":["GDC-L1-BAL-0001","GDC-L1-DESIGN-0001","GDC-L1-BAL-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-perfect-imbalance","S-sirlin-balance"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-BAL-0006.md","statement":"Players experience balance as a feeling, and a game can be mathematically balanced yet feel terrible — or slightly \"imbalanced\" yet feel great. Weigh perceived fairness and fun alongside the numbers: a slightly imbalanced option that's exciting can beat a perfectly tuned one that's dull, and even perfect balance can go stale.","sections":{"Statement":"> Players experience balance as a *feeling*, and a game can be mathematically balanced yet\n> feel terrible — or slightly \"imbalanced\" yet feel great. Weigh perceived fairness and fun\n> alongside the numbers: a slightly imbalanced option that's exciting can beat a perfectly\n> tuned one that's dull, and even perfect balance can go stale.","Rationale":"Balance serves the experience (BAL-0001, DESIGN-0001), and the experience is subjective:\nwhat matters to players is whether the game *feels* fair and fun, which doesn't always track\nthe spreadsheet. Two well-known consequences. First, *perceived* imbalance can wreck a\nmathematically-fine game (an option that's technically balanced but feels cheap or\nun-fun-to-face poisons the experience), while a bit of genuine imbalance can go unnoticed or\neven feel good. Second — the \"Perfect Imbalance\" argument — a perfectly balanced game trends\ntoward *solved*: once optimal play is found, everyone executes the same known strategies and\nthe metagame stagnates, whereas slight, shifting imbalances keep players hunting new answers\nand keep the game alive [S-perfect-imbalance]. So chasing parity for its own sake can cost\nyou fun and freshness.","Applies when":"Balance philosophy and any decision that trades measured parity against how the game feels\nor how lively its metagame stays. Most pointed in competitive and long-lived games.","Does not apply / Exceptions":"This does *not* license lazy or lopsided balance — \"it's more fun imbalanced\" is often an\nexcuse for a dominant strategy (BAL-0002) that genuinely needs fixing. Competitive-integrity\ncontexts (esports, ranked ladders) weight measured fairness heavily, because perceived\nunfairness there erodes trust in the competition itself.","Implementation (kept separate from the principle)":"Track *perceived* fairness (player sentiment, \"feels cheap\" complaints, what people ban or\navoid) alongside the numbers (BAL-0005). When an option is technically balanced but hated to\nplay against, treat that as a real problem. Be willing to leave — or even introduce — slight,\nhealthy imbalance to keep the meta evolving, while still hunting the *dominant* strategies\nthat actually collapse choice.","Disagreement":"This is the domain's sharpest live debate. **Perfect Imbalance** (Extra Credits): deliberate,\nshifting slight imbalance keeps the metagame fresh and avoids the \"solved game\" endpoint.\n**Balance-for-viable-diversity** (Sirlin): intentionally making the game unfair doesn't make\nsense; aim for many viable options through genuine balance, and let a healthy metagame emerge\nfrom *diversity*, not from engineered unfairness. Both agree perfect parity can stagnate and\nthat dominant strategies are bad; they disagree on whether the answer is *engineered\nimbalance* or *viable diversity*. Typed `stylistic` because it is a genuine, unresolved values\nsplit among expert designers.","Notes":"Where balance meets fun and perception, and home to the Perfect-Imbalance-vs-Sirlin debate\n(see `index/DISAGREEMENTS.md`). Confidence 3: the phenomena (perceived fairness, solved-game\nstagnation) are real and well-argued, but the prescriptive question is genuinely contested."},"rawMarkdown":"---\nid: GDC-L1-BAL-0006\ntitle: Balance for fun and perceived fairness, not just mathematical parity\nlayer: L1\ndomain: BAL\nsubdomain: balance-philosophy\ntype: stylistic\nconfidence: 3\nstatus: canonical\ntags:\n  - balance\n  - perceived-fairness\n  - fun\n  - perfect-imbalance\n  - metagame\nrelated:\n  - GDC-L1-BAL-0001\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-BAL-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-perfect-imbalance\n  - S-sirlin-balance\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Players experience balance as a *feeling*, and a game can be mathematically balanced yet\n> feel terrible — or slightly \"imbalanced\" yet feel great. Weigh perceived fairness and fun\n> alongside the numbers: a slightly imbalanced option that's exciting can beat a perfectly\n> tuned one that's dull, and even perfect balance can go stale.\n\n## Rationale\nBalance serves the experience (BAL-0001, DESIGN-0001), and the experience is subjective:\nwhat matters to players is whether the game *feels* fair and fun, which doesn't always track\nthe spreadsheet. Two well-known consequences. First, *perceived* imbalance can wreck a\nmathematically-fine game (an option that's technically balanced but feels cheap or\nun-fun-to-face poisons the experience), while a bit of genuine imbalance can go unnoticed or\neven feel good. Second — the \"Perfect Imbalance\" argument — a perfectly balanced game trends\ntoward *solved*: once optimal play is found, everyone executes the same known strategies and\nthe metagame stagnates, whereas slight, shifting imbalances keep players hunting new answers\nand keep the game alive [S-perfect-imbalance]. So chasing parity for its own sake can cost\nyou fun and freshness.\n\n## Applies when\nBalance philosophy and any decision that trades measured parity against how the game feels\nor how lively its metagame stays. Most pointed in competitive and long-lived games.\n\n## Does not apply / Exceptions\nThis does *not* license lazy or lopsided balance — \"it's more fun imbalanced\" is often an\nexcuse for a dominant strategy (BAL-0002) that genuinely needs fixing. Competitive-integrity\ncontexts (esports, ranked ladders) weight measured fairness heavily, because perceived\nunfairness there erodes trust in the competition itself.\n\n## Implementation (kept separate from the principle)\nTrack *perceived* fairness (player sentiment, \"feels cheap\" complaints, what people ban or\navoid) alongside the numbers (BAL-0005). When an option is technically balanced but hated to\nplay against, treat that as a real problem. Be willing to leave — or even introduce — slight,\nhealthy imbalance to keep the meta evolving, while still hunting the *dominant* strategies\nthat actually collapse choice.\n\n## Disagreement\nThis is the domain's sharpest live debate. **Perfect Imbalance** (Extra Credits): deliberate,\nshifting slight imbalance keeps the metagame fresh and avoids the \"solved game\" endpoint.\n**Balance-for-viable-diversity** (Sirlin): intentionally making the game unfair doesn't make\nsense; aim for many viable options through genuine balance, and let a healthy metagame emerge\nfrom *diversity*, not from engineered unfairness. Both agree perfect parity can stagnate and\nthat dominant strategies are bad; they disagree on whether the answer is *engineered\nimbalance* or *viable diversity*. Typed `stylistic` because it is a genuine, unresolved values\nsplit among expert designers.\n\n## Notes\nWhere balance meets fun and perception, and home to the Perfect-Imbalance-vs-Sirlin debate\n(see `index/DISAGREEMENTS.md`). Confidence 3: the phenomena (perceived fairness, solved-game\nstagnation) are real and well-argued, but the prescriptive question is genuinely contested.\n","searchText":"gdc-l1-bal-0006 balance for fun and perceived fairness, not just mathematical parity balance perceived-fairness fun perfect-imbalance metagame > players experience balance as a feeling, and a game can be mathematically balanced yet feel terrible — or slightly \"imbalanced\" yet feel great. weigh perceived fairness and fun alongside the numbers: a slightly imbalanced option that's exciting can beat a perfectly tuned one that's dull, and even perfect balance can go stale. balance serves the experience (bal-0001, design-0001), and the experience is subjective: what matters to players is whether the game feels fair and fun, which doesn't always track the spreadsheet. two well-known consequences. first, perceived imbalance can wreck a mathematically-fine game (an option that's technically balanced but feels cheap or un-fun-to-face poisons the experience), while a bit of genuine imbalance can go unnoticed or even feel good. second — the \"perfect imbalance\" argument — a perfectly balanced game trends toward solved: once optimal play is found, everyone executes the same known strategies and the metagame stagnates, whereas slight, shifting imbalances keep players hunting new answers and keep the game alive [s-perfect-imbalance]. so chasing parity for its own sake can cost you fun and freshness. balance philosophy and any decision that trades measured parity against how the game feels or how lively its metagame stays. most pointed in competitive and long-lived games. this does not license lazy or lopsided balance — \"it's more fun imbalanced\" is often an excuse for a dominant strategy (bal-0002) that genuinely needs fixing. competitive-integrity contexts (esports, ranked ladders) weight measured fairness heavily, because perceived unfairness there erodes trust in the competition itself. track perceived fairness (player sentiment, \"feels cheap\" complaints, what people ban or avoid) alongside the numbers (bal-0005). when an option is technically balanced but hated to play against, treat that as a real problem. be willing to leave — or even introduce — slight, healthy imbalance to keep the meta evolving, while still hunting the dominant strategies that actually collapse choice. this is the domain's sharpest live debate. perfect imbalance (extra credits): deliberate, shifting slight imbalance keeps the metagame fresh and avoids the \"solved game\" endpoint. balance-for-viable-diversity (sirlin): intentionally making the game unfair doesn't make sense; aim for many viable options through genuine balance, and let a healthy metagame emerge from diversity, not from engineered unfairness. both agree perfect parity can stagnate and that dominant strategies are bad; they disagree on whether the answer is engineered imbalance or viable diversity. typed stylistic because it is a genuine, unresolved values split among expert designers. where balance meets fun and perception, and home to the perfect-imbalance-vs-sirlin debate (see index/disagreements.md). confidence 3: the phenomena (perceived fairness, solved-game stagnation) are real and well-argued, but the prescriptive question is genuinely contested."}
{"id":"GDC-L1-LEVEL-0001","title":"Guide the player's eye with the environment, not with hand-holding","layer":"L1","domain":"LEVEL","subdomain":"guidance-and-legibility","type":"contextual","confidence":4,"status":"canonical","tags":["level-design","guidance","composition","lighting","leading-lines"],"related":["GDC-L1-LEVEL-0002","GDC-L1-LEVEL-0006","GDC-L1-DESIGN-0006"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-leveldesign-guidance"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-LEVEL-0001.md","statement":"Lead the player's attention and movement with the environment itself — light, color, contrast, leading lines, and composition — so they find their way and notice what matters without explicit markers, quest arrows, or hand-holding. Build the space so the right place pulls the eye.","sections":{"Statement":"> Lead the player's attention and movement with the environment itself — light, color,\n> contrast, leading lines, and composition — so they find their way and notice what\n> matters *without* explicit markers, quest arrows, or hand-holding. Build the space so the\n> right place pulls the eye.","Rationale":"Players read space the way they read a photograph: bright areas, high-contrast edges,\nsaturated color, converging lines, and framing all draw the eye, and movement tends to\nfollow the gaze [S-leveldesign-guidance]. A designer who controls these controls where\nplayers look and go — a spotlight in a dark room, a shaft of light on a doorway, a pipe or\nhedgerow that leads toward the exit, an architectural line that points at the objective.\nThis \"implicit\" guidance preserves the feeling of self-directed discovery (the player\nbelieves they chose the path), whereas explicit markers (giant arrows, waypoint UI)\nshort-circuit that feeling and train players to follow a HUD instead of reading the world.\nGuiding through the environment keeps players *in* the space.","Applies when":"Any spatial game where the player navigates and where you want them to reach places, notice\nthings, or feel guided without being told. Especially valuable for immersive, exploration-,\nand atmosphere-driven games.","Does not apply / Exceptions":"Explicit guidance (markers, minimaps, objective arrows) is legitimate and often necessary —\nin large open worlds, for accessibility, and where finding-the-way is friction rather than\nfun. Highly systemic or sandbox games may deliberately provide *no* guidance and let players\nset their own goals. And implicit guidance can fail: over-subtle cues leave players lost\n(see LEVEL-0002 on legibility). Match the guidance strength to how much wayfinding should\nbe part of the experience.","Implementation (kept separate from the principle)":"Use light and contrast as your strongest tools (the eye goes to the brightest readable\npoint). Add leading lines in architecture, props, and terrain that point where you want\nplayers to go. Reserve your most saturated color and strongest contrast for things that\nmatter. Playtest by watching where first-time players actually look and walk (PLAYTEST-0001)\n— if they miss the path, the composition, not the player, is wrong.","Disagreement":"Implicit (environmental) vs. explicit (UI markers) guidance is a real spectrum: implicit\npreserves immersion and the sense of discovery; explicit guarantees players aren't lost and\naids accessibility. Immersive-sim and exploration design lean implicit; large open-world and\nbroad-audience design lean explicit. Most games blend, matching the mix to how much\nwayfinding should be a skill.","Notes":"The attention half of level legibility; its orientation half is LEVEL-0002. A concrete,\nspatial expression of DESIGN-0006 (legible consequences/agency). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-LEVEL-0001\ntitle: Guide the player's eye with the environment, not with hand-holding\nlayer: L1\ndomain: LEVEL\nsubdomain: guidance-and-legibility\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - level-design\n  - guidance\n  - composition\n  - lighting\n  - leading-lines\nrelated:\n  - GDC-L1-LEVEL-0002\n  - GDC-L1-LEVEL-0006\n  - GDC-L1-DESIGN-0006\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-leveldesign-guidance\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Lead the player's attention and movement with the environment itself — light, color,\n> contrast, leading lines, and composition — so they find their way and notice what\n> matters *without* explicit markers, quest arrows, or hand-holding. Build the space so the\n> right place pulls the eye.\n\n## Rationale\nPlayers read space the way they read a photograph: bright areas, high-contrast edges,\nsaturated color, converging lines, and framing all draw the eye, and movement tends to\nfollow the gaze [S-leveldesign-guidance]. A designer who controls these controls where\nplayers look and go — a spotlight in a dark room, a shaft of light on a doorway, a pipe or\nhedgerow that leads toward the exit, an architectural line that points at the objective.\nThis \"implicit\" guidance preserves the feeling of self-directed discovery (the player\nbelieves they chose the path), whereas explicit markers (giant arrows, waypoint UI)\nshort-circuit that feeling and train players to follow a HUD instead of reading the world.\nGuiding through the environment keeps players *in* the space.\n\n## Applies when\nAny spatial game where the player navigates and where you want them to reach places, notice\nthings, or feel guided without being told. Especially valuable for immersive, exploration-,\nand atmosphere-driven games.\n\n## Does not apply / Exceptions\nExplicit guidance (markers, minimaps, objective arrows) is legitimate and often necessary —\nin large open worlds, for accessibility, and where finding-the-way is friction rather than\nfun. Highly systemic or sandbox games may deliberately provide *no* guidance and let players\nset their own goals. And implicit guidance can fail: over-subtle cues leave players lost\n(see LEVEL-0002 on legibility). Match the guidance strength to how much wayfinding should\nbe part of the experience.\n\n## Implementation (kept separate from the principle)\nUse light and contrast as your strongest tools (the eye goes to the brightest readable\npoint). Add leading lines in architecture, props, and terrain that point where you want\nplayers to go. Reserve your most saturated color and strongest contrast for things that\nmatter. Playtest by watching where first-time players actually look and walk (PLAYTEST-0001)\n— if they miss the path, the composition, not the player, is wrong.\n\n## Disagreement\nImplicit (environmental) vs. explicit (UI markers) guidance is a real spectrum: implicit\npreserves immersion and the sense of discovery; explicit guarantees players aren't lost and\naids accessibility. Immersive-sim and exploration design lean implicit; large open-world and\nbroad-audience design lean explicit. Most games blend, matching the mix to how much\nwayfinding should be a skill.\n\n## Notes\nThe attention half of level legibility; its orientation half is LEVEL-0002. A concrete,\nspatial expression of DESIGN-0006 (legible consequences/agency). Confidence 4.\n","searchText":"gdc-l1-level-0001 guide the player's eye with the environment, not with hand-holding level-design guidance composition lighting leading-lines > lead the player's attention and movement with the environment itself — light, color, contrast, leading lines, and composition — so they find their way and notice what matters without explicit markers, quest arrows, or hand-holding. build the space so the right place pulls the eye. players read space the way they read a photograph: bright areas, high-contrast edges, saturated color, converging lines, and framing all draw the eye, and movement tends to follow the gaze [s-leveldesign-guidance]. a designer who controls these controls where players look and go — a spotlight in a dark room, a shaft of light on a doorway, a pipe or hedgerow that leads toward the exit, an architectural line that points at the objective. this \"implicit\" guidance preserves the feeling of self-directed discovery (the player believes they chose the path), whereas explicit markers (giant arrows, waypoint ui) short-circuit that feeling and train players to follow a hud instead of reading the world. guiding through the environment keeps players in the space. any spatial game where the player navigates and where you want them to reach places, notice things, or feel guided without being told. especially valuable for immersive, exploration-, and atmosphere-driven games. explicit guidance (markers, minimaps, objective arrows) is legitimate and often necessary — in large open worlds, for accessibility, and where finding-the-way is friction rather than fun. highly systemic or sandbox games may deliberately provide no guidance and let players set their own goals. and implicit guidance can fail: over-subtle cues leave players lost (see level-0002 on legibility). match the guidance strength to how much wayfinding should be part of the experience. use light and contrast as your strongest tools (the eye goes to the brightest readable point). add leading lines in architecture, props, and terrain that point where you want players to go. reserve your most saturated color and strongest contrast for things that matter. playtest by watching where first-time players actually look and walk (playtest-0001) — if they miss the path, the composition, not the player, is wrong. implicit (environmental) vs. explicit (ui markers) guidance is a real spectrum: implicit preserves immersion and the sense of discovery; explicit guarantees players aren't lost and aids accessibility. immersive-sim and exploration design lean implicit; large open-world and broad-audience design lean explicit. most games blend, matching the mix to how much wayfinding should be a skill. the attention half of level legibility; its orientation half is level-0002. a concrete, spatial expression of design-0006 (legible consequences/agency). confidence 4."}
{"id":"GDC-L1-LEVEL-0002","title":"Make space legible — support the player's mental map","layer":"L1","domain":"LEVEL","subdomain":"guidance-and-legibility","type":"contextual","confidence":4,"status":"canonical","tags":["level-design","legibility","wayfinding","landmarks","navigation"],"related":["GDC-L1-LEVEL-0001","GDC-L1-SYS-0006","GDC-L1-DESIGN-0006"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-lynch-image-city"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-LEVEL-0002.md","statement":"Design space so the player can always answer where am I, where can I go, where have I been? Give the world the ingredients of a mental map — memorable landmarks, distinct districts, clear paths, readable edges and nodes — so it organizes into a coherent whole and players navigate by understanding rather than by luck.","sections":{"Statement":"> Design space so the player can always answer *where am I, where can I go, where have I\n> been?* Give the world the ingredients of a mental map — memorable **landmarks**, distinct\n> **districts**, clear **paths**, readable **edges** and **nodes** — so it organizes into a\n> coherent whole and players navigate by understanding rather than by luck.","Rationale":"People build mental maps of a space from a small set of elements — paths (routes), edges\n(boundaries), districts (areas with a shared character), nodes (junctions), and landmarks\n(distinctive reference points visible from afar) — and a space rich in these is \"legible\":\neasy to recognize, organize, and navigate without disorientation [S-lynch-image-city]. A\nlevel that ignores them becomes a samey maze where every corridor looks alike and players\nget lost, retread, and disengage. Strong landmarks let players orient after a distraction\n(a big fight, a detour) and re-fix their goal; distinct districts make \"I'm in the\nsewers now\" legible at a glance; clear paths and nodes make choices comprehensible.\nLegibility is what turns navigation from a chore into confident movement.","Applies when":"Any navigable space, and critically any large, open, or interconnected world where getting\nlost is a real risk. The bigger and more open the space, the more it depends on landmarks\nand district identity.","Does not apply / Exceptions":"Disorientation is sometimes the *goal*: horror, dread, and certain puzzle or dream-logic\nspaces deliberately break legibility to unsettle the player (a legible haunted house isn't\nscary). Deliberately labyrinthine design — mazes, getting-lost-as-content — inverts this on\npurpose. And an intentionally illegible *first* impression can make later mastery of the\nspace satisfying (Dark Souls' interconnected world rewards learning it). The principle is\nthe default; breaking it should be a choice.","Implementation (kept separate from the principle)":"Plant landmarks tall or bright enough to be seen across the level, and make them distinct\nfrom each other. Give districts their own palette, architecture, and mood so areas are\nidentifiable at a glance. Keep paths readable and junctions (nodes) clear. Vary silhouettes\nso places aren't confusable. Test by asking players to point toward where they've been —\nif they can't, the space isn't legible.","Disagreement":"Legibility vs. deliberate disorientation is the axis: readable, confident navigation (most\ngames) vs. intentional lostness for horror, mystery, or mastery-through-learning. Both are\nvalid; the question is whether *knowing where you are* should be given or earned.","Notes":"The orientation half of level legibility (LEVEL-0001 is the attention half), and the spatial counterpart of SYS-0006 (legible systems). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-LEVEL-0002\ntitle: Make space legible — support the player's mental map\nlayer: L1\ndomain: LEVEL\nsubdomain: guidance-and-legibility\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - level-design\n  - legibility\n  - wayfinding\n  - landmarks\n  - navigation\nrelated:\n  - GDC-L1-LEVEL-0001\n  - GDC-L1-SYS-0006\n  - GDC-L1-DESIGN-0006\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-lynch-image-city\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Design space so the player can always answer *where am I, where can I go, where have I\n> been?* Give the world the ingredients of a mental map — memorable **landmarks**, distinct\n> **districts**, clear **paths**, readable **edges** and **nodes** — so it organizes into a\n> coherent whole and players navigate by understanding rather than by luck.\n\n## Rationale\nPeople build mental maps of a space from a small set of elements — paths (routes), edges\n(boundaries), districts (areas with a shared character), nodes (junctions), and landmarks\n(distinctive reference points visible from afar) — and a space rich in these is \"legible\":\neasy to recognize, organize, and navigate without disorientation [S-lynch-image-city]. A\nlevel that ignores them becomes a samey maze where every corridor looks alike and players\nget lost, retread, and disengage. Strong landmarks let players orient after a distraction\n(a big fight, a detour) and re-fix their goal; distinct districts make \"I'm in the\nsewers now\" legible at a glance; clear paths and nodes make choices comprehensible.\nLegibility is what turns navigation from a chore into confident movement.\n\n## Applies when\nAny navigable space, and critically any large, open, or interconnected world where getting\nlost is a real risk. The bigger and more open the space, the more it depends on landmarks\nand district identity.\n\n## Does not apply / Exceptions\nDisorientation is sometimes the *goal*: horror, dread, and certain puzzle or dream-logic\nspaces deliberately break legibility to unsettle the player (a legible haunted house isn't\nscary). Deliberately labyrinthine design — mazes, getting-lost-as-content — inverts this on\npurpose. And an intentionally illegible *first* impression can make later mastery of the\nspace satisfying (Dark Souls' interconnected world rewards learning it). The principle is\nthe default; breaking it should be a choice.\n\n## Implementation (kept separate from the principle)\nPlant landmarks tall or bright enough to be seen across the level, and make them distinct\nfrom each other. Give districts their own palette, architecture, and mood so areas are\nidentifiable at a glance. Keep paths readable and junctions (nodes) clear. Vary silhouettes\nso places aren't confusable. Test by asking players to point toward where they've been —\nif they can't, the space isn't legible.\n\n## Disagreement\nLegibility vs. deliberate disorientation is the axis: readable, confident navigation (most\ngames) vs. intentional lostness for horror, mystery, or mastery-through-learning. Both are\nvalid; the question is whether *knowing where you are* should be given or earned.\n\n## Notes\nThe orientation half of level legibility (LEVEL-0001 is the attention half), and the spatial counterpart of SYS-0006 (legible systems). Confidence 4.\n","searchText":"gdc-l1-level-0002 make space legible — support the player's mental map level-design legibility wayfinding landmarks navigation > design space so the player can always answer where am i, where can i go, where have i been? give the world the ingredients of a mental map — memorable landmarks, distinct districts, clear paths, readable edges and nodes — so it organizes into a coherent whole and players navigate by understanding rather than by luck. people build mental maps of a space from a small set of elements — paths (routes), edges (boundaries), districts (areas with a shared character), nodes (junctions), and landmarks (distinctive reference points visible from afar) — and a space rich in these is \"legible\": easy to recognize, organize, and navigate without disorientation [s-lynch-image-city]. a level that ignores them becomes a samey maze where every corridor looks alike and players get lost, retread, and disengage. strong landmarks let players orient after a distraction (a big fight, a detour) and re-fix their goal; distinct districts make \"i'm in the sewers now\" legible at a glance; clear paths and nodes make choices comprehensible. legibility is what turns navigation from a chore into confident movement. any navigable space, and critically any large, open, or interconnected world where getting lost is a real risk. the bigger and more open the space, the more it depends on landmarks and district identity. disorientation is sometimes the goal: horror, dread, and certain puzzle or dream-logic spaces deliberately break legibility to unsettle the player (a legible haunted house isn't scary). deliberately labyrinthine design — mazes, getting-lost-as-content — inverts this on purpose. and an intentionally illegible first impression can make later mastery of the space satisfying (dark souls' interconnected world rewards learning it). the principle is the default; breaking it should be a choice. plant landmarks tall or bright enough to be seen across the level, and make them distinct from each other. give districts their own palette, architecture, and mood so areas are identifiable at a glance. keep paths readable and junctions (nodes) clear. vary silhouettes so places aren't confusable. test by asking players to point toward where they've been — if they can't, the space isn't legible. legibility vs. deliberate disorientation is the axis: readable, confident navigation (most games) vs. intentional lostness for horror, mystery, or mastery-through-learning. both are valid; the question is whether knowing where you are should be given or earned. the orientation half of level legibility (level-0001 is the attention half), and the spatial counterpart of sys-0006 (legible systems). confidence 4."}
{"id":"GDC-L1-LEVEL-0003","title":"Pace intensity — shape a rhythm of tension and release","layer":"L1","domain":"LEVEL","subdomain":"pacing","type":"contextual","confidence":4,"status":"canonical","tags":["level-design","pacing","tension-release","rhythm","flow"],"related":["GDC-L1-DESIGN-0004","GDC-L1-PROG-0001","GDC-L1-LEVEL-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-leveldesign-guidance"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-LEVEL-0003.md","statement":"Shape a level's intensity over time like music: build tension, deliver a peak, then grant release. Sustained high intensity exhausts and numbs; sustained low intensity bores. Design the dramatic curve deliberately, with genuine rest beats after peaks.","sections":{"Statement":"> Shape a level's intensity over time like music: build tension, deliver a peak, then grant\n> release. Sustained high intensity exhausts and numbs; sustained low intensity bores.\n> Design the dramatic curve deliberately, with genuine rest beats after peaks.","Rationale":"Intensity is relative — a climax only lands if quieter moments precede it, and a scary\nmoment only frightens against a lull. A flat-out level fatigues players and flattens its own\npeaks (if everything is intense, nothing is); a flat-quiet level never grips. Pacing the\nrise and fall keeps the player emotionally engaged and physically able to keep going, and it\ngives the highs somewhere to stand out from [S-leveldesign-guidance]. This is the\nlevel-scale expression of flow (DESIGN-0004): the intensity curve is how you keep challenge\noscillating in the engaging band, and the rest beats are where the player recovers and\nconsolidates. Combat, exploration, quiet, and spectacle are the instruments; their\narrangement over time is the composition.","Applies when":"Any level or sequence with a temporal experience — action, adventure, horror, and story\nlevels especially. Applies fractally: within an encounter, a level, and the whole game.","Does not apply / Exceptions":"Some experiences deliberately hold one register: a relentless bullet-hell or an unbroken\nhorror set-piece may sustain intensity on purpose, and a meditative/cozy game may stay\ngentle throughout. Systemic sandboxes generate their own pacing from player choices rather\nthan authored curves. The principle is about *authored* pacing; emergent games shape the\nconditions instead.","Implementation (kept separate from the principle)":"Sketch the intended intensity curve for a level before building it, and place peaks, builds,\nand rests deliberately. Follow big peaks with real downtime — a safe room, a vista, a quiet\ntraversal — so the player recovers (this is also where reward/save/consolidation beats fit).\nVary the instruments (combat, puzzle, exploration, spectacle) to avoid monotony even at a\nconstant intensity. Watch playtesters for fatigue and for peaks that don't land.","Disagreement":"Authored pacing (deliberate curves) vs. emergent pacing (systems + player choice generate\nrhythm) is the main split, plus the deliberate-monotone exception (sustained horror or\nrelentless action). All are valid; the choice follows whether the experience is composed or\ngenerated.","Notes":"The temporal companion to the spatial LEVEL principles, and the level-scale form of\nDESIGN-0004 (flow) and PROG-0001 (pacing of power). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-LEVEL-0003\ntitle: Pace intensity — shape a rhythm of tension and release\nlayer: L1\ndomain: LEVEL\nsubdomain: pacing\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - level-design\n  - pacing\n  - tension-release\n  - rhythm\n  - flow\nrelated:\n  - GDC-L1-DESIGN-0004\n  - GDC-L1-PROG-0001\n  - GDC-L1-LEVEL-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-leveldesign-guidance\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Shape a level's intensity over time like music: build tension, deliver a peak, then grant\n> release. Sustained high intensity exhausts and numbs; sustained low intensity bores.\n> Design the dramatic curve deliberately, with genuine rest beats after peaks.\n\n## Rationale\nIntensity is relative — a climax only lands if quieter moments precede it, and a scary\nmoment only frightens against a lull. A flat-out level fatigues players and flattens its own\npeaks (if everything is intense, nothing is); a flat-quiet level never grips. Pacing the\nrise and fall keeps the player emotionally engaged and physically able to keep going, and it\ngives the highs somewhere to stand out from [S-leveldesign-guidance]. This is the\nlevel-scale expression of flow (DESIGN-0004): the intensity curve is how you keep challenge\noscillating in the engaging band, and the rest beats are where the player recovers and\nconsolidates. Combat, exploration, quiet, and spectacle are the instruments; their\narrangement over time is the composition.\n\n## Applies when\nAny level or sequence with a temporal experience — action, adventure, horror, and story\nlevels especially. Applies fractally: within an encounter, a level, and the whole game.\n\n## Does not apply / Exceptions\nSome experiences deliberately hold one register: a relentless bullet-hell or an unbroken\nhorror set-piece may sustain intensity on purpose, and a meditative/cozy game may stay\ngentle throughout. Systemic sandboxes generate their own pacing from player choices rather\nthan authored curves. The principle is about *authored* pacing; emergent games shape the\nconditions instead.\n\n## Implementation (kept separate from the principle)\nSketch the intended intensity curve for a level before building it, and place peaks, builds,\nand rests deliberately. Follow big peaks with real downtime — a safe room, a vista, a quiet\ntraversal — so the player recovers (this is also where reward/save/consolidation beats fit).\nVary the instruments (combat, puzzle, exploration, spectacle) to avoid monotony even at a\nconstant intensity. Watch playtesters for fatigue and for peaks that don't land.\n\n## Disagreement\nAuthored pacing (deliberate curves) vs. emergent pacing (systems + player choice generate\nrhythm) is the main split, plus the deliberate-monotone exception (sustained horror or\nrelentless action). All are valid; the choice follows whether the experience is composed or\ngenerated.\n\n## Notes\nThe temporal companion to the spatial LEVEL principles, and the level-scale form of\nDESIGN-0004 (flow) and PROG-0001 (pacing of power). Confidence 4.\n","searchText":"gdc-l1-level-0003 pace intensity — shape a rhythm of tension and release level-design pacing tension-release rhythm flow > shape a level's intensity over time like music: build tension, deliver a peak, then grant release. sustained high intensity exhausts and numbs; sustained low intensity bores. design the dramatic curve deliberately, with genuine rest beats after peaks. intensity is relative — a climax only lands if quieter moments precede it, and a scary moment only frightens against a lull. a flat-out level fatigues players and flattens its own peaks (if everything is intense, nothing is); a flat-quiet level never grips. pacing the rise and fall keeps the player emotionally engaged and physically able to keep going, and it gives the highs somewhere to stand out from [s-leveldesign-guidance]. this is the level-scale expression of flow (design-0004): the intensity curve is how you keep challenge oscillating in the engaging band, and the rest beats are where the player recovers and consolidates. combat, exploration, quiet, and spectacle are the instruments; their arrangement over time is the composition. any level or sequence with a temporal experience — action, adventure, horror, and story levels especially. applies fractally: within an encounter, a level, and the whole game. some experiences deliberately hold one register: a relentless bullet-hell or an unbroken horror set-piece may sustain intensity on purpose, and a meditative/cozy game may stay gentle throughout. systemic sandboxes generate their own pacing from player choices rather than authored curves. the principle is about authored pacing; emergent games shape the conditions instead. sketch the intended intensity curve for a level before building it, and place peaks, builds, and rests deliberately. follow big peaks with real downtime — a safe room, a vista, a quiet traversal — so the player recovers (this is also where reward/save/consolidation beats fit). vary the instruments (combat, puzzle, exploration, spectacle) to avoid monotony even at a constant intensity. watch playtesters for fatigue and for peaks that don't land. authored pacing (deliberate curves) vs. emergent pacing (systems + player choice generate rhythm) is the main split, plus the deliberate-monotone exception (sustained horror or relentless action). all are valid; the choice follows whether the experience is composed or generated. the temporal companion to the spatial level principles, and the level-scale form of design-0004 (flow) and prog-0001 (pacing of power). confidence 4."}
{"id":"GDC-L1-LEVEL-0004","title":"Teach through space — the level is a tutorial","layer":"L1","domain":"LEVEL","subdomain":"encounter-design","type":"contextual","confidence":4,"status":"canonical","tags":["level-design","teaching","onboarding","spatial-teaching","safe-introduction"],"related":["GDC-L1-PROG-0005","GDC-L1-DESIGN-0003","GDC-L1-LEVEL-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-mark-brown-4step"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-LEVEL-0004.md","statement":"Use the environment to teach. Introduce a mechanic in a safe space where failure is cheap, then let the layout pose progressively harder applications of it. A well-built level teaches by doing, spatially, without text boxes — it is the game's best tutorial.","sections":{"Statement":"> Use the environment to teach. Introduce a mechanic in a **safe** space where failure is\n> cheap, then let the layout pose progressively harder applications of it. A well-built\n> level teaches by *doing*, spatially, without text boxes — it is the game's best tutorial.","Rationale":"Players learn mechanics far better by using them in a controlled space than by reading\ninstructions, and space is a superb teacher because it can *force* the right lesson: a pit\nwith a clear ledge teaches jumping; a gap that only a dash can cross teaches the dash the\nmoment after you earned it. The four-step arc (introduce safely → develop → twist → conclude)\nmaps directly onto physical space — a safe first encounter, a complication, a\nrecontextualization, and a final payoff [S-mark-brown-4step]. This is\n\"fun is learning\" (DESIGN-0003) delivered through geometry, and it keeps guidance implicit\n(LEVEL-0001) rather than interrupting play with tutorial pop-ups.","Applies when":"Introducing any mechanic, tool, or enemy through the world — tutorial areas, early levels,\nand the first appearance of anything new anywhere in the game.","Does not apply / Exceptions":"Highly systemic games teach through experimentation rather than authored spatial arcs. And some complex systems genuinely need explicit instruction that space alone can't convey.","Implementation (kept separate from the principle)":"For each new mechanic, build a safe introduction (try and fail without punishment), then\nspaces that develop and twist it, then a concluding payoff or demonstration. Use sightlines and composition\n(LEVEL-0001) to show the lesson before demanding it. Sequence introductions so the learning\nload stays steady (PROG-0005, PROG-0001). Where the game's identity is discovery, hide the\n\"teach\" step and let the space *imply* the mechanic.","Disagreement":"Authored spatial teaching (guided, clear) vs. discovery teaching (unguided, figure-it-out).\nThe former maximizes clarity and reach; the latter maximizes the pleasure of insight and\nsuits systemic/mystery/discovery games. Same axis as PROG-0005, expressed in space.","Notes":"The spatial delivery of PROG-0005 (introduce-develop-twist-conclude) and DESIGN-0003 (fun is learning). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-LEVEL-0004\ntitle: Teach through space — the level is a tutorial\nlayer: L1\ndomain: LEVEL\nsubdomain: encounter-design\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - level-design\n  - teaching\n  - onboarding\n  - spatial-teaching\n  - safe-introduction\nrelated:\n  - GDC-L1-PROG-0005\n  - GDC-L1-DESIGN-0003\n  - GDC-L1-LEVEL-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-mark-brown-4step\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Use the environment to teach. Introduce a mechanic in a **safe** space where failure is\n> cheap, then let the layout pose progressively harder applications of it. A well-built\n> level teaches by *doing*, spatially, without text boxes — it is the game's best tutorial.\n\n## Rationale\nPlayers learn mechanics far better by using them in a controlled space than by reading\ninstructions, and space is a superb teacher because it can *force* the right lesson: a pit\nwith a clear ledge teaches jumping; a gap that only a dash can cross teaches the dash the\nmoment after you earned it. The four-step arc (introduce safely → develop → twist → conclude)\nmaps directly onto physical space — a safe first encounter, a complication, a\nrecontextualization, and a final payoff [S-mark-brown-4step]. This is\n\"fun is learning\" (DESIGN-0003) delivered through geometry, and it keeps guidance implicit\n(LEVEL-0001) rather than interrupting play with tutorial pop-ups.\n\n## Applies when\nIntroducing any mechanic, tool, or enemy through the world — tutorial areas, early levels,\nand the first appearance of anything new anywhere in the game.\n\n## Does not apply / Exceptions\nHighly systemic games teach through experimentation rather than authored spatial arcs. And some complex systems genuinely need explicit instruction that space alone can't convey.\n\n## Implementation (kept separate from the principle)\nFor each new mechanic, build a safe introduction (try and fail without punishment), then\nspaces that develop and twist it, then a concluding payoff or demonstration. Use sightlines and composition\n(LEVEL-0001) to show the lesson before demanding it. Sequence introductions so the learning\nload stays steady (PROG-0005, PROG-0001). Where the game's identity is discovery, hide the\n\"teach\" step and let the space *imply* the mechanic.\n\n## Disagreement\nAuthored spatial teaching (guided, clear) vs. discovery teaching (unguided, figure-it-out).\nThe former maximizes clarity and reach; the latter maximizes the pleasure of insight and\nsuits systemic/mystery/discovery games. Same axis as PROG-0005, expressed in space.\n\n## Notes\nThe spatial delivery of PROG-0005 (introduce-develop-twist-conclude) and DESIGN-0003 (fun is learning). Confidence 4.\n","searchText":"gdc-l1-level-0004 teach through space — the level is a tutorial level-design teaching onboarding spatial-teaching safe-introduction > use the environment to teach. introduce a mechanic in a safe space where failure is cheap, then let the layout pose progressively harder applications of it. a well-built level teaches by doing, spatially, without text boxes — it is the game's best tutorial. players learn mechanics far better by using them in a controlled space than by reading instructions, and space is a superb teacher because it can force the right lesson: a pit with a clear ledge teaches jumping; a gap that only a dash can cross teaches the dash the moment after you earned it. the four-step arc (introduce safely → develop → twist → conclude) maps directly onto physical space — a safe first encounter, a complication, a recontextualization, and a final payoff [s-mark-brown-4step]. this is \"fun is learning\" (design-0003) delivered through geometry, and it keeps guidance implicit (level-0001) rather than interrupting play with tutorial pop-ups. introducing any mechanic, tool, or enemy through the world — tutorial areas, early levels, and the first appearance of anything new anywhere in the game. highly systemic games teach through experimentation rather than authored spatial arcs. and some complex systems genuinely need explicit instruction that space alone can't convey. for each new mechanic, build a safe introduction (try and fail without punishment), then spaces that develop and twist it, then a concluding payoff or demonstration. use sightlines and composition (level-0001) to show the lesson before demanding it. sequence introductions so the learning load stays steady (prog-0005, prog-0001). where the game's identity is discovery, hide the \"teach\" step and let the space imply the mechanic. authored spatial teaching (guided, clear) vs. discovery teaching (unguided, figure-it-out). the former maximizes clarity and reach; the latter maximizes the pleasure of insight and suits systemic/mystery/discovery games. same axis as prog-0005, expressed in space. the spatial delivery of prog-0005 (introduce-develop-twist-conclude) and design-0003 (fun is learning). confidence 4."}
{"id":"GDC-L1-LEVEL-0005","title":"Balance guidance with exploration — a clear spine and rewarded detours","layer":"L1","domain":"LEVEL","subdomain":"open-vs-linear","type":"contextual","confidence":4,"status":"canonical","tags":["level-design","exploration","critical-path","agency","open-vs-linear"],"related":["GDC-L1-DESIGN-0006","GDC-L1-SYS-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-leveldesign-guidance"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-LEVEL-0005.md","statement":"Give players a legible critical path so they rarely get truly stuck or lost — and reward those who stray from it with worthwhile discoveries. Pure linearity denies agency; pure openness invites disorientation and empty wandering. The craft is a readable spine with branches that pay.","sections":{"Statement":"> Give players a legible critical path so they rarely get truly stuck or lost — and reward\n> those who stray from it with worthwhile discoveries. Pure linearity denies agency; pure\n> openness invites disorientation and empty wandering. The craft is a readable spine with\n> branches that pay.","Rationale":"Exploration is only rewarding when two things are true at once: the player can always find their way forward (so straying is a choice, not a trap), and straying is *worth it* (so the choice has value). A level that is all corridor removes the player's agency to explore; a level that is all open space with no legible spine leaves players wandering, unsure if they're making progress or missing everything [S-leveldesign-guidance]. The resolution is a clear main route (guidance, LEVEL-0001/0002) threaded through optional space that rewards curiosity — so the directed player never gets lost and the curious player always gets paid.","Applies when":"Any level with more than a single forced path — most exploration, adventure, RPG, and\nmetroidvania design. The tension between guidance and freedom is central to all of them.","Does not apply / Exceptions":"Deliberately linear designs (many story-driven and cinematic games) trade exploration for a\ntightly controlled, authored experience — a valid choice, not a failure. Fully open sandbox\ndesigns push almost entirely to the freedom pole and accept some disorientation as the price\nof emergence (SYS-0003). Where a game sits on the linear↔open axis is a defining decision;\nthis principle governs the large middle where both matter.","Implementation (kept separate from the principle)":"Establish a readable critical path (landmarks, leading lines, district identity) so forward progress is always findable. Scale the reward to the effort to reach it. Use guidance to keep the spine legible without walling off the branches.","Disagreement":"Linear (authored, controlled, no getting lost) vs. open (free, exploratory, some\ndisorientation) is one of level design's defining axes. Both extremes ship great games; the\nchoice follows whether the experience is a directed story or a space to inhabit. This\nprinciple is the balanced middle both extremes bend toward.","Notes":"Connects to DESIGN-0006 (agency) and SYS-0003 (emergent vs authored). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-LEVEL-0005\ntitle: Balance guidance with exploration — a clear spine and rewarded detours\nlayer: L1\ndomain: LEVEL\nsubdomain: open-vs-linear\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - level-design\n  - exploration\n  - critical-path\n  - agency\n  - open-vs-linear\nrelated:\n  - GDC-L1-DESIGN-0006\n  - GDC-L1-SYS-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-leveldesign-guidance\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Give players a legible critical path so they rarely get truly stuck or lost — and reward\n> those who stray from it with worthwhile discoveries. Pure linearity denies agency; pure\n> openness invites disorientation and empty wandering. The craft is a readable spine with\n> branches that pay.\n\n## Rationale\nExploration is only rewarding when two things are true at once: the player can always find their way forward (so straying is a choice, not a trap), and straying is *worth it* (so the choice has value). A level that is all corridor removes the player's agency to explore; a level that is all open space with no legible spine leaves players wandering, unsure if they're making progress or missing everything [S-leveldesign-guidance]. The resolution is a clear main route (guidance, LEVEL-0001/0002) threaded through optional space that rewards curiosity — so the directed player never gets lost and the curious player always gets paid.\n\n## Applies when\nAny level with more than a single forced path — most exploration, adventure, RPG, and\nmetroidvania design. The tension between guidance and freedom is central to all of them.\n\n## Does not apply / Exceptions\nDeliberately linear designs (many story-driven and cinematic games) trade exploration for a\ntightly controlled, authored experience — a valid choice, not a failure. Fully open sandbox\ndesigns push almost entirely to the freedom pole and accept some disorientation as the price\nof emergence (SYS-0003). Where a game sits on the linear↔open axis is a defining decision;\nthis principle governs the large middle where both matter.\n\n## Implementation (kept separate from the principle)\nEstablish a readable critical path (landmarks, leading lines, district identity) so forward progress is always findable. Scale the reward to the effort to reach it. Use guidance to keep the spine legible without walling off the branches.\n\n## Disagreement\nLinear (authored, controlled, no getting lost) vs. open (free, exploratory, some\ndisorientation) is one of level design's defining axes. Both extremes ship great games; the\nchoice follows whether the experience is a directed story or a space to inhabit. This\nprinciple is the balanced middle both extremes bend toward.\n\n## Notes\nConnects to DESIGN-0006 (agency) and SYS-0003 (emergent vs authored). Confidence 4.\n","searchText":"gdc-l1-level-0005 balance guidance with exploration — a clear spine and rewarded detours level-design exploration critical-path agency open-vs-linear > give players a legible critical path so they rarely get truly stuck or lost — and reward those who stray from it with worthwhile discoveries. pure linearity denies agency; pure openness invites disorientation and empty wandering. the craft is a readable spine with branches that pay. exploration is only rewarding when two things are true at once: the player can always find their way forward (so straying is a choice, not a trap), and straying is worth it (so the choice has value). a level that is all corridor removes the player's agency to explore; a level that is all open space with no legible spine leaves players wandering, unsure if they're making progress or missing everything [s-leveldesign-guidance]. the resolution is a clear main route (guidance, level-0001/0002) threaded through optional space that rewards curiosity — so the directed player never gets lost and the curious player always gets paid. any level with more than a single forced path — most exploration, adventure, rpg, and metroidvania design. the tension between guidance and freedom is central to all of them. deliberately linear designs (many story-driven and cinematic games) trade exploration for a tightly controlled, authored experience — a valid choice, not a failure. fully open sandbox designs push almost entirely to the freedom pole and accept some disorientation as the price of emergence (sys-0003). where a game sits on the linear↔open axis is a defining decision; this principle governs the large middle where both matter. establish a readable critical path (landmarks, leading lines, district identity) so forward progress is always findable. scale the reward to the effort to reach it. use guidance to keep the spine legible without walling off the branches. linear (authored, controlled, no getting lost) vs. open (free, exploratory, some disorientation) is one of level design's defining axes. both extremes ship great games; the choice follows whether the experience is a directed story or a space to inhabit. this principle is the balanced middle both extremes bend toward. connects to design-0006 (agency) and sys-0003 (emergent vs authored). confidence 4."}
{"id":"GDC-L1-LEVEL-0006","title":"Show before you go — use vistas and foreshadowing to plant goals","layer":"L1","domain":"LEVEL","subdomain":"composition","type":"contextual","confidence":3,"status":"canonical","tags":["level-design","vistas","foreshadowing","anticipation","composition"],"related":["GDC-L1-LEVEL-0001","GDC-L1-LEVEL-0002","GDC-L1-LEVEL-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-leveldesign-guidance"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-LEVEL-0006.md","statement":"Let the player see a destination before they can reach it. A framed vista of a distant landmark, a glimpse of a locked-off area, or a preview of a coming challenge plants a self-directed goal and builds anticipation — so that arriving later feels earned and meaningful.","sections":{"Statement":"> Let the player *see* a destination before they can reach it. A framed vista of a distant\n> landmark, a glimpse of a locked-off area, or a preview of a coming challenge plants a\n> self-directed goal and builds anticipation — so that arriving later feels earned and\n> meaningful.","Rationale":"A goal the player forms themselves is more motivating than one the game assigns. When you\nframe a striking landmark on the horizon (\"I want to get up *there*\") or reveal a barred\ndoor (\"what's behind that?\"), you create desire and a memory that pays off on arrival — the\nplace is already meaningful because the player wanted it before they had it. Vistas also do\ndouble duty as orientation: a landmark seen from afar becomes the reference point that makes\nthe space legible later (LEVEL-0002). And foreshadowing a challenge lets dread or excitement\nbuild before the encounter, sharpening the moment. Showing-before-going turns traversal into\nanticipation instead of transit [S-leveldesign-guidance].","Applies when":"Open and semi-open spaces, and any moment you want the player to *want* to reach somewhere.\nEspecially powerful at the start of a level (establishing the goal) and before major set\npieces.","Does not apply / Exceptions":"Tightly enclosed or claustrophobic designs (many horror and corridor games) deliberately\ndeny the long view to keep players disoriented and anxious — the opposite technique on\npurpose. Overusing reveals can also spoil surprise; some payoffs land harder when\n*unforeshadowed*. And a promised destination that disappoints on arrival (LEVEL-0005's empty\ndiversion) is worse than never showing it — a shown goal makes a payoff *promise*.","Implementation (kept separate from the principle)":"Frame distant landmarks and future destinations through windows, ridgelines, and\narchitectural openings; use composition and light (LEVEL-0001) to make them pull the eye.\nReveal locked areas the player will later unlock, so the unlock feels like a returned\npromise. Foreshadow big challenges with a glimpse. Make sure every shown destination pays\noff on arrival (LEVEL-0005).","Disagreement":"Reveal-and-anticipate (open, motivating, orienting) vs. conceal-for-surprise-or-dread\n(enclosed, tense) are opposite tools for opposite feelings; neither is universally right.\nAnd some designers prize unforeshadowed surprises over telegraphed goals. Match the technique\nto the intended emotion.","Notes":"A composition technique that also feeds legibility (LEVEL-0002) and the guidance/exploration\nbalance (LEVEL-0005). Confidence 3 — effective and well-known, but more a strong technique\nthan a near-universal law, and genre-dependent."},"rawMarkdown":"---\nid: GDC-L1-LEVEL-0006\ntitle: Show before you go — use vistas and foreshadowing to plant goals\nlayer: L1\ndomain: LEVEL\nsubdomain: composition\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - level-design\n  - vistas\n  - foreshadowing\n  - anticipation\n  - composition\nrelated:\n  - GDC-L1-LEVEL-0001\n  - GDC-L1-LEVEL-0002\n  - GDC-L1-LEVEL-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-leveldesign-guidance\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Let the player *see* a destination before they can reach it. A framed vista of a distant\n> landmark, a glimpse of a locked-off area, or a preview of a coming challenge plants a\n> self-directed goal and builds anticipation — so that arriving later feels earned and\n> meaningful.\n\n## Rationale\nA goal the player forms themselves is more motivating than one the game assigns. When you\nframe a striking landmark on the horizon (\"I want to get up *there*\") or reveal a barred\ndoor (\"what's behind that?\"), you create desire and a memory that pays off on arrival — the\nplace is already meaningful because the player wanted it before they had it. Vistas also do\ndouble duty as orientation: a landmark seen from afar becomes the reference point that makes\nthe space legible later (LEVEL-0002). And foreshadowing a challenge lets dread or excitement\nbuild before the encounter, sharpening the moment. Showing-before-going turns traversal into\nanticipation instead of transit [S-leveldesign-guidance].\n\n## Applies when\nOpen and semi-open spaces, and any moment you want the player to *want* to reach somewhere.\nEspecially powerful at the start of a level (establishing the goal) and before major set\npieces.\n\n## Does not apply / Exceptions\nTightly enclosed or claustrophobic designs (many horror and corridor games) deliberately\ndeny the long view to keep players disoriented and anxious — the opposite technique on\npurpose. Overusing reveals can also spoil surprise; some payoffs land harder when\n*unforeshadowed*. And a promised destination that disappoints on arrival (LEVEL-0005's empty\ndiversion) is worse than never showing it — a shown goal makes a payoff *promise*.\n\n## Implementation (kept separate from the principle)\nFrame distant landmarks and future destinations through windows, ridgelines, and\narchitectural openings; use composition and light (LEVEL-0001) to make them pull the eye.\nReveal locked areas the player will later unlock, so the unlock feels like a returned\npromise. Foreshadow big challenges with a glimpse. Make sure every shown destination pays\noff on arrival (LEVEL-0005).\n\n## Disagreement\nReveal-and-anticipate (open, motivating, orienting) vs. conceal-for-surprise-or-dread\n(enclosed, tense) are opposite tools for opposite feelings; neither is universally right.\nAnd some designers prize unforeshadowed surprises over telegraphed goals. Match the technique\nto the intended emotion.\n\n## Notes\nA composition technique that also feeds legibility (LEVEL-0002) and the guidance/exploration\nbalance (LEVEL-0005). Confidence 3 — effective and well-known, but more a strong technique\nthan a near-universal law, and genre-dependent.\n","searchText":"gdc-l1-level-0006 show before you go — use vistas and foreshadowing to plant goals level-design vistas foreshadowing anticipation composition > let the player see a destination before they can reach it. a framed vista of a distant landmark, a glimpse of a locked-off area, or a preview of a coming challenge plants a self-directed goal and builds anticipation — so that arriving later feels earned and meaningful. a goal the player forms themselves is more motivating than one the game assigns. when you frame a striking landmark on the horizon (\"i want to get up there\") or reveal a barred door (\"what's behind that?\"), you create desire and a memory that pays off on arrival — the place is already meaningful because the player wanted it before they had it. vistas also do double duty as orientation: a landmark seen from afar becomes the reference point that makes the space legible later (level-0002). and foreshadowing a challenge lets dread or excitement build before the encounter, sharpening the moment. showing-before-going turns traversal into anticipation instead of transit [s-leveldesign-guidance]. open and semi-open spaces, and any moment you want the player to want to reach somewhere. especially powerful at the start of a level (establishing the goal) and before major set pieces. tightly enclosed or claustrophobic designs (many horror and corridor games) deliberately deny the long view to keep players disoriented and anxious — the opposite technique on purpose. overusing reveals can also spoil surprise; some payoffs land harder when unforeshadowed. and a promised destination that disappoints on arrival (level-0005's empty diversion) is worse than never showing it — a shown goal makes a payoff promise. frame distant landmarks and future destinations through windows, ridgelines, and architectural openings; use composition and light (level-0001) to make them pull the eye. reveal locked areas the player will later unlock, so the unlock feels like a returned promise. foreshadow big challenges with a glimpse. make sure every shown destination pays off on arrival (level-0005). reveal-and-anticipate (open, motivating, orienting) vs. conceal-for-surprise-or-dread (enclosed, tense) are opposite tools for opposite feelings; neither is universally right. and some designers prize unforeshadowed surprises over telegraphed goals. match the technique to the intended emotion. a composition technique that also feeds legibility (level-0002) and the guidance/exploration balance (level-0005). confidence 3 — effective and well-known, but more a strong technique than a near-universal law, and genre-dependent."}
{"id":"GDC-L1-LEVEL-0007","title":"Tell story through the environment — let players pull the narrative","layer":"L1","domain":"LEVEL","subdomain":"environmental-storytelling","type":"contextual","confidence":4,"status":"canonical","tags":["environmental-storytelling","narrative","level-design","discovery","worldbuilding"],"related":["GDC-L1-DESIGN-0006","GDC-L1-LEVEL-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-worch-smith-envstory"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-LEVEL-0007.md","statement":"Let space imply history and story through layout, props, aftermath, and composition, inviting the player to ask \"what happened here?\" and piece it together themselves. Because players explore rather than being shown, environmental narrative rewards attention — and it must be possible to miss some of it for finding it to feel meaningful.","sections":{"Statement":"> Let space imply history and story through layout, props, aftermath, and composition,\n> inviting the player to ask *\"what happened here?\"* and piece it together themselves.\n> Because players explore rather than being shown, environmental narrative rewards\n> attention — and it must be *possible to miss* some of it for finding it to feel\n> meaningful.","Rationale":"Film and prose *push* the audience's attention where the author wants it; games are\ndifferent — the player explores and *pulls* meaning from what they choose to examine\n[S-worch-smith-envstory]. Environmental storytelling leverages that: a ransacked room, two\nskeletons posed mid-argument, a child's drawing in a soldier's bunk, a barricade that failed\n— these invite the player to reconstruct events, and the act of inferring builds far more\ninvestment than being told. Two consequences follow. First, the story lives in the *space*,\nso it reaches players who ignore text. Second, and crucially, some of it must be *missable*:\nif every player is forced to see every story beat, discovery is hollow — it's the\npossibility of missing it that makes finding it feel like the player's own.","Applies when":"Any game with authored space and any desire to convey history, mood, or narrative without\n(or alongside) explicit text. Especially powerful for exploration- and atmosphere-driven\ngames, and for making spaces feel significant before written story exists.","Does not apply / Exceptions":"Some stories need to be *told*, not inferred — critical plot the player must not miss should\nnot rely solely on missable environmental cues (pair it with explicit narrative). Abstract,\nminimalist, or purely mechanical games may have no fiction to embed. And environmental\nstorytelling is craft-intensive; a rushed version reads as random clutter rather than\nimplied history.","Implementation (kept separate from the principle)":"Compose scenes that imply a before-and-after: what was this place, what happened, what's\nleft? Use props, damage, positioning, and juxtaposition as sentences. Layer it — a casual\nglance reads mood, a careful look reveals a specific story. Deliberately make the richer\nreadings optional and rewarding (LEVEL-0005's \"every space pays\"). Even before written\nnarrative exists, build \"lore-shaped\" spaces that *imply* meaning, so curiosity is rewarded\nwith a sense of significance.","Disagreement":"Embedded/pulled narrative (player-inferred, missable, immersive) vs. delivered/pushed\nnarrative (authored, guaranteed, controlled) are complementary, not rivals — most games use\nboth, reserving pushed narrative for must-not-miss plot and pulled narrative for depth,\nmood, and reward. The debate is about the *mix*, and how much to trust players to find and\nassemble.","Notes":"Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-LEVEL-0007\ntitle: Tell story through the environment — let players pull the narrative\nlayer: L1\ndomain: LEVEL\nsubdomain: environmental-storytelling\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - environmental-storytelling\n  - narrative\n  - level-design\n  - discovery\n  - worldbuilding\nrelated:\n  - GDC-L1-DESIGN-0006\n  - GDC-L1-LEVEL-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-worch-smith-envstory\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Let space imply history and story through layout, props, aftermath, and composition,\n> inviting the player to ask *\"what happened here?\"* and piece it together themselves.\n> Because players explore rather than being shown, environmental narrative rewards\n> attention — and it must be *possible to miss* some of it for finding it to feel\n> meaningful.\n\n## Rationale\nFilm and prose *push* the audience's attention where the author wants it; games are\ndifferent — the player explores and *pulls* meaning from what they choose to examine\n[S-worch-smith-envstory]. Environmental storytelling leverages that: a ransacked room, two\nskeletons posed mid-argument, a child's drawing in a soldier's bunk, a barricade that failed\n— these invite the player to reconstruct events, and the act of inferring builds far more\ninvestment than being told. Two consequences follow. First, the story lives in the *space*,\nso it reaches players who ignore text. Second, and crucially, some of it must be *missable*:\nif every player is forced to see every story beat, discovery is hollow — it's the\npossibility of missing it that makes finding it feel like the player's own.\n\n## Applies when\nAny game with authored space and any desire to convey history, mood, or narrative without\n(or alongside) explicit text. Especially powerful for exploration- and atmosphere-driven\ngames, and for making spaces feel significant before written story exists.\n\n## Does not apply / Exceptions\nSome stories need to be *told*, not inferred — critical plot the player must not miss should\nnot rely solely on missable environmental cues (pair it with explicit narrative). Abstract,\nminimalist, or purely mechanical games may have no fiction to embed. And environmental\nstorytelling is craft-intensive; a rushed version reads as random clutter rather than\nimplied history.\n\n## Implementation (kept separate from the principle)\nCompose scenes that imply a before-and-after: what was this place, what happened, what's\nleft? Use props, damage, positioning, and juxtaposition as sentences. Layer it — a casual\nglance reads mood, a careful look reveals a specific story. Deliberately make the richer\nreadings optional and rewarding (LEVEL-0005's \"every space pays\"). Even before written\nnarrative exists, build \"lore-shaped\" spaces that *imply* meaning, so curiosity is rewarded\nwith a sense of significance.\n\n## Disagreement\nEmbedded/pulled narrative (player-inferred, missable, immersive) vs. delivered/pushed\nnarrative (authored, guaranteed, controlled) are complementary, not rivals — most games use\nboth, reserving pushed narrative for must-not-miss plot and pulled narrative for depth,\nmood, and reward. The debate is about the *mix*, and how much to trust players to find and\nassemble.\n\n## Notes\nConfidence 4.\n","searchText":"gdc-l1-level-0007 tell story through the environment — let players pull the narrative environmental-storytelling narrative level-design discovery worldbuilding > let space imply history and story through layout, props, aftermath, and composition, inviting the player to ask \"what happened here?\" and piece it together themselves. because players explore rather than being shown, environmental narrative rewards attention — and it must be possible to miss some of it for finding it to feel meaningful. film and prose push the audience's attention where the author wants it; games are different — the player explores and pulls meaning from what they choose to examine [s-worch-smith-envstory]. environmental storytelling leverages that: a ransacked room, two skeletons posed mid-argument, a child's drawing in a soldier's bunk, a barricade that failed — these invite the player to reconstruct events, and the act of inferring builds far more investment than being told. two consequences follow. first, the story lives in the space, so it reaches players who ignore text. second, and crucially, some of it must be missable: if every player is forced to see every story beat, discovery is hollow — it's the possibility of missing it that makes finding it feel like the player's own. any game with authored space and any desire to convey history, mood, or narrative without (or alongside) explicit text. especially powerful for exploration- and atmosphere-driven games, and for making spaces feel significant before written story exists. some stories need to be told, not inferred — critical plot the player must not miss should not rely solely on missable environmental cues (pair it with explicit narrative). abstract, minimalist, or purely mechanical games may have no fiction to embed. and environmental storytelling is craft-intensive; a rushed version reads as random clutter rather than implied history. compose scenes that imply a before-and-after: what was this place, what happened, what's left? use props, damage, positioning, and juxtaposition as sentences. layer it — a casual glance reads mood, a careful look reveals a specific story. deliberately make the richer readings optional and rewarding (level-0005's \"every space pays\"). even before written narrative exists, build \"lore-shaped\" spaces that imply meaning, so curiosity is rewarded with a sense of significance. embedded/pulled narrative (player-inferred, missable, immersive) vs. delivered/pushed narrative (authored, guaranteed, controlled) are complementary, not rivals — most games use both, reserving pushed narrative for must-not-miss plot and pulled narrative for depth, mood, and reward. the debate is about the mix, and how much to trust players to find and assemble. confidence 4."}
{"id":"GDC-L1-LEVEL-0008","title":"Shape encounters through space — the arena is a combat design tool","layer":"L1","domain":"LEVEL","subdomain":"encounter-design","type":"contextual","confidence":4,"status":"canonical","tags":["encounter-design","combat","space","sightlines","level-design"],"related":["GDC-L1-DESIGN-0002","GDC-L1-LEVEL-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-leveldesign-guidance"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-LEVEL-0008.md","statement":"Combat is shaped as much by the space as by the enemies in it. Cover, elevation, chokepoints, sightlines, hazards, and open ground determine which tactics are viable and how a fight feels. Design encounter spaces to elicit the intended combat — don't drop enemies into neutral rooms and hope.","sections":{"Statement":"> Combat is shaped as much by the *space* as by the enemies in it. Cover, elevation,\n> chokepoints, sightlines, hazards, and open ground determine which tactics are viable and\n> how a fight feels. Design encounter spaces to *elicit* the intended combat — don't drop\n> enemies into neutral rooms and hope.","Rationale":"The same enemies produce entirely different fights depending on the arena: a sniper is\nlethal across a long sightline and useless in a cramped corridor; melee rushers are terrifying\nin open ground and trivial behind a chokepoint; cover invites peek-and-shoot, elevation\nrewards positioning, hazards add a third party to the fight [S-leveldesign-guidance]. So the\nspace is a primary lever of encounter design — it creates or removes the *interesting\ndecisions* a fight offers (DESIGN-0002). A well-shaped arena makes players use the mechanics\nyou want them to use and express the playstyles you're designing for; a shapeless one flattens\nevery encounter into the same exchange regardless of the enemy roster.","Applies when":"Any game with spatial combat — action, shooters, RPGs, tactics. The more the combat depends\non positioning, the more the space matters.","Does not apply / Exceptions":"Combat systems that are largely space-independent (many turn-based menu battles, some\nabstract or arena-agnostic fighters) derive challenge from mechanics rather than geometry.\nAnd space can be *over*-designed — an arena so bristling with cover and hazards that it reads\nas a puzzle can undercut a game that wants raw, readable brawls. Match the spatial complexity\nto the combat's intent.","Implementation (kept separate from the principle)":"Use sightlines to set engagement range, cover and elevation to create positional decisions, chokepoints to control flow, and hazards to add tension. Vary encounter spaces so fights don't feel identical (feeds pacing, LEVEL-0003). Playtest whether the space actually produces the intended fight.","Disagreement":"Space-driven encounter design (the arena is a core combat variable) vs. system-driven combat\n(the mechanics carry the fight, space is secondary) reflects genre: positional/tactical games\nlean spatial, abstract/menu combat leans systemic. Both are valid within their traditions.","Notes":"Feeds pacing (LEVEL-0003). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-LEVEL-0008\ntitle: Shape encounters through space — the arena is a combat design tool\nlayer: L1\ndomain: LEVEL\nsubdomain: encounter-design\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - encounter-design\n  - combat\n  - space\n  - sightlines\n  - level-design\nrelated:\n  - GDC-L1-DESIGN-0002\n  - GDC-L1-LEVEL-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-leveldesign-guidance\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Combat is shaped as much by the *space* as by the enemies in it. Cover, elevation,\n> chokepoints, sightlines, hazards, and open ground determine which tactics are viable and\n> how a fight feels. Design encounter spaces to *elicit* the intended combat — don't drop\n> enemies into neutral rooms and hope.\n\n## Rationale\nThe same enemies produce entirely different fights depending on the arena: a sniper is\nlethal across a long sightline and useless in a cramped corridor; melee rushers are terrifying\nin open ground and trivial behind a chokepoint; cover invites peek-and-shoot, elevation\nrewards positioning, hazards add a third party to the fight [S-leveldesign-guidance]. So the\nspace is a primary lever of encounter design — it creates or removes the *interesting\ndecisions* a fight offers (DESIGN-0002). A well-shaped arena makes players use the mechanics\nyou want them to use and express the playstyles you're designing for; a shapeless one flattens\nevery encounter into the same exchange regardless of the enemy roster.\n\n## Applies when\nAny game with spatial combat — action, shooters, RPGs, tactics. The more the combat depends\non positioning, the more the space matters.\n\n## Does not apply / Exceptions\nCombat systems that are largely space-independent (many turn-based menu battles, some\nabstract or arena-agnostic fighters) derive challenge from mechanics rather than geometry.\nAnd space can be *over*-designed — an arena so bristling with cover and hazards that it reads\nas a puzzle can undercut a game that wants raw, readable brawls. Match the spatial complexity\nto the combat's intent.\n\n## Implementation (kept separate from the principle)\nUse sightlines to set engagement range, cover and elevation to create positional decisions, chokepoints to control flow, and hazards to add tension. Vary encounter spaces so fights don't feel identical (feeds pacing, LEVEL-0003). Playtest whether the space actually produces the intended fight.\n\n## Disagreement\nSpace-driven encounter design (the arena is a core combat variable) vs. system-driven combat\n(the mechanics carry the fight, space is secondary) reflects genre: positional/tactical games\nlean spatial, abstract/menu combat leans systemic. Both are valid within their traditions.\n\n## Notes\nFeeds pacing (LEVEL-0003). Confidence 4.\n","searchText":"gdc-l1-level-0008 shape encounters through space — the arena is a combat design tool encounter-design combat space sightlines level-design > combat is shaped as much by the space as by the enemies in it. cover, elevation, chokepoints, sightlines, hazards, and open ground determine which tactics are viable and how a fight feels. design encounter spaces to elicit the intended combat — don't drop enemies into neutral rooms and hope. the same enemies produce entirely different fights depending on the arena: a sniper is lethal across a long sightline and useless in a cramped corridor; melee rushers are terrifying in open ground and trivial behind a chokepoint; cover invites peek-and-shoot, elevation rewards positioning, hazards add a third party to the fight [s-leveldesign-guidance]. so the space is a primary lever of encounter design — it creates or removes the interesting decisions a fight offers (design-0002). a well-shaped arena makes players use the mechanics you want them to use and express the playstyles you're designing for; a shapeless one flattens every encounter into the same exchange regardless of the enemy roster. any game with spatial combat — action, shooters, rpgs, tactics. the more the combat depends on positioning, the more the space matters. combat systems that are largely space-independent (many turn-based menu battles, some abstract or arena-agnostic fighters) derive challenge from mechanics rather than geometry. and space can be over-designed — an arena so bristling with cover and hazards that it reads as a puzzle can undercut a game that wants raw, readable brawls. match the spatial complexity to the combat's intent. use sightlines to set engagement range, cover and elevation to create positional decisions, chokepoints to control flow, and hazards to add tension. vary encounter spaces so fights don't feel identical (feeds pacing, level-0003). playtest whether the space actually produces the intended fight. space-driven encounter design (the arena is a core combat variable) vs. system-driven combat (the mechanics carry the fight, space is secondary) reflects genre: positional/tactical games lean spatial, abstract/menu combat leans systemic. both are valid within their traditions. feeds pacing (level-0003). confidence 4."}
{"id":"GDC-L1-NARR-0001","title":"Seek ludonarrative harmony — align what the game says with what it makes you do","layer":"L1","domain":"NARR","subdomain":"ludonarrative","type":"contextual","confidence":4,"status":"canonical","tags":["narrative","ludonarrative","harmony","mechanics","theme"],"related":["GDC-L1-DESIGN-0001","GDC-L1-SYS-0002","GDC-L1-NARR-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-hocking-ludonarrative"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-NARR-0001.md","statement":"A game tells its story two ways at once — through non-interactive narrative (cutscenes, dialogue, text) and through its mechanics (what the player actually does) — and when the two contradict (ludonarrative dissonance), the contradiction undercuts both. Aim for harmony: what the player does should reinforce what the story says.","sections":{"Statement":"> A game tells its story two ways at once — through non-interactive narrative (cutscenes,\n> dialogue, text) and through its **mechanics** (what the player actually does) — and when the\n> two contradict (**ludonarrative dissonance**), the contradiction undercuts both. Aim for\n> harmony: what the player *does* should reinforce what the story *says*.","Rationale":"Players believe actions over words: a game whose story preaches mercy while its mechanics\nreward slaughter teaches the mechanical lesson, and the narrative rings hollow\n[S-hocking-ludonarrative]. Mechanics are a rhetorical channel — the systems *argue* for a way\nof being in the world — so theme lands hardest when the systems embody it (a game about\nisolation that mechanically isolates you, a game about greed that mechanically tempts and\npunishes greed). This is DESIGN-0001 (the experience produced is what matters) applied to\nnarrative: the experience is produced by mechanics as much as by script, and it is authored\nsecond-order through the systems (SYS-0002). Harmony makes the whole game say one coherent\nthing; dissonance makes it argue with itself.","Applies when":"Any game with both authored narrative and meaningful mechanics — most story-driven action,\nRPG, and adventure games. Sharpest wherever the story asserts a theme the mechanics could\ncontradict.","Does not apply / Exceptions":"Dissonance can be a *deliberate device*, not only a flaw: intentional ludonarrative tension\ncan make a point by juxtaposing what the player is told against what they are made to do,\nfor example to critique control or complicity. Abstract or mechanics-only games have little narrative to harmonize\nwith. And perfect harmony isn't always the goal — a small dissonance in service of fun (you\nkill hundreds in a story about one death) is often accepted as convention. The rule is to make\ndissonance a *choice*, not an accident.","Implementation (kept separate from the principle)":"Ask of your core mechanics: what do these systems *teach* and *reward*, and does it match the\nstory's theme? Where they conflict unintentionally, change the mechanic or the story so they\nagree. Where you *want* tension, make it deliberate and legible so players read it as\ncommentary, not sloppiness. Design theme into systems (SYS-0002), not just into script.","Disagreement":"Harmony-by-default (mechanics and story should agree; dissonance is a flaw to fix) vs.\ndissonance-as-device (intentional tension is a legitimate expressive tool). Both are held by\nserious designers; the reconciliation is that *unintentional* dissonance is a defect while\n*intentional*, legible dissonance can be art.","Notes":"The mechanics-meet-story principle of NARR; an application of DESIGN-0001 and SYS-0002 to\ntheme. Confidence 4. Its harmony-vs-deliberate-dissonance split is catalogued in\n`index/DISAGREEMENTS.md`."},"rawMarkdown":"---\nid: GDC-L1-NARR-0001\ntitle: Seek ludonarrative harmony — align what the game says with what it makes you do\nlayer: L1\ndomain: NARR\nsubdomain: ludonarrative\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - narrative\n  - ludonarrative\n  - harmony\n  - mechanics\n  - theme\nrelated:\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-SYS-0002\n  - GDC-L1-NARR-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-hocking-ludonarrative\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A game tells its story two ways at once — through non-interactive narrative (cutscenes,\n> dialogue, text) and through its **mechanics** (what the player actually does) — and when the\n> two contradict (**ludonarrative dissonance**), the contradiction undercuts both. Aim for\n> harmony: what the player *does* should reinforce what the story *says*.\n\n## Rationale\nPlayers believe actions over words: a game whose story preaches mercy while its mechanics\nreward slaughter teaches the mechanical lesson, and the narrative rings hollow\n[S-hocking-ludonarrative]. Mechanics are a rhetorical channel — the systems *argue* for a way\nof being in the world — so theme lands hardest when the systems embody it (a game about\nisolation that mechanically isolates you, a game about greed that mechanically tempts and\npunishes greed). This is DESIGN-0001 (the experience produced is what matters) applied to\nnarrative: the experience is produced by mechanics as much as by script, and it is authored\nsecond-order through the systems (SYS-0002). Harmony makes the whole game say one coherent\nthing; dissonance makes it argue with itself.\n\n## Applies when\nAny game with both authored narrative and meaningful mechanics — most story-driven action,\nRPG, and adventure games. Sharpest wherever the story asserts a theme the mechanics could\ncontradict.\n\n## Does not apply / Exceptions\nDissonance can be a *deliberate device*, not only a flaw: intentional ludonarrative tension\ncan make a point by juxtaposing what the player is told against what they are made to do,\nfor example to critique control or complicity. Abstract or mechanics-only games have little narrative to harmonize\nwith. And perfect harmony isn't always the goal — a small dissonance in service of fun (you\nkill hundreds in a story about one death) is often accepted as convention. The rule is to make\ndissonance a *choice*, not an accident.\n\n## Implementation (kept separate from the principle)\nAsk of your core mechanics: what do these systems *teach* and *reward*, and does it match the\nstory's theme? Where they conflict unintentionally, change the mechanic or the story so they\nagree. Where you *want* tension, make it deliberate and legible so players read it as\ncommentary, not sloppiness. Design theme into systems (SYS-0002), not just into script.\n\n## Disagreement\nHarmony-by-default (mechanics and story should agree; dissonance is a flaw to fix) vs.\ndissonance-as-device (intentional tension is a legitimate expressive tool). Both are held by\nserious designers; the reconciliation is that *unintentional* dissonance is a defect while\n*intentional*, legible dissonance can be art.\n\n## Notes\nThe mechanics-meet-story principle of NARR; an application of DESIGN-0001 and SYS-0002 to\ntheme. Confidence 4. Its harmony-vs-deliberate-dissonance split is catalogued in\n`index/DISAGREEMENTS.md`.\n","searchText":"gdc-l1-narr-0001 seek ludonarrative harmony — align what the game says with what it makes you do narrative ludonarrative harmony mechanics theme > a game tells its story two ways at once — through non-interactive narrative (cutscenes, dialogue, text) and through its mechanics (what the player actually does) — and when the two contradict (ludonarrative dissonance), the contradiction undercuts both. aim for harmony: what the player does should reinforce what the story says. players believe actions over words: a game whose story preaches mercy while its mechanics reward slaughter teaches the mechanical lesson, and the narrative rings hollow [s-hocking-ludonarrative]. mechanics are a rhetorical channel — the systems argue for a way of being in the world — so theme lands hardest when the systems embody it (a game about isolation that mechanically isolates you, a game about greed that mechanically tempts and punishes greed). this is design-0001 (the experience produced is what matters) applied to narrative: the experience is produced by mechanics as much as by script, and it is authored second-order through the systems (sys-0002). harmony makes the whole game say one coherent thing; dissonance makes it argue with itself. any game with both authored narrative and meaningful mechanics — most story-driven action, rpg, and adventure games. sharpest wherever the story asserts a theme the mechanics could contradict. dissonance can be a deliberate device, not only a flaw: intentional ludonarrative tension can make a point by juxtaposing what the player is told against what they are made to do, for example to critique control or complicity. abstract or mechanics-only games have little narrative to harmonize with. and perfect harmony isn't always the goal — a small dissonance in service of fun (you kill hundreds in a story about one death) is often accepted as convention. the rule is to make dissonance a choice, not an accident. ask of your core mechanics: what do these systems teach and reward, and does it match the story's theme? where they conflict unintentionally, change the mechanic or the story so they agree. where you want tension, make it deliberate and legible so players read it as commentary, not sloppiness. design theme into systems (sys-0002), not just into script. harmony-by-default (mechanics and story should agree; dissonance is a flaw to fix) vs. dissonance-as-device (intentional tension is a legitimate expressive tool). both are held by serious designers; the reconciliation is that unintentional dissonance is a defect while intentional, legible dissonance can be art. the mechanics-meet-story principle of narr; an application of design-0001 and sys-0002 to theme. confidence 4. its harmony-vs-deliberate-dissonance split is catalogued in index/disagreements.md."}
{"id":"GDC-L1-NARR-0002","title":"The player is a co-author, not an audience","layer":"L1","domain":"NARR","subdomain":"player-authored-story","type":"contextual","confidence":4,"status":"canonical","tags":["narrative","agency","participation","player-authored","interactivity"],"related":["GDC-L1-DESIGN-0006","GDC-L1-NARR-0004","GDC-L1-NARR-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-interactive-narrative","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-NARR-0002.md","statement":"Games are participatory: the player experiences story by acting, not just watching. Design narrative for a participant with agency — account for what they do, react to it, and where it fits, let them help author the story rather than have it delivered to them passively.","sections":{"Statement":"> Games are participatory: the player experiences story by *acting*, not just watching. Design\n> narrative for a participant with agency — account for what they do, react to it, and where it\n> fits, let them help *author* the story rather than have it delivered to them passively.","Rationale":"The defining difference between games and linear media is that the audience acts, and acts\n*differently* each time [S-interactive-narrative]. Narrative that ignores this — that treats\nthe player as a viewer between cutscenes — wastes the medium's unique power and often creates\nthe passivity it fears (players skip the story they can't affect). Designing for a co-author\nmeans the world acknowledges the player's actions, choices carry consequences the player can\nfeel (DESIGN-0006, legible agency), and the most memorable \"stories\" are frequently the ones\nplayers generate themselves through play (an emergent escape, a desperate improvised win). The\nstrongest game narratives treat the player as the protagonist *doing* the story, not the\nspectator being told it.","Applies when":"Any game that wants narrative engagement — most story-driven and role-playing games, and any\ngame seeking the participatory, \"my story\" feeling.","Does not apply / Exceptions":"Some games deliberately keep the player a near-passive audience for authored, cinematic\nstorytelling (linear narrative adventures, \"walking simulators\" that curate a fixed emotional\njourney) — a valid trade of agency for authorial control and craft. And full player authorship\nhas real costs and risks (incoherence, the player \"missing\" the intended story) — see the\nbranching-cost principle (NARR-0004). Co-authorship is a spectrum, not an absolute.","Implementation (kept separate from the principle)":"Make the world react to what the player does, at whatever scale you can afford (from a guard\ncommenting on your last action to persistent world-state changes). Give consequential choices\nlegible consequences (DESIGN-0006). Create conditions for emergent player stories (systemic\ninteractions, SYS-0003). Where you deliver authored story, weave it into play rather than\nstopping play to show it (NARR-0003, NARR-0005).","Disagreement":"Participatory/agency-driven narrative (the player co-authors; \"my story\") vs. authored/curated\nnarrative (a crafted, controlled arc the player receives) — the immersive-sim and RPG tradition\nvs. the cinematic-adventure tradition. Both make great games; the split is the same\nagency-vs-authored axis as DESIGN-0006, seen from the narrative side.","Notes":"The participation principle of NARR; an application of DESIGN-0006 (agency) to storytelling,\nand the setup for the branching-cost craft (NARR-0004). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-NARR-0002\ntitle: The player is a co-author, not an audience\nlayer: L1\ndomain: NARR\nsubdomain: player-authored-story\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - narrative\n  - agency\n  - participation\n  - player-authored\n  - interactivity\nrelated:\n  - GDC-L1-DESIGN-0006\n  - GDC-L1-NARR-0004\n  - GDC-L1-NARR-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-interactive-narrative\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Games are participatory: the player experiences story by *acting*, not just watching. Design\n> narrative for a participant with agency — account for what they do, react to it, and where it\n> fits, let them help *author* the story rather than have it delivered to them passively.\n\n## Rationale\nThe defining difference between games and linear media is that the audience acts, and acts\n*differently* each time [S-interactive-narrative]. Narrative that ignores this — that treats\nthe player as a viewer between cutscenes — wastes the medium's unique power and often creates\nthe passivity it fears (players skip the story they can't affect). Designing for a co-author\nmeans the world acknowledges the player's actions, choices carry consequences the player can\nfeel (DESIGN-0006, legible agency), and the most memorable \"stories\" are frequently the ones\nplayers generate themselves through play (an emergent escape, a desperate improvised win). The\nstrongest game narratives treat the player as the protagonist *doing* the story, not the\nspectator being told it.\n\n## Applies when\nAny game that wants narrative engagement — most story-driven and role-playing games, and any\ngame seeking the participatory, \"my story\" feeling.\n\n## Does not apply / Exceptions\nSome games deliberately keep the player a near-passive audience for authored, cinematic\nstorytelling (linear narrative adventures, \"walking simulators\" that curate a fixed emotional\njourney) — a valid trade of agency for authorial control and craft. And full player authorship\nhas real costs and risks (incoherence, the player \"missing\" the intended story) — see the\nbranching-cost principle (NARR-0004). Co-authorship is a spectrum, not an absolute.\n\n## Implementation (kept separate from the principle)\nMake the world react to what the player does, at whatever scale you can afford (from a guard\ncommenting on your last action to persistent world-state changes). Give consequential choices\nlegible consequences (DESIGN-0006). Create conditions for emergent player stories (systemic\ninteractions, SYS-0003). Where you deliver authored story, weave it into play rather than\nstopping play to show it (NARR-0003, NARR-0005).\n\n## Disagreement\nParticipatory/agency-driven narrative (the player co-authors; \"my story\") vs. authored/curated\nnarrative (a crafted, controlled arc the player receives) — the immersive-sim and RPG tradition\nvs. the cinematic-adventure tradition. Both make great games; the split is the same\nagency-vs-authored axis as DESIGN-0006, seen from the narrative side.\n\n## Notes\nThe participation principle of NARR; an application of DESIGN-0006 (agency) to storytelling,\nand the setup for the branching-cost craft (NARR-0004). Confidence 4.\n","searchText":"gdc-l1-narr-0002 the player is a co-author, not an audience narrative agency participation player-authored interactivity > games are participatory: the player experiences story by acting, not just watching. design narrative for a participant with agency — account for what they do, react to it, and where it fits, let them help author the story rather than have it delivered to them passively. the defining difference between games and linear media is that the audience acts, and acts differently each time [s-interactive-narrative]. narrative that ignores this — that treats the player as a viewer between cutscenes — wastes the medium's unique power and often creates the passivity it fears (players skip the story they can't affect). designing for a co-author means the world acknowledges the player's actions, choices carry consequences the player can feel (design-0006, legible agency), and the most memorable \"stories\" are frequently the ones players generate themselves through play (an emergent escape, a desperate improvised win). the strongest game narratives treat the player as the protagonist doing the story, not the spectator being told it. any game that wants narrative engagement — most story-driven and role-playing games, and any game seeking the participatory, \"my story\" feeling. some games deliberately keep the player a near-passive audience for authored, cinematic storytelling (linear narrative adventures, \"walking simulators\" that curate a fixed emotional journey) — a valid trade of agency for authorial control and craft. and full player authorship has real costs and risks (incoherence, the player \"missing\" the intended story) — see the branching-cost principle (narr-0004). co-authorship is a spectrum, not an absolute. make the world react to what the player does, at whatever scale you can afford (from a guard commenting on your last action to persistent world-state changes). give consequential choices legible consequences (design-0006). create conditions for emergent player stories (systemic interactions, sys-0003). where you deliver authored story, weave it into play rather than stopping play to show it (narr-0003, narr-0005). participatory/agency-driven narrative (the player co-authors; \"my story\") vs. authored/curated narrative (a crafted, controlled arc the player receives) — the immersive-sim and rpg tradition vs. the cinematic-adventure tradition. both make great games; the split is the same agency-vs-authored axis as design-0006, seen from the narrative side. the participation principle of narr; an application of design-0006 (agency) to storytelling, and the setup for the branching-cost craft (narr-0004). confidence 4."}
{"id":"GDC-L1-NARR-0003","title":"Prefer embedded, experienced narrative over delivered exposition","layer":"L1","domain":"NARR","subdomain":"environmental-narrative","type":"contextual","confidence":4,"status":"canonical","tags":["narrative","embedded","environmental-storytelling","show-dont-tell","systemic"],"related":["GDC-L1-LEVEL-0007","GDC-L1-NARR-0002","GDC-L1-DESIGN-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-worch-smith-envstory","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-NARR-0003.md","statement":"The strongest game narrative is experienced — pulled from the world, the systems, and the player's own actions — rather than told in cutscenes and text dumps. Show through environment, systems, and consequence; reserve delivered exposition for what genuinely must be stated outright.","sections":{"Statement":"> The strongest game narrative is *experienced* — pulled from the world, the systems, and the\n> player's own actions — rather than *told* in cutscenes and text dumps. Show through\n> environment, systems, and consequence; reserve delivered exposition for what genuinely must\n> be stated outright.","Rationale":"Because players explore and act rather than sit and receive, story that is *embedded* in what\nthey do and see lands harder and interrupts less than story that is *delivered* by stopping\nthe game to tell them [S-worch-smith-envstory]. Environmental storytelling (a ransacked room, a\nfailed barricade — LEVEL-0007), systemic storytelling (a reputation system that makes towns\nreact to your deeds), and consequence (the world visibly changed by your choices) all let the\nplayer *infer* and *live* the narrative, which builds more investment than exposition (the\n\"pull, not push\" principle). This is DESIGN-0001 again — the experience is what matters, and an\nexperienced story is more real to the player than a described one. Delivered exposition still\nhas its place (some things must simply be told), but it should be the exception, woven into\nplay rather than walling it off.","Applies when":"Any game conveying story, world, or mood — especially exploration-, immersion-, and\natmosphere-driven games. The more the game trusts the player to look and infer, the more\nembedded narrative pays.","Does not apply / Exceptions":"Some narrative must be *delivered* — critical plot the player cannot be allowed to miss, complex\ninformation no environmental cue can carry, or the deliberate power of a well-directed cutscene.\nStrongly-authored cinematic games lean harder on delivered narrative by design. And embedded\nnarrative is craft-intensive and *missable* (NARR-0006) — a rushed version reads as random\nclutter, and over-reliance on it can leave players confused about the plot. Balance embedded\ndepth with enough delivered clarity that the through-line lands.","Implementation (kept separate from the principle)":"Ask what each story beat could be *shown* through space (LEVEL-0007), systems, or consequence\ninstead of told. Weave necessary exposition into play (environmental readables, ambient\ndialogue, in-world objects) rather than dedicated lecture scenes. Reserve cutscenes/text for\nwhat truly needs directing or stating. Layer it so a casual player gets the gist and a curious\none gets the depth (NARR-0006).","Disagreement":"Embedded/experienced narrative (immersive, inferred, low-interruption, missable) vs.\ndelivered/authored narrative (controlled, guaranteed, directed) — most games mix, reserving\ndelivery for must-not-miss plot and embedding for depth, mood, and reward. The debate is the\n*ratio* and how much to trust players to find and assemble.","Notes":"The general narrative principle for which LEVEL-0007 (environmental storytelling) is the\nlevel-design-specific instance — this is its parent. An application of DESIGN-0001 to story.\nConfidence 4."},"rawMarkdown":"---\nid: GDC-L1-NARR-0003\ntitle: Prefer embedded, experienced narrative over delivered exposition\nlayer: L1\ndomain: NARR\nsubdomain: environmental-narrative\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - narrative\n  - embedded\n  - environmental-storytelling\n  - show-dont-tell\n  - systemic\nrelated:\n  - GDC-L1-LEVEL-0007\n  - GDC-L1-NARR-0002\n  - GDC-L1-DESIGN-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-worch-smith-envstory\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> The strongest game narrative is *experienced* — pulled from the world, the systems, and the\n> player's own actions — rather than *told* in cutscenes and text dumps. Show through\n> environment, systems, and consequence; reserve delivered exposition for what genuinely must\n> be stated outright.\n\n## Rationale\nBecause players explore and act rather than sit and receive, story that is *embedded* in what\nthey do and see lands harder and interrupts less than story that is *delivered* by stopping\nthe game to tell them [S-worch-smith-envstory]. Environmental storytelling (a ransacked room, a\nfailed barricade — LEVEL-0007), systemic storytelling (a reputation system that makes towns\nreact to your deeds), and consequence (the world visibly changed by your choices) all let the\nplayer *infer* and *live* the narrative, which builds more investment than exposition (the\n\"pull, not push\" principle). This is DESIGN-0001 again — the experience is what matters, and an\nexperienced story is more real to the player than a described one. Delivered exposition still\nhas its place (some things must simply be told), but it should be the exception, woven into\nplay rather than walling it off.\n\n## Applies when\nAny game conveying story, world, or mood — especially exploration-, immersion-, and\natmosphere-driven games. The more the game trusts the player to look and infer, the more\nembedded narrative pays.\n\n## Does not apply / Exceptions\nSome narrative must be *delivered* — critical plot the player cannot be allowed to miss, complex\ninformation no environmental cue can carry, or the deliberate power of a well-directed cutscene.\nStrongly-authored cinematic games lean harder on delivered narrative by design. And embedded\nnarrative is craft-intensive and *missable* (NARR-0006) — a rushed version reads as random\nclutter, and over-reliance on it can leave players confused about the plot. Balance embedded\ndepth with enough delivered clarity that the through-line lands.\n\n## Implementation (kept separate from the principle)\nAsk what each story beat could be *shown* through space (LEVEL-0007), systems, or consequence\ninstead of told. Weave necessary exposition into play (environmental readables, ambient\ndialogue, in-world objects) rather than dedicated lecture scenes. Reserve cutscenes/text for\nwhat truly needs directing or stating. Layer it so a casual player gets the gist and a curious\none gets the depth (NARR-0006).\n\n## Disagreement\nEmbedded/experienced narrative (immersive, inferred, low-interruption, missable) vs.\ndelivered/authored narrative (controlled, guaranteed, directed) — most games mix, reserving\ndelivery for must-not-miss plot and embedding for depth, mood, and reward. The debate is the\n*ratio* and how much to trust players to find and assemble.\n\n## Notes\nThe general narrative principle for which LEVEL-0007 (environmental storytelling) is the\nlevel-design-specific instance — this is its parent. An application of DESIGN-0001 to story.\nConfidence 4.\n","searchText":"gdc-l1-narr-0003 prefer embedded, experienced narrative over delivered exposition narrative embedded environmental-storytelling show-dont-tell systemic > the strongest game narrative is experienced — pulled from the world, the systems, and the player's own actions — rather than told in cutscenes and text dumps. show through environment, systems, and consequence; reserve delivered exposition for what genuinely must be stated outright. because players explore and act rather than sit and receive, story that is embedded in what they do and see lands harder and interrupts less than story that is delivered by stopping the game to tell them [s-worch-smith-envstory]. environmental storytelling (a ransacked room, a failed barricade — level-0007), systemic storytelling (a reputation system that makes towns react to your deeds), and consequence (the world visibly changed by your choices) all let the player infer and live the narrative, which builds more investment than exposition (the \"pull, not push\" principle). this is design-0001 again — the experience is what matters, and an experienced story is more real to the player than a described one. delivered exposition still has its place (some things must simply be told), but it should be the exception, woven into play rather than walling it off. any game conveying story, world, or mood — especially exploration-, immersion-, and atmosphere-driven games. the more the game trusts the player to look and infer, the more embedded narrative pays. some narrative must be delivered — critical plot the player cannot be allowed to miss, complex information no environmental cue can carry, or the deliberate power of a well-directed cutscene. strongly-authored cinematic games lean harder on delivered narrative by design. and embedded narrative is craft-intensive and missable (narr-0006) — a rushed version reads as random clutter, and over-reliance on it can leave players confused about the plot. balance embedded depth with enough delivered clarity that the through-line lands. ask what each story beat could be shown through space (level-0007), systems, or consequence instead of told. weave necessary exposition into play (environmental readables, ambient dialogue, in-world objects) rather than dedicated lecture scenes. reserve cutscenes/text for what truly needs directing or stating. layer it so a casual player gets the gist and a curious one gets the depth (narr-0006). embedded/experienced narrative (immersive, inferred, low-interruption, missable) vs. delivered/authored narrative (controlled, guaranteed, directed) — most games mix, reserving delivery for must-not-miss plot and embedding for depth, mood, and reward. the debate is the ratio and how much to trust players to find and assemble. the general narrative principle for which level-0007 (environmental storytelling) is the level-design-specific instance — this is its parent. an application of design-0001 to story. confidence 4."}
{"id":"GDC-L1-NARR-0004","title":"Branching is expensive — buy the feeling of agency efficiently","layer":"L1","domain":"NARR","subdomain":"branching-vs-linear","type":"contextual","confidence":4,"status":"canonical","tags":["narrative","branching","illusion-of-choice","agency","cost"],"related":["GDC-L1-DESIGN-0006","GDC-L1-NARR-0002","GDC-L1-PROTO-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-interactive-narrative"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-NARR-0004.md","statement":"Fully branching narrative is combinatorially expensive and mostly unseen by any single player. Get the feeling of agency affordably: reactive storytelling (the world acknowledges choices without wholly branching), convergence and hub-and-spoke structures, and judicious illusion of choice — while keeping the choices that truly matter genuinely consequential.","sections":{"Statement":"> Fully branching narrative is combinatorially expensive and mostly unseen by any single\n> player. Get the *feeling* of agency affordably: reactive storytelling (the world\n> acknowledges choices without wholly branching), convergence and hub-and-spoke structures,\n> and judicious illusion of choice — while keeping the choices that truly matter genuinely\n> consequential.","Rationale":"Every branch that never rejoins multiplies the content you must build, and a player on one\npath never sees the others — so naive branching spends enormous effort on story most players\nnever experience [S-interactive-narrative]. The craft is decoupling the *feeling* of agency\nfrom the *cost* of true divergence. Reactive narrative (NPCs comment on your deeds, the world\nreflects your choices) delivers acknowledgment cheaply. **Convergence** — branches that\ndiverge then rejoin — lets choices feel impactful in the moment while keeping the content\nbounded. The **illusion of choice** (options that lead to the same outcome) is a real,\nrespectable tool when it protects the *feeling* of consequence — though it fails badly if\nplayers notice the seams and feel cheated (DESIGN-0006's warning). The goal is maximum\nperceived agency per unit of production, with the genuinely pivotal choices actually branching.","Applies when":"Any choice-driven or narrative game weighing how much real branching to build. Central to RPGs,\nnarrative adventures, and any \"your choices matter\" design.","Does not apply / Exceptions":"Some games *do* commit to deep, real branching as their identity (heavily replayable\nchoice-games, some visual novels) and accept the cost as the point. Purely linear games sidestep\nthe question entirely (NARR-0002's authored-narrative pole). And illusion of choice, over-used\nor clumsily hidden, becomes the *unsatisfying* illusion DESIGN-0006 warns against — the tool\nworks only while the seams stay invisible.","Implementation (kept separate from the principle)":"Reserve true branching for the few pivotal choices; make everything else *reactive*\n(acknowledged, not branched) or *convergent* (diverge then rejoin). Use hub-and-spoke structures\nto let players tackle content in their order without exploding the tree. Deploy illusion of\nchoice where it protects felt consequence, and hide the seams. Be willing to cut branches that\ndon't earn their cost (PROTO-0005, kill your darlings).","Disagreement":"Deep real branching (maximal agency and replayability, at high and often-unseen cost) vs.\nreactive/convergent/illusory structures (efficient perceived agency, bounded content). The\nchoice-game tradition leans real-branching; most narrative games lean efficient-agency. Both\nare valid; the risk to manage is the *noticed* illusion that feels like a cheat.","Notes":"The production-craft complement to NARR-0002 (co-authorship) and DESIGN-0006 (legible agency);\nits illusion-of-choice tool sits on DESIGN-0006's exact caution. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-NARR-0004\ntitle: Branching is expensive — buy the feeling of agency efficiently\nlayer: L1\ndomain: NARR\nsubdomain: branching-vs-linear\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - narrative\n  - branching\n  - illusion-of-choice\n  - agency\n  - cost\nrelated:\n  - GDC-L1-DESIGN-0006\n  - GDC-L1-NARR-0002\n  - GDC-L1-PROTO-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-interactive-narrative\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Fully branching narrative is combinatorially expensive and mostly unseen by any single\n> player. Get the *feeling* of agency affordably: reactive storytelling (the world\n> acknowledges choices without wholly branching), convergence and hub-and-spoke structures,\n> and judicious illusion of choice — while keeping the choices that truly matter genuinely\n> consequential.\n\n## Rationale\nEvery branch that never rejoins multiplies the content you must build, and a player on one\npath never sees the others — so naive branching spends enormous effort on story most players\nnever experience [S-interactive-narrative]. The craft is decoupling the *feeling* of agency\nfrom the *cost* of true divergence. Reactive narrative (NPCs comment on your deeds, the world\nreflects your choices) delivers acknowledgment cheaply. **Convergence** — branches that\ndiverge then rejoin — lets choices feel impactful in the moment while keeping the content\nbounded. The **illusion of choice** (options that lead to the same outcome) is a real,\nrespectable tool when it protects the *feeling* of consequence — though it fails badly if\nplayers notice the seams and feel cheated (DESIGN-0006's warning). The goal is maximum\nperceived agency per unit of production, with the genuinely pivotal choices actually branching.\n\n## Applies when\nAny choice-driven or narrative game weighing how much real branching to build. Central to RPGs,\nnarrative adventures, and any \"your choices matter\" design.\n\n## Does not apply / Exceptions\nSome games *do* commit to deep, real branching as their identity (heavily replayable\nchoice-games, some visual novels) and accept the cost as the point. Purely linear games sidestep\nthe question entirely (NARR-0002's authored-narrative pole). And illusion of choice, over-used\nor clumsily hidden, becomes the *unsatisfying* illusion DESIGN-0006 warns against — the tool\nworks only while the seams stay invisible.\n\n## Implementation (kept separate from the principle)\nReserve true branching for the few pivotal choices; make everything else *reactive*\n(acknowledged, not branched) or *convergent* (diverge then rejoin). Use hub-and-spoke structures\nto let players tackle content in their order without exploding the tree. Deploy illusion of\nchoice where it protects felt consequence, and hide the seams. Be willing to cut branches that\ndon't earn their cost (PROTO-0005, kill your darlings).\n\n## Disagreement\nDeep real branching (maximal agency and replayability, at high and often-unseen cost) vs.\nreactive/convergent/illusory structures (efficient perceived agency, bounded content). The\nchoice-game tradition leans real-branching; most narrative games lean efficient-agency. Both\nare valid; the risk to manage is the *noticed* illusion that feels like a cheat.\n\n## Notes\nThe production-craft complement to NARR-0002 (co-authorship) and DESIGN-0006 (legible agency);\nits illusion-of-choice tool sits on DESIGN-0006's exact caution. Confidence 4.\n","searchText":"gdc-l1-narr-0004 branching is expensive — buy the feeling of agency efficiently narrative branching illusion-of-choice agency cost > fully branching narrative is combinatorially expensive and mostly unseen by any single player. get the feeling of agency affordably: reactive storytelling (the world acknowledges choices without wholly branching), convergence and hub-and-spoke structures, and judicious illusion of choice — while keeping the choices that truly matter genuinely consequential. every branch that never rejoins multiplies the content you must build, and a player on one path never sees the others — so naive branching spends enormous effort on story most players never experience [s-interactive-narrative]. the craft is decoupling the feeling of agency from the cost of true divergence. reactive narrative (npcs comment on your deeds, the world reflects your choices) delivers acknowledgment cheaply. convergence — branches that diverge then rejoin — lets choices feel impactful in the moment while keeping the content bounded. the illusion of choice (options that lead to the same outcome) is a real, respectable tool when it protects the feeling of consequence — though it fails badly if players notice the seams and feel cheated (design-0006's warning). the goal is maximum perceived agency per unit of production, with the genuinely pivotal choices actually branching. any choice-driven or narrative game weighing how much real branching to build. central to rpgs, narrative adventures, and any \"your choices matter\" design. some games do commit to deep, real branching as their identity (heavily replayable choice-games, some visual novels) and accept the cost as the point. purely linear games sidestep the question entirely (narr-0002's authored-narrative pole). and illusion of choice, over-used or clumsily hidden, becomes the unsatisfying illusion design-0006 warns against — the tool works only while the seams stay invisible. reserve true branching for the few pivotal choices; make everything else reactive (acknowledged, not branched) or convergent (diverge then rejoin). use hub-and-spoke structures to let players tackle content in their order without exploding the tree. deploy illusion of choice where it protects felt consequence, and hide the seams. be willing to cut branches that don't earn their cost (proto-0005, kill your darlings). deep real branching (maximal agency and replayability, at high and often-unseen cost) vs. reactive/convergent/illusory structures (efficient perceived agency, bounded content). the choice-game tradition leans real-branching; most narrative games lean efficient-agency. both are valid; the risk to manage is the noticed illusion that feels like a cheat. the production-craft complement to narr-0002 (co-authorship) and design-0006 (legible agency); its illusion-of-choice tool sits on design-0006's exact caution. confidence 4."}
{"id":"GDC-L1-NARR-0005","title":"Pace story around player-controlled time","layer":"L1","domain":"NARR","subdomain":"pacing","type":"contextual","confidence":3,"status":"canonical","tags":["narrative","pacing","interactivity","interruptible"],"related":["GDC-L1-LEVEL-0003","GDC-L1-AUDIO-0003","GDC-L1-NARR-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-NARR-0005.md","statement":"In games the player controls the clock — they linger, rush, backtrack, wander off, and interrupt — so narrative pacing cannot assume a fixed timeline the way film can. Deliver story in player-controllable, interruptible chunks that survive being paced by the player, and let gameplay and story share a rhythm rather than fight for the player's time.","sections":{"Statement":"> In games the player controls the clock — they linger, rush, backtrack, wander off, and\n> interrupt — so narrative pacing cannot assume a fixed timeline the way film can. Deliver\n> story in player-controllable, interruptible chunks that survive being paced by the player,\n> and let gameplay and story share a rhythm rather than fight for the player's time.","Rationale":"A film runs on the director's clock; a game runs on the player's, and that breaks any narrative\npacing that assumes the audience is moving through at a set rate [S-schell-artofgamedesign]. A\nstory beat the player triggers three hours late (having explored elsewhere), or misses, or\nrushes past, lands wrong if it was written for a fixed cadence. Worse, story that *stops* the\ngame to deliver itself fights the player's momentum and gets skipped. So narrative pacing in\ngames is a negotiation with player agency: parcel the story into interruptible units, make beats\nrobust to being reached out of tempo, and align the story's rhythm with the gameplay's\n(the pacing curve of LEVEL-0003, and adaptive audio's response to state, AUDIO-0003) so the two\nreinforce rather than interrupt each other.","Applies when":"Any game delivering authored story alongside player-controlled exploration or action —\nespecially open and semi-open games where the player sets the tempo.","Does not apply / Exceptions":"Tightly linear or on-rails sequences *do* control the clock (a scripted set-piece, a\ncutscene) and can pace like film for that stretch — a valid tool used in bursts. Rhythm and\nstrongly-timed games control tempo by design. The principle bites hardest where the player has\nreal freedom over pace and place.","Implementation (kept separate from the principle)":"Break narrative into interruptible, self-contained beats rather than long unskippable sequences.\nMake story robust to being reached early, late, or out of order (gate the truly\norder-dependent beats). Align story rhythm with gameplay pacing (LEVEL-0003) and let systems\nlike adaptive music (AUDIO-0003) carry emotional pacing that survives player timing. Prefer\nweaving story into play over stopping play to tell it (NARR-0003).","Disagreement":"Player-paced narrative (interruptible, robust, non-blocking — respects agency) vs.\nauthor-paced sequences (controlled cadence, cinematic power — at the cost of interrupting the\nplayer). Open games lean player-paced; cinematic games use author-paced bursts. The tension is\ncontrol-of-tempo vs. respect-for-agency.","Notes":"The narrative side of pacing — partner to LEVEL-0003 (spatial/intensity pacing) and AUDIO-0003\n(adaptive music), all three about rhythm under player-controlled time. Confidence 3: sound and\nwidely-held, but narrative pacing craft is highly form-dependent."},"rawMarkdown":"---\nid: GDC-L1-NARR-0005\ntitle: Pace story around player-controlled time\nlayer: L1\ndomain: NARR\nsubdomain: pacing\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - narrative\n  - pacing\n  - interactivity\n  - interruptible\nrelated:\n  - GDC-L1-LEVEL-0003\n  - GDC-L1-AUDIO-0003\n  - GDC-L1-NARR-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> In games the player controls the clock — they linger, rush, backtrack, wander off, and\n> interrupt — so narrative pacing cannot assume a fixed timeline the way film can. Deliver\n> story in player-controllable, interruptible chunks that survive being paced by the player,\n> and let gameplay and story share a rhythm rather than fight for the player's time.\n\n## Rationale\nA film runs on the director's clock; a game runs on the player's, and that breaks any narrative\npacing that assumes the audience is moving through at a set rate [S-schell-artofgamedesign]. A\nstory beat the player triggers three hours late (having explored elsewhere), or misses, or\nrushes past, lands wrong if it was written for a fixed cadence. Worse, story that *stops* the\ngame to deliver itself fights the player's momentum and gets skipped. So narrative pacing in\ngames is a negotiation with player agency: parcel the story into interruptible units, make beats\nrobust to being reached out of tempo, and align the story's rhythm with the gameplay's\n(the pacing curve of LEVEL-0003, and adaptive audio's response to state, AUDIO-0003) so the two\nreinforce rather than interrupt each other.\n\n## Applies when\nAny game delivering authored story alongside player-controlled exploration or action —\nespecially open and semi-open games where the player sets the tempo.\n\n## Does not apply / Exceptions\nTightly linear or on-rails sequences *do* control the clock (a scripted set-piece, a\ncutscene) and can pace like film for that stretch — a valid tool used in bursts. Rhythm and\nstrongly-timed games control tempo by design. The principle bites hardest where the player has\nreal freedom over pace and place.\n\n## Implementation (kept separate from the principle)\nBreak narrative into interruptible, self-contained beats rather than long unskippable sequences.\nMake story robust to being reached early, late, or out of order (gate the truly\norder-dependent beats). Align story rhythm with gameplay pacing (LEVEL-0003) and let systems\nlike adaptive music (AUDIO-0003) carry emotional pacing that survives player timing. Prefer\nweaving story into play over stopping play to tell it (NARR-0003).\n\n## Disagreement\nPlayer-paced narrative (interruptible, robust, non-blocking — respects agency) vs.\nauthor-paced sequences (controlled cadence, cinematic power — at the cost of interrupting the\nplayer). Open games lean player-paced; cinematic games use author-paced bursts. The tension is\ncontrol-of-tempo vs. respect-for-agency.\n\n## Notes\nThe narrative side of pacing — partner to LEVEL-0003 (spatial/intensity pacing) and AUDIO-0003\n(adaptive music), all three about rhythm under player-controlled time. Confidence 3: sound and\nwidely-held, but narrative pacing craft is highly form-dependent.\n","searchText":"gdc-l1-narr-0005 pace story around player-controlled time narrative pacing interactivity interruptible > in games the player controls the clock — they linger, rush, backtrack, wander off, and interrupt — so narrative pacing cannot assume a fixed timeline the way film can. deliver story in player-controllable, interruptible chunks that survive being paced by the player, and let gameplay and story share a rhythm rather than fight for the player's time. a film runs on the director's clock; a game runs on the player's, and that breaks any narrative pacing that assumes the audience is moving through at a set rate [s-schell-artofgamedesign]. a story beat the player triggers three hours late (having explored elsewhere), or misses, or rushes past, lands wrong if it was written for a fixed cadence. worse, story that stops the game to deliver itself fights the player's momentum and gets skipped. so narrative pacing in games is a negotiation with player agency: parcel the story into interruptible units, make beats robust to being reached out of tempo, and align the story's rhythm with the gameplay's (the pacing curve of level-0003, and adaptive audio's response to state, audio-0003) so the two reinforce rather than interrupt each other. any game delivering authored story alongside player-controlled exploration or action — especially open and semi-open games where the player sets the tempo. tightly linear or on-rails sequences do control the clock (a scripted set-piece, a cutscene) and can pace like film for that stretch — a valid tool used in bursts. rhythm and strongly-timed games control tempo by design. the principle bites hardest where the player has real freedom over pace and place. break narrative into interruptible, self-contained beats rather than long unskippable sequences. make story robust to being reached early, late, or out of order (gate the truly order-dependent beats). align story rhythm with gameplay pacing (level-0003) and let systems like adaptive music (audio-0003) carry emotional pacing that survives player timing. prefer weaving story into play over stopping play to tell it (narr-0003). player-paced narrative (interruptible, robust, non-blocking — respects agency) vs. author-paced sequences (controlled cadence, cinematic power — at the cost of interrupting the player). open games lean player-paced; cinematic games use author-paced bursts. the tension is control-of-tempo vs. respect-for-agency. the narrative side of pacing — partner to level-0003 (spatial/intensity pacing) and audio-0003 (adaptive music), all three about rhythm under player-controlled time. confidence 3: sound and widely-held, but narrative pacing craft is highly form-dependent."}
{"id":"GDC-L1-NARR-0006","title":"Build worlds by implication — and let players miss things","layer":"L1","domain":"NARR","subdomain":"worldbuilding","type":"contextual","confidence":4,"status":"canonical","tags":["narrative","worldbuilding","iceberg","implication","missability","discovery"],"related":["GDC-L1-LEVEL-0007","GDC-L1-NARR-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-worch-smith-envstory","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-NARR-0006.md","statement":"Believable worlds and characters come from coherent, implied depth — the iceberg — not exhaustive exposition: present a consistent surface and let the player infer the mass beneath. And make much of that depth optional: missable lore and detail reward curiosity precisely because they can be missed.","sections":{"Statement":"> Believable worlds and characters come from coherent, *implied* depth — the iceberg — not\n> exhaustive exposition: present a consistent surface and let the player infer the mass\n> beneath. And make much of that depth **optional**: missable lore and detail reward curiosity\n> precisely *because* they can be missed.","Rationale":"A world feels real not when everything is explained but when everything *hangs together* — a\ncoherent surface implies a consistent, deeper reality the player fills in, and that inference\nis more powerful (and cheaper) than spelling it all out [S-schell-artofgamedesign]. Over-\nexplaining, by contrast, deflates mystery and buries the player in lore. The second half is\njust as important: depth that every player is forced through isn't discovery, it's a lecture —\nwhereas depth the player can *miss* becomes a reward for looking, which is what makes finding\nit meaningful (\"it has to be possible to miss some things to make finding them meaningful\")\n[S-worch-smith-envstory]. Optional, missable worldbuilding turns curiosity into its own reward\nloop and lets each player build the version of the world they dug for.","Applies when":"Worldbuilding and lore in any game with a setting — RPGs, adventures, exploration and\natmosphere games. Especially powerful where discovery is a core pleasure.","Does not apply / Exceptions":"Critical setup the player must understand to follow the game should *not* be buried in missable\noptional lore — essential information needs reliable delivery (NARR-0003's balance). Some genres\nwant their world fully and explicitly rendered (certain narrative-heavy or educational games).\nAnd \"imply depth\" still requires the depth to actually be *consistent* — implication over an\nincoherent world reads as vagueness, not mystery.","Implementation (kept separate from the principle)":"Design a coherent underlying world and show only its telling surface; let players infer the\nrest. Layer lore so a casual player gets the gist and a curious one is rewarded with depth\n(pairs with NARR-0003, LEVEL-0007). Make the rich readings *optional and missable* — the reward\nfor attention. Keep the surface internally consistent so inference has something true to land on.","Disagreement":"Iceberg/implied worldbuilding (evocative, mysterious, rewards inference, missable) vs. fully-\nexplicit worldbuilding (comprehensive, guaranteed understanding, no gaps). Most games favor\nimplication for flavor and depth while explicitly delivering the essential through-line; the\ndebate is how much to withhold and trust the player to infer.","Notes":"Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-NARR-0006\ntitle: Build worlds by implication — and let players miss things\nlayer: L1\ndomain: NARR\nsubdomain: worldbuilding\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - narrative\n  - worldbuilding\n  - iceberg\n  - implication\n  - missability\n  - discovery\nrelated:\n  - GDC-L1-LEVEL-0007\n  - GDC-L1-NARR-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-worch-smith-envstory\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Believable worlds and characters come from coherent, *implied* depth — the iceberg — not\n> exhaustive exposition: present a consistent surface and let the player infer the mass\n> beneath. And make much of that depth **optional**: missable lore and detail reward curiosity\n> precisely *because* they can be missed.\n\n## Rationale\nA world feels real not when everything is explained but when everything *hangs together* — a\ncoherent surface implies a consistent, deeper reality the player fills in, and that inference\nis more powerful (and cheaper) than spelling it all out [S-schell-artofgamedesign]. Over-\nexplaining, by contrast, deflates mystery and buries the player in lore. The second half is\njust as important: depth that every player is forced through isn't discovery, it's a lecture —\nwhereas depth the player can *miss* becomes a reward for looking, which is what makes finding\nit meaningful (\"it has to be possible to miss some things to make finding them meaningful\")\n[S-worch-smith-envstory]. Optional, missable worldbuilding turns curiosity into its own reward\nloop and lets each player build the version of the world they dug for.\n\n## Applies when\nWorldbuilding and lore in any game with a setting — RPGs, adventures, exploration and\natmosphere games. Especially powerful where discovery is a core pleasure.\n\n## Does not apply / Exceptions\nCritical setup the player must understand to follow the game should *not* be buried in missable\noptional lore — essential information needs reliable delivery (NARR-0003's balance). Some genres\nwant their world fully and explicitly rendered (certain narrative-heavy or educational games).\nAnd \"imply depth\" still requires the depth to actually be *consistent* — implication over an\nincoherent world reads as vagueness, not mystery.\n\n## Implementation (kept separate from the principle)\nDesign a coherent underlying world and show only its telling surface; let players infer the\nrest. Layer lore so a casual player gets the gist and a curious one is rewarded with depth\n(pairs with NARR-0003, LEVEL-0007). Make the rich readings *optional and missable* — the reward\nfor attention. Keep the surface internally consistent so inference has something true to land on.\n\n## Disagreement\nIceberg/implied worldbuilding (evocative, mysterious, rewards inference, missable) vs. fully-\nexplicit worldbuilding (comprehensive, guaranteed understanding, no gaps). Most games favor\nimplication for flavor and depth while explicitly delivering the essential through-line; the\ndebate is how much to withhold and trust the player to infer.\n\n## Notes\nConfidence 4.\n","searchText":"gdc-l1-narr-0006 build worlds by implication — and let players miss things narrative worldbuilding iceberg implication missability discovery > believable worlds and characters come from coherent, implied depth — the iceberg — not exhaustive exposition: present a consistent surface and let the player infer the mass beneath. and make much of that depth optional: missable lore and detail reward curiosity precisely because they can be missed. a world feels real not when everything is explained but when everything hangs together — a coherent surface implies a consistent, deeper reality the player fills in, and that inference is more powerful (and cheaper) than spelling it all out [s-schell-artofgamedesign]. over- explaining, by contrast, deflates mystery and buries the player in lore. the second half is just as important: depth that every player is forced through isn't discovery, it's a lecture — whereas depth the player can miss becomes a reward for looking, which is what makes finding it meaningful (\"it has to be possible to miss some things to make finding them meaningful\") [s-worch-smith-envstory]. optional, missable worldbuilding turns curiosity into its own reward loop and lets each player build the version of the world they dug for. worldbuilding and lore in any game with a setting — rpgs, adventures, exploration and atmosphere games. especially powerful where discovery is a core pleasure. critical setup the player must understand to follow the game should not be buried in missable optional lore — essential information needs reliable delivery (narr-0003's balance). some genres want their world fully and explicitly rendered (certain narrative-heavy or educational games). and \"imply depth\" still requires the depth to actually be consistent — implication over an incoherent world reads as vagueness, not mystery. design a coherent underlying world and show only its telling surface; let players infer the rest. layer lore so a casual player gets the gist and a curious one is rewarded with depth (pairs with narr-0003, level-0007). make the rich readings optional and missable — the reward for attention. keep the surface internally consistent so inference has something true to land on. iceberg/implied worldbuilding (evocative, mysterious, rewards inference, missable) vs. fully- explicit worldbuilding (comprehensive, guaranteed understanding, no gaps). most games favor implication for flavor and depth while explicitly delivering the essential through-line; the debate is how much to withhold and trust the player to infer. confidence 4."}
{"id":"GDC-L1-UX-0001","title":"Teach by doing, just in time — not with front-loaded walls of text","layer":"L1","domain":"UX","subdomain":"onboarding-and-tutorials","type":"contextual","confidence":4,"status":"canonical","tags":["ux","onboarding","tutorials","cognitive-load","learning"],"related":["GDC-L1-LEVEL-0004","GDC-L1-PROG-0005","GDC-L1-DESIGN-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-hodent-gamers-brain"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-UX-0001.md","statement":"Teach a mechanic when the player needs it, through action, not in a front-loaded wall of text or a mandatory tutorial gauntlet. Introduce one thing at a time, in context, and let the player learn by doing. Information delivered before it's needed overloads working memory and is forgotten before it's used.","sections":{"Statement":"> Teach a mechanic *when the player needs it*, through *action*, not in a front-loaded wall\n> of text or a mandatory tutorial gauntlet. Introduce one thing at a time, in context, and\n> let the player learn by doing. Information delivered before it's needed overloads working\n> memory and is forgotten before it's used.","Rationale":"Working memory is small and short-lived, so a tutorial that front-loads a dozen controls\nand rules exceeds the player's capacity to hold them — most of it evaporates before the\nfirst real use [S-hodent-gamers-brain]. Learning sticks when it's *active* (the player does\nthe thing) and *timely* (taught at the moment of need, so it's immediately reinforced by\nuse). This is the UX/cognitive complement to teaching through space (LEVEL-0004) and the\nmastery arc (PROG-0005): those shape *what* order to teach in; this insists on *how* — in\nsmall, contextual, doing-based doses rather than a lecture up front. Fun is learning\n(DESIGN-0003), and learning by playing is far more effective (and more fun) than learning by\nreading.","Applies when":"Onboarding and the introduction of any mechanic, control, or system. Highest-value in the\nopening hour, where first impressions and drop-off are decided.","Does not apply / Exceptions":"Some complexity genuinely needs explicit reference (deep strategy/sim games, complex control\nschemes) — the fix there is an *accessible, optional* reference the player can consult, not a\nforced lecture. Genre conventions vary: a hardcore sim audience tolerates (even expects) a\nmanual; a broad-audience game cannot. And \"just in time\" still needs the teaching to arrive\n*before* failure, not after.","Implementation (kept separate from the principle)":"Break teaching into single-concept, in-context moments triggered by need. Prefer showing and doing over telling. Make any necessary text short, skippable, and re-accessible. Avoid the unskippable tutorial wall. Test onboarding with true first-time players and watch where they overload or forget (PLAYTEST-0001/0003).","Disagreement":"Guided just-in-time onboarding (accessible, low-overload) vs. manual/upfront instruction (thorough, suits complex or hardcore games) vs. discovery-first (teach nothing, let players find out).","Notes":"The cognitive/onboarding angle on teaching, complementing the spatial (LEVEL-0004) and\npacing (PROG-0005) angles. Feeds cognitive-load management (UX-0002). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-UX-0001\ntitle: Teach by doing, just in time — not with front-loaded walls of text\nlayer: L1\ndomain: UX\nsubdomain: onboarding-and-tutorials\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - ux\n  - onboarding\n  - tutorials\n  - cognitive-load\n  - learning\nrelated:\n  - GDC-L1-LEVEL-0004\n  - GDC-L1-PROG-0005\n  - GDC-L1-DESIGN-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-hodent-gamers-brain\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Teach a mechanic *when the player needs it*, through *action*, not in a front-loaded wall\n> of text or a mandatory tutorial gauntlet. Introduce one thing at a time, in context, and\n> let the player learn by doing. Information delivered before it's needed overloads working\n> memory and is forgotten before it's used.\n\n## Rationale\nWorking memory is small and short-lived, so a tutorial that front-loads a dozen controls\nand rules exceeds the player's capacity to hold them — most of it evaporates before the\nfirst real use [S-hodent-gamers-brain]. Learning sticks when it's *active* (the player does\nthe thing) and *timely* (taught at the moment of need, so it's immediately reinforced by\nuse). This is the UX/cognitive complement to teaching through space (LEVEL-0004) and the\nmastery arc (PROG-0005): those shape *what* order to teach in; this insists on *how* — in\nsmall, contextual, doing-based doses rather than a lecture up front. Fun is learning\n(DESIGN-0003), and learning by playing is far more effective (and more fun) than learning by\nreading.\n\n## Applies when\nOnboarding and the introduction of any mechanic, control, or system. Highest-value in the\nopening hour, where first impressions and drop-off are decided.\n\n## Does not apply / Exceptions\nSome complexity genuinely needs explicit reference (deep strategy/sim games, complex control\nschemes) — the fix there is an *accessible, optional* reference the player can consult, not a\nforced lecture. Genre conventions vary: a hardcore sim audience tolerates (even expects) a\nmanual; a broad-audience game cannot. And \"just in time\" still needs the teaching to arrive\n*before* failure, not after.\n\n## Implementation (kept separate from the principle)\nBreak teaching into single-concept, in-context moments triggered by need. Prefer showing and doing over telling. Make any necessary text short, skippable, and re-accessible. Avoid the unskippable tutorial wall. Test onboarding with true first-time players and watch where they overload or forget (PLAYTEST-0001/0003).\n\n## Disagreement\nGuided just-in-time onboarding (accessible, low-overload) vs. manual/upfront instruction (thorough, suits complex or hardcore games) vs. discovery-first (teach nothing, let players find out).\n\n## Notes\nThe cognitive/onboarding angle on teaching, complementing the spatial (LEVEL-0004) and\npacing (PROG-0005) angles. Feeds cognitive-load management (UX-0002). Confidence 4.\n","searchText":"gdc-l1-ux-0001 teach by doing, just in time — not with front-loaded walls of text ux onboarding tutorials cognitive-load learning > teach a mechanic when the player needs it, through action, not in a front-loaded wall of text or a mandatory tutorial gauntlet. introduce one thing at a time, in context, and let the player learn by doing. information delivered before it's needed overloads working memory and is forgotten before it's used. working memory is small and short-lived, so a tutorial that front-loads a dozen controls and rules exceeds the player's capacity to hold them — most of it evaporates before the first real use [s-hodent-gamers-brain]. learning sticks when it's active (the player does the thing) and timely (taught at the moment of need, so it's immediately reinforced by use). this is the ux/cognitive complement to teaching through space (level-0004) and the mastery arc (prog-0005): those shape what order to teach in; this insists on how — in small, contextual, doing-based doses rather than a lecture up front. fun is learning (design-0003), and learning by playing is far more effective (and more fun) than learning by reading. onboarding and the introduction of any mechanic, control, or system. highest-value in the opening hour, where first impressions and drop-off are decided. some complexity genuinely needs explicit reference (deep strategy/sim games, complex control schemes) — the fix there is an accessible, optional reference the player can consult, not a forced lecture. genre conventions vary: a hardcore sim audience tolerates (even expects) a manual; a broad-audience game cannot. and \"just in time\" still needs the teaching to arrive before failure, not after. break teaching into single-concept, in-context moments triggered by need. prefer showing and doing over telling. make any necessary text short, skippable, and re-accessible. avoid the unskippable tutorial wall. test onboarding with true first-time players and watch where they overload or forget (playtest-0001/0003). guided just-in-time onboarding (accessible, low-overload) vs. manual/upfront instruction (thorough, suits complex or hardcore games) vs. discovery-first (teach nothing, let players find out). the cognitive/onboarding angle on teaching, complementing the spatial (level-0004) and pacing (prog-0005) angles. feeds cognitive-load management (ux-0002). confidence 4."}
{"id":"GDC-L1-UX-0002","title":"Manage cognitive load — reveal complexity progressively","layer":"L1","domain":"UX","subdomain":"cognitive-load","type":"contextual","confidence":4,"status":"canonical","tags":["ux","cognitive-load","progressive-disclosure","information-hierarchy","attention"],"related":["GDC-L1-UX-0001","GDC-L1-DESIGN-0005","GDC-L1-SYS-0006"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-hodent-gamers-brain"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-UX-0002.md","statement":"Attention and working memory are limited resources — spend them deliberately. Show the player what they need when they need it and no more, and introduce systems and interface gradually (progressive disclosure) rather than all at once. Complexity revealed over time is depth; complexity dumped at once is overload.","sections":{"Statement":"> Attention and working memory are limited resources — spend them deliberately. Show the\n> player what they need *when* they need it and no more, and introduce systems and interface\n> gradually (progressive disclosure) rather than all at once. Complexity revealed over time\n> is depth; complexity dumped at once is overload.","Rationale":"The brain can only attend to and hold so much at once, and exceeding that budget produces\nconfusion, missed information, and stress rather than mastery [S-hodent-gamers-brain]. The\nsame total complexity feels completely different depending on delivery: metered out as the\nplayer is ready, it reads as a game with satisfying depth (easy to learn, hard to master —\nDESIGN-0005); delivered all at once, it reads as impenetrable. Progressive disclosure — a\nUI that starts simple and grows, systems introduced one at a time, advanced options tucked\nuntil relevant — keeps the player inside their cognitive budget while still building toward\nreal depth. This is also how a legible system (SYS-0006) stays legible even when it's large.","Applies when":"Any game with substantial systems or interface — RPGs, strategy, sims, and especially deep\nsystemic games. The more total complexity, the more its *pacing* matters.","Does not apply / Exceptions":"Some audiences want the full dashboard immediately (expert-facing tools, hardcore sims where\nmastering the information *is* the game). And progressive disclosure can be overdone —\nhiding things players need, or gating information so aggressively it becomes patronizing or\nobscure. Balance disclosure against the player's genuine need to see.","Implementation (kept separate from the principle)":"Introduce mechanics and UI elements one at a time, unlocking complexity as competence grows (pairs with just-in-time teaching, UX-0001). Use information hierarchy so the most important things dominate attention and secondary detail recedes. Hide advanced options until relevant.","Disagreement":"Progressive disclosure (start simple, reveal over time) vs. full-transparency (show\neverything, trust the player) — the latter suits expert audiences and tools; the former suits\nbroad audiences and deep systems. Also overlaps the transparency⇄mystery axis: how much to\nreveal is partly a UX-clarity question and partly a discovery-design choice.","Notes":"The attention-budget principle behind good onboarding (UX-0001) and legible large systems (SYS-0006, DESIGN-0005). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-UX-0002\ntitle: Manage cognitive load — reveal complexity progressively\nlayer: L1\ndomain: UX\nsubdomain: cognitive-load\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - ux\n  - cognitive-load\n  - progressive-disclosure\n  - information-hierarchy\n  - attention\nrelated:\n  - GDC-L1-UX-0001\n  - GDC-L1-DESIGN-0005\n  - GDC-L1-SYS-0006\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-hodent-gamers-brain\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Attention and working memory are limited resources — spend them deliberately. Show the\n> player what they need *when* they need it and no more, and introduce systems and interface\n> gradually (progressive disclosure) rather than all at once. Complexity revealed over time\n> is depth; complexity dumped at once is overload.\n\n## Rationale\nThe brain can only attend to and hold so much at once, and exceeding that budget produces\nconfusion, missed information, and stress rather than mastery [S-hodent-gamers-brain]. The\nsame total complexity feels completely different depending on delivery: metered out as the\nplayer is ready, it reads as a game with satisfying depth (easy to learn, hard to master —\nDESIGN-0005); delivered all at once, it reads as impenetrable. Progressive disclosure — a\nUI that starts simple and grows, systems introduced one at a time, advanced options tucked\nuntil relevant — keeps the player inside their cognitive budget while still building toward\nreal depth. This is also how a legible system (SYS-0006) stays legible even when it's large.\n\n## Applies when\nAny game with substantial systems or interface — RPGs, strategy, sims, and especially deep\nsystemic games. The more total complexity, the more its *pacing* matters.\n\n## Does not apply / Exceptions\nSome audiences want the full dashboard immediately (expert-facing tools, hardcore sims where\nmastering the information *is* the game). And progressive disclosure can be overdone —\nhiding things players need, or gating information so aggressively it becomes patronizing or\nobscure. Balance disclosure against the player's genuine need to see.\n\n## Implementation (kept separate from the principle)\nIntroduce mechanics and UI elements one at a time, unlocking complexity as competence grows (pairs with just-in-time teaching, UX-0001). Use information hierarchy so the most important things dominate attention and secondary detail recedes. Hide advanced options until relevant.\n\n## Disagreement\nProgressive disclosure (start simple, reveal over time) vs. full-transparency (show\neverything, trust the player) — the latter suits expert audiences and tools; the former suits\nbroad audiences and deep systems. Also overlaps the transparency⇄mystery axis: how much to\nreveal is partly a UX-clarity question and partly a discovery-design choice.\n\n## Notes\nThe attention-budget principle behind good onboarding (UX-0001) and legible large systems (SYS-0006, DESIGN-0005). Confidence 4.\n","searchText":"gdc-l1-ux-0002 manage cognitive load — reveal complexity progressively ux cognitive-load progressive-disclosure information-hierarchy attention > attention and working memory are limited resources — spend them deliberately. show the player what they need when they need it and no more, and introduce systems and interface gradually (progressive disclosure) rather than all at once. complexity revealed over time is depth; complexity dumped at once is overload. the brain can only attend to and hold so much at once, and exceeding that budget produces confusion, missed information, and stress rather than mastery [s-hodent-gamers-brain]. the same total complexity feels completely different depending on delivery: metered out as the player is ready, it reads as a game with satisfying depth (easy to learn, hard to master — design-0005); delivered all at once, it reads as impenetrable. progressive disclosure — a ui that starts simple and grows, systems introduced one at a time, advanced options tucked until relevant — keeps the player inside their cognitive budget while still building toward real depth. this is also how a legible system (sys-0006) stays legible even when it's large. any game with substantial systems or interface — rpgs, strategy, sims, and especially deep systemic games. the more total complexity, the more its pacing matters. some audiences want the full dashboard immediately (expert-facing tools, hardcore sims where mastering the information is the game). and progressive disclosure can be overdone — hiding things players need, or gating information so aggressively it becomes patronizing or obscure. balance disclosure against the player's genuine need to see. introduce mechanics and ui elements one at a time, unlocking complexity as competence grows (pairs with just-in-time teaching, ux-0001). use information hierarchy so the most important things dominate attention and secondary detail recedes. hide advanced options until relevant. progressive disclosure (start simple, reveal over time) vs. full-transparency (show everything, trust the player) — the latter suits expert audiences and tools; the former suits broad audiences and deep systems. also overlaps the transparency⇄mystery axis: how much to reveal is partly a ux-clarity question and partly a discovery-design choice. the attention-budget principle behind good onboarding (ux-0001) and legible large systems (sys-0006, design-0005). confidence 4."}
{"id":"GDC-L1-UX-0003","title":"Make the interface communicate — readability, hierarchy, and feedback","layer":"L1","domain":"UX","subdomain":"ui-design","type":"objective","confidence":4,"status":"canonical","tags":["ux","ui","readability","information-hierarchy","feedback","hud"],"related":["GDC-L1-FEEL-0004","GDC-L1-SYS-0006","GDC-L1-LEVEL-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-hodent-gamers-brain","S-norman-doet"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-UX-0003.md","statement":"The interface exists to answer the player's questions at a glance: what's happening, what can I do, what just happened, what matters most? Use visual hierarchy — size, contrast, position, color, motion — to rank importance, and give clear feedback for every action. If players have to squint, hunt, or guess, the UI has failed its job.","sections":{"Statement":"> The interface exists to answer the player's questions at a glance: *what's happening, what\n> can I do, what just happened, what matters most?* Use visual hierarchy — size, contrast,\n> position, color, motion — to rank importance, and give clear feedback for every action. If\n> players have to squint, hunt, or guess, the UI has failed its job.","Rationale":"An interface is a communication channel, and its quality is measured by how quickly and\ncorrectly the player reads it, not by how it looks in a screenshot [S-hodent-gamers-brain].\nThe eye and brain triage by salience — bright, big, high-contrast, moving things get\nattention first — so a UI that doesn't *rank* its elements forces the player to search, which\ncosts attention that should be on the game (UX-0002). Feedback closes the loop Norman\ndescribes: every action needs a visible, immediate confirmation, or the player can't tell if\nit worked [S-norman-doet] (the UI expression of FEEL-0004). Good UI makes the important\nlegible instantly and the unimportant recede.","Applies when":"All HUD, menu, and interface design, and any moment the game must convey state,\navailability, or the result of an action.","Does not apply / Exceptions":"Deliberate minimalism and diegetic/no-HUD design are valid stylistic choices (immersion,\ntension, art) — but they don't exempt the game from *communicating*; they just move the\ncommunication into the world (a wounded character's limp instead of a health bar). Some\ninformation is intentionally withheld for tension or discovery (transparency⇄mystery). The\nrule is \"communicate what the player needs, clearly,\" not \"put everything on a HUD.\"","Implementation (kept separate from the principle)":"Establish a clear hierarchy: the most important information is the most salient; secondary\ndetail is quieter. Never encode critical information in color alone (accessibility, UX-0006).\nGive immediate, unambiguous feedback for actions and state changes. Test readability with\nreal players at real speed and viewing distance — if they miss it, redesign the presentation,\nnot the player. Reduce clutter; every element competes for attention.","Disagreement":"Rich/informative HUD (clarity, low friction) vs. minimal/diegetic UI (immersion, art) is a\nstylistic split — but both camps agree the game must *communicate*, differing on *where* and\n*how much*. The debate is presentation, not whether to inform.","Notes":"The UI face of legibility — SYS-0006 (systems), LEVEL-0002 (space), and FEEL-0004 (feedback)\nall meet here in the interface layer. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-UX-0003\ntitle: Make the interface communicate — readability, hierarchy, and feedback\nlayer: L1\ndomain: UX\nsubdomain: ui-design\ntype: objective\nconfidence: 4\nstatus: canonical\ntags:\n  - ux\n  - ui\n  - readability\n  - information-hierarchy\n  - feedback\n  - hud\nrelated:\n  - GDC-L1-FEEL-0004\n  - GDC-L1-SYS-0006\n  - GDC-L1-LEVEL-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-hodent-gamers-brain\n  - S-norman-doet\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> The interface exists to answer the player's questions at a glance: *what's happening, what\n> can I do, what just happened, what matters most?* Use visual hierarchy — size, contrast,\n> position, color, motion — to rank importance, and give clear feedback for every action. If\n> players have to squint, hunt, or guess, the UI has failed its job.\n\n## Rationale\nAn interface is a communication channel, and its quality is measured by how quickly and\ncorrectly the player reads it, not by how it looks in a screenshot [S-hodent-gamers-brain].\nThe eye and brain triage by salience — bright, big, high-contrast, moving things get\nattention first — so a UI that doesn't *rank* its elements forces the player to search, which\ncosts attention that should be on the game (UX-0002). Feedback closes the loop Norman\ndescribes: every action needs a visible, immediate confirmation, or the player can't tell if\nit worked [S-norman-doet] (the UI expression of FEEL-0004). Good UI makes the important\nlegible instantly and the unimportant recede.\n\n## Applies when\nAll HUD, menu, and interface design, and any moment the game must convey state,\navailability, or the result of an action.\n\n## Does not apply / Exceptions\nDeliberate minimalism and diegetic/no-HUD design are valid stylistic choices (immersion,\ntension, art) — but they don't exempt the game from *communicating*; they just move the\ncommunication into the world (a wounded character's limp instead of a health bar). Some\ninformation is intentionally withheld for tension or discovery (transparency⇄mystery). The\nrule is \"communicate what the player needs, clearly,\" not \"put everything on a HUD.\"\n\n## Implementation (kept separate from the principle)\nEstablish a clear hierarchy: the most important information is the most salient; secondary\ndetail is quieter. Never encode critical information in color alone (accessibility, UX-0006).\nGive immediate, unambiguous feedback for actions and state changes. Test readability with\nreal players at real speed and viewing distance — if they miss it, redesign the presentation,\nnot the player. Reduce clutter; every element competes for attention.\n\n## Disagreement\nRich/informative HUD (clarity, low friction) vs. minimal/diegetic UI (immersion, art) is a\nstylistic split — but both camps agree the game must *communicate*, differing on *where* and\n*how much*. The debate is presentation, not whether to inform.\n\n## Notes\nThe UI face of legibility — SYS-0006 (systems), LEVEL-0002 (space), and FEEL-0004 (feedback)\nall meet here in the interface layer. Confidence 4.\n","searchText":"gdc-l1-ux-0003 make the interface communicate — readability, hierarchy, and feedback ux ui readability information-hierarchy feedback hud > the interface exists to answer the player's questions at a glance: what's happening, what can i do, what just happened, what matters most? use visual hierarchy — size, contrast, position, color, motion — to rank importance, and give clear feedback for every action. if players have to squint, hunt, or guess, the ui has failed its job. an interface is a communication channel, and its quality is measured by how quickly and correctly the player reads it, not by how it looks in a screenshot [s-hodent-gamers-brain]. the eye and brain triage by salience — bright, big, high-contrast, moving things get attention first — so a ui that doesn't rank its elements forces the player to search, which costs attention that should be on the game (ux-0002). feedback closes the loop norman describes: every action needs a visible, immediate confirmation, or the player can't tell if it worked [s-norman-doet] (the ui expression of feel-0004). good ui makes the important legible instantly and the unimportant recede. all hud, menu, and interface design, and any moment the game must convey state, availability, or the result of an action. deliberate minimalism and diegetic/no-hud design are valid stylistic choices (immersion, tension, art) — but they don't exempt the game from communicating; they just move the communication into the world (a wounded character's limp instead of a health bar). some information is intentionally withheld for tension or discovery (transparency⇄mystery). the rule is \"communicate what the player needs, clearly,\" not \"put everything on a hud.\" establish a clear hierarchy: the most important information is the most salient; secondary detail is quieter. never encode critical information in color alone (accessibility, ux-0006). give immediate, unambiguous feedback for actions and state changes. test readability with real players at real speed and viewing distance — if they miss it, redesign the presentation, not the player. reduce clutter; every element competes for attention. rich/informative hud (clarity, low friction) vs. minimal/diegetic ui (immersion, art) is a stylistic split — but both camps agree the game must communicate, differing on where and how much. the debate is presentation, not whether to inform. the ui face of legibility — sys-0006 (systems), level-0002 (space), and feel-0004 (feedback) all meet here in the interface layer. confidence 4."}
{"id":"GDC-L1-UX-0004","title":"Use affordances, signifiers, and conventions — make the right action obvious","layer":"L1","domain":"UX","subdomain":"ui-design","type":"contextual","confidence":4,"status":"canonical","tags":["ux","affordances","signifiers","conventions","mapping","discoverability"],"related":["GDC-L1-UX-0003","GDC-L1-UX-0005","GDC-L1-FEEL-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-norman-doet"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-UX-0004.md","statement":"Design so the correct action is obvious and the wrong one is hard. Objects and controls should signal how to use them (affordances and signifiers), controls should map naturally to their effects, and established conventions (WASD to move, red for danger, a button prompt to interact) should be honored unless breaking them clearly pays. Don't make players guess or relearn what they already know.","sections":{"Statement":"> Design so the correct action is obvious and the wrong one is hard. Objects and controls\n> should signal how to use them (**affordances** and **signifiers**), controls should map\n> naturally to their effects, and established **conventions** (WASD to move, red for danger,\n> a button prompt to interact) should be honored unless breaking them clearly pays. Don't\n> make players guess or relearn what they already know.","Rationale":"Players arrive with a huge library of learned conventions and real-world intuitions, and good\ndesign *leverages* that library rather than fighting it [S-norman-doet]. An affordance is\nwhat an object lets you do; a signifier is the cue that tells the player it's possible — a\nledge that's clearly grabbable, a door that's obviously openable, a highlighted interactable.\nNatural mapping (the control relates intuitively to its effect) and honored convention mean\nthe player transfers existing knowledge instead of learning from scratch, which lowers\ncognitive load (UX-0002) and gets them playing sooner. Violating a strong convention without\na reason imposes a relearning tax and a stream of avoidable errors.","Applies when":"Control schemes, interactable objects, UI elements, iconography — anywhere the player must\nfigure out \"what can I do here and how?\"","Does not apply / Exceptions":"Breaking convention can be a deliberate, valuable design move — a novel control or interface\nthat unlocks something conventions can't (motion controls, unique traversal, an\nintentionally alien UI). The test is whether the payoff exceeds the relearning cost. Some\nsignifiers are also deliberately hidden for discovery/puzzle design (a secret is *supposed*\nto be non-obvious). Convention is the default to depart from consciously, not a mandate.","Implementation (kept separate from the principle)":"Signal interactivity clearly (highlights, prompts, distinct shapes/materials for\ninteractables). Map controls to their effects intuitively. Follow platform and genre\nconventions for common actions unless you have a real reason not to — and when you break one,\nteach the new pattern deliberately (UX-0001). Make illegal or harmful actions hard or\nimpossible rather than merely discouraged.","Disagreement":"Convention (leverage learned patterns, low friction, fast onboarding) vs. innovation (novel\nschemes that enable new experiences at a learning cost) is a real tension. Broad-audience and\nusability-first design leans convention; distinctive, mechanic-defining design sometimes earns\nthe cost of the new. Break conventions on purpose, not by accident.","Notes":"The Norman core of the UX domain; pairs with readable communication (UX-0003), control\nergonomics (UX-0005), and responsiveness (FEEL-0002 — a signified action must also *respond*).\nConfidence 4."},"rawMarkdown":"---\nid: GDC-L1-UX-0004\ntitle: Use affordances, signifiers, and conventions — make the right action obvious\nlayer: L1\ndomain: UX\nsubdomain: ui-design\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - ux\n  - affordances\n  - signifiers\n  - conventions\n  - mapping\n  - discoverability\nrelated:\n  - GDC-L1-UX-0003\n  - GDC-L1-UX-0005\n  - GDC-L1-FEEL-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-norman-doet\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Design so the correct action is obvious and the wrong one is hard. Objects and controls\n> should signal how to use them (**affordances** and **signifiers**), controls should map\n> naturally to their effects, and established **conventions** (WASD to move, red for danger,\n> a button prompt to interact) should be honored unless breaking them clearly pays. Don't\n> make players guess or relearn what they already know.\n\n## Rationale\nPlayers arrive with a huge library of learned conventions and real-world intuitions, and good\ndesign *leverages* that library rather than fighting it [S-norman-doet]. An affordance is\nwhat an object lets you do; a signifier is the cue that tells the player it's possible — a\nledge that's clearly grabbable, a door that's obviously openable, a highlighted interactable.\nNatural mapping (the control relates intuitively to its effect) and honored convention mean\nthe player transfers existing knowledge instead of learning from scratch, which lowers\ncognitive load (UX-0002) and gets them playing sooner. Violating a strong convention without\na reason imposes a relearning tax and a stream of avoidable errors.\n\n## Applies when\nControl schemes, interactable objects, UI elements, iconography — anywhere the player must\nfigure out \"what can I do here and how?\"\n\n## Does not apply / Exceptions\nBreaking convention can be a deliberate, valuable design move — a novel control or interface\nthat unlocks something conventions can't (motion controls, unique traversal, an\nintentionally alien UI). The test is whether the payoff exceeds the relearning cost. Some\nsignifiers are also deliberately hidden for discovery/puzzle design (a secret is *supposed*\nto be non-obvious). Convention is the default to depart from consciously, not a mandate.\n\n## Implementation (kept separate from the principle)\nSignal interactivity clearly (highlights, prompts, distinct shapes/materials for\ninteractables). Map controls to their effects intuitively. Follow platform and genre\nconventions for common actions unless you have a real reason not to — and when you break one,\nteach the new pattern deliberately (UX-0001). Make illegal or harmful actions hard or\nimpossible rather than merely discouraged.\n\n## Disagreement\nConvention (leverage learned patterns, low friction, fast onboarding) vs. innovation (novel\nschemes that enable new experiences at a learning cost) is a real tension. Broad-audience and\nusability-first design leans convention; distinctive, mechanic-defining design sometimes earns\nthe cost of the new. Break conventions on purpose, not by accident.\n\n## Notes\nThe Norman core of the UX domain; pairs with readable communication (UX-0003), control\nergonomics (UX-0005), and responsiveness (FEEL-0002 — a signified action must also *respond*).\nConfidence 4.\n","searchText":"gdc-l1-ux-0004 use affordances, signifiers, and conventions — make the right action obvious ux affordances signifiers conventions mapping discoverability > design so the correct action is obvious and the wrong one is hard. objects and controls should signal how to use them (affordances and signifiers), controls should map naturally to their effects, and established conventions (wasd to move, red for danger, a button prompt to interact) should be honored unless breaking them clearly pays. don't make players guess or relearn what they already know. players arrive with a huge library of learned conventions and real-world intuitions, and good design leverages that library rather than fighting it [s-norman-doet]. an affordance is what an object lets you do; a signifier is the cue that tells the player it's possible — a ledge that's clearly grabbable, a door that's obviously openable, a highlighted interactable. natural mapping (the control relates intuitively to its effect) and honored convention mean the player transfers existing knowledge instead of learning from scratch, which lowers cognitive load (ux-0002) and gets them playing sooner. violating a strong convention without a reason imposes a relearning tax and a stream of avoidable errors. control schemes, interactable objects, ui elements, iconography — anywhere the player must figure out \"what can i do here and how?\" breaking convention can be a deliberate, valuable design move — a novel control or interface that unlocks something conventions can't (motion controls, unique traversal, an intentionally alien ui). the test is whether the payoff exceeds the relearning cost. some signifiers are also deliberately hidden for discovery/puzzle design (a secret is supposed to be non-obvious). convention is the default to depart from consciously, not a mandate. signal interactivity clearly (highlights, prompts, distinct shapes/materials for interactables). map controls to their effects intuitively. follow platform and genre conventions for common actions unless you have a real reason not to — and when you break one, teach the new pattern deliberately (ux-0001). make illegal or harmful actions hard or impossible rather than merely discouraged. convention (leverage learned patterns, low friction, fast onboarding) vs. innovation (novel schemes that enable new experiences at a learning cost) is a real tension. broad-audience and usability-first design leans convention; distinctive, mechanic-defining design sometimes earns the cost of the new. break conventions on purpose, not by accident. the norman core of the ux domain; pairs with readable communication (ux-0003), control ergonomics (ux-0005), and responsiveness (feel-0002 — a signified action must also respond). confidence 4."}
{"id":"GDC-L1-UX-0005","title":"Design controls for the hand — ergonomics, mapping, and button economy","layer":"L1","domain":"UX","subdomain":"control-schemes","type":"contextual","confidence":4,"status":"canonical","tags":["ux","controls","ergonomics","button-economy","mapping","muscle-memory"],"related":["GDC-L1-UX-0004","GDC-L1-FEEL-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-norman-doet","S-hodent-gamers-brain"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-UX-0005.md","statement":"Controls live in the body, not just the menu. Map actions to inputs that fit the hand, respect muscle memory, and treat input space as scarce — every binding competes for the player's fingers and memory. Give the most frequent actions the easiest inputs, and never demand more simultaneous inputs than hands can comfortably manage.","sections":{"Statement":"> Controls live in the body, not just the menu. Map actions to inputs that fit the hand,\n> respect muscle memory, and treat input space as **scarce** — every binding competes for the\n> player's fingers and memory. Give the most frequent actions the easiest inputs, and never\n> demand more simultaneous inputs than hands can comfortably manage.","Rationale":"Play is physical: the player's fingers, not their conscious mind, execute most actions once\nlearned, so the *layout* of controls shapes how the game feels to operate\n[S-hodent-gamers-brain]. Frequent actions on awkward inputs cause constant friction and\nerror; conflicting or overloaded bindings break the muscle memory that skilled play depends\non. Button economy is real — a controller has a fixed, small number of comfortable inputs, so\neach new action *costs* one, and adding capability often means *replacing* a binding rather\nthan piling on another (natural mapping and constraint, per Norman [S-norman-doet]). Designing\nfor the hand keeps the interface between intent and action invisible, which is the\nprecondition for good feel (FEEL-0002).","Applies when":"Control-scheme design, input mapping, and any time you add a new player action or ability.\nMost acute on controllers (scarce buttons) and for action games (execution matters).","Does not apply / Exceptions":"Input-rich platforms (keyboard+mouse, complex sim setups) have more room and audiences who\naccept dense bindings. Some genres intentionally use awkward or demanding controls for effect\n(deliberate clumsiness for comedy or tension). And accessibility overrides ergonomic\n\"defaults\" — full remapping (UX-0006) means no single layout must fit every hand.","Implementation (kept separate from the principle)":"Assign the easiest, most reachable inputs to the most frequent actions. Group related actions sensibly, respect platform conventions (UX-0004), and always offer full remapping.","Disagreement":"Minimal/economical control sets (accessible, low cognitive and motor load) vs. rich/expressive\ncontrol sets (depth, expert expression, more verbs) — fighting games and sims lean rich;\nbroad-audience and mobile lean minimal. The scarcity of comfortable inputs is the constraint\nboth negotiate.","Notes":"Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-UX-0005\ntitle: Design controls for the hand — ergonomics, mapping, and button economy\nlayer: L1\ndomain: UX\nsubdomain: control-schemes\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - ux\n  - controls\n  - ergonomics\n  - button-economy\n  - mapping\n  - muscle-memory\nrelated:\n  - GDC-L1-UX-0004\n  - GDC-L1-FEEL-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-norman-doet\n  - S-hodent-gamers-brain\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Controls live in the body, not just the menu. Map actions to inputs that fit the hand,\n> respect muscle memory, and treat input space as **scarce** — every binding competes for the\n> player's fingers and memory. Give the most frequent actions the easiest inputs, and never\n> demand more simultaneous inputs than hands can comfortably manage.\n\n## Rationale\nPlay is physical: the player's fingers, not their conscious mind, execute most actions once\nlearned, so the *layout* of controls shapes how the game feels to operate\n[S-hodent-gamers-brain]. Frequent actions on awkward inputs cause constant friction and\nerror; conflicting or overloaded bindings break the muscle memory that skilled play depends\non. Button economy is real — a controller has a fixed, small number of comfortable inputs, so\neach new action *costs* one, and adding capability often means *replacing* a binding rather\nthan piling on another (natural mapping and constraint, per Norman [S-norman-doet]). Designing\nfor the hand keeps the interface between intent and action invisible, which is the\nprecondition for good feel (FEEL-0002).\n\n## Applies when\nControl-scheme design, input mapping, and any time you add a new player action or ability.\nMost acute on controllers (scarce buttons) and for action games (execution matters).\n\n## Does not apply / Exceptions\nInput-rich platforms (keyboard+mouse, complex sim setups) have more room and audiences who\naccept dense bindings. Some genres intentionally use awkward or demanding controls for effect\n(deliberate clumsiness for comedy or tension). And accessibility overrides ergonomic\n\"defaults\" — full remapping (UX-0006) means no single layout must fit every hand.\n\n## Implementation (kept separate from the principle)\nAssign the easiest, most reachable inputs to the most frequent actions. Group related actions sensibly, respect platform conventions (UX-0004), and always offer full remapping.\n\n## Disagreement\nMinimal/economical control sets (accessible, low cognitive and motor load) vs. rich/expressive\ncontrol sets (depth, expert expression, more verbs) — fighting games and sims lean rich;\nbroad-audience and mobile lean minimal. The scarcity of comfortable inputs is the constraint\nboth negotiate.\n\n## Notes\nConfidence 4.\n","searchText":"gdc-l1-ux-0005 design controls for the hand — ergonomics, mapping, and button economy ux controls ergonomics button-economy mapping muscle-memory > controls live in the body, not just the menu. map actions to inputs that fit the hand, respect muscle memory, and treat input space as scarce — every binding competes for the player's fingers and memory. give the most frequent actions the easiest inputs, and never demand more simultaneous inputs than hands can comfortably manage. play is physical: the player's fingers, not their conscious mind, execute most actions once learned, so the layout of controls shapes how the game feels to operate [s-hodent-gamers-brain]. frequent actions on awkward inputs cause constant friction and error; conflicting or overloaded bindings break the muscle memory that skilled play depends on. button economy is real — a controller has a fixed, small number of comfortable inputs, so each new action costs one, and adding capability often means replacing a binding rather than piling on another (natural mapping and constraint, per norman [s-norman-doet]). designing for the hand keeps the interface between intent and action invisible, which is the precondition for good feel (feel-0002). control-scheme design, input mapping, and any time you add a new player action or ability. most acute on controllers (scarce buttons) and for action games (execution matters). input-rich platforms (keyboard+mouse, complex sim setups) have more room and audiences who accept dense bindings. some genres intentionally use awkward or demanding controls for effect (deliberate clumsiness for comedy or tension). and accessibility overrides ergonomic \"defaults\" — full remapping (ux-0006) means no single layout must fit every hand. assign the easiest, most reachable inputs to the most frequent actions. group related actions sensibly, respect platform conventions (ux-0004), and always offer full remapping. minimal/economical control sets (accessible, low cognitive and motor load) vs. rich/expressive control sets (depth, expert expression, more verbs) — fighting games and sims lean rich; broad-audience and mobile lean minimal. the scarcity of comfortable inputs is the constraint both negotiate. confidence 4."}
{"id":"GDC-L1-UX-0006","title":"Treat accessibility as design — and build it in early","layer":"L1","domain":"UX","subdomain":"accessibility","type":"contextual","confidence":4,"status":"canonical","tags":["ux","accessibility","inclusion","player-respect","options"],"related":["GDC-L1-FEEL-0006","GDC-L1-PROG-0004","GDC-L1-UX-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-game-accessibility"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-UX-0006.md","statement":"Build accessibility in from the start, not as a late patch: remappable controls, scalable text, colorblind-safe visuals (never encode information in color alone), subtitles and captions, difficulty/assist options, and toggles for effects like screen shake. Accessibility widens your audience and usually makes the game better for everyone. Plan for it early so core UI, input, audio, and visual systems can support it.","sections":{"Statement":"> Build accessibility in from the start, not as a late patch: remappable controls, scalable\n> text, colorblind-safe visuals (never encode information in color alone), subtitles and\n> captions, difficulty/assist options, and toggles for effects like screen shake.\n> Accessibility widens your audience and usually makes the game better for everyone.\n> Plan for it early so core UI, input, audio, and visual systems can support it.","Rationale":"A large number of players have disabilities — visual, auditory, motor, cognitive — and small,\nwell-known features remove barriers that exclude them [S-game-accessibility]. Common high-impact\nneeds include control remapping, scalable text, colorblind-safe information, and strong subtitle\npresentation. These are architectural design concerns, not a charity add-on: no color-only\nencoding, scalable UI, and a remappable input layer are easier to support when the underlying\nsystems anticipate them. Accessibility features also routinely help *everyone*\n(the \"curb-cut effect\"): subtitles help players in noisy rooms, remapping helps everyone find\na comfortable layout, a screen-shake toggle helps the motion-sensitive and the easily-nauseated\nalike (FEEL-0006). It's an extension of respecting the player (PROG-0004).","Applies when":"From the earliest UI, input, audio, and visual-design decisions onward.","Does not apply / Exceptions":"Not every accessibility feature fits every game, and some interact with core design (a\ndifficulty/assist mode can conflict with a game whose identity *is* its difficulty — a real\nand much-debated tension). Tiny-scope or experimental projects may implement only a focused\nset of high-impact essentials. The principle is to *design so accessibility is possible*,\nnot that every option must ship in every game.","Implementation (kept separate from the principle)":"Plan high-impact basics from day one: full input remapping, scalable/high-contrast\ntext, no color-only information (add shape/icon/text), subtitles with size and contrast\ncontrols, and effect toggles (screen shake — FEEL-0006). Add difficulty/assist options and\npause-anywhere where they fit. Consult established guidelines and test with players who have\nrelevant needs. Treat \"can everyone who wants to play, play?\" as a design question.","Disagreement":"The live debate is narrow but real: **difficulty/assist options** — do they belong in every\ngame, or does a deliberately punishing game have the right to its difficulty as an\ninseparable part of its identity? (The rest of accessibility — remapping, text, color,\ncaptions — enjoys broad consensus.) Even there, most argue assist options rarely harm the\nplayers who ignore them.","Notes":"The inclusion-and-respect principle of UX; directly connects to FEEL-0006 (screen-shake\ntoggle) and PROG-0004 (respect the player), with a clear ethics/wellbeing dimension.\nConfidence 4."},"rawMarkdown":"---\nid: GDC-L1-UX-0006\ntitle: Treat accessibility as design — and build it in early\nlayer: L1\ndomain: UX\nsubdomain: accessibility\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - ux\n  - accessibility\n  - inclusion\n  - player-respect\n  - options\nrelated:\n  - GDC-L1-FEEL-0006\n  - GDC-L1-PROG-0004\n  - GDC-L1-UX-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-game-accessibility\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Build accessibility in from the start, not as a late patch: remappable controls, scalable\n> text, colorblind-safe visuals (never encode information in color alone), subtitles and\n> captions, difficulty/assist options, and toggles for effects like screen shake.\n> Accessibility widens your audience and usually makes the game better for everyone.\n> Plan for it early so core UI, input, audio, and visual systems can support it.\n\n## Rationale\nA large number of players have disabilities — visual, auditory, motor, cognitive — and small,\nwell-known features remove barriers that exclude them [S-game-accessibility]. Common high-impact\nneeds include control remapping, scalable text, colorblind-safe information, and strong subtitle\npresentation. These are architectural design concerns, not a charity add-on: no color-only\nencoding, scalable UI, and a remappable input layer are easier to support when the underlying\nsystems anticipate them. Accessibility features also routinely help *everyone*\n(the \"curb-cut effect\"): subtitles help players in noisy rooms, remapping helps everyone find\na comfortable layout, a screen-shake toggle helps the motion-sensitive and the easily-nauseated\nalike (FEEL-0006). It's an extension of respecting the player (PROG-0004).\n\n## Applies when\nFrom the earliest UI, input, audio, and visual-design decisions onward.\n\n## Does not apply / Exceptions\nNot every accessibility feature fits every game, and some interact with core design (a\ndifficulty/assist mode can conflict with a game whose identity *is* its difficulty — a real\nand much-debated tension). Tiny-scope or experimental projects may implement only a focused\nset of high-impact essentials. The principle is to *design so accessibility is possible*,\nnot that every option must ship in every game.\n\n## Implementation (kept separate from the principle)\nPlan high-impact basics from day one: full input remapping, scalable/high-contrast\ntext, no color-only information (add shape/icon/text), subtitles with size and contrast\ncontrols, and effect toggles (screen shake — FEEL-0006). Add difficulty/assist options and\npause-anywhere where they fit. Consult established guidelines and test with players who have\nrelevant needs. Treat \"can everyone who wants to play, play?\" as a design question.\n\n## Disagreement\nThe live debate is narrow but real: **difficulty/assist options** — do they belong in every\ngame, or does a deliberately punishing game have the right to its difficulty as an\ninseparable part of its identity? (The rest of accessibility — remapping, text, color,\ncaptions — enjoys broad consensus.) Even there, most argue assist options rarely harm the\nplayers who ignore them.\n\n## Notes\nThe inclusion-and-respect principle of UX; directly connects to FEEL-0006 (screen-shake\ntoggle) and PROG-0004 (respect the player), with a clear ethics/wellbeing dimension.\nConfidence 4.\n","searchText":"gdc-l1-ux-0006 treat accessibility as design — and build it in early ux accessibility inclusion player-respect options > build accessibility in from the start, not as a late patch: remappable controls, scalable text, colorblind-safe visuals (never encode information in color alone), subtitles and captions, difficulty/assist options, and toggles for effects like screen shake. accessibility widens your audience and usually makes the game better for everyone. plan for it early so core ui, input, audio, and visual systems can support it. a large number of players have disabilities — visual, auditory, motor, cognitive — and small, well-known features remove barriers that exclude them [s-game-accessibility]. common high-impact needs include control remapping, scalable text, colorblind-safe information, and strong subtitle presentation. these are architectural design concerns, not a charity add-on: no color-only encoding, scalable ui, and a remappable input layer are easier to support when the underlying systems anticipate them. accessibility features also routinely help everyone (the \"curb-cut effect\"): subtitles help players in noisy rooms, remapping helps everyone find a comfortable layout, a screen-shake toggle helps the motion-sensitive and the easily-nauseated alike (feel-0006). it's an extension of respecting the player (prog-0004). from the earliest ui, input, audio, and visual-design decisions onward. not every accessibility feature fits every game, and some interact with core design (a difficulty/assist mode can conflict with a game whose identity is its difficulty — a real and much-debated tension). tiny-scope or experimental projects may implement only a focused set of high-impact essentials. the principle is to design so accessibility is possible, not that every option must ship in every game. plan high-impact basics from day one: full input remapping, scalable/high-contrast text, no color-only information (add shape/icon/text), subtitles with size and contrast controls, and effect toggles (screen shake — feel-0006). add difficulty/assist options and pause-anywhere where they fit. consult established guidelines and test with players who have relevant needs. treat \"can everyone who wants to play, play?\" as a design question. the live debate is narrow but real: difficulty/assist options — do they belong in every game, or does a deliberately punishing game have the right to its difficulty as an inseparable part of its identity? (the rest of accessibility — remapping, text, color, captions — enjoys broad consensus.) even there, most argue assist options rarely harm the players who ignore them. the inclusion-and-respect principle of ux; directly connects to feel-0006 (screen-shake toggle) and prog-0004 (respect the player), with a clear ethics/wellbeing dimension. confidence 4."}
{"id":"GDC-L1-UX-0007","title":"Minimize friction between the player and the fun","layer":"L1","domain":"UX","subdomain":"ui-design","type":"contextual","confidence":4,"status":"canonical","tags":["ux","friction","player-respect","flow","core-loop"],"related":["GDC-L1-SYS-0001","GDC-L1-PROG-0004","GDC-L1-FEEL-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-hodent-gamers-brain"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-UX-0007.md","statement":"Every menu, load screen, unskippable cutscene, confirmation dialog, and scrap of busywork between the player and the core loop is a tax on engagement. Ruthlessly reduce friction on the path to play. Respect the player's time and attention — get them to the fun and keep them in it.","sections":{"Statement":"> Every menu, load screen, unskippable cutscene, confirmation dialog, and scrap of busywork\n> between the player and the core loop is a tax on engagement. Ruthlessly reduce friction on\n> the path to play. Respect the player's time and attention — get them to the fun and keep\n> them in it.","Rationale":"Engagement is fragile: friction on the way to the fun (long loads, menu mazes, forced\ntutorials, needless confirmations, grindy setup) leaks motivation and gives the player exits\n[S-hodent-gamers-brain]. The core loop (SYS-0001) is where the value lives, so anything that\ndelays, interrupts, or clutters the route to it is spending the player's goodwill for no\ngameplay return. Minimizing friction is partly respect (PROG-0004 — don't waste the player's\ntime) and partly practical (a game that's quick to get into and stay in gets played more, and\nloses fewer players at each seam). Fast, clean access to play is invisible when done well and\ncorrosive when ignored.","Applies when":"Boot-to-play flow, menu and inventory design, mission setup, retries and respawns, and any\nrepeated action on the path to the core loop.","Does not apply / Exceptions":"Not all friction is bad — **deliberate friction** creates weight, ritual, tension, and\nmeaning: a Souls bonfire's deliberate rest, inventory management *as* gameplay, a slow reload\nthat raises stakes, a save ritual that makes the world feel consequential. The distinction is\n*meaningful* friction (part of the intended experience) vs. *incidental* friction (accidental\ntax with no payoff). Cut the incidental; keep the meaningful. Removing all friction can also\nflatten pacing (LEVEL-0003 needs rests).","Implementation (kept separate from the principle)":"Audit the path from launch to play and from failure to retry; cut or streamline every step\nthat isn't earning its place. Reduce load times (or mask them), skip or shorten repeated\ncutscenes, trim confirmation dialogs to the genuinely destructive actions, and get respawns\nfast. Ask of each bit of friction: does this add to the experience, or just delay it? Keep\nthe meaningful, cut the rest.","Disagreement":"Frictionless design (respect time, maximize flow, remove obstacles) vs. meaningful-friction\ndesign (weight, ritual, stakes, and downtime as part of the experience). Both are right about\ndifferent friction; the craft is telling incidental tax from intentional texture. Hyper-casual\nleans frictionless; immersive and deliberate games keep chosen friction.","Notes":"The engagement/respect principle that ties UX to the core loop (SYS-0001) and player respect\n(PROG-0004); its meaningful-friction exception connects to pacing (LEVEL-0003) and weight\n(FEEL-0008). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-UX-0007\ntitle: Minimize friction between the player and the fun\nlayer: L1\ndomain: UX\nsubdomain: ui-design\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - ux\n  - friction\n  - player-respect\n  - flow\n  - core-loop\nrelated:\n  - GDC-L1-SYS-0001\n  - GDC-L1-PROG-0004\n  - GDC-L1-FEEL-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-hodent-gamers-brain\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Every menu, load screen, unskippable cutscene, confirmation dialog, and scrap of busywork\n> between the player and the core loop is a tax on engagement. Ruthlessly reduce friction on\n> the path to play. Respect the player's time and attention — get them to the fun and keep\n> them in it.\n\n## Rationale\nEngagement is fragile: friction on the way to the fun (long loads, menu mazes, forced\ntutorials, needless confirmations, grindy setup) leaks motivation and gives the player exits\n[S-hodent-gamers-brain]. The core loop (SYS-0001) is where the value lives, so anything that\ndelays, interrupts, or clutters the route to it is spending the player's goodwill for no\ngameplay return. Minimizing friction is partly respect (PROG-0004 — don't waste the player's\ntime) and partly practical (a game that's quick to get into and stay in gets played more, and\nloses fewer players at each seam). Fast, clean access to play is invisible when done well and\ncorrosive when ignored.\n\n## Applies when\nBoot-to-play flow, menu and inventory design, mission setup, retries and respawns, and any\nrepeated action on the path to the core loop.\n\n## Does not apply / Exceptions\nNot all friction is bad — **deliberate friction** creates weight, ritual, tension, and\nmeaning: a Souls bonfire's deliberate rest, inventory management *as* gameplay, a slow reload\nthat raises stakes, a save ritual that makes the world feel consequential. The distinction is\n*meaningful* friction (part of the intended experience) vs. *incidental* friction (accidental\ntax with no payoff). Cut the incidental; keep the meaningful. Removing all friction can also\nflatten pacing (LEVEL-0003 needs rests).\n\n## Implementation (kept separate from the principle)\nAudit the path from launch to play and from failure to retry; cut or streamline every step\nthat isn't earning its place. Reduce load times (or mask them), skip or shorten repeated\ncutscenes, trim confirmation dialogs to the genuinely destructive actions, and get respawns\nfast. Ask of each bit of friction: does this add to the experience, or just delay it? Keep\nthe meaningful, cut the rest.\n\n## Disagreement\nFrictionless design (respect time, maximize flow, remove obstacles) vs. meaningful-friction\ndesign (weight, ritual, stakes, and downtime as part of the experience). Both are right about\ndifferent friction; the craft is telling incidental tax from intentional texture. Hyper-casual\nleans frictionless; immersive and deliberate games keep chosen friction.\n\n## Notes\nThe engagement/respect principle that ties UX to the core loop (SYS-0001) and player respect\n(PROG-0004); its meaningful-friction exception connects to pacing (LEVEL-0003) and weight\n(FEEL-0008). Confidence 4.\n","searchText":"gdc-l1-ux-0007 minimize friction between the player and the fun ux friction player-respect flow core-loop > every menu, load screen, unskippable cutscene, confirmation dialog, and scrap of busywork between the player and the core loop is a tax on engagement. ruthlessly reduce friction on the path to play. respect the player's time and attention — get them to the fun and keep them in it. engagement is fragile: friction on the way to the fun (long loads, menu mazes, forced tutorials, needless confirmations, grindy setup) leaks motivation and gives the player exits [s-hodent-gamers-brain]. the core loop (sys-0001) is where the value lives, so anything that delays, interrupts, or clutters the route to it is spending the player's goodwill for no gameplay return. minimizing friction is partly respect (prog-0004 — don't waste the player's time) and partly practical (a game that's quick to get into and stay in gets played more, and loses fewer players at each seam). fast, clean access to play is invisible when done well and corrosive when ignored. boot-to-play flow, menu and inventory design, mission setup, retries and respawns, and any repeated action on the path to the core loop. not all friction is bad — deliberate friction creates weight, ritual, tension, and meaning: a souls bonfire's deliberate rest, inventory management as gameplay, a slow reload that raises stakes, a save ritual that makes the world feel consequential. the distinction is meaningful friction (part of the intended experience) vs. incidental friction (accidental tax with no payoff). cut the incidental; keep the meaningful. removing all friction can also flatten pacing (level-0003 needs rests). audit the path from launch to play and from failure to retry; cut or streamline every step that isn't earning its place. reduce load times (or mask them), skip or shorten repeated cutscenes, trim confirmation dialogs to the genuinely destructive actions, and get respawns fast. ask of each bit of friction: does this add to the experience, or just delay it? keep the meaningful, cut the rest. frictionless design (respect time, maximize flow, remove obstacles) vs. meaningful-friction design (weight, ritual, stakes, and downtime as part of the experience). both are right about different friction; the craft is telling incidental tax from intentional texture. hyper-casual leans frictionless; immersive and deliberate games keep chosen friction. the engagement/respect principle that ties ux to the core loop (sys-0001) and player respect (prog-0004); its meaningful-friction exception connects to pacing (level-0003) and weight (feel-0008). confidence 4."}
{"id":"GDC-L1-MP-0001","title":"Design the social experience, not just the netcode","layer":"L1","domain":"MP","subdomain":"social-dynamics","type":"contextual","confidence":4,"status":"canonical","tags":["multiplayer","social","community","human-interaction"],"related":["GDC-L1-MP-0002","GDC-L1-DESIGN-0001","GDC-L1-MP-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-multiplayer-design"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-MP-0001.md","statement":"In multiplayer games the product is human interaction, not just synchronized state. Design the social experience — how players meet, cooperate, compete, communicate, and relate — deliberately. The other players are the content; the netcode only delivers them.","sections":{"Statement":"> In multiplayer games the product is **human interaction**, not just synchronized state. Design\n> the social experience — how players meet, cooperate, compete, communicate, and relate —\n> deliberately. The other players are the content; the netcode only delivers them.","Rationale":"What players remember about multiplayer games is the *people* — the clutch teammate, the rival,\nthe friend made in a raid, the stranger who was kind or cruel — and those experiences are\nproduced by the game's social systems, not incidentally [S-multiplayer-design]. Treating\nmultiplayer as \"single-player plus networking\" misses that the design object is the *interaction*:\nwhether the game fosters cooperation or hostility, connection or isolation, is a design outcome\n(DESIGN-0001, the experience produced). Matchmaking, communication tools, team structures,\nincentives, and social features all shape what kind of human experience the game creates. The\nnetcode (MP-0004) is necessary infrastructure, but the social design is the actual game.","Applies when":"Any multiplayer game — cooperative, competitive, social, or massively-multiplayer. The more\ncentral other players are to the experience, the more social design dominates.","Does not apply / Exceptions":"Primarily single-player games with thin multiplayer (a leaderboard, an async ghost) have little\nsocial experience to design. And some multiplayer is deliberately anonymous or minimal-contact\n(a background-population feel) — a valid choice, but still a *social* design decision (how much\ncontact), not the absence of one.","Implementation (kept separate from the principle)":"Decide what social experience you want (cooperation? rivalry? community? fleeting encounters?)\nand build the systems that produce it: matchmaking (MP-0003), communication affordances and\nlimits (MP-0002), team and role structures, and incentives that reward the interactions you want.\nDesign against the toxic dynamics your systems could produce (MP-0002). Treat \"how does it feel to\nplay *with people*\" as the core question.","Disagreement":"Rich social design (deep interaction, community, relationships — but heavier design and moderation\ncost) vs. minimal/anonymous multiplayer (lower friction and moderation burden, but thinner human\nexperience). The right amount depends on the game; the point is that it's a *design* choice, made\non purpose.","Notes":"The framing principle of the MP domain; an application of DESIGN-0001 to human interaction, and the\ncontext for behavior design (MP-0002) and matchmaking (MP-0003). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-MP-0001\ntitle: Design the social experience, not just the netcode\nlayer: L1\ndomain: MP\nsubdomain: social-dynamics\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - multiplayer\n  - social\n  - community\n  - human-interaction\nrelated:\n  - GDC-L1-MP-0002\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-MP-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-multiplayer-design\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> In multiplayer games the product is **human interaction**, not just synchronized state. Design\n> the social experience — how players meet, cooperate, compete, communicate, and relate —\n> deliberately. The other players are the content; the netcode only delivers them.\n\n## Rationale\nWhat players remember about multiplayer games is the *people* — the clutch teammate, the rival,\nthe friend made in a raid, the stranger who was kind or cruel — and those experiences are\nproduced by the game's social systems, not incidentally [S-multiplayer-design]. Treating\nmultiplayer as \"single-player plus networking\" misses that the design object is the *interaction*:\nwhether the game fosters cooperation or hostility, connection or isolation, is a design outcome\n(DESIGN-0001, the experience produced). Matchmaking, communication tools, team structures,\nincentives, and social features all shape what kind of human experience the game creates. The\nnetcode (MP-0004) is necessary infrastructure, but the social design is the actual game.\n\n## Applies when\nAny multiplayer game — cooperative, competitive, social, or massively-multiplayer. The more\ncentral other players are to the experience, the more social design dominates.\n\n## Does not apply / Exceptions\nPrimarily single-player games with thin multiplayer (a leaderboard, an async ghost) have little\nsocial experience to design. And some multiplayer is deliberately anonymous or minimal-contact\n(a background-population feel) — a valid choice, but still a *social* design decision (how much\ncontact), not the absence of one.\n\n## Implementation (kept separate from the principle)\nDecide what social experience you want (cooperation? rivalry? community? fleeting encounters?)\nand build the systems that produce it: matchmaking (MP-0003), communication affordances and\nlimits (MP-0002), team and role structures, and incentives that reward the interactions you want.\nDesign against the toxic dynamics your systems could produce (MP-0002). Treat \"how does it feel to\nplay *with people*\" as the core question.\n\n## Disagreement\nRich social design (deep interaction, community, relationships — but heavier design and moderation\ncost) vs. minimal/anonymous multiplayer (lower friction and moderation burden, but thinner human\nexperience). The right amount depends on the game; the point is that it's a *design* choice, made\non purpose.\n\n## Notes\nThe framing principle of the MP domain; an application of DESIGN-0001 to human interaction, and the\ncontext for behavior design (MP-0002) and matchmaking (MP-0003). Confidence 4.\n","searchText":"gdc-l1-mp-0001 design the social experience, not just the netcode multiplayer social community human-interaction > in multiplayer games the product is human interaction, not just synchronized state. design the social experience — how players meet, cooperate, compete, communicate, and relate — deliberately. the other players are the content; the netcode only delivers them. what players remember about multiplayer games is the people — the clutch teammate, the rival, the friend made in a raid, the stranger who was kind or cruel — and those experiences are produced by the game's social systems, not incidentally [s-multiplayer-design]. treating multiplayer as \"single-player plus networking\" misses that the design object is the interaction: whether the game fosters cooperation or hostility, connection or isolation, is a design outcome (design-0001, the experience produced). matchmaking, communication tools, team structures, incentives, and social features all shape what kind of human experience the game creates. the netcode (mp-0004) is necessary infrastructure, but the social design is the actual game. any multiplayer game — cooperative, competitive, social, or massively-multiplayer. the more central other players are to the experience, the more social design dominates. primarily single-player games with thin multiplayer (a leaderboard, an async ghost) have little social experience to design. and some multiplayer is deliberately anonymous or minimal-contact (a background-population feel) — a valid choice, but still a social design decision (how much contact), not the absence of one. decide what social experience you want (cooperation? rivalry? community? fleeting encounters?) and build the systems that produce it: matchmaking (mp-0003), communication affordances and limits (mp-0002), team and role structures, and incentives that reward the interactions you want. design against the toxic dynamics your systems could produce (mp-0002). treat \"how does it feel to play with people\" as the core question. rich social design (deep interaction, community, relationships — but heavier design and moderation cost) vs. minimal/anonymous multiplayer (lower friction and moderation burden, but thinner human experience). the right amount depends on the game; the point is that it's a design choice, made on purpose. the framing principle of the mp domain; an application of design-0001 to human interaction, and the context for behavior design (mp-0002) and matchmaking (mp-0003). confidence 4."}
{"id":"GDC-L1-MP-0002","title":"Behavior is designed — shape the community with systems, don't just moderate it","layer":"L1","domain":"MP","subdomain":"fairness-and-anti-toxicity","type":"contextual","confidence":4,"status":"canonical","tags":["multiplayer","toxicity","community","incentives","moderation"],"related":["GDC-L1-MP-0001","GDC-L1-SYS-0007","GDC-L1-TEAM-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-multiplayer-design"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-MP-0002.md","statement":"Player behavior is partly a design outcome: systems shape whether a community is toxic or welcoming. Design for good behavior — matchmaking, communication affordances and limits, reporting, penalties, and positive incentives — rather than treating toxicity as an inevitable externality to be mopped up after the fact.","sections":{"Statement":"> Player behavior is partly a *design outcome*: systems shape whether a community is toxic or\n> welcoming. Design for good behavior — matchmaking, communication affordances and limits,\n> reporting, penalties, and positive incentives — rather than treating toxicity as an inevitable\n> externality to be mopped up after the fact.","Rationale":"Toxicity isn't purely a property of \"bad players\"; it's strongly influenced by what the game\nincentivizes, permits, and punishes [S-multiplayer-design]. Anonymous, consequence-free\ninteraction with frustrated, mismatched opponents *produces* hostility; systems that add\naccountability (reporting, reputation), reduce frustration (good matchmaking, MP-0003), shape\ncommunication (mute/limit options, positive comms), and penalize harm (e.g. leaving penalties —\n\"a 4v5 is no fun for anybody\") measurably shift behavior. This is the multiplayer form of a\nsystemic truth already in the constitution: players respond to incentives (SYS-0007), so the\ncommunity you get is partly the community you *designed for*. Moderation is necessary, but\ndesigning the conditions that reduce toxicity in the first place is more effective than\npunishing it after.","Applies when":"Any multiplayer game with real player-to-player interaction, especially competitive and\ncommunication-heavy games where toxicity thrives.","Does not apply / Exceptions":"Systems can't eliminate all bad behavior — some moderation and human judgment is always needed,\nand over-restricting communication to prevent toxicity can also strip out the positive social\ncontact that makes multiplayer worthwhile (MP-0001). The balance between open interaction and\nsafety is real. And behavior design must avoid punishing false positives that alienate good\nplayers.","Implementation (kept separate from the principle)":"Reduce the *causes* of toxicity (frustration, mismatch) via matchmaking (MP-0003) and fair play\n(anti-cheat, MP-0004). Add accountability (reporting, reputation, escalating penalties) and\npositive incentives (honor/commend systems). Give players tools to shape their own experience\n(mute, block, communication options). Penalize genuinely harmful acts (quitting, abuse)\nproportionately. Moderate *and* design — don't rely on moderation alone.","Disagreement":"Open communication and freedom (richer social experience, but more toxicity to manage) vs.\nrestricted/managed interaction (safer, but thinner contact). And behavior-shaping via systems vs.\nreactive moderation. Most healthy communities use both design and moderation; the debate is the\nmix and how much to constrain interaction.","Notes":"The community-health principle of MP; the multiplayer application of incentive design (SYS-0007)\nand a social parallel to psychological safety (TEAM-0001) — safe spaces produce better behavior,\nin teams and in player communities alike. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-MP-0002\ntitle: Behavior is designed — shape the community with systems, don't just moderate it\nlayer: L1\ndomain: MP\nsubdomain: fairness-and-anti-toxicity\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - multiplayer\n  - toxicity\n  - community\n  - incentives\n  - moderation\nrelated:\n  - GDC-L1-MP-0001\n  - GDC-L1-SYS-0007\n  - GDC-L1-TEAM-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-multiplayer-design\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Player behavior is partly a *design outcome*: systems shape whether a community is toxic or\n> welcoming. Design for good behavior — matchmaking, communication affordances and limits,\n> reporting, penalties, and positive incentives — rather than treating toxicity as an inevitable\n> externality to be mopped up after the fact.\n\n## Rationale\nToxicity isn't purely a property of \"bad players\"; it's strongly influenced by what the game\nincentivizes, permits, and punishes [S-multiplayer-design]. Anonymous, consequence-free\ninteraction with frustrated, mismatched opponents *produces* hostility; systems that add\naccountability (reporting, reputation), reduce frustration (good matchmaking, MP-0003), shape\ncommunication (mute/limit options, positive comms), and penalize harm (e.g. leaving penalties —\n\"a 4v5 is no fun for anybody\") measurably shift behavior. This is the multiplayer form of a\nsystemic truth already in the constitution: players respond to incentives (SYS-0007), so the\ncommunity you get is partly the community you *designed for*. Moderation is necessary, but\ndesigning the conditions that reduce toxicity in the first place is more effective than\npunishing it after.\n\n## Applies when\nAny multiplayer game with real player-to-player interaction, especially competitive and\ncommunication-heavy games where toxicity thrives.\n\n## Does not apply / Exceptions\nSystems can't eliminate all bad behavior — some moderation and human judgment is always needed,\nand over-restricting communication to prevent toxicity can also strip out the positive social\ncontact that makes multiplayer worthwhile (MP-0001). The balance between open interaction and\nsafety is real. And behavior design must avoid punishing false positives that alienate good\nplayers.\n\n## Implementation (kept separate from the principle)\nReduce the *causes* of toxicity (frustration, mismatch) via matchmaking (MP-0003) and fair play\n(anti-cheat, MP-0004). Add accountability (reporting, reputation, escalating penalties) and\npositive incentives (honor/commend systems). Give players tools to shape their own experience\n(mute, block, communication options). Penalize genuinely harmful acts (quitting, abuse)\nproportionately. Moderate *and* design — don't rely on moderation alone.\n\n## Disagreement\nOpen communication and freedom (richer social experience, but more toxicity to manage) vs.\nrestricted/managed interaction (safer, but thinner contact). And behavior-shaping via systems vs.\nreactive moderation. Most healthy communities use both design and moderation; the debate is the\nmix and how much to constrain interaction.\n\n## Notes\nThe community-health principle of MP; the multiplayer application of incentive design (SYS-0007)\nand a social parallel to psychological safety (TEAM-0001) — safe spaces produce better behavior,\nin teams and in player communities alike. Confidence 4.\n","searchText":"gdc-l1-mp-0002 behavior is designed — shape the community with systems, don't just moderate it multiplayer toxicity community incentives moderation > player behavior is partly a design outcome: systems shape whether a community is toxic or welcoming. design for good behavior — matchmaking, communication affordances and limits, reporting, penalties, and positive incentives — rather than treating toxicity as an inevitable externality to be mopped up after the fact. toxicity isn't purely a property of \"bad players\"; it's strongly influenced by what the game incentivizes, permits, and punishes [s-multiplayer-design]. anonymous, consequence-free interaction with frustrated, mismatched opponents produces hostility; systems that add accountability (reporting, reputation), reduce frustration (good matchmaking, mp-0003), shape communication (mute/limit options, positive comms), and penalize harm (e.g. leaving penalties — \"a 4v5 is no fun for anybody\") measurably shift behavior. this is the multiplayer form of a systemic truth already in the constitution: players respond to incentives (sys-0007), so the community you get is partly the community you designed for. moderation is necessary, but designing the conditions that reduce toxicity in the first place is more effective than punishing it after. any multiplayer game with real player-to-player interaction, especially competitive and communication-heavy games where toxicity thrives. systems can't eliminate all bad behavior — some moderation and human judgment is always needed, and over-restricting communication to prevent toxicity can also strip out the positive social contact that makes multiplayer worthwhile (mp-0001). the balance between open interaction and safety is real. and behavior design must avoid punishing false positives that alienate good players. reduce the causes of toxicity (frustration, mismatch) via matchmaking (mp-0003) and fair play (anti-cheat, mp-0004). add accountability (reporting, reputation, escalating penalties) and positive incentives (honor/commend systems). give players tools to shape their own experience (mute, block, communication options). penalize genuinely harmful acts (quitting, abuse) proportionately. moderate and design — don't rely on moderation alone. open communication and freedom (richer social experience, but more toxicity to manage) vs. restricted/managed interaction (safer, but thinner contact). and behavior-shaping via systems vs. reactive moderation. most healthy communities use both design and moderation; the debate is the mix and how much to constrain interaction. the community-health principle of mp; the multiplayer application of incentive design (sys-0007) and a social parallel to psychological safety (team-0001) — safe spaces produce better behavior, in teams and in player communities alike. confidence 4."}
{"id":"GDC-L1-MP-0003","title":"Fair matchmaking is core design — match by skill and connection","layer":"L1","domain":"MP","subdomain":"matchmaking-design","type":"contextual","confidence":4,"status":"canonical","tags":["multiplayer","matchmaking","fairness","skill","flow"],"related":["GDC-L1-MP-0002","GDC-L1-DESIGN-0004","GDC-L1-BAL-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-multiplayer-design"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-MP-0003.md","statement":"Matchmaking is game design, not plumbing: who a player is matched with largely determines whether a match is fun. Match players by skill (for balanced, engaging contests) and by connection quality (for a fair, playable match). A great game with bad matchmaking delivers bad games.","sections":{"Statement":"> Matchmaking *is* game design, not plumbing: who a player is matched with largely determines\n> whether a match is fun. Match players by skill (for balanced, engaging contests) and by\n> connection quality (for a fair, playable match). A great game with bad matchmaking delivers\n> bad games.","Rationale":"For competitive and many cooperative games, the moment-to-moment experience is produced by the\nmatch, and the match is produced by matchmaking — so a mismatch (a stomp in either direction, a\nlaggy opponent, a broken team) ruins an otherwise-great game [S-multiplayer-design]. Skill-based\nmatching keeps players in the flow channel (DESIGN-0004): fights that are neither trivial nor\nhopeless. Connection-based matching keeps them *fair* (a player shouldn't lose to latency,\nMP-0004). And matchmaking shapes behavior — repeated stomps breed frustration and toxicity\n(MP-0002). Because it so directly governs the experience, matchmaking deserves first-class design\nattention and iteration (informed by player feedback and telemetry), not a set-and-forget\nformula.","Applies when":"Any multiplayer game that pairs or groups players — competitive matches, co-op sessions, ranked\nladders. Most critical in competitive games where fairness and balance are the point.","Does not apply / Exceptions":"Small-population games face a real tension: strict skill/connection matching can mean *no* match\n(long queues), so they must trade match quality against wait time. Social/party play often\n*wants* mismatched skill (friends playing together). And some designs deliberately avoid tight\nmatchmaking (open-world PvP, casual playlists). The principle is strongest for competitive\nintegrity; it bends for population and social goals.","Implementation (kept separate from the principle)":"Match on skill (a rating system) and connection (latency/region), balancing match quality against\nqueue time for your population. Avoid repeated stomps (they breed toxicity, MP-0002). Iterate the\nsystem on player feedback and telemetry (PLAYTEST-0005) — matchmaking is never \"done.\" Handle\nparties and social play as a deliberate exception, not a bug.","Disagreement":"Tight skill/connection matching (fair, balanced matches — but longer queues, harder on small\npopulations) vs. loose/fast matching (short queues, but stomps and unfair matches). Also\nskill-based matchmaking itself is debated in casual contexts (some players want to \"pubstomp\").\nThe balance depends on population size and whether the mode is competitive or casual.","Notes":"The matchmaking principle of MP; connects to flow (DESIGN-0004), fairness/balance (BAL-0002), and\ncommunity health (MP-0002 — good matches reduce toxicity). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-MP-0003\ntitle: Fair matchmaking is core design — match by skill and connection\nlayer: L1\ndomain: MP\nsubdomain: matchmaking-design\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - multiplayer\n  - matchmaking\n  - fairness\n  - skill\n  - flow\nrelated:\n  - GDC-L1-MP-0002\n  - GDC-L1-DESIGN-0004\n  - GDC-L1-BAL-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-multiplayer-design\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Matchmaking *is* game design, not plumbing: who a player is matched with largely determines\n> whether a match is fun. Match players by skill (for balanced, engaging contests) and by\n> connection quality (for a fair, playable match). A great game with bad matchmaking delivers\n> bad games.\n\n## Rationale\nFor competitive and many cooperative games, the moment-to-moment experience is produced by the\nmatch, and the match is produced by matchmaking — so a mismatch (a stomp in either direction, a\nlaggy opponent, a broken team) ruins an otherwise-great game [S-multiplayer-design]. Skill-based\nmatching keeps players in the flow channel (DESIGN-0004): fights that are neither trivial nor\nhopeless. Connection-based matching keeps them *fair* (a player shouldn't lose to latency,\nMP-0004). And matchmaking shapes behavior — repeated stomps breed frustration and toxicity\n(MP-0002). Because it so directly governs the experience, matchmaking deserves first-class design\nattention and iteration (informed by player feedback and telemetry), not a set-and-forget\nformula.\n\n## Applies when\nAny multiplayer game that pairs or groups players — competitive matches, co-op sessions, ranked\nladders. Most critical in competitive games where fairness and balance are the point.\n\n## Does not apply / Exceptions\nSmall-population games face a real tension: strict skill/connection matching can mean *no* match\n(long queues), so they must trade match quality against wait time. Social/party play often\n*wants* mismatched skill (friends playing together). And some designs deliberately avoid tight\nmatchmaking (open-world PvP, casual playlists). The principle is strongest for competitive\nintegrity; it bends for population and social goals.\n\n## Implementation (kept separate from the principle)\nMatch on skill (a rating system) and connection (latency/region), balancing match quality against\nqueue time for your population. Avoid repeated stomps (they breed toxicity, MP-0002). Iterate the\nsystem on player feedback and telemetry (PLAYTEST-0005) — matchmaking is never \"done.\" Handle\nparties and social play as a deliberate exception, not a bug.\n\n## Disagreement\nTight skill/connection matching (fair, balanced matches — but longer queues, harder on small\npopulations) vs. loose/fast matching (short queues, but stomps and unfair matches). Also\nskill-based matchmaking itself is debated in casual contexts (some players want to \"pubstomp\").\nThe balance depends on population size and whether the mode is competitive or casual.\n\n## Notes\nThe matchmaking principle of MP; connects to flow (DESIGN-0004), fairness/balance (BAL-0002), and\ncommunity health (MP-0002 — good matches reduce toxicity). Confidence 4.\n","searchText":"gdc-l1-mp-0003 fair matchmaking is core design — match by skill and connection multiplayer matchmaking fairness skill flow > matchmaking is game design, not plumbing: who a player is matched with largely determines whether a match is fun. match players by skill (for balanced, engaging contests) and by connection quality (for a fair, playable match). a great game with bad matchmaking delivers bad games. for competitive and many cooperative games, the moment-to-moment experience is produced by the match, and the match is produced by matchmaking — so a mismatch (a stomp in either direction, a laggy opponent, a broken team) ruins an otherwise-great game [s-multiplayer-design]. skill-based matching keeps players in the flow channel (design-0004): fights that are neither trivial nor hopeless. connection-based matching keeps them fair (a player shouldn't lose to latency, mp-0004). and matchmaking shapes behavior — repeated stomps breed frustration and toxicity (mp-0002). because it so directly governs the experience, matchmaking deserves first-class design attention and iteration (informed by player feedback and telemetry), not a set-and-forget formula. any multiplayer game that pairs or groups players — competitive matches, co-op sessions, ranked ladders. most critical in competitive games where fairness and balance are the point. small-population games face a real tension: strict skill/connection matching can mean no match (long queues), so they must trade match quality against wait time. social/party play often wants mismatched skill (friends playing together). and some designs deliberately avoid tight matchmaking (open-world pvp, casual playlists). the principle is strongest for competitive integrity; it bends for population and social goals. match on skill (a rating system) and connection (latency/region), balancing match quality against queue time for your population. avoid repeated stomps (they breed toxicity, mp-0002). iterate the system on player feedback and telemetry (playtest-0005) — matchmaking is never \"done.\" handle parties and social play as a deliberate exception, not a bug. tight skill/connection matching (fair, balanced matches — but longer queues, harder on small populations) vs. loose/fast matching (short queues, but stomps and unfair matches). also skill-based matchmaking itself is debated in casual contexts (some players want to \"pubstomp\"). the balance depends on population size and whether the mode is competitive or casual. the matchmaking principle of mp; connects to flow (design-0004), fairness/balance (bal-0002), and community health (mp-0002 — good matches reduce toxicity). confidence 4."}
{"id":"GDC-L1-MP-0004","title":"Trust the server, not the client — assume the network is hostile","layer":"L1","domain":"MP","subdomain":"competitive","type":"contextual","confidence":4,"status":"canonical","tags":["multiplayer","netcode","authoritative-server","anti-cheat","lag-compensation"],"related":["GDC-L1-MP-0003","GDC-L1-ARCH-0006","GDC-L1-FEEL-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-multiplayer-design"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-MP-0004.md","statement":"In networked multiplayer, treat the client as untrusted and the network as hostile. Make the server authoritative over game state, never trust a client's claims, and use lag compensation to keep play fair and responsive despite latency. Fairness and security are designed in, not bolted on.","sections":{"Statement":"> In networked multiplayer, treat the client as untrusted and the network as hostile. Make the\n> **server authoritative** over game state, **never trust a client's claims**, and use lag\n> compensation to keep play fair and responsive despite latency. Fairness and security are\n> designed in, not bolted on.","Rationale":"A client runs on a machine the player controls, so anything the client asserts (I hit, I moved\nthere, I have this item) can be forged — which is why a server-authoritative model, where the\nserver validates and owns the truth, is the foundation of fair networked play\n[S-multiplayer-design]. \"Never trust the client\" limits the cheats possible and protects the\ncompetition (MP-0003's fairness). At the same time, latency is unavoidable, so responsiveness\n(FEEL-0002) must be preserved through techniques like client prediction and server-side lag\ncompensation (rewinding to validate a shot against what the shooter saw) — balancing \"fair to\nthe shooter\" against \"fair to the target.\" These are architectural commitments (authoritative\nstate, ARCH-0006) that shape the whole game and are extremely costly to retrofit.","Applies when":"Any real-time networked multiplayer, especially competitive games where cheating and latency\ndirectly affect outcomes.","Does not apply / Exceptions":"Purely cooperative or low-stakes multiplayer may tolerate more client trust for simplicity\n(peer-to-peer, host-authoritative) — the security bar scales with how much cheating would hurt.\nTurn-based and asynchronous games have weaker real-time constraints. And there are genuine\ntradeoffs in lag compensation (favoring shooter vs. target) with no perfect answer. Full\nserver-authority also has cost (server infrastructure) that small/co-op games may forgo.","Implementation (kept separate from the principle)":"Make the server authoritative over outcomes; validate, don't trust, client input. Use client\nprediction + reconciliation for responsiveness (FEEL-0002) and lag compensation for fairness\nacross latencies. Decide the netcode model (authoritative state, ARCH-0006) *early* — it's\nfoundational. Layer anti-cheat, but rely first on the server-authority architecture. Test under\nreal latency, packet loss, and adversarial clients (QA).","Disagreement":"Server-authoritative (secure, fair, but infrastructure cost and latency-handling complexity) vs.\nclient-trusting/peer-to-peer (cheaper, simpler, but exploitable) — the security bar follows the\nstakes. And within lag compensation, favor-the-shooter vs. favor-the-target is a genuine,\nunresolved fairness tradeoff. Competitive games lean fully authoritative; casual co-op may not.","Notes":"The networking-reality principle of MP; an architectural commitment (authoritative state,\nARCH-0006) that also serves fairness (MP-0003) and responsiveness (FEEL-0002). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-MP-0004\ntitle: Trust the server, not the client — assume the network is hostile\nlayer: L1\ndomain: MP\nsubdomain: competitive\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - multiplayer\n  - netcode\n  - authoritative-server\n  - anti-cheat\n  - lag-compensation\nrelated:\n  - GDC-L1-MP-0003\n  - GDC-L1-ARCH-0006\n  - GDC-L1-FEEL-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-multiplayer-design\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> In networked multiplayer, treat the client as untrusted and the network as hostile. Make the\n> **server authoritative** over game state, **never trust a client's claims**, and use lag\n> compensation to keep play fair and responsive despite latency. Fairness and security are\n> designed in, not bolted on.\n\n## Rationale\nA client runs on a machine the player controls, so anything the client asserts (I hit, I moved\nthere, I have this item) can be forged — which is why a server-authoritative model, where the\nserver validates and owns the truth, is the foundation of fair networked play\n[S-multiplayer-design]. \"Never trust the client\" limits the cheats possible and protects the\ncompetition (MP-0003's fairness). At the same time, latency is unavoidable, so responsiveness\n(FEEL-0002) must be preserved through techniques like client prediction and server-side lag\ncompensation (rewinding to validate a shot against what the shooter saw) — balancing \"fair to\nthe shooter\" against \"fair to the target.\" These are architectural commitments (authoritative\nstate, ARCH-0006) that shape the whole game and are extremely costly to retrofit.\n\n## Applies when\nAny real-time networked multiplayer, especially competitive games where cheating and latency\ndirectly affect outcomes.\n\n## Does not apply / Exceptions\nPurely cooperative or low-stakes multiplayer may tolerate more client trust for simplicity\n(peer-to-peer, host-authoritative) — the security bar scales with how much cheating would hurt.\nTurn-based and asynchronous games have weaker real-time constraints. And there are genuine\ntradeoffs in lag compensation (favoring shooter vs. target) with no perfect answer. Full\nserver-authority also has cost (server infrastructure) that small/co-op games may forgo.\n\n## Implementation (kept separate from the principle)\nMake the server authoritative over outcomes; validate, don't trust, client input. Use client\nprediction + reconciliation for responsiveness (FEEL-0002) and lag compensation for fairness\nacross latencies. Decide the netcode model (authoritative state, ARCH-0006) *early* — it's\nfoundational. Layer anti-cheat, but rely first on the server-authority architecture. Test under\nreal latency, packet loss, and adversarial clients (QA).\n\n## Disagreement\nServer-authoritative (secure, fair, but infrastructure cost and latency-handling complexity) vs.\nclient-trusting/peer-to-peer (cheaper, simpler, but exploitable) — the security bar follows the\nstakes. And within lag compensation, favor-the-shooter vs. favor-the-target is a genuine,\nunresolved fairness tradeoff. Competitive games lean fully authoritative; casual co-op may not.\n\n## Notes\nThe networking-reality principle of MP; an architectural commitment (authoritative state,\nARCH-0006) that also serves fairness (MP-0003) and responsiveness (FEEL-0002). Confidence 4.\n","searchText":"gdc-l1-mp-0004 trust the server, not the client — assume the network is hostile multiplayer netcode authoritative-server anti-cheat lag-compensation > in networked multiplayer, treat the client as untrusted and the network as hostile. make the server authoritative over game state, never trust a client's claims, and use lag compensation to keep play fair and responsive despite latency. fairness and security are designed in, not bolted on. a client runs on a machine the player controls, so anything the client asserts (i hit, i moved there, i have this item) can be forged — which is why a server-authoritative model, where the server validates and owns the truth, is the foundation of fair networked play [s-multiplayer-design]. \"never trust the client\" limits the cheats possible and protects the competition (mp-0003's fairness). at the same time, latency is unavoidable, so responsiveness (feel-0002) must be preserved through techniques like client prediction and server-side lag compensation (rewinding to validate a shot against what the shooter saw) — balancing \"fair to the shooter\" against \"fair to the target.\" these are architectural commitments (authoritative state, arch-0006) that shape the whole game and are extremely costly to retrofit. any real-time networked multiplayer, especially competitive games where cheating and latency directly affect outcomes. purely cooperative or low-stakes multiplayer may tolerate more client trust for simplicity (peer-to-peer, host-authoritative) — the security bar scales with how much cheating would hurt. turn-based and asynchronous games have weaker real-time constraints. and there are genuine tradeoffs in lag compensation (favoring shooter vs. target) with no perfect answer. full server-authority also has cost (server infrastructure) that small/co-op games may forgo. make the server authoritative over outcomes; validate, don't trust, client input. use client prediction + reconciliation for responsiveness (feel-0002) and lag compensation for fairness across latencies. decide the netcode model (authoritative state, arch-0006) early — it's foundational. layer anti-cheat, but rely first on the server-authority architecture. test under real latency, packet loss, and adversarial clients (qa). server-authoritative (secure, fair, but infrastructure cost and latency-handling complexity) vs. client-trusting/peer-to-peer (cheaper, simpler, but exploitable) — the security bar follows the stakes. and within lag compensation, favor-the-shooter vs. favor-the-target is a genuine, unresolved fairness tradeoff. competitive games lean fully authoritative; casual co-op may not. the networking-reality principle of mp; an architectural commitment (authoritative state, arch-0006) that also serves fairness (mp-0003) and responsiveness (feel-0002). confidence 4."}
{"id":"GDC-L1-MP-0005","title":"Design for the players who actually show up","layer":"L1","domain":"MP","subdomain":"community","type":"contextual","confidence":3,"status":"canonical","tags":["multiplayer","community","population","resilience","griefers"],"related":["GDC-L1-MP-0001","GDC-L1-MP-0002","GDC-L1-SYS-0007"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-multiplayer-design"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-MP-0005.md","statement":"Design multiplayer for the real population, not an idealized one: uneven skill and numbers, off-peak hours, disconnects, AFKers, griefers, and a community with its own culture. The game must stay good when the lobby isn't perfect — because it rarely will be.","sections":{"Statement":"> Design multiplayer for the *real* population, not an idealized one: uneven skill and numbers,\n> off-peak hours, disconnects, AFKers, griefers, and a community with its own culture. The game\n> must stay good when the lobby isn't perfect — because it rarely will be.","Rationale":"Multiplayer designs quietly assume full, balanced, well-behaved lobbies, and then reality\ndelivers a 4v5 after a disconnect, a lopsided skill spread at 3am, a griefer, or a dwindling\noff-hours population [S-multiplayer-design]. Systems that only work under ideal conditions fail\nconstantly in practice. Robust multiplayer plans for the imperfect case: backfill and surrender\noptions for abandoned matches, bots or scaling for thin populations, penalties and safeguards for\ngriefing and quitting (MP-0002), and graceful handling of disconnects. Players also form a\n*community* with emergent norms and their own optimization pressure (SYS-0007) — anticipate that\nthey'll find the exploits and the antisocial edges, and design so the common, messy reality still\nproduces good games.","Applies when":"Any multiplayer game, especially those depending on healthy populations and fair lobbies —\ncompetitive, session-based, and community-driven games.","Does not apply / Exceptions":"Games with guaranteed full, curated lobbies (private matches, esports, tightly-managed sessions)\nface less of this. Very large, always-populated games have more slack. But even they hit off-peak\nand adversarial conditions eventually. The principle scales with how much the game depends on\nother players cooperating.","Implementation (kept separate from the principle)":"Plan for imperfect lobbies: backfill, surrender/forfeit, disconnect handling, bot or scaling\nsupport for thin populations, and anti-griefing/quitting safeguards (MP-0002). Watch the real\ncommunity's behavior and norms, and design against the antisocial edges players will find\n(SYS-0007). Test with realistic, adversarial, and under-populated conditions, not just ideal\nones.","Disagreement":"Robustness-for-the-real-population (resilient, but more systems to build) vs. design-for-the-happy\n-path (simpler, but brittle in practice). Also how much to spend accommodating small/off-peak\npopulations vs. focusing on peak. The right investment tracks how central healthy lobbies are to\nthe experience.","Notes":"The resilience/community principle of MP; extends behavior design (MP-0002) and optimization\npressure (SYS-0007) to the messy reality of live populations. Confidence 3 — clearly wise, but\nhow much to invest is highly game- and population-dependent."},"rawMarkdown":"---\nid: GDC-L1-MP-0005\ntitle: Design for the players who actually show up\nlayer: L1\ndomain: MP\nsubdomain: community\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - multiplayer\n  - community\n  - population\n  - resilience\n  - griefers\nrelated:\n  - GDC-L1-MP-0001\n  - GDC-L1-MP-0002\n  - GDC-L1-SYS-0007\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-multiplayer-design\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Design multiplayer for the *real* population, not an idealized one: uneven skill and numbers,\n> off-peak hours, disconnects, AFKers, griefers, and a community with its own culture. The game\n> must stay good when the lobby isn't perfect — because it rarely will be.\n\n## Rationale\nMultiplayer designs quietly assume full, balanced, well-behaved lobbies, and then reality\ndelivers a 4v5 after a disconnect, a lopsided skill spread at 3am, a griefer, or a dwindling\noff-hours population [S-multiplayer-design]. Systems that only work under ideal conditions fail\nconstantly in practice. Robust multiplayer plans for the imperfect case: backfill and surrender\noptions for abandoned matches, bots or scaling for thin populations, penalties and safeguards for\ngriefing and quitting (MP-0002), and graceful handling of disconnects. Players also form a\n*community* with emergent norms and their own optimization pressure (SYS-0007) — anticipate that\nthey'll find the exploits and the antisocial edges, and design so the common, messy reality still\nproduces good games.\n\n## Applies when\nAny multiplayer game, especially those depending on healthy populations and fair lobbies —\ncompetitive, session-based, and community-driven games.\n\n## Does not apply / Exceptions\nGames with guaranteed full, curated lobbies (private matches, esports, tightly-managed sessions)\nface less of this. Very large, always-populated games have more slack. But even they hit off-peak\nand adversarial conditions eventually. The principle scales with how much the game depends on\nother players cooperating.\n\n## Implementation (kept separate from the principle)\nPlan for imperfect lobbies: backfill, surrender/forfeit, disconnect handling, bot or scaling\nsupport for thin populations, and anti-griefing/quitting safeguards (MP-0002). Watch the real\ncommunity's behavior and norms, and design against the antisocial edges players will find\n(SYS-0007). Test with realistic, adversarial, and under-populated conditions, not just ideal\nones.\n\n## Disagreement\nRobustness-for-the-real-population (resilient, but more systems to build) vs. design-for-the-happy\n-path (simpler, but brittle in practice). Also how much to spend accommodating small/off-peak\npopulations vs. focusing on peak. The right investment tracks how central healthy lobbies are to\nthe experience.\n\n## Notes\nThe resilience/community principle of MP; extends behavior design (MP-0002) and optimization\npressure (SYS-0007) to the messy reality of live populations. Confidence 3 — clearly wise, but\nhow much to invest is highly game- and population-dependent.\n","searchText":"gdc-l1-mp-0005 design for the players who actually show up multiplayer community population resilience griefers > design multiplayer for the real population, not an idealized one: uneven skill and numbers, off-peak hours, disconnects, afkers, griefers, and a community with its own culture. the game must stay good when the lobby isn't perfect — because it rarely will be. multiplayer designs quietly assume full, balanced, well-behaved lobbies, and then reality delivers a 4v5 after a disconnect, a lopsided skill spread at 3am, a griefer, or a dwindling off-hours population [s-multiplayer-design]. systems that only work under ideal conditions fail constantly in practice. robust multiplayer plans for the imperfect case: backfill and surrender options for abandoned matches, bots or scaling for thin populations, penalties and safeguards for griefing and quitting (mp-0002), and graceful handling of disconnects. players also form a community with emergent norms and their own optimization pressure (sys-0007) — anticipate that they'll find the exploits and the antisocial edges, and design so the common, messy reality still produces good games. any multiplayer game, especially those depending on healthy populations and fair lobbies — competitive, session-based, and community-driven games. games with guaranteed full, curated lobbies (private matches, esports, tightly-managed sessions) face less of this. very large, always-populated games have more slack. but even they hit off-peak and adversarial conditions eventually. the principle scales with how much the game depends on other players cooperating. plan for imperfect lobbies: backfill, surrender/forfeit, disconnect handling, bot or scaling support for thin populations, and anti-griefing/quitting safeguards (mp-0002). watch the real community's behavior and norms, and design against the antisocial edges players will find (sys-0007). test with realistic, adversarial, and under-populated conditions, not just ideal ones. robustness-for-the-real-population (resilient, but more systems to build) vs. design-for-the-happy -path (simpler, but brittle in practice). also how much to spend accommodating small/off-peak populations vs. focusing on peak. the right investment tracks how central healthy lobbies are to the experience. the resilience/community principle of mp; extends behavior design (mp-0002) and optimization pressure (sys-0007) to the messy reality of live populations. confidence 3 — clearly wise, but how much to invest is highly game- and population-dependent."}
{"id":"GDC-L1-MON-0001","title":"Choose a monetization model that fits the game and is honest about the deal","layer":"L1","domain":"MON","subdomain":"models","type":"contextual","confidence":4,"status":"canonical","tags":["monetization","business-model","ethics","honesty"],"related":["GDC-L1-MON-0002","GDC-L1-DESIGN-0001","GDC-L1-PROG-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-monetization-ethics"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-MON-0001.md","statement":"Pick a monetization model — premium, free-to-play, subscription, expansions, cosmetics — that fits the game's design and audience, and be honest with the player about the deal they're getting. The model is a design decision with ethical weight, not a bolt-on afterthought.","sections":{"Statement":"> Pick a monetization model — premium, free-to-play, subscription, expansions, cosmetics —\n> that fits the game's design and audience, and be honest with the player about the deal\n> they're getting. The model is a design decision with ethical weight, not a bolt-on\n> afterthought.","Rationale":"Monetization shapes design: a free-to-play game's economy, pacing, and retention loops are\nbuilt around its business model, so choosing the model *after* the design tends to graft\nextractive mechanics onto a game that wasn't built for them [S-monetization-ethics]. Different\nmodels fit different games — premium suits a finite, authored experience; F2P suits broad-reach\nlive games; subscription suits ongoing services — and forcing a mismatched model distorts the\ndesign (DESIGN-0001: the model becomes part of the experience produced). The honesty clause is\nthe ethical core: players should understand what's free, what costs money, and what they're\nbuying, up front. A model chosen to fit the game and communicated plainly earns trust; one\nchosen to maximize extraction and obscured erodes it.","Applies when":"Any commercial game — the model should be considered early, alongside the design, not tacked on\nnear launch.","Does not apply / Exceptions":"Non-commercial, free, or art games may have no monetization to design. And the \"right\" model is\ngenuinely game-dependent — there's no universally superior choice (premium vs. F2P is a real\nstrategic decision, not a moral hierarchy). The invariant is *fit and honesty*, not a particular\nmodel.","Implementation (kept separate from the principle)":"Decide the model early and design the game and its economy (ECON) coherently around it. State\nthe deal plainly (what's free, what's paid, whether there's randomness — MON-0005). Prefer models\nwhere the player's interests and the revenue align (MON-0002) over models that pit them against\neach other. Revisit if the design and model drift apart.","Disagreement":"Premium (one honest purchase, aligned incentives, smaller reach) vs. free-to-play (broad reach,\nongoing revenue, but strong temptation toward extractive mechanics) vs. subscription — a genuine\nstrategic choice with different ethical hazards. This constitution takes no position on *which*\nmodel, only that it fit the game and be honest.","Notes":"The framing principle of the MON domain; ties to ECON (the model shapes the economy), DESIGN-0001\n(the model is part of the experience), and the ethics thread (PROG-0004, MON-0002/0003).\nConfidence 4."},"rawMarkdown":"---\nid: GDC-L1-MON-0001\ntitle: Choose a monetization model that fits the game and is honest about the deal\nlayer: L1\ndomain: MON\nsubdomain: models\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - monetization\n  - business-model\n  - ethics\n  - honesty\nrelated:\n  - GDC-L1-MON-0002\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-PROG-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-monetization-ethics\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Pick a monetization model — premium, free-to-play, subscription, expansions, cosmetics —\n> that fits the game's design and audience, and be honest with the player about the deal\n> they're getting. The model is a design decision with ethical weight, not a bolt-on\n> afterthought.\n\n## Rationale\nMonetization shapes design: a free-to-play game's economy, pacing, and retention loops are\nbuilt around its business model, so choosing the model *after* the design tends to graft\nextractive mechanics onto a game that wasn't built for them [S-monetization-ethics]. Different\nmodels fit different games — premium suits a finite, authored experience; F2P suits broad-reach\nlive games; subscription suits ongoing services — and forcing a mismatched model distorts the\ndesign (DESIGN-0001: the model becomes part of the experience produced). The honesty clause is\nthe ethical core: players should understand what's free, what costs money, and what they're\nbuying, up front. A model chosen to fit the game and communicated plainly earns trust; one\nchosen to maximize extraction and obscured erodes it.\n\n## Applies when\nAny commercial game — the model should be considered early, alongside the design, not tacked on\nnear launch.\n\n## Does not apply / Exceptions\nNon-commercial, free, or art games may have no monetization to design. And the \"right\" model is\ngenuinely game-dependent — there's no universally superior choice (premium vs. F2P is a real\nstrategic decision, not a moral hierarchy). The invariant is *fit and honesty*, not a particular\nmodel.\n\n## Implementation (kept separate from the principle)\nDecide the model early and design the game and its economy (ECON) coherently around it. State\nthe deal plainly (what's free, what's paid, whether there's randomness — MON-0005). Prefer models\nwhere the player's interests and the revenue align (MON-0002) over models that pit them against\neach other. Revisit if the design and model drift apart.\n\n## Disagreement\nPremium (one honest purchase, aligned incentives, smaller reach) vs. free-to-play (broad reach,\nongoing revenue, but strong temptation toward extractive mechanics) vs. subscription — a genuine\nstrategic choice with different ethical hazards. This constitution takes no position on *which*\nmodel, only that it fit the game and be honest.\n\n## Notes\nThe framing principle of the MON domain; ties to ECON (the model shapes the economy), DESIGN-0001\n(the model is part of the experience), and the ethics thread (PROG-0004, MON-0002/0003).\nConfidence 4.\n","searchText":"gdc-l1-mon-0001 choose a monetization model that fits the game and is honest about the deal monetization business-model ethics honesty > pick a monetization model — premium, free-to-play, subscription, expansions, cosmetics — that fits the game's design and audience, and be honest with the player about the deal they're getting. the model is a design decision with ethical weight, not a bolt-on afterthought. monetization shapes design: a free-to-play game's economy, pacing, and retention loops are built around its business model, so choosing the model after the design tends to graft extractive mechanics onto a game that wasn't built for them [s-monetization-ethics]. different models fit different games — premium suits a finite, authored experience; f2p suits broad-reach live games; subscription suits ongoing services — and forcing a mismatched model distorts the design (design-0001: the model becomes part of the experience produced). the honesty clause is the ethical core: players should understand what's free, what costs money, and what they're buying, up front. a model chosen to fit the game and communicated plainly earns trust; one chosen to maximize extraction and obscured erodes it. any commercial game — the model should be considered early, alongside the design, not tacked on near launch. non-commercial, free, or art games may have no monetization to design. and the \"right\" model is genuinely game-dependent — there's no universally superior choice (premium vs. f2p is a real strategic decision, not a moral hierarchy). the invariant is fit and honesty, not a particular model. decide the model early and design the game and its economy (econ) coherently around it. state the deal plainly (what's free, what's paid, whether there's randomness — mon-0005). prefer models where the player's interests and the revenue align (mon-0002) over models that pit them against each other. revisit if the design and model drift apart. premium (one honest purchase, aligned incentives, smaller reach) vs. free-to-play (broad reach, ongoing revenue, but strong temptation toward extractive mechanics) vs. subscription — a genuine strategic choice with different ethical hazards. this constitution takes no position on which model, only that it fit the game and be honest. the framing principle of the mon domain; ties to econ (the model shapes the economy), design-0001 (the model is part of the experience), and the ethics thread (prog-0004, mon-0002/0003). confidence 4."}
{"id":"GDC-L1-MON-0002","title":"Trade fair value — monetization should add value, not manufacture problems to sell relief","layer":"L1","domain":"MON","subdomain":"value-exchange","type":"contextual","confidence":4,"status":"canonical","tags":["monetization","value-exchange","ethics","player-respect"],"related":["GDC-L1-MON-0003","GDC-L1-PROG-0004","GDC-L1-UX-0007"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-monetization-ethics"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-MON-0002.md","statement":"Monetization should give the player something they genuinely value in fair exchange for money — content, cosmetics, convenience, expression. It should add value, not manufacture a problem (artificial grind, imposed friction, withheld fun) in order to sell the relief.","sections":{"Statement":"> Monetization should give the player something they genuinely value in fair exchange for\n> money — content, cosmetics, convenience, expression. It should *add* value, not manufacture\n> a problem (artificial grind, imposed friction, withheld fun) in order to sell the relief.","Rationale":"There are two fundamentally different ways to make money from a game: sell things that make the\nexperience *better* (new content, cosmetics, quality-of-life), or degrade the experience and\nsell the fix (padding the grind so players pay to skip it, adding friction so players pay to\nremove it) [S-monetization-ethics]. The first is a fair value exchange that aligns the\nstudio's and player's interests; the second pits them against each other and treats the player\nas a mark. The difference is felt: players reward games that respect them and resent games that\nhold fun hostage. This is the monetization face of respecting the player (PROG-0004) and\nminimizing manufactured friction (UX-0007) — the friction here is imposed *specifically* to be\nsold back.","Applies when":"Any paid content or transaction — DLC, cosmetics, battle passes, convenience purchases, currency.","Does not apply / Exceptions":"Some friction is legitimate design, not a manufactured paywall (a grind that's fun on its own,\na time-cost that creates meaning); the line is whether the friction exists *to be sold*.\nConvenience purchases (skip the grind) can be fair when the grind is optional and the game is\nfun without paying — the abuse is *building* the grind to force the sale. Genuinely generous\nfree experiences with optional paid extras are the healthy end of this.","Implementation (kept separate from the principle)":"Audit each monetization hook: does it add value, or does it create a problem the purchase\nsolves? Keep the free/base experience genuinely good on its own (so paying is a bonus, not a\nransom — echoes PROG-0004). Sell content, expression, and true convenience; don't engineer\ntedium or friction to monetize its removal. Ask whether players would feel *respected* or\n*exploited* on reflection.","Disagreement":"Value-add monetization (aligned incentives, sustainable goodwill) vs. friction/relief\nmonetization (higher short-term revenue, player resentment). The engagement/revenue-maximization\ncase is that these techniques demonstrably work and players opt in; the player-respect case\n(this constitution's lean) is that manufacturing problems to sell relief exploits rather than\nserves. A real, ongoing industry values split.","Notes":"The value-exchange ethic of MON; the monetization form of PROG-0004 (intrinsic-over-treadmill)\nand UX-0007 (don't manufacture friction). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-MON-0002\ntitle: Trade fair value — monetization should add value, not manufacture problems to sell relief\nlayer: L1\ndomain: MON\nsubdomain: value-exchange\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - monetization\n  - value-exchange\n  - ethics\n  - player-respect\nrelated:\n  - GDC-L1-MON-0003\n  - GDC-L1-PROG-0004\n  - GDC-L1-UX-0007\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-monetization-ethics\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Monetization should give the player something they genuinely value in fair exchange for\n> money — content, cosmetics, convenience, expression. It should *add* value, not manufacture\n> a problem (artificial grind, imposed friction, withheld fun) in order to sell the relief.\n\n## Rationale\nThere are two fundamentally different ways to make money from a game: sell things that make the\nexperience *better* (new content, cosmetics, quality-of-life), or degrade the experience and\nsell the fix (padding the grind so players pay to skip it, adding friction so players pay to\nremove it) [S-monetization-ethics]. The first is a fair value exchange that aligns the\nstudio's and player's interests; the second pits them against each other and treats the player\nas a mark. The difference is felt: players reward games that respect them and resent games that\nhold fun hostage. This is the monetization face of respecting the player (PROG-0004) and\nminimizing manufactured friction (UX-0007) — the friction here is imposed *specifically* to be\nsold back.\n\n## Applies when\nAny paid content or transaction — DLC, cosmetics, battle passes, convenience purchases, currency.\n\n## Does not apply / Exceptions\nSome friction is legitimate design, not a manufactured paywall (a grind that's fun on its own,\na time-cost that creates meaning); the line is whether the friction exists *to be sold*.\nConvenience purchases (skip the grind) can be fair when the grind is optional and the game is\nfun without paying — the abuse is *building* the grind to force the sale. Genuinely generous\nfree experiences with optional paid extras are the healthy end of this.\n\n## Implementation (kept separate from the principle)\nAudit each monetization hook: does it add value, or does it create a problem the purchase\nsolves? Keep the free/base experience genuinely good on its own (so paying is a bonus, not a\nransom — echoes PROG-0004). Sell content, expression, and true convenience; don't engineer\ntedium or friction to monetize its removal. Ask whether players would feel *respected* or\n*exploited* on reflection.\n\n## Disagreement\nValue-add monetization (aligned incentives, sustainable goodwill) vs. friction/relief\nmonetization (higher short-term revenue, player resentment). The engagement/revenue-maximization\ncase is that these techniques demonstrably work and players opt in; the player-respect case\n(this constitution's lean) is that manufacturing problems to sell relief exploits rather than\nserves. A real, ongoing industry values split.\n\n## Notes\nThe value-exchange ethic of MON; the monetization form of PROG-0004 (intrinsic-over-treadmill)\nand UX-0007 (don't manufacture friction). Confidence 4.\n","searchText":"gdc-l1-mon-0002 trade fair value — monetization should add value, not manufacture problems to sell relief monetization value-exchange ethics player-respect > monetization should give the player something they genuinely value in fair exchange for money — content, cosmetics, convenience, expression. it should add value, not manufacture a problem (artificial grind, imposed friction, withheld fun) in order to sell the relief. there are two fundamentally different ways to make money from a game: sell things that make the experience better (new content, cosmetics, quality-of-life), or degrade the experience and sell the fix (padding the grind so players pay to skip it, adding friction so players pay to remove it) [s-monetization-ethics]. the first is a fair value exchange that aligns the studio's and player's interests; the second pits them against each other and treats the player as a mark. the difference is felt: players reward games that respect them and resent games that hold fun hostage. this is the monetization face of respecting the player (prog-0004) and minimizing manufactured friction (ux-0007) — the friction here is imposed specifically to be sold back. any paid content or transaction — dlc, cosmetics, battle passes, convenience purchases, currency. some friction is legitimate design, not a manufactured paywall (a grind that's fun on its own, a time-cost that creates meaning); the line is whether the friction exists to be sold. convenience purchases (skip the grind) can be fair when the grind is optional and the game is fun without paying — the abuse is building the grind to force the sale. genuinely generous free experiences with optional paid extras are the healthy end of this. audit each monetization hook: does it add value, or does it create a problem the purchase solves? keep the free/base experience genuinely good on its own (so paying is a bonus, not a ransom — echoes prog-0004). sell content, expression, and true convenience; don't engineer tedium or friction to monetize its removal. ask whether players would feel respected or exploited on reflection. value-add monetization (aligned incentives, sustainable goodwill) vs. friction/relief monetization (higher short-term revenue, player resentment). the engagement/revenue-maximization case is that these techniques demonstrably work and players opt in; the player-respect case (this constitution's lean) is that manufacturing problems to sell relief exploits rather than serves. a real, ongoing industry values split. the value-exchange ethic of mon; the monetization form of prog-0004 (intrinsic-over-treadmill) and ux-0007 (don't manufacture friction). confidence 4."}
{"id":"GDC-L1-MON-0003","title":"Refuse dark patterns — don't exploit cognitive biases to extract spending","layer":"L1","domain":"MON","subdomain":"dark-patterns-to-avoid","type":"contextual","confidence":4,"status":"canonical","tags":["monetization","dark-patterns","ethics","wellbeing","manipulation"],"related":["GDC-L1-MON-0002","GDC-L1-PROG-0004","GDC-L1-UX-0006"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-monetization-ethics"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-MON-0003.md","statement":"Do not use dark patterns — manipulative designs that exploit cognitive biases to get players to spend in ways they wouldn't on reflection. Artificial urgency (FOMO timers), sunk-cost and loss-aversion traps, obscured real costs (opaque currencies, layered conversions), and reward-anticipation loops belong on a refuse-list, not a design doc.","sections":{"Statement":"> Do not use dark patterns — manipulative designs that exploit cognitive biases to get players\n> to spend in ways they wouldn't on reflection. Artificial urgency (FOMO timers), sunk-cost and\n> loss-aversion traps, obscured real costs (opaque currencies, layered conversions), and\n> reward-anticipation loops belong on a refuse-list, not a design doc.","Rationale":"Dark patterns work by *overriding* the player's judgment rather than earning their choice: they\nweaponize well-documented biases — loss aversion, the sunk-cost fallacy, reward anticipation,\nsocial pressure — and obscure information (the true cost to obtain a reward) so the player can't\ndecide rationally [S-monetization-ethics]. This is exploitation, not persuasion, and it is most\nharmful to those least able to resist it — younger players and people vulnerable to compulsion.\nIt is the monetization extreme of everything the constitution warns against: manufactured\ncompulsion (PROG-0004), imposed friction (UX-0007), and the opposite of clear, honest\ncommunication (UX-0003, MON-0005). Beyond the ethics, it is increasingly a *legal* risk —\nregulators have fined publishers for undisclosed odds and disguised paywalls.","Applies when":"Any monetization surface — stores, currencies, offers, loot mechanics, timers, bundles.","Does not apply / Exceptions":"Not every persuasive technique is a dark pattern — a genuinely limited-time cosmetic, a clearly-\npriced bundle, or an honestly-communicated sale is legitimate marketing. The line is\n*manipulation and concealment*: exploiting bias and hiding true cost is the abuse; clear,\nhonest offers are fine. Intent and transparency separate persuasion from a dark pattern.","Implementation (kept separate from the principle)":"Keep a refuse-list: no fake scarcity/urgency, no obscured real-money cost, no currency mazes\ndesigned to hide value, no compulsion loops (loss-aversion streaks), no predatory targeting of\nspenders or minors. Show true costs and odds plainly (MON-0005). Design offers you'd be\ncomfortable explaining to the player's face. Take extra care where minors may play (UX-0006's\nduty-of-care spirit extends here).","Disagreement":"Engagement/revenue-optimization argues these techniques are effective, widely used, and that\nadults opt in freely; the player-respect/wellbeing position (this constitution's, and\nincreasingly regulators') is that exploiting cognitive bias and concealing cost is manipulation\nthat harms players, especially the vulnerable. This is a genuine, live industry and legal\ndispute — but the manipulation-and-concealment core is what this principle refuses.","Notes":"The sharpest ethics principle in the MON domain, with legal as well as moral stakes; the extreme\ncase of PROG-0004 (compulsion) and the opposite of honest communication (MON-0005, UX-0003).\nConfidence 4."},"rawMarkdown":"---\nid: GDC-L1-MON-0003\ntitle: Refuse dark patterns — don't exploit cognitive biases to extract spending\nlayer: L1\ndomain: MON\nsubdomain: dark-patterns-to-avoid\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - monetization\n  - dark-patterns\n  - ethics\n  - wellbeing\n  - manipulation\nrelated:\n  - GDC-L1-MON-0002\n  - GDC-L1-PROG-0004\n  - GDC-L1-UX-0006\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-monetization-ethics\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Do not use dark patterns — manipulative designs that exploit cognitive biases to get players\n> to spend in ways they wouldn't on reflection. Artificial urgency (FOMO timers), sunk-cost and\n> loss-aversion traps, obscured real costs (opaque currencies, layered conversions), and\n> reward-anticipation loops belong on a refuse-list, not a design doc.\n\n## Rationale\nDark patterns work by *overriding* the player's judgment rather than earning their choice: they\nweaponize well-documented biases — loss aversion, the sunk-cost fallacy, reward anticipation,\nsocial pressure — and obscure information (the true cost to obtain a reward) so the player can't\ndecide rationally [S-monetization-ethics]. This is exploitation, not persuasion, and it is most\nharmful to those least able to resist it — younger players and people vulnerable to compulsion.\nIt is the monetization extreme of everything the constitution warns against: manufactured\ncompulsion (PROG-0004), imposed friction (UX-0007), and the opposite of clear, honest\ncommunication (UX-0003, MON-0005). Beyond the ethics, it is increasingly a *legal* risk —\nregulators have fined publishers for undisclosed odds and disguised paywalls.\n\n## Applies when\nAny monetization surface — stores, currencies, offers, loot mechanics, timers, bundles.\n\n## Does not apply / Exceptions\nNot every persuasive technique is a dark pattern — a genuinely limited-time cosmetic, a clearly-\npriced bundle, or an honestly-communicated sale is legitimate marketing. The line is\n*manipulation and concealment*: exploiting bias and hiding true cost is the abuse; clear,\nhonest offers are fine. Intent and transparency separate persuasion from a dark pattern.\n\n## Implementation (kept separate from the principle)\nKeep a refuse-list: no fake scarcity/urgency, no obscured real-money cost, no currency mazes\ndesigned to hide value, no compulsion loops (loss-aversion streaks), no predatory targeting of\nspenders or minors. Show true costs and odds plainly (MON-0005). Design offers you'd be\ncomfortable explaining to the player's face. Take extra care where minors may play (UX-0006's\nduty-of-care spirit extends here).\n\n## Disagreement\nEngagement/revenue-optimization argues these techniques are effective, widely used, and that\nadults opt in freely; the player-respect/wellbeing position (this constitution's, and\nincreasingly regulators') is that exploiting cognitive bias and concealing cost is manipulation\nthat harms players, especially the vulnerable. This is a genuine, live industry and legal\ndispute — but the manipulation-and-concealment core is what this principle refuses.\n\n## Notes\nThe sharpest ethics principle in the MON domain, with legal as well as moral stakes; the extreme\ncase of PROG-0004 (compulsion) and the opposite of honest communication (MON-0005, UX-0003).\nConfidence 4.\n","searchText":"gdc-l1-mon-0003 refuse dark patterns — don't exploit cognitive biases to extract spending monetization dark-patterns ethics wellbeing manipulation > do not use dark patterns — manipulative designs that exploit cognitive biases to get players to spend in ways they wouldn't on reflection. artificial urgency (fomo timers), sunk-cost and loss-aversion traps, obscured real costs (opaque currencies, layered conversions), and reward-anticipation loops belong on a refuse-list, not a design doc. dark patterns work by overriding the player's judgment rather than earning their choice: they weaponize well-documented biases — loss aversion, the sunk-cost fallacy, reward anticipation, social pressure — and obscure information (the true cost to obtain a reward) so the player can't decide rationally [s-monetization-ethics]. this is exploitation, not persuasion, and it is most harmful to those least able to resist it — younger players and people vulnerable to compulsion. it is the monetization extreme of everything the constitution warns against: manufactured compulsion (prog-0004), imposed friction (ux-0007), and the opposite of clear, honest communication (ux-0003, mon-0005). beyond the ethics, it is increasingly a legal risk — regulators have fined publishers for undisclosed odds and disguised paywalls. any monetization surface — stores, currencies, offers, loot mechanics, timers, bundles. not every persuasive technique is a dark pattern — a genuinely limited-time cosmetic, a clearly- priced bundle, or an honestly-communicated sale is legitimate marketing. the line is manipulation and concealment: exploiting bias and hiding true cost is the abuse; clear, honest offers are fine. intent and transparency separate persuasion from a dark pattern. keep a refuse-list: no fake scarcity/urgency, no obscured real-money cost, no currency mazes designed to hide value, no compulsion loops (loss-aversion streaks), no predatory targeting of spenders or minors. show true costs and odds plainly (mon-0005). design offers you'd be comfortable explaining to the player's face. take extra care where minors may play (ux-0006's duty-of-care spirit extends here). engagement/revenue-optimization argues these techniques are effective, widely used, and that adults opt in freely; the player-respect/wellbeing position (this constitution's, and increasingly regulators') is that exploiting cognitive bias and concealing cost is manipulation that harms players, especially the vulnerable. this is a genuine, live industry and legal dispute — but the manipulation-and-concealment core is what this principle refuses. the sharpest ethics principle in the mon domain, with legal as well as moral stakes; the extreme case of prog-0004 (compulsion) and the opposite of honest communication (mon-0005, ux-0003). confidence 4."}
{"id":"GDC-L1-MON-0004","title":"Keep pay out of \"win\" — sell expression and convenience, not competitive power","layer":"L1","domain":"MON","subdomain":"models","type":"stylistic","confidence":3,"status":"canonical","tags":["monetization","pay-to-win","fairness","cosmetics","competitive"],"related":["GDC-L1-MON-0002","GDC-L1-BAL-0001","GDC-L1-MP-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-monetization-ethics"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-MON-0004.md","statement":"In games where players compete or share a world, prefer selling cosmetics, expression, and (optional) convenience over selling competitive power. \"Pay-to-win\" — where money buys a gameplay advantage others must match with cash or grind — corrodes fairness and the trust the competition depends on.","sections":{"Statement":"> In games where players compete or share a world, prefer selling **cosmetics, expression, and\n> (optional) convenience** over selling **competitive power**. \"Pay-to-win\" — where money buys a\n> gameplay advantage others must match with cash or grind — corrodes fairness and the trust the\n> competition depends on.","Rationale":"There is a meaningful ethical and design line between cosmetic purchases and purchases that\naffect gameplay outcomes in a shared or competitive game [S-monetization-ethics]. When money\nbuys power, the contest is no longer decided by skill or investment but by wallet, which breaks\nthe fairness that makes competition meaningful (BAL, MP-0003) and tells free or lower-spending\nplayers their effort is worth less than someone's credit card. Cosmetics and expression, by\ncontrast, let players spend to *personalize* without distorting outcomes — a fair value exchange\n(MON-0002). Convenience (skipping optional grind) sits in between and can be acceptable when it\ndoesn't create a competitive gap. The healthiest competitive monetization keeps the playing field\nlevel and sells everything *around* it.","Applies when":"Competitive and shared-world multiplayer, and any game where one player's purchases affect\nanother's experience. Less pressing in purely single-player games.","Does not apply / Exceptions":"This is genuinely contested (hence stylistic). Single-player games have no fairness stake in\npower purchases (buying an advantage in a solo game harms no one — arguably it's just a\ndifficulty option). Some entire genres and markets (many mobile RPGs, gacha games) are built on\npower monetization and their audiences accept it. And the cosmetic/convenience/power line blurs\n(is a time-saver in a co-op game pay-to-win?). The principle is strongest for *competitive\nintegrity*; it weakens as the shared/competitive stakes fall.","Implementation (kept separate from the principle)":"In competitive/shared games, keep purchasable items cosmetic or expressive; keep power earnable\nthrough play, equally available to all. If selling convenience, ensure it doesn't create a\ncompetitive advantage. Communicate clearly what purchases do (MON-0005). Where the design is\nsingle-player, treat \"power for money\" as a difficulty/accessibility option, not a fairness\nissue.","Disagreement":"Cosmetic-only/fair-play monetization (protects competitive integrity and goodwill) vs.\npower/progression monetization (higher revenue, accepted in some genres/markets, harmless in\nsingle-player). A real, market-dependent split — competitive and community-focused games lean\ncosmetic-only; many mobile and gacha economies are built on the opposite. Typed stylistic\nbecause it's a genuine values-and-market choice, sharpest where competition is real.","Notes":"The fairness-in-monetization principle; connects MON to balance (BAL-0001) and multiplayer\nfairness (MP-0003). Confidence 3 — the competitive case is strong, but the single-player and\ngenre exceptions make it a contextual/values call."},"rawMarkdown":"---\nid: GDC-L1-MON-0004\ntitle: Keep pay out of \"win\" — sell expression and convenience, not competitive power\nlayer: L1\ndomain: MON\nsubdomain: models\ntype: stylistic\nconfidence: 3\nstatus: canonical\ntags:\n  - monetization\n  - pay-to-win\n  - fairness\n  - cosmetics\n  - competitive\nrelated:\n  - GDC-L1-MON-0002\n  - GDC-L1-BAL-0001\n  - GDC-L1-MP-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-monetization-ethics\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> In games where players compete or share a world, prefer selling **cosmetics, expression, and\n> (optional) convenience** over selling **competitive power**. \"Pay-to-win\" — where money buys a\n> gameplay advantage others must match with cash or grind — corrodes fairness and the trust the\n> competition depends on.\n\n## Rationale\nThere is a meaningful ethical and design line between cosmetic purchases and purchases that\naffect gameplay outcomes in a shared or competitive game [S-monetization-ethics]. When money\nbuys power, the contest is no longer decided by skill or investment but by wallet, which breaks\nthe fairness that makes competition meaningful (BAL, MP-0003) and tells free or lower-spending\nplayers their effort is worth less than someone's credit card. Cosmetics and expression, by\ncontrast, let players spend to *personalize* without distorting outcomes — a fair value exchange\n(MON-0002). Convenience (skipping optional grind) sits in between and can be acceptable when it\ndoesn't create a competitive gap. The healthiest competitive monetization keeps the playing field\nlevel and sells everything *around* it.\n\n## Applies when\nCompetitive and shared-world multiplayer, and any game where one player's purchases affect\nanother's experience. Less pressing in purely single-player games.\n\n## Does not apply / Exceptions\nThis is genuinely contested (hence stylistic). Single-player games have no fairness stake in\npower purchases (buying an advantage in a solo game harms no one — arguably it's just a\ndifficulty option). Some entire genres and markets (many mobile RPGs, gacha games) are built on\npower monetization and their audiences accept it. And the cosmetic/convenience/power line blurs\n(is a time-saver in a co-op game pay-to-win?). The principle is strongest for *competitive\nintegrity*; it weakens as the shared/competitive stakes fall.\n\n## Implementation (kept separate from the principle)\nIn competitive/shared games, keep purchasable items cosmetic or expressive; keep power earnable\nthrough play, equally available to all. If selling convenience, ensure it doesn't create a\ncompetitive advantage. Communicate clearly what purchases do (MON-0005). Where the design is\nsingle-player, treat \"power for money\" as a difficulty/accessibility option, not a fairness\nissue.\n\n## Disagreement\nCosmetic-only/fair-play monetization (protects competitive integrity and goodwill) vs.\npower/progression monetization (higher revenue, accepted in some genres/markets, harmless in\nsingle-player). A real, market-dependent split — competitive and community-focused games lean\ncosmetic-only; many mobile and gacha economies are built on the opposite. Typed stylistic\nbecause it's a genuine values-and-market choice, sharpest where competition is real.\n\n## Notes\nThe fairness-in-monetization principle; connects MON to balance (BAL-0001) and multiplayer\nfairness (MP-0003). Confidence 3 — the competitive case is strong, but the single-player and\ngenre exceptions make it a contextual/values call.\n","searchText":"gdc-l1-mon-0004 keep pay out of \"win\" — sell expression and convenience, not competitive power monetization pay-to-win fairness cosmetics competitive > in games where players compete or share a world, prefer selling cosmetics, expression, and (optional) convenience over selling competitive power. \"pay-to-win\" — where money buys a gameplay advantage others must match with cash or grind — corrodes fairness and the trust the competition depends on. there is a meaningful ethical and design line between cosmetic purchases and purchases that affect gameplay outcomes in a shared or competitive game [s-monetization-ethics]. when money buys power, the contest is no longer decided by skill or investment but by wallet, which breaks the fairness that makes competition meaningful (bal, mp-0003) and tells free or lower-spending players their effort is worth less than someone's credit card. cosmetics and expression, by contrast, let players spend to personalize without distorting outcomes — a fair value exchange (mon-0002). convenience (skipping optional grind) sits in between and can be acceptable when it doesn't create a competitive gap. the healthiest competitive monetization keeps the playing field level and sells everything around it. competitive and shared-world multiplayer, and any game where one player's purchases affect another's experience. less pressing in purely single-player games. this is genuinely contested (hence stylistic). single-player games have no fairness stake in power purchases (buying an advantage in a solo game harms no one — arguably it's just a difficulty option). some entire genres and markets (many mobile rpgs, gacha games) are built on power monetization and their audiences accept it. and the cosmetic/convenience/power line blurs (is a time-saver in a co-op game pay-to-win?). the principle is strongest for competitive integrity; it weakens as the shared/competitive stakes fall. in competitive/shared games, keep purchasable items cosmetic or expressive; keep power earnable through play, equally available to all. if selling convenience, ensure it doesn't create a competitive advantage. communicate clearly what purchases do (mon-0005). where the design is single-player, treat \"power for money\" as a difficulty/accessibility option, not a fairness issue. cosmetic-only/fair-play monetization (protects competitive integrity and goodwill) vs. power/progression monetization (higher revenue, accepted in some genres/markets, harmless in single-player). a real, market-dependent split — competitive and community-focused games lean cosmetic-only; many mobile and gacha economies are built on the opposite. typed stylistic because it's a genuine values-and-market choice, sharpest where competition is real. the fairness-in-monetization principle; connects mon to balance (bal-0001) and multiplayer fairness (mp-0003). confidence 3 — the competitive case is strong, but the single-player and genre exceptions make it a contextual/values call."}
{"id":"GDC-L1-MON-0005","title":"Be transparent — disclose odds and true costs; enable informed consent","layer":"L1","domain":"MON","subdomain":"ethics","type":"contextual","confidence":4,"status":"canonical","tags":["monetization","transparency","disclosure","odds","informed-consent"],"related":["GDC-L1-MON-0003","GDC-L1-UX-0003","GDC-L1-MON-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-monetization-ethics"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-MON-0005.md","statement":"Tell players the truth about what they're buying: disclose the real cost in money and the odds of any randomized reward, in plain terms, before purchase. Informed consent requires that material information — true price, drop rates, what the item does — be visible, not buried.","sections":{"Statement":"> Tell players the truth about what they're buying: disclose the **real cost** in money and the\n> **odds** of any randomized reward, in plain terms, before purchase. Informed consent requires\n> that material information — true price, drop rates, what the item does — be visible, not buried.","Rationale":"A purchase decision is only fair if the player has the information to make it, and randomized or\ncurrency-obscured monetization routinely hides exactly what the player needs: the real-money cost\nto obtain a specific reward, and the probability of getting it [S-monetization-ethics].\nConcealing this — through opaque premium currencies, layered conversions, or undisclosed loot-box\nodds — is what makes such systems a dark pattern (MON-0003) and, increasingly, illegal.\nTransparency is the antidote: publish odds, show true costs, and make the terms legible\n(UX-0003). It's also simply respectful — a studio confident its offers are fair has no reason to\nhide them. Disclosure lets players who *want* to spend do so knowingly, and lets others opt out.","Applies when":"Any paid transaction, and especially any randomized reward (loot boxes, gacha) or\nmulti-currency store.","Does not apply / Exceptions":"Straightforward fixed-price purchases (a $10 expansion, a named cosmetic) already carry their\ninformation and need little extra disclosure. Some surprise/reveal in *earned* (non-paid) rewards\nis fine — the transparency duty attaches to *money*. Platform and regional regulations set\nminimums; meeting them is a floor, not a ceiling.","Implementation (kept separate from the principle)":"Publish drop rates/odds for randomized paid rewards. Show the real-money cost, not just an opaque\ncurrency amount. State what an item does before purchase. Make prices and terms legible (UX-0003),\nnot buried in menus. Where minors may play, err further toward clarity and restraint (MON-0003).\nTreat legal minimums as the floor.","Disagreement":"Little serious dissent that transparency is *right*; the industry tension is how much disclosure\nhurts revenue (obscurity sells) versus builds trust. Regulators and player-respect ethics push\ntoward full disclosure; some business practice resists it. This principle sides with disclosure.","Notes":"The informed-consent principle of MON; the honest counterpart to dark patterns (MON-0003) and an\napplication of clear communication (UX-0003) to money. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-MON-0005\ntitle: Be transparent — disclose odds and true costs; enable informed consent\nlayer: L1\ndomain: MON\nsubdomain: ethics\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - monetization\n  - transparency\n  - disclosure\n  - odds\n  - informed-consent\nrelated:\n  - GDC-L1-MON-0003\n  - GDC-L1-UX-0003\n  - GDC-L1-MON-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-monetization-ethics\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Tell players the truth about what they're buying: disclose the **real cost** in money and the\n> **odds** of any randomized reward, in plain terms, before purchase. Informed consent requires\n> that material information — true price, drop rates, what the item does — be visible, not buried.\n\n## Rationale\nA purchase decision is only fair if the player has the information to make it, and randomized or\ncurrency-obscured monetization routinely hides exactly what the player needs: the real-money cost\nto obtain a specific reward, and the probability of getting it [S-monetization-ethics].\nConcealing this — through opaque premium currencies, layered conversions, or undisclosed loot-box\nodds — is what makes such systems a dark pattern (MON-0003) and, increasingly, illegal.\nTransparency is the antidote: publish odds, show true costs, and make the terms legible\n(UX-0003). It's also simply respectful — a studio confident its offers are fair has no reason to\nhide them. Disclosure lets players who *want* to spend do so knowingly, and lets others opt out.\n\n## Applies when\nAny paid transaction, and especially any randomized reward (loot boxes, gacha) or\nmulti-currency store.\n\n## Does not apply / Exceptions\nStraightforward fixed-price purchases (a $10 expansion, a named cosmetic) already carry their\ninformation and need little extra disclosure. Some surprise/reveal in *earned* (non-paid) rewards\nis fine — the transparency duty attaches to *money*. Platform and regional regulations set\nminimums; meeting them is a floor, not a ceiling.\n\n## Implementation (kept separate from the principle)\nPublish drop rates/odds for randomized paid rewards. Show the real-money cost, not just an opaque\ncurrency amount. State what an item does before purchase. Make prices and terms legible (UX-0003),\nnot buried in menus. Where minors may play, err further toward clarity and restraint (MON-0003).\nTreat legal minimums as the floor.\n\n## Disagreement\nLittle serious dissent that transparency is *right*; the industry tension is how much disclosure\nhurts revenue (obscurity sells) versus builds trust. Regulators and player-respect ethics push\ntoward full disclosure; some business practice resists it. This principle sides with disclosure.\n\n## Notes\nThe informed-consent principle of MON; the honest counterpart to dark patterns (MON-0003) and an\napplication of clear communication (UX-0003) to money. Confidence 4.\n","searchText":"gdc-l1-mon-0005 be transparent — disclose odds and true costs; enable informed consent monetization transparency disclosure odds informed-consent > tell players the truth about what they're buying: disclose the real cost in money and the odds of any randomized reward, in plain terms, before purchase. informed consent requires that material information — true price, drop rates, what the item does — be visible, not buried. a purchase decision is only fair if the player has the information to make it, and randomized or currency-obscured monetization routinely hides exactly what the player needs: the real-money cost to obtain a specific reward, and the probability of getting it [s-monetization-ethics]. concealing this — through opaque premium currencies, layered conversions, or undisclosed loot-box odds — is what makes such systems a dark pattern (mon-0003) and, increasingly, illegal. transparency is the antidote: publish odds, show true costs, and make the terms legible (ux-0003). it's also simply respectful — a studio confident its offers are fair has no reason to hide them. disclosure lets players who want to spend do so knowingly, and lets others opt out. any paid transaction, and especially any randomized reward (loot boxes, gacha) or multi-currency store. straightforward fixed-price purchases (a $10 expansion, a named cosmetic) already carry their information and need little extra disclosure. some surprise/reveal in earned (non-paid) rewards is fine — the transparency duty attaches to money. platform and regional regulations set minimums; meeting them is a floor, not a ceiling. publish drop rates/odds for randomized paid rewards. show the real-money cost, not just an opaque currency amount. state what an item does before purchase. make prices and terms legible (ux-0003), not buried in menus. where minors may play, err further toward clarity and restraint (mon-0003). treat legal minimums as the floor. little serious dissent that transparency is right; the industry tension is how much disclosure hurts revenue (obscurity sells) versus builds trust. regulators and player-respect ethics push toward full disclosure; some business practice resists it. this principle sides with disclosure. the informed-consent principle of mon; the honest counterpart to dark patterns (mon-0003) and an application of clear communication (ux-0003) to money. confidence 4."}
{"id":"GDC-L1-ARCH-0001","title":"Make the game data-driven — push behavior and tuning out of code into editable data","layer":"L1","domain":"ARCH","subdomain":"data-driven-design","type":"contextual","confidence":4,"status":"canonical","tags":["data-driven","iteration","tooling","decoupling","empower-creators"],"related":["GDC-L1-ARCH-0005","GDC-L1-SYS-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-nystrom-gpp"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ARCH-0001.md","statement":"Push as much game behavior, content, and tuning as practical out of compiled code and into data — assets, tables, config, DataAssets — that can be edited and reloaded without a rebuild. This separates what the game does from how the engine runs it, and lets designers and artists iterate directly instead of through a programmer.","sections":{"Statement":"> Push as much game behavior, content, and tuning as practical out of compiled code and\n> into **data** — assets, tables, config, DataAssets — that can be edited and reloaded\n> without a rebuild. This separates *what the game does* from *how the engine runs it*,\n> and lets designers and artists iterate directly instead of through a programmer.","Rationale":"Games are found through iteration, and the iteration bottleneck is usually the\nedit→compile→see-result loop. Moving values and behavior into data collapses that loop:\na designer changes a number or a rule in an asset and sees the result immediately, with\nno code change [S-nystrom-gpp]. It also decouples systems — the code becomes a generic\nengine that interprets data, so new content is new data rather than new code, and the\npeople closest to the design (not just programmers) can shape it. The deeper payoff is\narchitectural: a data-driven system is one where you \"build the seam\" (baseline plus\nparameters) once and fill it endlessly, which is exactly what makes large, tunable\nsystems tractable.","Applies when":"Content- and tuning-heavy games; anything with many entities, abilities, items, or\nvalues that will be balanced and iterated. The more content and the more iteration\nexpected, the stronger the case.","Does not apply / Exceptions":"Data-driving everything has real upfront cost — schema design, tooling, an interpretation\nlayer — and can be over-applied (YAGNI): for a tiny game, a game-jam prototype, or a\none-off system, hardcoding is faster and clearer. Over-abstraction into data can also\nhurt readability and debuggability. Data-drive what will actually be iterated; hardcode\nwhat won't.","Implementation (kept separate from the principle)":"Identify the values and behaviors that will be tuned or extended, and expose them as\ndata with a clear schema. Support hot-reload so edits show up live (see ARCH-0005). Give\nthe data good authoring tools (even a spreadsheet beats recompiling). Keep the code a\nthin, generic interpreter of the data. Validate data on load so bad content fails loudly,\nnot silently.","Disagreement":"The tension is future-proofing vs. YAGNI. Over-engineering seams that never get used is\nwaste; under-building them forces painful refactors when iteration demand arrives. The\nresolution most teams accept: data-drive the systems you *know* will be iterated heavily\n(combat tuning, content), hardcode the rest until proven otherwise.","Notes":"Partners with SYS-0002 (second-order design — data is how you author the rules players play with) and ARCH-0005 (iteration speed). Confidence 4; typed `contextual` for the genuine small-project exception."},"rawMarkdown":"---\nid: GDC-L1-ARCH-0001\ntitle: Make the game data-driven — push behavior and tuning out of code into editable data\nlayer: L1\ndomain: ARCH\nsubdomain: data-driven-design\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - data-driven\n  - iteration\n  - tooling\n  - decoupling\n  - empower-creators\nrelated:\n  - GDC-L1-ARCH-0005\n  - GDC-L1-SYS-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-nystrom-gpp\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Push as much game behavior, content, and tuning as practical out of compiled code and\n> into **data** — assets, tables, config, DataAssets — that can be edited and reloaded\n> without a rebuild. This separates *what the game does* from *how the engine runs it*,\n> and lets designers and artists iterate directly instead of through a programmer.\n\n## Rationale\nGames are found through iteration, and the iteration bottleneck is usually the\nedit→compile→see-result loop. Moving values and behavior into data collapses that loop:\na designer changes a number or a rule in an asset and sees the result immediately, with\nno code change [S-nystrom-gpp]. It also decouples systems — the code becomes a generic\nengine that interprets data, so new content is new data rather than new code, and the\npeople closest to the design (not just programmers) can shape it. The deeper payoff is\narchitectural: a data-driven system is one where you \"build the seam\" (baseline plus\nparameters) once and fill it endlessly, which is exactly what makes large, tunable\nsystems tractable.\n\n## Applies when\nContent- and tuning-heavy games; anything with many entities, abilities, items, or\nvalues that will be balanced and iterated. The more content and the more iteration\nexpected, the stronger the case.\n\n## Does not apply / Exceptions\nData-driving everything has real upfront cost — schema design, tooling, an interpretation\nlayer — and can be over-applied (YAGNI): for a tiny game, a game-jam prototype, or a\none-off system, hardcoding is faster and clearer. Over-abstraction into data can also\nhurt readability and debuggability. Data-drive what will actually be iterated; hardcode\nwhat won't.\n\n## Implementation (kept separate from the principle)\nIdentify the values and behaviors that will be tuned or extended, and expose them as\ndata with a clear schema. Support hot-reload so edits show up live (see ARCH-0005). Give\nthe data good authoring tools (even a spreadsheet beats recompiling). Keep the code a\nthin, generic interpreter of the data. Validate data on load so bad content fails loudly,\nnot silently.\n\n## Disagreement\nThe tension is future-proofing vs. YAGNI. Over-engineering seams that never get used is\nwaste; under-building them forces painful refactors when iteration demand arrives. The\nresolution most teams accept: data-drive the systems you *know* will be iterated heavily\n(combat tuning, content), hardcode the rest until proven otherwise.\n\n## Notes\nPartners with SYS-0002 (second-order design — data is how you author the rules players play with) and ARCH-0005 (iteration speed). Confidence 4; typed `contextual` for the genuine small-project exception.\n","searchText":"gdc-l1-arch-0001 make the game data-driven — push behavior and tuning out of code into editable data data-driven iteration tooling decoupling empower-creators > push as much game behavior, content, and tuning as practical out of compiled code and into data — assets, tables, config, dataassets — that can be edited and reloaded without a rebuild. this separates what the game does from how the engine runs it, and lets designers and artists iterate directly instead of through a programmer. games are found through iteration, and the iteration bottleneck is usually the edit→compile→see-result loop. moving values and behavior into data collapses that loop: a designer changes a number or a rule in an asset and sees the result immediately, with no code change [s-nystrom-gpp]. it also decouples systems — the code becomes a generic engine that interprets data, so new content is new data rather than new code, and the people closest to the design (not just programmers) can shape it. the deeper payoff is architectural: a data-driven system is one where you \"build the seam\" (baseline plus parameters) once and fill it endlessly, which is exactly what makes large, tunable systems tractable. content- and tuning-heavy games; anything with many entities, abilities, items, or values that will be balanced and iterated. the more content and the more iteration expected, the stronger the case. data-driving everything has real upfront cost — schema design, tooling, an interpretation layer — and can be over-applied (yagni): for a tiny game, a game-jam prototype, or a one-off system, hardcoding is faster and clearer. over-abstraction into data can also hurt readability and debuggability. data-drive what will actually be iterated; hardcode what won't. identify the values and behaviors that will be tuned or extended, and expose them as data with a clear schema. support hot-reload so edits show up live (see arch-0005). give the data good authoring tools (even a spreadsheet beats recompiling). keep the code a thin, generic interpreter of the data. validate data on load so bad content fails loudly, not silently. the tension is future-proofing vs. yagni. over-engineering seams that never get used is waste; under-building them forces painful refactors when iteration demand arrives. the resolution most teams accept: data-drive the systems you know will be iterated heavily (combat tuning, content), hardcode the rest until proven otherwise. partners with sys-0002 (second-order design — data is how you author the rules players play with) and arch-0005 (iteration speed). confidence 4; typed contextual for the genuine small-project exception."}
{"id":"GDC-L1-ARCH-0002","title":"Favor composition over inheritance — build entities from components","layer":"L1","domain":"ARCH","subdomain":"patterns","type":"contextual","confidence":4,"status":"canonical","tags":["composition","components","ecs","modularity","decoupling"],"related":["GDC-L1-ARCH-0003","GDC-L1-SYS-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-nystrom-gpp"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ARCH-0002.md","statement":"Assemble game entities from small, reusable components rather than from deep inheritance hierarchies. Add behavior by composing parts, not by extending an ever-growing class tree. \"This entity has a health component, a movement component, an inventory\" scales; \"this entity is a subclass of a subclass of Actor\" does not.","sections":{"Statement":"> Assemble game entities from small, reusable **components** rather than from deep\n> inheritance hierarchies. Add behavior by composing parts, not by extending an\n> ever-growing class tree. \"This entity *has* a health component, a movement component, an\n> inventory\" scales; \"this entity *is a* subclass of a subclass of Actor\" does not.","Rationale":"Game entities need behavior in combinations that a single inheritance tree can't express\ncleanly — the moment you want \"a crate that's also flammable and also a mount,\" a rigid\nhierarchy forces duplication or contortion [S-nystrom-gpp]. Composition sidesteps this:\neach capability is an independent, reusable component, and an entity is whatever set of\ncomponents it holds. This keeps capabilities decoupled (each component is testable and\neditable alone), avoids the duplication that deep inheritance breeds, and lets designers\nbuild new entity types by mixing existing parts — which pairs naturally with data-driven\ndesign (ARCH-0001).","Applies when":"Any game with many entity types that share overlapping-but-not-identical behavior — most\ngames with a variety of actors, items, or units.","Does not apply / Exceptions":"Composition has overhead: indirection, wiring, and (in full ECS) a real conceptual and\ntooling cost that a small game may not need. Shallow, stable inheritance is perfectly\nfine where the \"is-a\" relationship is genuine and unlikely to combine in surprising ways.\nFull data-oriented ECS is a bigger commitment than \"components over inheritance\" and\nbrings its own tradeoffs (performance wins vs. complexity) — adopt the depth the game\nactually needs.","Implementation (kept separate from the principle)":"Model capabilities as components with narrow responsibilities; compose entities from\nthem. Prefer wiring components together over subclassing. Let components communicate\nthrough events or a shared owner rather than direct hard references (ARCH-0003). Keep each\ncomponent's job orthogonal to the others' (the code-level echo of SYS-0005).","Disagreement":"Component/ECS vs. classical OOP inheritance is a long-running debate. Inheritance is\nsimpler for small, stable hierarchies; composition scales far better for combinatorial\nbehavior. Full ECS adds performance and decoupling benefits at a real complexity cost.\nThe pragmatic default — \"favor composition, reach for ECS only when its benefits are\nneeded\" — is what this principle encodes.","Notes":"The code-level counterpart to systems-orthogonality (SYS-0005): distinct, non-overlapping parts, whether they're game systems or software components. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-ARCH-0002\ntitle: Favor composition over inheritance — build entities from components\nlayer: L1\ndomain: ARCH\nsubdomain: patterns\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - composition\n  - components\n  - ecs\n  - modularity\n  - decoupling\nrelated:\n  - GDC-L1-ARCH-0003\n  - GDC-L1-SYS-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-nystrom-gpp\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Assemble game entities from small, reusable **components** rather than from deep\n> inheritance hierarchies. Add behavior by composing parts, not by extending an\n> ever-growing class tree. \"This entity *has* a health component, a movement component, an\n> inventory\" scales; \"this entity *is a* subclass of a subclass of Actor\" does not.\n\n## Rationale\nGame entities need behavior in combinations that a single inheritance tree can't express\ncleanly — the moment you want \"a crate that's also flammable and also a mount,\" a rigid\nhierarchy forces duplication or contortion [S-nystrom-gpp]. Composition sidesteps this:\neach capability is an independent, reusable component, and an entity is whatever set of\ncomponents it holds. This keeps capabilities decoupled (each component is testable and\neditable alone), avoids the duplication that deep inheritance breeds, and lets designers\nbuild new entity types by mixing existing parts — which pairs naturally with data-driven\ndesign (ARCH-0001).\n\n## Applies when\nAny game with many entity types that share overlapping-but-not-identical behavior — most\ngames with a variety of actors, items, or units.\n\n## Does not apply / Exceptions\nComposition has overhead: indirection, wiring, and (in full ECS) a real conceptual and\ntooling cost that a small game may not need. Shallow, stable inheritance is perfectly\nfine where the \"is-a\" relationship is genuine and unlikely to combine in surprising ways.\nFull data-oriented ECS is a bigger commitment than \"components over inheritance\" and\nbrings its own tradeoffs (performance wins vs. complexity) — adopt the depth the game\nactually needs.\n\n## Implementation (kept separate from the principle)\nModel capabilities as components with narrow responsibilities; compose entities from\nthem. Prefer wiring components together over subclassing. Let components communicate\nthrough events or a shared owner rather than direct hard references (ARCH-0003). Keep each\ncomponent's job orthogonal to the others' (the code-level echo of SYS-0005).\n\n## Disagreement\nComponent/ECS vs. classical OOP inheritance is a long-running debate. Inheritance is\nsimpler for small, stable hierarchies; composition scales far better for combinatorial\nbehavior. Full ECS adds performance and decoupling benefits at a real complexity cost.\nThe pragmatic default — \"favor composition, reach for ECS only when its benefits are\nneeded\" — is what this principle encodes.\n\n## Notes\nThe code-level counterpart to systems-orthogonality (SYS-0005): distinct, non-overlapping parts, whether they're game systems or software components. Confidence 4.\n","searchText":"gdc-l1-arch-0002 favor composition over inheritance — build entities from components composition components ecs modularity decoupling > assemble game entities from small, reusable components rather than from deep inheritance hierarchies. add behavior by composing parts, not by extending an ever-growing class tree. \"this entity has a health component, a movement component, an inventory\" scales; \"this entity is a subclass of a subclass of actor\" does not. game entities need behavior in combinations that a single inheritance tree can't express cleanly — the moment you want \"a crate that's also flammable and also a mount,\" a rigid hierarchy forces duplication or contortion [s-nystrom-gpp]. composition sidesteps this: each capability is an independent, reusable component, and an entity is whatever set of components it holds. this keeps capabilities decoupled (each component is testable and editable alone), avoids the duplication that deep inheritance breeds, and lets designers build new entity types by mixing existing parts — which pairs naturally with data-driven design (arch-0001). any game with many entity types that share overlapping-but-not-identical behavior — most games with a variety of actors, items, or units. composition has overhead: indirection, wiring, and (in full ecs) a real conceptual and tooling cost that a small game may not need. shallow, stable inheritance is perfectly fine where the \"is-a\" relationship is genuine and unlikely to combine in surprising ways. full data-oriented ecs is a bigger commitment than \"components over inheritance\" and brings its own tradeoffs (performance wins vs. complexity) — adopt the depth the game actually needs. model capabilities as components with narrow responsibilities; compose entities from them. prefer wiring components together over subclassing. let components communicate through events or a shared owner rather than direct hard references (arch-0003). keep each component's job orthogonal to the others' (the code-level echo of sys-0005). component/ecs vs. classical oop inheritance is a long-running debate. inheritance is simpler for small, stable hierarchies; composition scales far better for combinatorial behavior. full ecs adds performance and decoupling benefits at a real complexity cost. the pragmatic default — \"favor composition, reach for ecs only when its benefits are needed\" — is what this principle encodes. the code-level counterpart to systems-orthogonality (sys-0005): distinct, non-overlapping parts, whether they're game systems or software components. confidence 4."}
{"id":"GDC-L1-ARCH-0003","title":"Decouple systems through events, not direct references","layer":"L1","domain":"ARCH","subdomain":"decoupling","type":"contextual","confidence":4,"status":"canonical","tags":["events","observer","event-queue","decoupling","messaging"],"related":["GDC-L1-ARCH-0002","GDC-L1-SYS-0006"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-nystrom-gpp"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ARCH-0003.md","statement":"Let systems communicate by broadcasting events through a mediator, rather than holding direct references to one another. A sender announces \"this happened\" without knowing who listens; listeners subscribe without knowing who sent it. This keeps systems independent — new listeners can be added without touching the sender.","sections":{"Statement":"> Let systems communicate by broadcasting **events** through a mediator, rather than\n> holding direct references to one another. A sender announces \"this happened\" without\n> knowing who listens; listeners subscribe without knowing who sent it. This keeps\n> systems independent — new listeners can be added without touching the sender.","Rationale":"Direct references make systems mutually dependent: the combat system calling the audio\nsystem, the UI, the achievement tracker, and the particle system directly becomes a knot\nwhere nothing can change in isolation [S-nystrom-gpp]. An event/observer boundary cuts\nthe knot — the combat system fires \"enemy died\" and is done; any number of systems react,\neach ignorant of the others. An event *queue* goes further, decoupling *when* a message is\nsent from *when* it's processed, which smooths frame spikes and ordering. This is the\narchitecture that lets a system like a behavior-observing skill engine watch everything\nthe player does without every other system having to know it exists.","Applies when":"Cross-cutting reactions to game events (audio, UI, VFX, analytics, progression), and any\nsystem that must observe many others without coupling to them.","Does not apply / Exceptions":"Events are not free. Indirection makes control flow harder to trace, hides ordering\ndependencies, and — overused — produces \"event spaghetti\" where no one can tell what\nhappens when. For tight, direct, one-to-one relationships a plain function call is\nclearer and more debuggable than an event. Use events to decouple *across* system\nboundaries; don't event-ify everything inside a system.","Implementation (kept separate from the principle)":"Define a clear, typed event vocabulary (a fixed set of well-named events beats ad-hoc\nstrings). Fire events at meaningful moments; let systems subscribe. Consider an event\nqueue when timing/ordering or frame-spikes matter. Guard debuggability: log/inspect the\nevent stream, and keep the vocabulary small and documented (this is where ARCH meets\nSYS-0006, legibility — events can hurt traceability, so invest in tooling that restores\nit).","Disagreement":"Event-driven decoupling vs. direct calls is a real tradeoff: decoupling and extensibility\nvs. traceability and simplicity. The synthesis: use events at seams where decoupling pays\n(many independent reactors, or a system that must not know its observers), and direct\ncalls where the relationship is tight and clarity matters more than flexibility.","Notes":"Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-ARCH-0003\ntitle: Decouple systems through events, not direct references\nlayer: L1\ndomain: ARCH\nsubdomain: decoupling\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - events\n  - observer\n  - event-queue\n  - decoupling\n  - messaging\nrelated:\n  - GDC-L1-ARCH-0002\n  - GDC-L1-SYS-0006\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-nystrom-gpp\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Let systems communicate by broadcasting **events** through a mediator, rather than\n> holding direct references to one another. A sender announces \"this happened\" without\n> knowing who listens; listeners subscribe without knowing who sent it. This keeps\n> systems independent — new listeners can be added without touching the sender.\n\n## Rationale\nDirect references make systems mutually dependent: the combat system calling the audio\nsystem, the UI, the achievement tracker, and the particle system directly becomes a knot\nwhere nothing can change in isolation [S-nystrom-gpp]. An event/observer boundary cuts\nthe knot — the combat system fires \"enemy died\" and is done; any number of systems react,\neach ignorant of the others. An event *queue* goes further, decoupling *when* a message is\nsent from *when* it's processed, which smooths frame spikes and ordering. This is the\narchitecture that lets a system like a behavior-observing skill engine watch everything\nthe player does without every other system having to know it exists.\n\n## Applies when\nCross-cutting reactions to game events (audio, UI, VFX, analytics, progression), and any\nsystem that must observe many others without coupling to them.\n\n## Does not apply / Exceptions\nEvents are not free. Indirection makes control flow harder to trace, hides ordering\ndependencies, and — overused — produces \"event spaghetti\" where no one can tell what\nhappens when. For tight, direct, one-to-one relationships a plain function call is\nclearer and more debuggable than an event. Use events to decouple *across* system\nboundaries; don't event-ify everything inside a system.\n\n## Implementation (kept separate from the principle)\nDefine a clear, typed event vocabulary (a fixed set of well-named events beats ad-hoc\nstrings). Fire events at meaningful moments; let systems subscribe. Consider an event\nqueue when timing/ordering or frame-spikes matter. Guard debuggability: log/inspect the\nevent stream, and keep the vocabulary small and documented (this is where ARCH meets\nSYS-0006, legibility — events can hurt traceability, so invest in tooling that restores\nit).\n\n## Disagreement\nEvent-driven decoupling vs. direct calls is a real tradeoff: decoupling and extensibility\nvs. traceability and simplicity. The synthesis: use events at seams where decoupling pays\n(many independent reactors, or a system that must not know its observers), and direct\ncalls where the relationship is tight and clarity matters more than flexibility.\n\n## Notes\nConfidence 4.\n","searchText":"gdc-l1-arch-0003 decouple systems through events, not direct references events observer event-queue decoupling messaging > let systems communicate by broadcasting events through a mediator, rather than holding direct references to one another. a sender announces \"this happened\" without knowing who listens; listeners subscribe without knowing who sent it. this keeps systems independent — new listeners can be added without touching the sender. direct references make systems mutually dependent: the combat system calling the audio system, the ui, the achievement tracker, and the particle system directly becomes a knot where nothing can change in isolation [s-nystrom-gpp]. an event/observer boundary cuts the knot — the combat system fires \"enemy died\" and is done; any number of systems react, each ignorant of the others. an event queue goes further, decoupling when a message is sent from when it's processed, which smooths frame spikes and ordering. this is the architecture that lets a system like a behavior-observing skill engine watch everything the player does without every other system having to know it exists. cross-cutting reactions to game events (audio, ui, vfx, analytics, progression), and any system that must observe many others without coupling to them. events are not free. indirection makes control flow harder to trace, hides ordering dependencies, and — overused — produces \"event spaghetti\" where no one can tell what happens when. for tight, direct, one-to-one relationships a plain function call is clearer and more debuggable than an event. use events to decouple across system boundaries; don't event-ify everything inside a system. define a clear, typed event vocabulary (a fixed set of well-named events beats ad-hoc strings). fire events at meaningful moments; let systems subscribe. consider an event queue when timing/ordering or frame-spikes matter. guard debuggability: log/inspect the event stream, and keep the vocabulary small and documented (this is where arch meets sys-0006, legibility — events can hurt traceability, so invest in tooling that restores it). event-driven decoupling vs. direct calls is a real tradeoff: decoupling and extensibility vs. traceability and simplicity. the synthesis: use events at seams where decoupling pays (many independent reactors, or a system that must not know its observers), and direct calls where the relationship is tight and clarity matters more than flexibility. confidence 4."}
{"id":"GDC-L1-ARCH-0004","title":"Keep game logic decoupled from engine and platform specifics","layer":"L1","domain":"ARCH","subdomain":"gameplay-architecture","type":"contextual","confidence":3,"status":"canonical","tags":["separation-of-concerns","portability","testability","engine-agnostic"],"related":["GDC-L1-ARCH-0001","GDC-L1-ARCH-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-gregory-game-engine-arch","S-nystrom-gpp"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ARCH-0004.md","statement":"Express game rules in terms of the game, not the engine. Isolate gameplay logic behind interfaces so it doesn't depend directly on rendering, input, platform, or engine internals. The more your rules are engine-agnostic, the more testable, portable, and durable they are.","sections":{"Statement":"> Express game rules in terms of the game, not the engine. Isolate gameplay logic behind\n> interfaces so it doesn't depend directly on rendering, input, platform, or engine\n> internals. The more your rules are engine-agnostic, the more testable, portable, and\n> durable they are.","Rationale":"Engine and platform details churn — APIs change, engines get upgraded, platforms come and go — while a game's core rules are comparatively stable [S-gregory-game-engine-arch]. Binding rules directly to engine specifics couples the durable to the volatile, so an engine change ripples into gameplay code, and the rules can't be unit-tested without spinning up the whole engine. A clean seam between \"the game\" and \"the engine that runs it\" contains that volatility: gameplay logic becomes testable in isolation and survives engine changes, and the engine-specific layer stays thin and replaceable.","Applies when":"Longer-lived projects, teams anticipating engine upgrades or ports, and any logic worth\nunit-testing. The value grows with the project's lifespan and the cost of an engine change.","Does not apply / Exceptions":"This is the most contested ARCH principle, and honestly so. For a team fully committed to\none engine, *embracing* the engine's idioms (its component model, its ability system, its\ndata assets) is often more pragmatic than abstracting over them — over-abstraction to\npreserve a portability you'll never use is wasted effort and can fight the engine.\nPrototypes and jam games should just use the engine directly. Decouple where testability\nor longevity genuinely pays; otherwise lean into the engine.","Implementation (kept separate from the principle)":"Keep core rules in engine-agnostic terms and push engine calls to a thin adapter layer.\nDepend on interfaces, not concrete engine types, at the seam. Aim for gameplay logic you\ncan exercise in a test harness without the full runtime. But calibrate the effort to the\nproject — a fully committed single-engine game may draw the seam loosely.","Disagreement":"Engine-agnostic purity vs. engine-embrace is a live disagreement with no universal winner.\nPurity buys testability and portability; embrace buys velocity and full use of the engine's\nstrengths. The deciding factors are project lifespan, port intentions, and how much of the\nengine you're leaning on.","Notes":""},"rawMarkdown":"---\nid: GDC-L1-ARCH-0004\ntitle: Keep game logic decoupled from engine and platform specifics\nlayer: L1\ndomain: ARCH\nsubdomain: gameplay-architecture\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - separation-of-concerns\n  - portability\n  - testability\n  - engine-agnostic\nrelated:\n  - GDC-L1-ARCH-0001\n  - GDC-L1-ARCH-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-gregory-game-engine-arch\n  - S-nystrom-gpp\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Express game rules in terms of the game, not the engine. Isolate gameplay logic behind\n> interfaces so it doesn't depend directly on rendering, input, platform, or engine\n> internals. The more your rules are engine-agnostic, the more testable, portable, and\n> durable they are.\n\n## Rationale\nEngine and platform details churn — APIs change, engines get upgraded, platforms come and go — while a game's core rules are comparatively stable [S-gregory-game-engine-arch]. Binding rules directly to engine specifics couples the durable to the volatile, so an engine change ripples into gameplay code, and the rules can't be unit-tested without spinning up the whole engine. A clean seam between \"the game\" and \"the engine that runs it\" contains that volatility: gameplay logic becomes testable in isolation and survives engine changes, and the engine-specific layer stays thin and replaceable.\n\n## Applies when\nLonger-lived projects, teams anticipating engine upgrades or ports, and any logic worth\nunit-testing. The value grows with the project's lifespan and the cost of an engine change.\n\n## Does not apply / Exceptions\nThis is the most contested ARCH principle, and honestly so. For a team fully committed to\none engine, *embracing* the engine's idioms (its component model, its ability system, its\ndata assets) is often more pragmatic than abstracting over them — over-abstraction to\npreserve a portability you'll never use is wasted effort and can fight the engine.\nPrototypes and jam games should just use the engine directly. Decouple where testability\nor longevity genuinely pays; otherwise lean into the engine.\n\n## Implementation (kept separate from the principle)\nKeep core rules in engine-agnostic terms and push engine calls to a thin adapter layer.\nDepend on interfaces, not concrete engine types, at the seam. Aim for gameplay logic you\ncan exercise in a test harness without the full runtime. But calibrate the effort to the\nproject — a fully committed single-engine game may draw the seam loosely.\n\n## Disagreement\nEngine-agnostic purity vs. engine-embrace is a live disagreement with no universal winner.\nPurity buys testability and portability; embrace buys velocity and full use of the engine's\nstrengths. The deciding factors are project lifespan, port intentions, and how much of the\nengine you're leaning on.\n\n## Notes\n","searchText":"gdc-l1-arch-0004 keep game logic decoupled from engine and platform specifics separation-of-concerns portability testability engine-agnostic > express game rules in terms of the game, not the engine. isolate gameplay logic behind interfaces so it doesn't depend directly on rendering, input, platform, or engine internals. the more your rules are engine-agnostic, the more testable, portable, and durable they are. engine and platform details churn — apis change, engines get upgraded, platforms come and go — while a game's core rules are comparatively stable [s-gregory-game-engine-arch]. binding rules directly to engine specifics couples the durable to the volatile, so an engine change ripples into gameplay code, and the rules can't be unit-tested without spinning up the whole engine. a clean seam between \"the game\" and \"the engine that runs it\" contains that volatility: gameplay logic becomes testable in isolation and survives engine changes, and the engine-specific layer stays thin and replaceable. longer-lived projects, teams anticipating engine upgrades or ports, and any logic worth unit-testing. the value grows with the project's lifespan and the cost of an engine change. this is the most contested arch principle, and honestly so. for a team fully committed to one engine, embracing the engine's idioms (its component model, its ability system, its data assets) is often more pragmatic than abstracting over them — over-abstraction to preserve a portability you'll never use is wasted effort and can fight the engine. prototypes and jam games should just use the engine directly. decouple where testability or longevity genuinely pays; otherwise lean into the engine. keep core rules in engine-agnostic terms and push engine calls to a thin adapter layer. depend on interfaces, not concrete engine types, at the seam. aim for gameplay logic you can exercise in a test harness without the full runtime. but calibrate the effort to the project — a fully committed single-engine game may draw the seam loosely. engine-agnostic purity vs. engine-embrace is a live disagreement with no universal winner. purity buys testability and portability; embrace buys velocity and full use of the engine's strengths. the deciding factors are project lifespan, port intentions, and how much of the engine you're leaning on."}
{"id":"GDC-L1-ARCH-0005","title":"Architect for iteration speed — treat the change-to-feedback loop as first-class","layer":"L1","domain":"ARCH","subdomain":"code-that-designers-can-touch","type":"objective","confidence":4,"status":"canonical","tags":["iteration","hot-reload","tooling","workflow","empower-creators"],"related":["GDC-L1-ARCH-0001","GDC-L1-DESIGN-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-nystrom-gpp"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ARCH-0005.md","statement":"Treat the length of the change-to-feedback loop as a primary architectural concern. Hot-reload, live tuning, data-driven values, fast builds, and good in-editor tools all compound: the faster a creator sees the result of a change, the more iterations they get — and iteration count, not any single decision, is what produces quality.","sections":{"Statement":"> Treat the length of the change-to-feedback loop as a primary architectural concern.\n> Hot-reload, live tuning, data-driven values, fast builds, and good in-editor tools all\n> compound: the faster a creator sees the result of a change, the more iterations they\n> get — and iteration count, not any single decision, is what produces quality.","Rationale":"Good games are found, not specified — the target experience only becomes real through\nrepeated try-observe-adjust cycles against actual play (DESIGN-0001). That makes the\n*cost of one iteration* the master variable of a project's quality ceiling: halve the\nedit→see-result time and you roughly double how many refinements fit in the same schedule.\nArchitecture directly sets that cost — a codebase that requires a full recompile and\nrelaunch to test a tweak strangles iteration, while one with hot-reloadable data and live\ntuning invites it [S-nystrom-gpp]. Investing in iteration speed pays back continuously,\nacross every future change.","Applies when":"Throughout development, for any system that will be tuned or iterated — which is most of a\ngame. The earlier the investment, the more cycles benefit.","Does not apply / Exceptions":"Iteration tooling has upfront cost, and there's a point of diminishing returns — building\nelaborate live-tuning for a value you'll set once is waste. Tiny or one-off projects may\nnot recoup the investment. Spend the tooling budget where iteration will actually be heavy.","Implementation (kept separate from the principle)":"Make tunable values data-driven and hot-reloadable (ARCH-0001). Minimize build and load\ntimes on the critical iteration path. Provide in-editor/live controls for the parameters\ndesigners touch most. Measure the loop: if changing a combat value takes minutes, that's\nan architectural bug worth fixing. Prefer play-in-editor and fast preview over\nfull-rebuild testing.","Disagreement":"Little on the principle; debate is only about *how much* to invest and *when*. The honest\ncaution is over-tooling — gold-plating iteration affordances that never get used. Target\nthe systems with real iteration demand.","Notes":"The architectural enabler of the whole design-by-iteration philosophy (DESIGN-0001, and\nthe PROTO domain to come). Tightly paired with ARCH-0001 (data-driven). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-ARCH-0005\ntitle: Architect for iteration speed — treat the change-to-feedback loop as first-class\nlayer: L1\ndomain: ARCH\nsubdomain: code-that-designers-can-touch\ntype: objective\nconfidence: 4\nstatus: canonical\ntags:\n  - iteration\n  - hot-reload\n  - tooling\n  - workflow\n  - empower-creators\nrelated:\n  - GDC-L1-ARCH-0001\n  - GDC-L1-DESIGN-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-nystrom-gpp\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Treat the length of the change-to-feedback loop as a primary architectural concern.\n> Hot-reload, live tuning, data-driven values, fast builds, and good in-editor tools all\n> compound: the faster a creator sees the result of a change, the more iterations they\n> get — and iteration count, not any single decision, is what produces quality.\n\n## Rationale\nGood games are found, not specified — the target experience only becomes real through\nrepeated try-observe-adjust cycles against actual play (DESIGN-0001). That makes the\n*cost of one iteration* the master variable of a project's quality ceiling: halve the\nedit→see-result time and you roughly double how many refinements fit in the same schedule.\nArchitecture directly sets that cost — a codebase that requires a full recompile and\nrelaunch to test a tweak strangles iteration, while one with hot-reloadable data and live\ntuning invites it [S-nystrom-gpp]. Investing in iteration speed pays back continuously,\nacross every future change.\n\n## Applies when\nThroughout development, for any system that will be tuned or iterated — which is most of a\ngame. The earlier the investment, the more cycles benefit.\n\n## Does not apply / Exceptions\nIteration tooling has upfront cost, and there's a point of diminishing returns — building\nelaborate live-tuning for a value you'll set once is waste. Tiny or one-off projects may\nnot recoup the investment. Spend the tooling budget where iteration will actually be heavy.\n\n## Implementation (kept separate from the principle)\nMake tunable values data-driven and hot-reloadable (ARCH-0001). Minimize build and load\ntimes on the critical iteration path. Provide in-editor/live controls for the parameters\ndesigners touch most. Measure the loop: if changing a combat value takes minutes, that's\nan architectural bug worth fixing. Prefer play-in-editor and fast preview over\nfull-rebuild testing.\n\n## Disagreement\nLittle on the principle; debate is only about *how much* to invest and *when*. The honest\ncaution is over-tooling — gold-plating iteration affordances that never get used. Target\nthe systems with real iteration demand.\n\n## Notes\nThe architectural enabler of the whole design-by-iteration philosophy (DESIGN-0001, and\nthe PROTO domain to come). Tightly paired with ARCH-0001 (data-driven). Confidence 4.\n","searchText":"gdc-l1-arch-0005 architect for iteration speed — treat the change-to-feedback loop as first-class iteration hot-reload tooling workflow empower-creators > treat the length of the change-to-feedback loop as a primary architectural concern. hot-reload, live tuning, data-driven values, fast builds, and good in-editor tools all compound: the faster a creator sees the result of a change, the more iterations they get — and iteration count, not any single decision, is what produces quality. good games are found, not specified — the target experience only becomes real through repeated try-observe-adjust cycles against actual play (design-0001). that makes the cost of one iteration the master variable of a project's quality ceiling: halve the edit→see-result time and you roughly double how many refinements fit in the same schedule. architecture directly sets that cost — a codebase that requires a full recompile and relaunch to test a tweak strangles iteration, while one with hot-reloadable data and live tuning invites it [s-nystrom-gpp]. investing in iteration speed pays back continuously, across every future change. throughout development, for any system that will be tuned or iterated — which is most of a game. the earlier the investment, the more cycles benefit. iteration tooling has upfront cost, and there's a point of diminishing returns — building elaborate live-tuning for a value you'll set once is waste. tiny or one-off projects may not recoup the investment. spend the tooling budget where iteration will actually be heavy. make tunable values data-driven and hot-reloadable (arch-0001). minimize build and load times on the critical iteration path. provide in-editor/live controls for the parameters designers touch most. measure the loop: if changing a combat value takes minutes, that's an architectural bug worth fixing. prefer play-in-editor and fast preview over full-rebuild testing. little on the principle; debate is only about how much to invest and when. the honest caution is over-tooling — gold-plating iteration affordances that never get used. target the systems with real iteration demand. the architectural enabler of the whole design-by-iteration philosophy (design-0001, and the proto domain to come). tightly paired with arch-0001 (data-driven). confidence 4."}
{"id":"GDC-L1-ARCH-0006","title":"Decide your authoritative state and how it serializes — early","layer":"L1","domain":"ARCH","subdomain":"save-systems","type":"contextual","confidence":3,"status":"canonical","tags":["save-systems","serialization","state","determinism","networking"],"related":["GDC-L1-ARCH-0001","GDC-L1-ARCH-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-gregory-game-engine-arch"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ARCH-0006.md","statement":"Decide early what the game's authoritative state is and how it serializes. Save/load, networking, and determinism all depend on a clean answer to \"what is the state, and how does it persist?\" Retrofitting persistence onto a codebase that ignored it is painful, bug-prone, and sometimes save-breaking.","sections":{"Statement":"> Decide early what the game's **authoritative state** is and **how it serializes**.\n> Save/load, networking, and determinism all depend on a clean answer to \"what is the\n> state, and how does it persist?\" Retrofitting persistence onto a codebase that ignored\n> it is painful, bug-prone, and sometimes save-breaking.","Rationale":"Persistence cuts across everything: if state is scattered, implicit, or tangled with\ntransient runtime objects, then saving, loading, syncing, or replaying it becomes a\nminefield of special cases [S-gregory-game-engine-arch]. Deciding up front what is\ncanonical state (versus derived or transient), and giving it a stable serialized form,\nkeeps that complexity contained. It also front-loads decisions that are *expensive to\nchange later* — notably identifier and format stability: once a build ships, the ids and\nschemas in save files are effectively permanent, because changing them breaks existing\nsaves. Thinking about this before shipping avoids a class of the worst late bugs.","Applies when":"Any game with saves, progression, multiplayer, or replays — anything where state must\npersist or synchronize. The larger and longer-lived the state, the more this matters.","Does not apply / Exceptions":"Games with little or no persistent state (pure arcade loops, some session-only\nexperiences) can treat this lightly. Early prototypes may defer it deliberately — but\nshould *know* they're deferring it, since the cost of retrofitting rises with codebase\nsize.","Implementation (kept separate from the principle)":"Distinguish authoritative state from derived/transient state, and keep the authoritative\nset explicit and serializable. Choose stable identifiers and a versioned save format\nearly; treat shipped ids and schemas as append-only/immutable. Design state so it can be\nreconstructed from its serialized form. If determinism or netcode is a goal, decide that\nearly too — it constrains the whole architecture.","Disagreement":"Mostly about timing: persistence-first designers argue state/serialization should shape\narchitecture from day one; YAGNI-leaning developers defer it to avoid over-designing an\nuncertain game. The reconciliation: the *decision* about what state is authoritative\nshould be early and conscious even if the *implementation* is deferred — deferring\nknowingly is fine, ignoring it is not.","Notes":"Confidence 3; typed `contextual` for the low-persistence exception."},"rawMarkdown":"---\nid: GDC-L1-ARCH-0006\ntitle: Decide your authoritative state and how it serializes — early\nlayer: L1\ndomain: ARCH\nsubdomain: save-systems\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - save-systems\n  - serialization\n  - state\n  - determinism\n  - networking\nrelated:\n  - GDC-L1-ARCH-0001\n  - GDC-L1-ARCH-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-gregory-game-engine-arch\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Decide early what the game's **authoritative state** is and **how it serializes**.\n> Save/load, networking, and determinism all depend on a clean answer to \"what is the\n> state, and how does it persist?\" Retrofitting persistence onto a codebase that ignored\n> it is painful, bug-prone, and sometimes save-breaking.\n\n## Rationale\nPersistence cuts across everything: if state is scattered, implicit, or tangled with\ntransient runtime objects, then saving, loading, syncing, or replaying it becomes a\nminefield of special cases [S-gregory-game-engine-arch]. Deciding up front what is\ncanonical state (versus derived or transient), and giving it a stable serialized form,\nkeeps that complexity contained. It also front-loads decisions that are *expensive to\nchange later* — notably identifier and format stability: once a build ships, the ids and\nschemas in save files are effectively permanent, because changing them breaks existing\nsaves. Thinking about this before shipping avoids a class of the worst late bugs.\n\n## Applies when\nAny game with saves, progression, multiplayer, or replays — anything where state must\npersist or synchronize. The larger and longer-lived the state, the more this matters.\n\n## Does not apply / Exceptions\nGames with little or no persistent state (pure arcade loops, some session-only\nexperiences) can treat this lightly. Early prototypes may defer it deliberately — but\nshould *know* they're deferring it, since the cost of retrofitting rises with codebase\nsize.\n\n## Implementation (kept separate from the principle)\nDistinguish authoritative state from derived/transient state, and keep the authoritative\nset explicit and serializable. Choose stable identifiers and a versioned save format\nearly; treat shipped ids and schemas as append-only/immutable. Design state so it can be\nreconstructed from its serialized form. If determinism or netcode is a goal, decide that\nearly too — it constrains the whole architecture.\n\n## Disagreement\nMostly about timing: persistence-first designers argue state/serialization should shape\narchitecture from day one; YAGNI-leaning developers defer it to avoid over-designing an\nuncertain game. The reconciliation: the *decision* about what state is authoritative\nshould be early and conscious even if the *implementation* is deferred — deferring\nknowingly is fine, ignoring it is not.\n\n## Notes\nConfidence 3; typed `contextual` for the low-persistence exception.\n","searchText":"gdc-l1-arch-0006 decide your authoritative state and how it serializes — early save-systems serialization state determinism networking > decide early what the game's authoritative state is and how it serializes. save/load, networking, and determinism all depend on a clean answer to \"what is the state, and how does it persist?\" retrofitting persistence onto a codebase that ignored it is painful, bug-prone, and sometimes save-breaking. persistence cuts across everything: if state is scattered, implicit, or tangled with transient runtime objects, then saving, loading, syncing, or replaying it becomes a minefield of special cases [s-gregory-game-engine-arch]. deciding up front what is canonical state (versus derived or transient), and giving it a stable serialized form, keeps that complexity contained. it also front-loads decisions that are expensive to change later — notably identifier and format stability: once a build ships, the ids and schemas in save files are effectively permanent, because changing them breaks existing saves. thinking about this before shipping avoids a class of the worst late bugs. any game with saves, progression, multiplayer, or replays — anything where state must persist or synchronize. the larger and longer-lived the state, the more this matters. games with little or no persistent state (pure arcade loops, some session-only experiences) can treat this lightly. early prototypes may defer it deliberately — but should know they're deferring it, since the cost of retrofitting rises with codebase size. distinguish authoritative state from derived/transient state, and keep the authoritative set explicit and serializable. choose stable identifiers and a versioned save format early; treat shipped ids and schemas as append-only/immutable. design state so it can be reconstructed from its serialized form. if determinism or netcode is a goal, decide that early too — it constrains the whole architecture. mostly about timing: persistence-first designers argue state/serialization should shape architecture from day one; yagni-leaning developers defer it to avoid over-designing an uncertain game. the reconciliation: the decision about what state is authoritative should be early and conscious even if the implementation is deferred — deferring knowingly is fine, ignoring it is not. confidence 3; typed contextual for the low-persistence exception."}
{"id":"GDC-L1-TECH-0001","title":"Technical art is one discipline — bridge art intent and engine reality","layer":"L1","domain":"TECH","subdomain":"art-tech-pipeline","type":"contextual","confidence":4,"status":"canonical","tags":["technical-art","rendering","pipeline","collaboration"],"related":["GDC-L1-TECH-0002","GDC-L1-ARCH-0004","GDC-L1-TEAM-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-realtime-rendering","S-gregory-game-engine-arch"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-TECH-0001.md","statement":"Treat technical art as a single discipline bridging art intent and engine reality, not two camps throwing assets over a wall. The constraints of real-time rendering shape what art is possible, and art goals drive what tech must deliver — so the people and tools that connect them are where visual quality is won or lost.","sections":{"Statement":"> Treat technical art as a single discipline bridging art intent and engine reality, not two\n> camps throwing assets over a wall. The constraints of real-time rendering shape what art is\n> possible, and art goals drive what tech must deliver — so the people and tools that connect\n> them are where visual quality is won or lost.","Rationale":"Real-time graphics are a negotiation between what artists want and what the engine can render at\nframe rate, and that negotiation *is* technical art: shaders, tools, optimization, and pipelines\nthat let art hit its intent within the machine's limits [S-realtime-rendering]\n[S-gregory-game-engine-arch]. When art and engineering are siloed, artists author things that\ncan't ship (too expensive, wrong format) and engineers optimize away the intent — the classic\ncost of walls between disciplines (TEAM-0005). A strong technical-art bridge lets art aim high\n*and* fit the budget (TECH-0002), because someone owns the translation between \"how it should\nlook\" and \"how the renderer works.\" It's also where the L1↔engine seam (ARCH-0004) lives on the\nvisual side.","Applies when":"Any game with meaningful real-time visuals, and any team where artists and rendering engineers\nmust collaborate. The higher the visual ambition, the more it matters.","Does not apply / Exceptions":"Tiny teams may have one person wearing both hats (which is itself technical art). Very simple or\nabstract visuals need little of this bridge. And solo/tool-driven pipelines (off-the-shelf\nengine, no custom rendering) lean on the engine's built-in tech art rather than building their\nown.","Implementation (kept separate from the principle)":"Invest in the art-tech bridge: shared understanding of the rendering budget (TECH-0002), tools\nthat let artists work within engine constraints (CONTENT-0002), and roles/people who translate\nbetween art intent and engine reality. Involve technical art *early* (in look-dev and pipeline\ndesign), not as a cleanup pass. Collaborate across the discipline wall (TEAM-0005) rather than\nhanding off over it.","Disagreement":"Little on the value of technical art; the nuance is org structure (a dedicated tech-art\ndiscipline vs. tech-savvy artists and art-savvy engineers) and how much custom rendering to build\nvs. use the engine's. Scales with visual ambition and team size.","Notes":"The bridging principle of TECH; connects to the rendering budget (TECH-0002), the L1↔engine seam\n(ARCH-0004), and cross-discipline collaboration (TEAM-0005). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-TECH-0001\ntitle: Technical art is one discipline — bridge art intent and engine reality\nlayer: L1\ndomain: TECH\nsubdomain: art-tech-pipeline\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - technical-art\n  - rendering\n  - pipeline\n  - collaboration\nrelated:\n  - GDC-L1-TECH-0002\n  - GDC-L1-ARCH-0004\n  - GDC-L1-TEAM-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-realtime-rendering\n  - S-gregory-game-engine-arch\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Treat technical art as a single discipline bridging art intent and engine reality, not two\n> camps throwing assets over a wall. The constraints of real-time rendering shape what art is\n> possible, and art goals drive what tech must deliver — so the people and tools that connect\n> them are where visual quality is won or lost.\n\n## Rationale\nReal-time graphics are a negotiation between what artists want and what the engine can render at\nframe rate, and that negotiation *is* technical art: shaders, tools, optimization, and pipelines\nthat let art hit its intent within the machine's limits [S-realtime-rendering]\n[S-gregory-game-engine-arch]. When art and engineering are siloed, artists author things that\ncan't ship (too expensive, wrong format) and engineers optimize away the intent — the classic\ncost of walls between disciplines (TEAM-0005). A strong technical-art bridge lets art aim high\n*and* fit the budget (TECH-0002), because someone owns the translation between \"how it should\nlook\" and \"how the renderer works.\" It's also where the L1↔engine seam (ARCH-0004) lives on the\nvisual side.\n\n## Applies when\nAny game with meaningful real-time visuals, and any team where artists and rendering engineers\nmust collaborate. The higher the visual ambition, the more it matters.\n\n## Does not apply / Exceptions\nTiny teams may have one person wearing both hats (which is itself technical art). Very simple or\nabstract visuals need little of this bridge. And solo/tool-driven pipelines (off-the-shelf\nengine, no custom rendering) lean on the engine's built-in tech art rather than building their\nown.\n\n## Implementation (kept separate from the principle)\nInvest in the art-tech bridge: shared understanding of the rendering budget (TECH-0002), tools\nthat let artists work within engine constraints (CONTENT-0002), and roles/people who translate\nbetween art intent and engine reality. Involve technical art *early* (in look-dev and pipeline\ndesign), not as a cleanup pass. Collaborate across the discipline wall (TEAM-0005) rather than\nhanding off over it.\n\n## Disagreement\nLittle on the value of technical art; the nuance is org structure (a dedicated tech-art\ndiscipline vs. tech-savvy artists and art-savvy engineers) and how much custom rendering to build\nvs. use the engine's. Scales with visual ambition and team size.\n\n## Notes\nThe bridging principle of TECH; connects to the rendering budget (TECH-0002), the L1↔engine seam\n(ARCH-0004), and cross-discipline collaboration (TEAM-0005). Confidence 4.\n","searchText":"gdc-l1-tech-0001 technical art is one discipline — bridge art intent and engine reality technical-art rendering pipeline collaboration > treat technical art as a single discipline bridging art intent and engine reality, not two camps throwing assets over a wall. the constraints of real-time rendering shape what art is possible, and art goals drive what tech must deliver — so the people and tools that connect them are where visual quality is won or lost. real-time graphics are a negotiation between what artists want and what the engine can render at frame rate, and that negotiation is technical art: shaders, tools, optimization, and pipelines that let art hit its intent within the machine's limits [s-realtime-rendering] [s-gregory-game-engine-arch]. when art and engineering are siloed, artists author things that can't ship (too expensive, wrong format) and engineers optimize away the intent — the classic cost of walls between disciplines (team-0005). a strong technical-art bridge lets art aim high and fit the budget (tech-0002), because someone owns the translation between \"how it should look\" and \"how the renderer works.\" it's also where the l1↔engine seam (arch-0004) lives on the visual side. any game with meaningful real-time visuals, and any team where artists and rendering engineers must collaborate. the higher the visual ambition, the more it matters. tiny teams may have one person wearing both hats (which is itself technical art). very simple or abstract visuals need little of this bridge. and solo/tool-driven pipelines (off-the-shelf engine, no custom rendering) lean on the engine's built-in tech art rather than building their own. invest in the art-tech bridge: shared understanding of the rendering budget (tech-0002), tools that let artists work within engine constraints (content-0002), and roles/people who translate between art intent and engine reality. involve technical art early (in look-dev and pipeline design), not as a cleanup pass. collaborate across the discipline wall (team-0005) rather than handing off over it. little on the value of technical art; the nuance is org structure (a dedicated tech-art discipline vs. tech-savvy artists and art-savvy engineers) and how much custom rendering to build vs. use the engine's. scales with visual ambition and team size. the bridging principle of tech; connects to the rendering budget (tech-0002), the l1↔engine seam (arch-0004), and cross-discipline collaboration (team-0005). confidence 4."}
{"id":"GDC-L1-TECH-0002","title":"Budget the frame's visuals — art must fit the rendering cost","layer":"L1","domain":"TECH","subdomain":"rendering-budget","type":"contextual","confidence":4,"status":"canonical","tags":["technical-art","rendering-budget","draw-calls","overdraw","optimization"],"related":["GDC-L1-PERF-0004","GDC-L1-TECH-0004","GDC-L1-TECH-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-realtime-rendering"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-TECH-0002.md","statement":"Rendering has a fixed per-frame budget, and visuals must fit it. Draw calls, overdraw, polygon and texture counts, shader complexity, and memory all cost time and space — so art is designed to a budget, not to whatever looks best in isolation. A gorgeous asset that blows the frame is a bug, not an achievement.","sections":{"Statement":"> Rendering has a fixed per-frame budget, and visuals must fit it. Draw calls, overdraw, polygon\n> and texture counts, shader complexity, and memory all cost time and space — so art is designed\n> *to a budget*, not to whatever looks best in isolation. A gorgeous asset that blows the frame is\n> a bug, not an achievement.","Rationale":"Every frame must finish within the frame-time budget (PERF-0004), and the GPU side of that budget\nis spent by rendering cost — the number and expense of draw calls, how many pixels are shaded\n(overdraw), shader instruction counts, texture memory bandwidth [S-realtime-rendering]. These\ncosts are driven largely by *art* decisions (mesh density, material complexity, transparency,\ntexture sizes), so visual quality is a budgeting problem: allocate the rendering budget across\nwhat matters and hold assets to their share. Ignoring this produces the familiar failure — a\nscene that looks stunning in a screenshot and runs at ten frames per second. Budgeting rendering\nis the GPU-side, art-facing companion to frame budgeting (PERF-0004) and the reason optimization\ntechniques (TECH-0004) exist.","Applies when":"Any real-time-rendered game, on any platform — most acute on fixed/constrained hardware (console,\nmobile, VR) where the budget is hard and known.","Does not apply / Exceptions":"Pre-rendered or non-real-time visuals (cinematics, offline renders) aren't frame-budget-bound.\nVery simple or stylized games may have generous headroom. And the budget varies enormously by\ntarget (a high-end PC vs. mobile), so \"fits the budget\" is relative to the platform, not absolute.","Implementation (kept separate from the principle)":"Set rendering sub-budgets (draw calls, triangles, texture memory, shader cost) for the target hardware and design art to them. Use optimization techniques — LODs, batching, atlasing, culling (TECH-0004) — to fit quality into the budget. Involve technical art early (TECH-0001) so budget informs look-dev.","Disagreement":"Little on the principle; the tension is where to *spend* the budget (fidelity vs. scene scale vs.\neffects) and how much to sacrifice visuals for performance — a per-game, per-platform judgment\ntied to the fidelity-vs-framerate choice (PERF-0004).","Notes":"The GPU/art side of frame budgeting (PERF-0004); the reason art-optimization (TECH-0004) exists,\nowned via technical art (TECH-0001). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-TECH-0002\ntitle: Budget the frame's visuals — art must fit the rendering cost\nlayer: L1\ndomain: TECH\nsubdomain: rendering-budget\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - technical-art\n  - rendering-budget\n  - draw-calls\n  - overdraw\n  - optimization\nrelated:\n  - GDC-L1-PERF-0004\n  - GDC-L1-TECH-0004\n  - GDC-L1-TECH-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-realtime-rendering\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Rendering has a fixed per-frame budget, and visuals must fit it. Draw calls, overdraw, polygon\n> and texture counts, shader complexity, and memory all cost time and space — so art is designed\n> *to a budget*, not to whatever looks best in isolation. A gorgeous asset that blows the frame is\n> a bug, not an achievement.\n\n## Rationale\nEvery frame must finish within the frame-time budget (PERF-0004), and the GPU side of that budget\nis spent by rendering cost — the number and expense of draw calls, how many pixels are shaded\n(overdraw), shader instruction counts, texture memory bandwidth [S-realtime-rendering]. These\ncosts are driven largely by *art* decisions (mesh density, material complexity, transparency,\ntexture sizes), so visual quality is a budgeting problem: allocate the rendering budget across\nwhat matters and hold assets to their share. Ignoring this produces the familiar failure — a\nscene that looks stunning in a screenshot and runs at ten frames per second. Budgeting rendering\nis the GPU-side, art-facing companion to frame budgeting (PERF-0004) and the reason optimization\ntechniques (TECH-0004) exist.\n\n## Applies when\nAny real-time-rendered game, on any platform — most acute on fixed/constrained hardware (console,\nmobile, VR) where the budget is hard and known.\n\n## Does not apply / Exceptions\nPre-rendered or non-real-time visuals (cinematics, offline renders) aren't frame-budget-bound.\nVery simple or stylized games may have generous headroom. And the budget varies enormously by\ntarget (a high-end PC vs. mobile), so \"fits the budget\" is relative to the platform, not absolute.\n\n## Implementation (kept separate from the principle)\nSet rendering sub-budgets (draw calls, triangles, texture memory, shader cost) for the target hardware and design art to them. Use optimization techniques — LODs, batching, atlasing, culling (TECH-0004) — to fit quality into the budget. Involve technical art early (TECH-0001) so budget informs look-dev.\n\n## Disagreement\nLittle on the principle; the tension is where to *spend* the budget (fidelity vs. scene scale vs.\neffects) and how much to sacrifice visuals for performance — a per-game, per-platform judgment\ntied to the fidelity-vs-framerate choice (PERF-0004).\n\n## Notes\nThe GPU/art side of frame budgeting (PERF-0004); the reason art-optimization (TECH-0004) exists,\nowned via technical art (TECH-0001). Confidence 4.\n","searchText":"gdc-l1-tech-0002 budget the frame's visuals — art must fit the rendering cost technical-art rendering-budget draw-calls overdraw optimization > rendering has a fixed per-frame budget, and visuals must fit it. draw calls, overdraw, polygon and texture counts, shader complexity, and memory all cost time and space — so art is designed to a budget, not to whatever looks best in isolation. a gorgeous asset that blows the frame is a bug, not an achievement. every frame must finish within the frame-time budget (perf-0004), and the gpu side of that budget is spent by rendering cost — the number and expense of draw calls, how many pixels are shaded (overdraw), shader instruction counts, texture memory bandwidth [s-realtime-rendering]. these costs are driven largely by art decisions (mesh density, material complexity, transparency, texture sizes), so visual quality is a budgeting problem: allocate the rendering budget across what matters and hold assets to their share. ignoring this produces the familiar failure — a scene that looks stunning in a screenshot and runs at ten frames per second. budgeting rendering is the gpu-side, art-facing companion to frame budgeting (perf-0004) and the reason optimization techniques (tech-0004) exist. any real-time-rendered game, on any platform — most acute on fixed/constrained hardware (console, mobile, vr) where the budget is hard and known. pre-rendered or non-real-time visuals (cinematics, offline renders) aren't frame-budget-bound. very simple or stylized games may have generous headroom. and the budget varies enormously by target (a high-end pc vs. mobile), so \"fits the budget\" is relative to the platform, not absolute. set rendering sub-budgets (draw calls, triangles, texture memory, shader cost) for the target hardware and design art to them. use optimization techniques — lods, batching, atlasing, culling (tech-0004) — to fit quality into the budget. involve technical art early (tech-0001) so budget informs look-dev. little on the principle; the tension is where to spend the budget (fidelity vs. scene scale vs. effects) and how much to sacrifice visuals for performance — a per-game, per-platform judgment tied to the fidelity-vs-framerate choice (perf-0004). the gpu/art side of frame budgeting (perf-0004); the reason art-optimization (tech-0004) exists, owned via technical art (tech-0001). confidence 4."}
{"id":"GDC-L1-TECH-0003","title":"Lighting is the highest-leverage visual tool","layer":"L1","domain":"TECH","subdomain":"lighting","type":"contextual","confidence":4,"status":"canonical","tags":["technical-art","lighting","mood","readability","composition"],"related":["GDC-L1-LEVEL-0001","GDC-L1-TECH-0004","GDC-L1-FEEL-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-realtime-rendering"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-TECH-0003.md","statement":"Lighting does more for a scene than almost any other visual element: it sets mood, directs attention, creates depth, and makes a world believable. The same geometry reads completely differently under different light — so treat lighting as a primary tool, not a final pass.","sections":{"Statement":"> Lighting does more for a scene than almost any other visual element: it sets mood, directs\n> attention, creates depth, and makes a world believable. The same geometry reads completely\n> differently under different light — so treat lighting as a primary tool, not a final pass.","Rationale":"Human perception is exquisitely tuned to light and shadow, so lighting carries an outsized share\nof a scene's mood, legibility, and realism [S-realtime-rendering]. It's the cheapest way to make\nmodest assets look great and the fastest way to make great assets look flat. Lighting also does\n*gameplay* work: it guides the player's eye (the level-design use of light to direct attention,\nLEVEL-0001), separates figure from ground for readability, and sets emotional tone. Because it's\nso leverage-heavy, lighting deserves deliberate art direction and iteration rather than being\nbolted on after the geometry is built. It is a major contributor to the \"polish\" layer of game\nfeel (FEEL-0001) and often the single biggest lever on how a game *looks*.","Applies when":"Any 3D (and much 2D) visual work — environments, characters, key moments. Especially powerful in\natmosphere-, horror-, and mood-driven games, and for guidance/readability everywhere.","Does not apply / Exceptions":"Flat, unlit, or deliberately-styled art (some 2D, cel/toon, retro) uses lighting minimally or\nstylistically. Performance budgets constrain dynamic lighting (TECH-0002/0004) — expensive\nlighting must fit the frame. And lighting must serve, not fight, gameplay readability (LEVEL-0001,\nANIM-0003) — beautiful lighting that hides threats or paths is a defect.","Implementation (kept separate from the principle)":"Treat lighting as art direction: design it for mood, depth, and attention-guidance (LEVEL-0001)\nalongside the geometry, not after. Use light and contrast to lead the eye and separate the\nimportant. Balance dynamic vs. baked lighting against the rendering budget (TECH-0002/0004).\nIterate lighting as a first-class part of look-dev.","Disagreement":"Little on lighting's importance; the tension is dynamic vs. baked lighting (flexibility/realism\nvs. cost — TECH-0002) and realistic vs. stylized lighting (TECH-0005). These are budget and\nart-direction choices, not disputes about whether lighting matters.","Notes":"The highest-leverage TECH principle; overlaps LEVEL-0001 (guide the eye with light) and\ncontributes heavily to game feel's polish layer (FEEL-0001). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-TECH-0003\ntitle: Lighting is the highest-leverage visual tool\nlayer: L1\ndomain: TECH\nsubdomain: lighting\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - technical-art\n  - lighting\n  - mood\n  - readability\n  - composition\nrelated:\n  - GDC-L1-LEVEL-0001\n  - GDC-L1-TECH-0004\n  - GDC-L1-FEEL-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-realtime-rendering\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Lighting does more for a scene than almost any other visual element: it sets mood, directs\n> attention, creates depth, and makes a world believable. The same geometry reads completely\n> differently under different light — so treat lighting as a primary tool, not a final pass.\n\n## Rationale\nHuman perception is exquisitely tuned to light and shadow, so lighting carries an outsized share\nof a scene's mood, legibility, and realism [S-realtime-rendering]. It's the cheapest way to make\nmodest assets look great and the fastest way to make great assets look flat. Lighting also does\n*gameplay* work: it guides the player's eye (the level-design use of light to direct attention,\nLEVEL-0001), separates figure from ground for readability, and sets emotional tone. Because it's\nso leverage-heavy, lighting deserves deliberate art direction and iteration rather than being\nbolted on after the geometry is built. It is a major contributor to the \"polish\" layer of game\nfeel (FEEL-0001) and often the single biggest lever on how a game *looks*.\n\n## Applies when\nAny 3D (and much 2D) visual work — environments, characters, key moments. Especially powerful in\natmosphere-, horror-, and mood-driven games, and for guidance/readability everywhere.\n\n## Does not apply / Exceptions\nFlat, unlit, or deliberately-styled art (some 2D, cel/toon, retro) uses lighting minimally or\nstylistically. Performance budgets constrain dynamic lighting (TECH-0002/0004) — expensive\nlighting must fit the frame. And lighting must serve, not fight, gameplay readability (LEVEL-0001,\nANIM-0003) — beautiful lighting that hides threats or paths is a defect.\n\n## Implementation (kept separate from the principle)\nTreat lighting as art direction: design it for mood, depth, and attention-guidance (LEVEL-0001)\nalongside the geometry, not after. Use light and contrast to lead the eye and separate the\nimportant. Balance dynamic vs. baked lighting against the rendering budget (TECH-0002/0004).\nIterate lighting as a first-class part of look-dev.\n\n## Disagreement\nLittle on lighting's importance; the tension is dynamic vs. baked lighting (flexibility/realism\nvs. cost — TECH-0002) and realistic vs. stylized lighting (TECH-0005). These are budget and\nart-direction choices, not disputes about whether lighting matters.\n\n## Notes\nThe highest-leverage TECH principle; overlaps LEVEL-0001 (guide the eye with light) and\ncontributes heavily to game feel's polish layer (FEEL-0001). Confidence 4.\n","searchText":"gdc-l1-tech-0003 lighting is the highest-leverage visual tool technical-art lighting mood readability composition > lighting does more for a scene than almost any other visual element: it sets mood, directs attention, creates depth, and makes a world believable. the same geometry reads completely differently under different light — so treat lighting as a primary tool, not a final pass. human perception is exquisitely tuned to light and shadow, so lighting carries an outsized share of a scene's mood, legibility, and realism [s-realtime-rendering]. it's the cheapest way to make modest assets look great and the fastest way to make great assets look flat. lighting also does gameplay work: it guides the player's eye (the level-design use of light to direct attention, level-0001), separates figure from ground for readability, and sets emotional tone. because it's so leverage-heavy, lighting deserves deliberate art direction and iteration rather than being bolted on after the geometry is built. it is a major contributor to the \"polish\" layer of game feel (feel-0001) and often the single biggest lever on how a game looks. any 3d (and much 2d) visual work — environments, characters, key moments. especially powerful in atmosphere-, horror-, and mood-driven games, and for guidance/readability everywhere. flat, unlit, or deliberately-styled art (some 2d, cel/toon, retro) uses lighting minimally or stylistically. performance budgets constrain dynamic lighting (tech-0002/0004) — expensive lighting must fit the frame. and lighting must serve, not fight, gameplay readability (level-0001, anim-0003) — beautiful lighting that hides threats or paths is a defect. treat lighting as art direction: design it for mood, depth, and attention-guidance (level-0001) alongside the geometry, not after. use light and contrast to lead the eye and separate the important. balance dynamic vs. baked lighting against the rendering budget (tech-0002/0004). iterate lighting as a first-class part of look-dev. little on lighting's importance; the tension is dynamic vs. baked lighting (flexibility/realism vs. cost — tech-0002) and realistic vs. stylized lighting (tech-0005). these are budget and art-direction choices, not disputes about whether lighting matters. the highest-leverage tech principle; overlaps level-0001 (guide the eye with light) and contributes heavily to game feel's polish layer (feel-0001). confidence 4."}
{"id":"GDC-L1-TECH-0004","title":"Coherent art direction beats raw fidelity","layer":"L1","domain":"TECH","subdomain":"optimization-of-art","type":"stylistic","confidence":3,"status":"canonical","tags":["technical-art","art-direction","style","fidelity","coherence"],"related":["GDC-L1-VISION-0001","GDC-L1-TECH-0002","GDC-L1-DESIGN-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-realtime-rendering"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-TECH-0004.md","statement":"A coherent art direction — a consistent, intentional style — beats maxed-out raw fidelity. A unified style reads better, ages far better, and fits a budget more gracefully than chasing photorealism the hardware can barely afford. Style is a choice; fidelity is a treadmill.","sections":{"Statement":"> A coherent art *direction* — a consistent, intentional style — beats maxed-out raw fidelity. A\n> unified style reads better, ages far better, and fits a budget more gracefully than chasing\n> photorealism the hardware can barely afford. Style is a choice; fidelity is a treadmill.","Rationale":"Perceived visual quality comes more from coherence than from polygon counts: a game whose every\nelement shares a clear artistic vision reads as beautiful, while a game chasing maximum realism\noften lands in the \"uncanny\" or inconsistent middle and dates quickly as hardware moves on\n[S-realtime-rendering]. A strong style is also *cheaper* — stylization lets you spend the\nrendering budget (TECH-0002) where it matters and skip the expensive last 10% of realism, and it\ngives the whole game a legible, memorable identity (an extension of the vision, VISION-0001).\nPhotorealism is a moving target you can never win against next year's hardware; a coherent style\nis a target you can actually hit and hold. Many of the most enduring-looking games are stylized,\nnot the most technically advanced of their era.","Applies when":"Art-direction and visual-target decisions — the \"what should this look like, and how real?\"\nquestion. Most impactful for teams that can't out-spend AAA on fidelity (i.e. most).","Does not apply / Exceptions":"This is genuinely a values/strategy choice (hence stylistic). Some games' whole appeal *is*\ncutting-edge fidelity (showcase AAA, certain simulations), and for a studio with the resources,\npushing realism is a legitimate identity. And \"coherent style\" still requires enough craft to\nexecute — a consistent-but-ugly style isn't a win. The claim is that coherence beats fidelity for\n*most* teams and ages better, not that fidelity is never the right call.","Implementation (kept separate from the principle)":"Define a clear art direction early (part of the vision, VISION-0001) and hold every asset to it.\nChoose a style you can execute consistently within budget (TECH-0002). Prefer coherence over\nper-asset realism. Judge visuals by whether the *whole* reads as intentional and unified, not by\nindividual-asset fidelity.","Disagreement":"Coherent style (memorable, ages well, budget-friendly, executable by most teams) vs. maximum\nfidelity (cutting-edge appeal, showcase value, resource-intensive, dates fast). A real\nart-direction and business strategy split — resource-rich studios may rightly chase fidelity;\nmost benefit from a strong style. Typed stylistic accordingly.","Notes":"The art-direction principle of TECH; an extension of the vision (VISION-0001) into the visual\ntarget, and an ally of budget discipline (TECH-0002). Confidence 3 — sound and widely-held, but a\ngenuine strategic/values choice, not a law."},"rawMarkdown":"---\nid: GDC-L1-TECH-0004\ntitle: Coherent art direction beats raw fidelity\nlayer: L1\ndomain: TECH\nsubdomain: optimization-of-art\ntype: stylistic\nconfidence: 3\nstatus: canonical\ntags:\n  - technical-art\n  - art-direction\n  - style\n  - fidelity\n  - coherence\nrelated:\n  - GDC-L1-VISION-0001\n  - GDC-L1-TECH-0002\n  - GDC-L1-DESIGN-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-realtime-rendering\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A coherent art *direction* — a consistent, intentional style — beats maxed-out raw fidelity. A\n> unified style reads better, ages far better, and fits a budget more gracefully than chasing\n> photorealism the hardware can barely afford. Style is a choice; fidelity is a treadmill.\n\n## Rationale\nPerceived visual quality comes more from coherence than from polygon counts: a game whose every\nelement shares a clear artistic vision reads as beautiful, while a game chasing maximum realism\noften lands in the \"uncanny\" or inconsistent middle and dates quickly as hardware moves on\n[S-realtime-rendering]. A strong style is also *cheaper* — stylization lets you spend the\nrendering budget (TECH-0002) where it matters and skip the expensive last 10% of realism, and it\ngives the whole game a legible, memorable identity (an extension of the vision, VISION-0001).\nPhotorealism is a moving target you can never win against next year's hardware; a coherent style\nis a target you can actually hit and hold. Many of the most enduring-looking games are stylized,\nnot the most technically advanced of their era.\n\n## Applies when\nArt-direction and visual-target decisions — the \"what should this look like, and how real?\"\nquestion. Most impactful for teams that can't out-spend AAA on fidelity (i.e. most).\n\n## Does not apply / Exceptions\nThis is genuinely a values/strategy choice (hence stylistic). Some games' whole appeal *is*\ncutting-edge fidelity (showcase AAA, certain simulations), and for a studio with the resources,\npushing realism is a legitimate identity. And \"coherent style\" still requires enough craft to\nexecute — a consistent-but-ugly style isn't a win. The claim is that coherence beats fidelity for\n*most* teams and ages better, not that fidelity is never the right call.\n\n## Implementation (kept separate from the principle)\nDefine a clear art direction early (part of the vision, VISION-0001) and hold every asset to it.\nChoose a style you can execute consistently within budget (TECH-0002). Prefer coherence over\nper-asset realism. Judge visuals by whether the *whole* reads as intentional and unified, not by\nindividual-asset fidelity.\n\n## Disagreement\nCoherent style (memorable, ages well, budget-friendly, executable by most teams) vs. maximum\nfidelity (cutting-edge appeal, showcase value, resource-intensive, dates fast). A real\nart-direction and business strategy split — resource-rich studios may rightly chase fidelity;\nmost benefit from a strong style. Typed stylistic accordingly.\n\n## Notes\nThe art-direction principle of TECH; an extension of the vision (VISION-0001) into the visual\ntarget, and an ally of budget discipline (TECH-0002). Confidence 3 — sound and widely-held, but a\ngenuine strategic/values choice, not a law.\n","searchText":"gdc-l1-tech-0004 coherent art direction beats raw fidelity technical-art art-direction style fidelity coherence > a coherent art direction — a consistent, intentional style — beats maxed-out raw fidelity. a unified style reads better, ages far better, and fits a budget more gracefully than chasing photorealism the hardware can barely afford. style is a choice; fidelity is a treadmill. perceived visual quality comes more from coherence than from polygon counts: a game whose every element shares a clear artistic vision reads as beautiful, while a game chasing maximum realism often lands in the \"uncanny\" or inconsistent middle and dates quickly as hardware moves on [s-realtime-rendering]. a strong style is also cheaper — stylization lets you spend the rendering budget (tech-0002) where it matters and skip the expensive last 10% of realism, and it gives the whole game a legible, memorable identity (an extension of the vision, vision-0001). photorealism is a moving target you can never win against next year's hardware; a coherent style is a target you can actually hit and hold. many of the most enduring-looking games are stylized, not the most technically advanced of their era. art-direction and visual-target decisions — the \"what should this look like, and how real?\" question. most impactful for teams that can't out-spend aaa on fidelity (i.e. most). this is genuinely a values/strategy choice (hence stylistic). some games' whole appeal is cutting-edge fidelity (showcase aaa, certain simulations), and for a studio with the resources, pushing realism is a legitimate identity. and \"coherent style\" still requires enough craft to execute — a consistent-but-ugly style isn't a win. the claim is that coherence beats fidelity for most teams and ages better, not that fidelity is never the right call. define a clear art direction early (part of the vision, vision-0001) and hold every asset to it. choose a style you can execute consistently within budget (tech-0002). prefer coherence over per-asset realism. judge visuals by whether the whole reads as intentional and unified, not by individual-asset fidelity. coherent style (memorable, ages well, budget-friendly, executable by most teams) vs. maximum fidelity (cutting-edge appeal, showcase value, resource-intensive, dates fast). a real art-direction and business strategy split — resource-rich studios may rightly chase fidelity; most benefit from a strong style. typed stylistic accordingly. the art-direction principle of tech; an extension of the vision (vision-0001) into the visual target, and an ally of budget discipline (tech-0002). confidence 3 — sound and widely-held, but a genuine strategic/values choice, not a law."}
{"id":"GDC-L1-TECH-0005","title":"Build materials and shaders as a data-driven system, not one-offs","layer":"L1","domain":"TECH","subdomain":"shaders-and-materials","type":"contextual","confidence":4,"status":"canonical","tags":["technical-art","shaders","materials","data-driven","reuse"],"related":["GDC-L1-ARCH-0001","GDC-L1-TECH-0002","GDC-L1-CONTENT-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-realtime-rendering","S-gregory-game-engine-arch"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-TECH-0005.md","statement":"Build materials and shaders as a system — a small set of flexible master materials driven by parameters and instanced for variation — rather than a pile of bespoke one-off shaders. Data-driven materials let artists produce and tune vast visual variety without new code, and keep the rendering cost and pipeline manageable.","sections":{"Statement":"> Build materials and shaders as a *system* — a small set of flexible master materials driven by\n> parameters and instanced for variation — rather than a pile of bespoke one-off shaders.\n> Data-driven materials let artists produce and tune vast visual variety without new code, and\n> keep the rendering cost and pipeline manageable.","Rationale":"Authoring a unique shader per material doesn't scale: it multiplies engineering work,\nfragments the rendering pipeline, makes optimization impossible, and locks artists out of their\nown materials [S-realtime-rendering]. A systemic approach — master materials exposing parameters,\ninstanced and tuned per asset — is the data-driven-design principle (ARCH-0001) applied to\nrendering: behavior and variety live in editable data (material instances) that artists control,\nwhile the underlying shaders stay few and optimizable. This empowers content creators\n(CONTENT-0002) to author look variety without programmers, keeps the shader count (and thus\nrendering cost, TECH-0002) under control, and makes the material library consistent and\nmaintainable. It's the same \"build the seam, fill it with data\" logic that runs through the\narchitecture layer.","Applies when":"Any game with more than a handful of materials — most 3D and many 2D games. The more visual\nvariety, the more a material *system* pays over one-offs.","Does not apply / Exceptions":"Tiny games with a few materials may not need the abstraction. Some genuinely unique effects\n(a signature hero shader, a special-case visual) warrant a bespoke shader — the rule is \"systemic\nby default, bespoke by exception,\" not \"never write a custom shader.\" Over-parameterizing a\nmaster material into an unusable monster is its own failure (the YAGNI caution from ARCH-0001).","Implementation (kept separate from the principle)":"Author a small set of flexible master materials with exposed parameters; create variation through\nmaterial *instances*, not new shaders. Let artists tune instances without code (CONTENT-0002).\nKeep shader permutations and cost in check (TECH-0002). Reserve bespoke shaders for genuinely\nunique effects. Validate and organize the material library (CONTENT-0003).","Disagreement":"Systemic/data-driven materials (scalable, artist-tunable, optimizable) vs. bespoke shaders\n(maximal control per effect, but unscalable) — the same data-driven-vs-YAGNI tension as ARCH-0001,\nin the rendering domain. Systemic by default; bespoke where a unique effect earns it.","Notes":"The rendering application of data-driven design (ARCH-0001) and creator-empowerment\n(CONTENT-0002); keeps rendering cost (TECH-0002) manageable. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-TECH-0005\ntitle: Build materials and shaders as a data-driven system, not one-offs\nlayer: L1\ndomain: TECH\nsubdomain: shaders-and-materials\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - technical-art\n  - shaders\n  - materials\n  - data-driven\n  - reuse\nrelated:\n  - GDC-L1-ARCH-0001\n  - GDC-L1-TECH-0002\n  - GDC-L1-CONTENT-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-realtime-rendering\n  - S-gregory-game-engine-arch\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Build materials and shaders as a *system* — a small set of flexible master materials driven by\n> parameters and instanced for variation — rather than a pile of bespoke one-off shaders.\n> Data-driven materials let artists produce and tune vast visual variety without new code, and\n> keep the rendering cost and pipeline manageable.\n\n## Rationale\nAuthoring a unique shader per material doesn't scale: it multiplies engineering work,\nfragments the rendering pipeline, makes optimization impossible, and locks artists out of their\nown materials [S-realtime-rendering]. A systemic approach — master materials exposing parameters,\ninstanced and tuned per asset — is the data-driven-design principle (ARCH-0001) applied to\nrendering: behavior and variety live in editable data (material instances) that artists control,\nwhile the underlying shaders stay few and optimizable. This empowers content creators\n(CONTENT-0002) to author look variety without programmers, keeps the shader count (and thus\nrendering cost, TECH-0002) under control, and makes the material library consistent and\nmaintainable. It's the same \"build the seam, fill it with data\" logic that runs through the\narchitecture layer.\n\n## Applies when\nAny game with more than a handful of materials — most 3D and many 2D games. The more visual\nvariety, the more a material *system* pays over one-offs.\n\n## Does not apply / Exceptions\nTiny games with a few materials may not need the abstraction. Some genuinely unique effects\n(a signature hero shader, a special-case visual) warrant a bespoke shader — the rule is \"systemic\nby default, bespoke by exception,\" not \"never write a custom shader.\" Over-parameterizing a\nmaster material into an unusable monster is its own failure (the YAGNI caution from ARCH-0001).\n\n## Implementation (kept separate from the principle)\nAuthor a small set of flexible master materials with exposed parameters; create variation through\nmaterial *instances*, not new shaders. Let artists tune instances without code (CONTENT-0002).\nKeep shader permutations and cost in check (TECH-0002). Reserve bespoke shaders for genuinely\nunique effects. Validate and organize the material library (CONTENT-0003).\n\n## Disagreement\nSystemic/data-driven materials (scalable, artist-tunable, optimizable) vs. bespoke shaders\n(maximal control per effect, but unscalable) — the same data-driven-vs-YAGNI tension as ARCH-0001,\nin the rendering domain. Systemic by default; bespoke where a unique effect earns it.\n\n## Notes\nThe rendering application of data-driven design (ARCH-0001) and creator-empowerment\n(CONTENT-0002); keeps rendering cost (TECH-0002) manageable. Confidence 4.\n","searchText":"gdc-l1-tech-0005 build materials and shaders as a data-driven system, not one-offs technical-art shaders materials data-driven reuse > build materials and shaders as a system — a small set of flexible master materials driven by parameters and instanced for variation — rather than a pile of bespoke one-off shaders. data-driven materials let artists produce and tune vast visual variety without new code, and keep the rendering cost and pipeline manageable. authoring a unique shader per material doesn't scale: it multiplies engineering work, fragments the rendering pipeline, makes optimization impossible, and locks artists out of their own materials [s-realtime-rendering]. a systemic approach — master materials exposing parameters, instanced and tuned per asset — is the data-driven-design principle (arch-0001) applied to rendering: behavior and variety live in editable data (material instances) that artists control, while the underlying shaders stay few and optimizable. this empowers content creators (content-0002) to author look variety without programmers, keeps the shader count (and thus rendering cost, tech-0002) under control, and makes the material library consistent and maintainable. it's the same \"build the seam, fill it with data\" logic that runs through the architecture layer. any game with more than a handful of materials — most 3d and many 2d games. the more visual variety, the more a material system pays over one-offs. tiny games with a few materials may not need the abstraction. some genuinely unique effects (a signature hero shader, a special-case visual) warrant a bespoke shader — the rule is \"systemic by default, bespoke by exception,\" not \"never write a custom shader.\" over-parameterizing a master material into an unusable monster is its own failure (the yagni caution from arch-0001). author a small set of flexible master materials with exposed parameters; create variation through material instances, not new shaders. let artists tune instances without code (content-0002). keep shader permutations and cost in check (tech-0002). reserve bespoke shaders for genuinely unique effects. validate and organize the material library (content-0003). systemic/data-driven materials (scalable, artist-tunable, optimizable) vs. bespoke shaders (maximal control per effect, but unscalable) — the same data-driven-vs-yagni tension as arch-0001, in the rendering domain. systemic by default; bespoke where a unique effect earns it. the rendering application of data-driven design (arch-0001) and creator-empowerment (content-0002); keeps rendering cost (tech-0002) manageable. confidence 4."}
{"id":"GDC-L1-ANIM-0001","title":"Apply the principles of animation — games are animation too","layer":"L1","domain":"ANIM","subdomain":"principles-of-animation","type":"contextual","confidence":4,"status":"canonical","tags":["animation","principles","squash-stretch","anticipation","timing"],"related":["GDC-L1-FEEL-0001","GDC-L1-ANIM-0003","GDC-L1-ANIM-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-thomas-johnston-animation","S-cooper-game-anim"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ANIM-0001.md","statement":"The classical principles of animation — squash & stretch, anticipation, staging, follow-through and overlapping action, timing, exaggeration, secondary action — apply to games. They are what make motion read as alive and weighty; a game that ignores them looks stiff and lifeless even when technically correct.","sections":{"Statement":"> The classical principles of animation — squash & stretch, anticipation, staging,\n> follow-through and overlapping action, timing, exaggeration, secondary action — apply to\n> games. They are what make motion read as *alive* and *weighty*; a game that ignores them\n> looks stiff and lifeless even when technically correct.","Rationale":"The twelve principles distilled by Disney's animators are not a house style; they are how\nhuman perception reads motion as believable and expressive, which is why they transfer\ndirectly to game animation [S-thomas-johnston-animation] [S-cooper-game-anim]. Anticipation\nmakes an action readable before it lands; squash & stretch and follow-through give it weight\nand life; timing and exaggeration make it feel right rather than merely correct. A game whose\nmotion ignores them reads as robotic — accurate poses interpolated without life — no matter\nhow good the models are. Because animation is a huge part of game feel (FEEL-0001, the\n\"polish\" layer), these principles are a primary lever on how a game *feels* to watch and\ncontrol, not just how it looks.","Applies when":"Any game with meaningful character or object animation — most action, adventure, platformer,\nand character-driven games. The more the animation carries expression or feedback, the more\nthe principles matter.","Does not apply / Exceptions":"Games use the principles *in service of gameplay*, not as pure film craft — several bend\nunder the responsiveness constraint (ANIM-0002), e.g. anticipation must be short enough not\nto add input lag on a player action. Abstract, minimalist, or deliberately-stylized games\n(flat 2D, geometric) apply only the subset that fits their style. And technical/simulation\ncontexts may prioritize accuracy over expressive animation.","Implementation (kept separate from the principle)":"Learn the twelve principles and apply them within game constraints: use anticipation and\nfollow-through for readability and weight, timing and exaggeration for feel, secondary motion\nfor life (ANIM-0005). Adapt each to the responsiveness budget (ANIM-0002) — e.g. keep\nanticipation on player-initiated actions minimal or cancelable. Judge animation by how it\nreads and feels in play (PLAYTEST-0001), not by how it looks in isolation.","Disagreement":"No serious dissent that the principles apply; the game-specific tension is *how much* to\nhonor them against responsiveness and functionality (ANIM-0002, ANIM-0004) — full film-style\nfollow-through vs. snappy, cancelable game motion. Games resolve it case by case, gameplay\nfirst.","Notes":"The craft foundation of the ANIM domain and a major contributor to the \"polish\" layer of game\nfeel (FEEL-0001). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-ANIM-0001\ntitle: Apply the principles of animation — games are animation too\nlayer: L1\ndomain: ANIM\nsubdomain: principles-of-animation\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - animation\n  - principles\n  - squash-stretch\n  - anticipation\n  - timing\nrelated:\n  - GDC-L1-FEEL-0001\n  - GDC-L1-ANIM-0003\n  - GDC-L1-ANIM-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-thomas-johnston-animation\n  - S-cooper-game-anim\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> The classical principles of animation — squash & stretch, anticipation, staging,\n> follow-through and overlapping action, timing, exaggeration, secondary action — apply to\n> games. They are what make motion read as *alive* and *weighty*; a game that ignores them\n> looks stiff and lifeless even when technically correct.\n\n## Rationale\nThe twelve principles distilled by Disney's animators are not a house style; they are how\nhuman perception reads motion as believable and expressive, which is why they transfer\ndirectly to game animation [S-thomas-johnston-animation] [S-cooper-game-anim]. Anticipation\nmakes an action readable before it lands; squash & stretch and follow-through give it weight\nand life; timing and exaggeration make it feel right rather than merely correct. A game whose\nmotion ignores them reads as robotic — accurate poses interpolated without life — no matter\nhow good the models are. Because animation is a huge part of game feel (FEEL-0001, the\n\"polish\" layer), these principles are a primary lever on how a game *feels* to watch and\ncontrol, not just how it looks.\n\n## Applies when\nAny game with meaningful character or object animation — most action, adventure, platformer,\nand character-driven games. The more the animation carries expression or feedback, the more\nthe principles matter.\n\n## Does not apply / Exceptions\nGames use the principles *in service of gameplay*, not as pure film craft — several bend\nunder the responsiveness constraint (ANIM-0002), e.g. anticipation must be short enough not\nto add input lag on a player action. Abstract, minimalist, or deliberately-stylized games\n(flat 2D, geometric) apply only the subset that fits their style. And technical/simulation\ncontexts may prioritize accuracy over expressive animation.\n\n## Implementation (kept separate from the principle)\nLearn the twelve principles and apply them within game constraints: use anticipation and\nfollow-through for readability and weight, timing and exaggeration for feel, secondary motion\nfor life (ANIM-0005). Adapt each to the responsiveness budget (ANIM-0002) — e.g. keep\nanticipation on player-initiated actions minimal or cancelable. Judge animation by how it\nreads and feels in play (PLAYTEST-0001), not by how it looks in isolation.\n\n## Disagreement\nNo serious dissent that the principles apply; the game-specific tension is *how much* to\nhonor them against responsiveness and functionality (ANIM-0002, ANIM-0004) — full film-style\nfollow-through vs. snappy, cancelable game motion. Games resolve it case by case, gameplay\nfirst.\n\n## Notes\nThe craft foundation of the ANIM domain and a major contributor to the \"polish\" layer of game\nfeel (FEEL-0001). Confidence 4.\n","searchText":"gdc-l1-anim-0001 apply the principles of animation — games are animation too animation principles squash-stretch anticipation timing > the classical principles of animation — squash & stretch, anticipation, staging, follow-through and overlapping action, timing, exaggeration, secondary action — apply to games. they are what make motion read as alive and weighty; a game that ignores them looks stiff and lifeless even when technically correct. the twelve principles distilled by disney's animators are not a house style; they are how human perception reads motion as believable and expressive, which is why they transfer directly to game animation [s-thomas-johnston-animation] [s-cooper-game-anim]. anticipation makes an action readable before it lands; squash & stretch and follow-through give it weight and life; timing and exaggeration make it feel right rather than merely correct. a game whose motion ignores them reads as robotic — accurate poses interpolated without life — no matter how good the models are. because animation is a huge part of game feel (feel-0001, the \"polish\" layer), these principles are a primary lever on how a game feels to watch and control, not just how it looks. any game with meaningful character or object animation — most action, adventure, platformer, and character-driven games. the more the animation carries expression or feedback, the more the principles matter. games use the principles in service of gameplay, not as pure film craft — several bend under the responsiveness constraint (anim-0002), e.g. anticipation must be short enough not to add input lag on a player action. abstract, minimalist, or deliberately-stylized games (flat 2d, geometric) apply only the subset that fits their style. and technical/simulation contexts may prioritize accuracy over expressive animation. learn the twelve principles and apply them within game constraints: use anticipation and follow-through for readability and weight, timing and exaggeration for feel, secondary motion for life (anim-0005). adapt each to the responsiveness budget (anim-0002) — e.g. keep anticipation on player-initiated actions minimal or cancelable. judge animation by how it reads and feels in play (playtest-0001), not by how it looks in isolation. no serious dissent that the principles apply; the game-specific tension is how much to honor them against responsiveness and functionality (anim-0002, anim-0004) — full film-style follow-through vs. snappy, cancelable game motion. games resolve it case by case, gameplay first. the craft foundation of the anim domain and a major contributor to the \"polish\" layer of game feel (feel-0001). confidence 4."}
{"id":"GDC-L1-ANIM-0002","title":"Responsiveness beats fidelity — never let animation block input","layer":"L1","domain":"ANIM","subdomain":"responsiveness-vs-fidelity","type":"contextual","confidence":4,"status":"canonical","tags":["animation","responsiveness","input","cancel-windows","game-feel"],"related":["GDC-L1-FEEL-0002","GDC-L1-FEEL-0008","GDC-L1-ANIM-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-cooper-game-anim"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ANIM-0002.md","statement":"In games, the player's control comes first. Beautiful animation that delays or blocks the player's next action feels worse than cruder animation that stays responsive. Give the player back control before an animation fully finishes (cancel windows), and let the follow-through play out only if no new input arrives.","sections":{"Statement":"> In games, the player's control comes first. Beautiful animation that *delays or blocks* the\n> player's next action feels worse than cruder animation that stays responsive. Give the\n> player back control before an animation fully finishes (cancel windows), and let the\n> follow-through play out only if no new input arrives.","Rationale":"Game animation is functional, not just visual: it must coexist with snappy controls,\ncollision, and the player's need to act *now* [S-cooper-game-anim]. A gorgeous attack\nanimation that locks the player out for its full duration reads as sluggish and unresponsive,\nviolating the responsiveness ideal (FEEL-0002) — the player experiences it as input lag, not\nas beauty. The craft technique is to decouple *control* from *display*: specify a frame where\nthe player regains control before the animation ends, so the follow-through plays fully when\nthere's no new input but yields instantly when the player acts again. This is the animation\nform of \"acknowledge input instantly\" (FEEL-0002) and a key lever on the\nresponsiveness–commitment axis (FEEL-0008): how long an animation holds the player is a\ndesign dial, not an accident of the animation's length.","Applies when":"Any real-time game where the player controls an animated avatar — action, platformer,\nfighting, character-action. Sharpest for fast, skill-expressive games where every frame of\nlockout is felt.","Does not apply / Exceptions":"Deliberately weighty, commitment-heavy games (souls-likes, some fighting games) *choose*\nlonger animation commitment as a feature (FEEL-0008) — there the animation's hold is the\nintended risk/weight, not a defect. And non-interactive animation (cutscenes, ambient NPCs)\nhas no responsiveness constraint and can prioritize fidelity fully. The rule governs\n*player-controlled* action animation.","Implementation (kept separate from the principle)":"Author cancel windows and \"regain control\" frames into gameplay animations so the player is never locked out longer than the design intends. Prefer responsiveness on the player's core verbs; reserve full commitment for actions where weight is the point (FEEL-0008). Tune the lockout by feel in playtest — if players report \"sluggish,\" it's usually animation lockout, not latency.","Disagreement":"This is the FEEL-0008 responsiveness–commitment axis expressed in animation: snappy/cancelable\n(control-first) vs. committed/weighty (fidelity-and-weight-first). Both are valid for their\nfantasies; the invariant is that lockout be a *deliberate design choice*, not an accident of\nhow long the animator made the clip.","Notes":"The core game-animation tension; the animation arm of FEEL-0002 (responsiveness) and FEEL-0008\n(commitment). Its movement form is ANIM-0004 (root motion vs. code-driven). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-ANIM-0002\ntitle: Responsiveness beats fidelity — never let animation block input\nlayer: L1\ndomain: ANIM\nsubdomain: responsiveness-vs-fidelity\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - animation\n  - responsiveness\n  - input\n  - cancel-windows\n  - game-feel\nrelated:\n  - GDC-L1-FEEL-0002\n  - GDC-L1-FEEL-0008\n  - GDC-L1-ANIM-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-cooper-game-anim\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> In games, the player's control comes first. Beautiful animation that *delays or blocks* the\n> player's next action feels worse than cruder animation that stays responsive. Give the\n> player back control before an animation fully finishes (cancel windows), and let the\n> follow-through play out only if no new input arrives.\n\n## Rationale\nGame animation is functional, not just visual: it must coexist with snappy controls,\ncollision, and the player's need to act *now* [S-cooper-game-anim]. A gorgeous attack\nanimation that locks the player out for its full duration reads as sluggish and unresponsive,\nviolating the responsiveness ideal (FEEL-0002) — the player experiences it as input lag, not\nas beauty. The craft technique is to decouple *control* from *display*: specify a frame where\nthe player regains control before the animation ends, so the follow-through plays fully when\nthere's no new input but yields instantly when the player acts again. This is the animation\nform of \"acknowledge input instantly\" (FEEL-0002) and a key lever on the\nresponsiveness–commitment axis (FEEL-0008): how long an animation holds the player is a\ndesign dial, not an accident of the animation's length.\n\n## Applies when\nAny real-time game where the player controls an animated avatar — action, platformer,\nfighting, character-action. Sharpest for fast, skill-expressive games where every frame of\nlockout is felt.\n\n## Does not apply / Exceptions\nDeliberately weighty, commitment-heavy games (souls-likes, some fighting games) *choose*\nlonger animation commitment as a feature (FEEL-0008) — there the animation's hold is the\nintended risk/weight, not a defect. And non-interactive animation (cutscenes, ambient NPCs)\nhas no responsiveness constraint and can prioritize fidelity fully. The rule governs\n*player-controlled* action animation.\n\n## Implementation (kept separate from the principle)\nAuthor cancel windows and \"regain control\" frames into gameplay animations so the player is never locked out longer than the design intends. Prefer responsiveness on the player's core verbs; reserve full commitment for actions where weight is the point (FEEL-0008). Tune the lockout by feel in playtest — if players report \"sluggish,\" it's usually animation lockout, not latency.\n\n## Disagreement\nThis is the FEEL-0008 responsiveness–commitment axis expressed in animation: snappy/cancelable\n(control-first) vs. committed/weighty (fidelity-and-weight-first). Both are valid for their\nfantasies; the invariant is that lockout be a *deliberate design choice*, not an accident of\nhow long the animator made the clip.\n\n## Notes\nThe core game-animation tension; the animation arm of FEEL-0002 (responsiveness) and FEEL-0008\n(commitment). Its movement form is ANIM-0004 (root motion vs. code-driven). Confidence 4.\n","searchText":"gdc-l1-anim-0002 responsiveness beats fidelity — never let animation block input animation responsiveness input cancel-windows game-feel > in games, the player's control comes first. beautiful animation that delays or blocks the player's next action feels worse than cruder animation that stays responsive. give the player back control before an animation fully finishes (cancel windows), and let the follow-through play out only if no new input arrives. game animation is functional, not just visual: it must coexist with snappy controls, collision, and the player's need to act now [s-cooper-game-anim]. a gorgeous attack animation that locks the player out for its full duration reads as sluggish and unresponsive, violating the responsiveness ideal (feel-0002) — the player experiences it as input lag, not as beauty. the craft technique is to decouple control from display: specify a frame where the player regains control before the animation ends, so the follow-through plays fully when there's no new input but yields instantly when the player acts again. this is the animation form of \"acknowledge input instantly\" (feel-0002) and a key lever on the responsiveness–commitment axis (feel-0008): how long an animation holds the player is a design dial, not an accident of the animation's length. any real-time game where the player controls an animated avatar — action, platformer, fighting, character-action. sharpest for fast, skill-expressive games where every frame of lockout is felt. deliberately weighty, commitment-heavy games (souls-likes, some fighting games) choose longer animation commitment as a feature (feel-0008) — there the animation's hold is the intended risk/weight, not a defect. and non-interactive animation (cutscenes, ambient npcs) has no responsiveness constraint and can prioritize fidelity fully. the rule governs player-controlled action animation. author cancel windows and \"regain control\" frames into gameplay animations so the player is never locked out longer than the design intends. prefer responsiveness on the player's core verbs; reserve full commitment for actions where weight is the point (feel-0008). tune the lockout by feel in playtest — if players report \"sluggish,\" it's usually animation lockout, not latency. this is the feel-0008 responsiveness–commitment axis expressed in animation: snappy/cancelable (control-first) vs. committed/weighty (fidelity-and-weight-first). both are valid for their fantasies; the invariant is that lockout be a deliberate design choice, not an accident of how long the animator made the clip. the core game-animation tension; the animation arm of feel-0002 (responsiveness) and feel-0008 (commitment). its movement form is anim-0004 (root motion vs. code-driven). confidence 4."}
{"id":"GDC-L1-ANIM-0003","title":"Animation is feedback — it communicates state and sells action","layer":"L1","domain":"ANIM","subdomain":"gameplay-animation","type":"contextual","confidence":4,"status":"canonical","tags":["animation","feedback","readability","telegraphing","communication"],"related":["GDC-L1-FEEL-0004","GDC-L1-UX-0003","GDC-L1-ANIM-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-cooper-game-anim"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ANIM-0003.md","statement":"Animation is a communication channel, not just decoration. Wind-ups telegraph attacks, hit reactions confirm damage, idle tells convey state, recovery frames signal vulnerability. Animate to inform the player as much as to look good — a readable-but-plain animation beats a gorgeous-but-illegible one.","sections":{"Statement":"> Animation is a communication channel, not just decoration. Wind-ups telegraph attacks, hit\n> reactions confirm damage, idle tells convey state, recovery frames signal vulnerability.\n> Animate to *inform* the player as much as to look good — a readable-but-plain animation\n> beats a gorgeous-but-illegible one.","Rationale":"Players read animation to know what's happening and what to do: an enemy's wind-up tells them\nwhen to dodge, a stagger confirms their hit landed, a character's posture signals low health\n[S-cooper-game-anim]. This makes animation part of the game's feedback system (FEEL-0004) and\nits readability (UX-0003, SYS-0006) — the animation of an attack is often the *only* fair\nwarning the player gets, so its clarity is a gameplay property, not just an aesthetic one. An\nanimation that looks stunning but doesn't clearly telegraph its gameplay meaning makes the game\nfeel unfair; a plainer animation that reads instantly makes it feel fair and responsive. This\nis also why anticipation (ANIM-0001) matters mechanically, not just artistically — it *is* the\ntelegraph.","Applies when":"Any gameplay animation the player must read to respond — combat (enemy tells, hit reactions,\nrecovery), platforming (jump/land states), and any action with timing the player reacts to.","Does not apply / Exceptions":"Purely ambient or cosmetic animation (background life, non-threat NPCs) doesn't carry gameplay\ninformation and can prioritize beauty freely. And some designs deliberately *reduce* readability\nfor difficulty or dread (a boss with subtle tells is a harder, tenser fight) — but that's a\ndeliberate difficulty choice, and even then the information must be *there* to be learned, not\nabsent. Fairness requires that the telegraph exist, however subtle.","Implementation (kept separate from the principle)":"Design gameplay animations around their *communicative* job: clear, distinct wind-ups for\nattacks (with anticipation, ANIM-0001); unambiguous hit reactions and recovery frames; readable\nstate tells. Make gameplay-critical animations distinguishable from each other at speed. Where\nyou dial down readability for difficulty, keep the tell present and learnable. Test whether\nplayers actually read the animations in play (PLAYTEST-0001), not whether they look good in\nisolation.","Disagreement":"Readability-first (clear tells, fair, sometimes less flashy) vs. spectacle/realism-first\n(gorgeous, immersive, sometimes harder to read) — competitive and action games lean readability;\ncinematic and spectacle games lean fidelity. The reconciliation: gameplay-critical animation\nmust communicate; cosmetic animation can indulge.","Notes":"The animation form of feedback (FEEL-0004) and readability (UX-0003, SYS-0006); the mechanical\nreason anticipation (ANIM-0001) matters. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-ANIM-0003\ntitle: Animation is feedback — it communicates state and sells action\nlayer: L1\ndomain: ANIM\nsubdomain: gameplay-animation\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - animation\n  - feedback\n  - readability\n  - telegraphing\n  - communication\nrelated:\n  - GDC-L1-FEEL-0004\n  - GDC-L1-UX-0003\n  - GDC-L1-ANIM-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-cooper-game-anim\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Animation is a communication channel, not just decoration. Wind-ups telegraph attacks, hit\n> reactions confirm damage, idle tells convey state, recovery frames signal vulnerability.\n> Animate to *inform* the player as much as to look good — a readable-but-plain animation\n> beats a gorgeous-but-illegible one.\n\n## Rationale\nPlayers read animation to know what's happening and what to do: an enemy's wind-up tells them\nwhen to dodge, a stagger confirms their hit landed, a character's posture signals low health\n[S-cooper-game-anim]. This makes animation part of the game's feedback system (FEEL-0004) and\nits readability (UX-0003, SYS-0006) — the animation of an attack is often the *only* fair\nwarning the player gets, so its clarity is a gameplay property, not just an aesthetic one. An\nanimation that looks stunning but doesn't clearly telegraph its gameplay meaning makes the game\nfeel unfair; a plainer animation that reads instantly makes it feel fair and responsive. This\nis also why anticipation (ANIM-0001) matters mechanically, not just artistically — it *is* the\ntelegraph.\n\n## Applies when\nAny gameplay animation the player must read to respond — combat (enemy tells, hit reactions,\nrecovery), platforming (jump/land states), and any action with timing the player reacts to.\n\n## Does not apply / Exceptions\nPurely ambient or cosmetic animation (background life, non-threat NPCs) doesn't carry gameplay\ninformation and can prioritize beauty freely. And some designs deliberately *reduce* readability\nfor difficulty or dread (a boss with subtle tells is a harder, tenser fight) — but that's a\ndeliberate difficulty choice, and even then the information must be *there* to be learned, not\nabsent. Fairness requires that the telegraph exist, however subtle.\n\n## Implementation (kept separate from the principle)\nDesign gameplay animations around their *communicative* job: clear, distinct wind-ups for\nattacks (with anticipation, ANIM-0001); unambiguous hit reactions and recovery frames; readable\nstate tells. Make gameplay-critical animations distinguishable from each other at speed. Where\nyou dial down readability for difficulty, keep the tell present and learnable. Test whether\nplayers actually read the animations in play (PLAYTEST-0001), not whether they look good in\nisolation.\n\n## Disagreement\nReadability-first (clear tells, fair, sometimes less flashy) vs. spectacle/realism-first\n(gorgeous, immersive, sometimes harder to read) — competitive and action games lean readability;\ncinematic and spectacle games lean fidelity. The reconciliation: gameplay-critical animation\nmust communicate; cosmetic animation can indulge.\n\n## Notes\nThe animation form of feedback (FEEL-0004) and readability (UX-0003, SYS-0006); the mechanical\nreason anticipation (ANIM-0001) matters. Confidence 4.\n","searchText":"gdc-l1-anim-0003 animation is feedback — it communicates state and sells action animation feedback readability telegraphing communication > animation is a communication channel, not just decoration. wind-ups telegraph attacks, hit reactions confirm damage, idle tells convey state, recovery frames signal vulnerability. animate to inform the player as much as to look good — a readable-but-plain animation beats a gorgeous-but-illegible one. players read animation to know what's happening and what to do: an enemy's wind-up tells them when to dodge, a stagger confirms their hit landed, a character's posture signals low health [s-cooper-game-anim]. this makes animation part of the game's feedback system (feel-0004) and its readability (ux-0003, sys-0006) — the animation of an attack is often the only fair warning the player gets, so its clarity is a gameplay property, not just an aesthetic one. an animation that looks stunning but doesn't clearly telegraph its gameplay meaning makes the game feel unfair; a plainer animation that reads instantly makes it feel fair and responsive. this is also why anticipation (anim-0001) matters mechanically, not just artistically — it is the telegraph. any gameplay animation the player must read to respond — combat (enemy tells, hit reactions, recovery), platforming (jump/land states), and any action with timing the player reacts to. purely ambient or cosmetic animation (background life, non-threat npcs) doesn't carry gameplay information and can prioritize beauty freely. and some designs deliberately reduce readability for difficulty or dread (a boss with subtle tells is a harder, tenser fight) — but that's a deliberate difficulty choice, and even then the information must be there to be learned, not absent. fairness requires that the telegraph exist, however subtle. design gameplay animations around their communicative job: clear, distinct wind-ups for attacks (with anticipation, anim-0001); unambiguous hit reactions and recovery frames; readable state tells. make gameplay-critical animations distinguishable from each other at speed. where you dial down readability for difficulty, keep the tell present and learnable. test whether players actually read the animations in play (playtest-0001), not whether they look good in isolation. readability-first (clear tells, fair, sometimes less flashy) vs. spectacle/realism-first (gorgeous, immersive, sometimes harder to read) — competitive and action games lean readability; cinematic and spectacle games lean fidelity. the reconciliation: gameplay-critical animation must communicate; cosmetic animation can indulge. the animation form of feedback (feel-0004) and readability (ux-0003, sys-0006); the mechanical reason anticipation (anim-0001) matters. confidence 4."}
{"id":"GDC-L1-ANIM-0004","title":"Choose your point on the root-motion vs. code-driven axis deliberately","layer":"L1","domain":"ANIM","subdomain":"root-motion-vs-in-place","type":"contextual","confidence":4,"status":"canonical","tags":["animation","root-motion","locomotion","responsiveness","weight"],"related":["GDC-L1-FEEL-0008","GDC-L1-ANIM-0002","GDC-L1-FEEL-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-cooper-game-anim"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ANIM-0004.md","statement":"Movement can be driven by the animation (root motion — precise, weighty, visually connected, but less responsive and harder to tweak) or by code (in-place / procedural — responsive, tweakable, but can feel floaty and disconnected from the animation). Choose the approach deliberately, per action; it is the animation form of the responsiveness–commitment tradeoff.","sections":{"Statement":"> Movement can be driven by the animation (**root motion** — precise, weighty, visually\n> connected, but less responsive and harder to tweak) or by code (**in-place / procedural** —\n> responsive, tweakable, but can feel floaty and disconnected from the animation). Choose the\n> approach deliberately, per action; it is the animation form of the responsiveness–commitment\n> tradeoff.","Rationale":"The two locomotion approaches sit at opposite ends of the same tension. Code-driven movement\nlets you set exact speeds and turn rates and change them instantly — fast, responsive, easy to\ntune — but the animation is just played on top, so it can slide, float, or desync from the\nmotion [S-cooper-game-anim]. Root motion bakes the movement into the animation itself, so the\ncharacter's feet and body match its travel exactly, giving weight and a strong\nanimation-to-motion connection — at the cost of responsiveness (you're committed to the\nanimation's path) and tweakability. This is FEEL-0008 (responsiveness vs. commitment) and\nANIM-0002 (responsiveness vs. fidelity) made concrete in locomotion: root motion buys weight\nand precision by spending responsiveness; code-driven buys responsiveness by spending visual\nconnection. Neither is right in general; the right choice depends per action on whether that\nmotion should feel *snappy* or *grounded*.","Applies when":"Locomotion and movement-action design — walking/running, dodges, rolls, attacks that travel,\ntraversal. Especially where weight vs. snappiness is a defining feel choice.","Does not apply / Exceptions":"Many games mix both — code-driven locomotion for responsive general movement, root motion for\nspecific weighty actions (a committed dodge-roll, a lunging attack) — so it's per-action, not a\nwhole-game commitment. Hybrid and blended approaches (partial root motion, motion warping) blur\nthe line. And highly stylized or abstract games may not care about the visual-connection\nbenefit root motion provides.","Implementation (kept separate from the principle)":"Use motion-warping/blending to get some of both where needed. Expose the code-driven parameters for tuning (ARCH-0001). Judge by feel in playtest.","Disagreement":"Root-motion (weight, precision, visual fidelity) vs. code-driven (responsiveness, tweakability)\n— the same axis as FEEL-0008/ANIM-0002, specific to how movement is produced. Weighty,\ngrounded games lean root motion; fast, snappy games lean code-driven; most blend per action.","Notes":"Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-ANIM-0004\ntitle: Choose your point on the root-motion vs. code-driven axis deliberately\nlayer: L1\ndomain: ANIM\nsubdomain: root-motion-vs-in-place\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - animation\n  - root-motion\n  - locomotion\n  - responsiveness\n  - weight\nrelated:\n  - GDC-L1-FEEL-0008\n  - GDC-L1-ANIM-0002\n  - GDC-L1-FEEL-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-cooper-game-anim\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Movement can be driven by the animation (**root motion** — precise, weighty, visually\n> connected, but less responsive and harder to tweak) or by code (**in-place / procedural** —\n> responsive, tweakable, but can feel floaty and disconnected from the animation). Choose the\n> approach deliberately, per action; it is the animation form of the responsiveness–commitment\n> tradeoff.\n\n## Rationale\nThe two locomotion approaches sit at opposite ends of the same tension. Code-driven movement\nlets you set exact speeds and turn rates and change them instantly — fast, responsive, easy to\ntune — but the animation is just played on top, so it can slide, float, or desync from the\nmotion [S-cooper-game-anim]. Root motion bakes the movement into the animation itself, so the\ncharacter's feet and body match its travel exactly, giving weight and a strong\nanimation-to-motion connection — at the cost of responsiveness (you're committed to the\nanimation's path) and tweakability. This is FEEL-0008 (responsiveness vs. commitment) and\nANIM-0002 (responsiveness vs. fidelity) made concrete in locomotion: root motion buys weight\nand precision by spending responsiveness; code-driven buys responsiveness by spending visual\nconnection. Neither is right in general; the right choice depends per action on whether that\nmotion should feel *snappy* or *grounded*.\n\n## Applies when\nLocomotion and movement-action design — walking/running, dodges, rolls, attacks that travel,\ntraversal. Especially where weight vs. snappiness is a defining feel choice.\n\n## Does not apply / Exceptions\nMany games mix both — code-driven locomotion for responsive general movement, root motion for\nspecific weighty actions (a committed dodge-roll, a lunging attack) — so it's per-action, not a\nwhole-game commitment. Hybrid and blended approaches (partial root motion, motion warping) blur\nthe line. And highly stylized or abstract games may not care about the visual-connection\nbenefit root motion provides.\n\n## Implementation (kept separate from the principle)\nUse motion-warping/blending to get some of both where needed. Expose the code-driven parameters for tuning (ARCH-0001). Judge by feel in playtest.\n\n## Disagreement\nRoot-motion (weight, precision, visual fidelity) vs. code-driven (responsiveness, tweakability)\n— the same axis as FEEL-0008/ANIM-0002, specific to how movement is produced. Weighty,\ngrounded games lean root motion; fast, snappy games lean code-driven; most blend per action.\n\n## Notes\nConfidence 4.\n","searchText":"gdc-l1-anim-0004 choose your point on the root-motion vs. code-driven axis deliberately animation root-motion locomotion responsiveness weight > movement can be driven by the animation (root motion — precise, weighty, visually connected, but less responsive and harder to tweak) or by code (in-place / procedural — responsive, tweakable, but can feel floaty and disconnected from the animation). choose the approach deliberately, per action; it is the animation form of the responsiveness–commitment tradeoff. the two locomotion approaches sit at opposite ends of the same tension. code-driven movement lets you set exact speeds and turn rates and change them instantly — fast, responsive, easy to tune — but the animation is just played on top, so it can slide, float, or desync from the motion [s-cooper-game-anim]. root motion bakes the movement into the animation itself, so the character's feet and body match its travel exactly, giving weight and a strong animation-to-motion connection — at the cost of responsiveness (you're committed to the animation's path) and tweakability. this is feel-0008 (responsiveness vs. commitment) and anim-0002 (responsiveness vs. fidelity) made concrete in locomotion: root motion buys weight and precision by spending responsiveness; code-driven buys responsiveness by spending visual connection. neither is right in general; the right choice depends per action on whether that motion should feel snappy or grounded. locomotion and movement-action design — walking/running, dodges, rolls, attacks that travel, traversal. especially where weight vs. snappiness is a defining feel choice. many games mix both — code-driven locomotion for responsive general movement, root motion for specific weighty actions (a committed dodge-roll, a lunging attack) — so it's per-action, not a whole-game commitment. hybrid and blended approaches (partial root motion, motion warping) blur the line. and highly stylized or abstract games may not care about the visual-connection benefit root motion provides. use motion-warping/blending to get some of both where needed. expose the code-driven parameters for tuning (arch-0001). judge by feel in playtest. root-motion (weight, precision, visual fidelity) vs. code-driven (responsiveness, tweakability) — the same axis as feel-0008/anim-0002, specific to how movement is produced. weighty, grounded games lean root motion; fast, snappy games lean code-driven; most blend per action. confidence 4."}
{"id":"GDC-L1-ANIM-0005","title":"Life is in the secondary motion — animate more than the primary action","layer":"L1","domain":"ANIM","subdomain":"procedural","type":"contextual","confidence":3,"status":"canonical","tags":["animation","secondary-motion","overlapping-action","polish","life"],"related":["GDC-L1-ANIM-0001","GDC-L1-FEEL-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-thomas-johnston-animation","S-cooper-game-anim"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-ANIM-0005.md","statement":"Believable characters and worlds come from secondary and overlapping motion — cloth, hair, follow-through, idle breathing, weight shifts, reactions — layered on top of the primary action. Purely-primary motion reads as robotic; the incidental movement is what sells life.","sections":{"Statement":"> Believable characters and worlds come from **secondary and overlapping motion** — cloth,\n> hair, follow-through, idle breathing, weight shifts, reactions — layered on top of the\n> primary action. Purely-primary motion reads as robotic; the incidental movement is what\n> sells life.","Rationale":"Real bodies and objects don't move in one rigid piece: when a character stops, momentum carries\ntheir hair and coat a beat longer; when they stand still, they still breathe and shift weight;\nwhen hit, they react [S-thomas-johnston-animation]. This overlapping, secondary motion is a\nlarge part of what the eye reads as *alive* — its absence is exactly why stiff animation looks\ndead even with correct primary poses. In games this is often layered procedurally (physics on\ncloth/hair, additive idle motion, procedural reactions) so it responds dynamically to whatever\nthe primary animation and gameplay do [S-cooper-game-anim]. It's a high-value part of the polish\nlayer of game feel (FEEL-0004/FEEL-0001): relatively cheap secondary motion can bring an\notherwise-stiff character to life.","Applies when":"Character animation and any animated object where believability or life matters — especially\nidles, reactions, and moments the player watches closely.","Does not apply / Exceptions":"Stylized and minimalist aesthetics deliberately omit or simplify secondary motion (snappy 2D,\ngeometric, retro styles read as intentional, not dead). Performance budgets limit how much\nprocedural secondary motion (cloth/hair sims) you can afford, especially with many characters\n(PERF). And gameplay-critical readability (ANIM-0003) takes priority — secondary motion must not\nobscure the primary action's tell.","Implementation (kept separate from the principle)":"Layer secondary motion on primary animation: procedural/physics cloth and hair, additive idle\nbreathing and weight shifts, follow-through and overlap, dynamic reactions. Keep it subordinate\nto gameplay readability (ANIM-0003) and within performance budget (PERF-0004). Even simple\nadditive idles and follow-through dramatically raise perceived life for low cost.","Disagreement":"Rich secondary motion (life, believability, immersion — at performance/production cost) vs.\nminimal/stylized motion (snappy, cheap, intentional aesthetic). Realistic and\ncharacter-driven games lean rich; stylized and performance-constrained games lean minimal.\nConfidence 3: clearly effective, but how much secondary motion is right is highly\nstyle-and-budget-dependent.","Notes":"The \"life\" contributor to the polish layer of game feel (FEEL-0001/0004); an application of the\noverlapping-action principle (ANIM-0001). Confidence 3."},"rawMarkdown":"---\nid: GDC-L1-ANIM-0005\ntitle: Life is in the secondary motion — animate more than the primary action\nlayer: L1\ndomain: ANIM\nsubdomain: procedural\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - animation\n  - secondary-motion\n  - overlapping-action\n  - polish\n  - life\nrelated:\n  - GDC-L1-ANIM-0001\n  - GDC-L1-FEEL-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-thomas-johnston-animation\n  - S-cooper-game-anim\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Believable characters and worlds come from **secondary and overlapping motion** — cloth,\n> hair, follow-through, idle breathing, weight shifts, reactions — layered on top of the\n> primary action. Purely-primary motion reads as robotic; the incidental movement is what\n> sells life.\n\n## Rationale\nReal bodies and objects don't move in one rigid piece: when a character stops, momentum carries\ntheir hair and coat a beat longer; when they stand still, they still breathe and shift weight;\nwhen hit, they react [S-thomas-johnston-animation]. This overlapping, secondary motion is a\nlarge part of what the eye reads as *alive* — its absence is exactly why stiff animation looks\ndead even with correct primary poses. In games this is often layered procedurally (physics on\ncloth/hair, additive idle motion, procedural reactions) so it responds dynamically to whatever\nthe primary animation and gameplay do [S-cooper-game-anim]. It's a high-value part of the polish\nlayer of game feel (FEEL-0004/FEEL-0001): relatively cheap secondary motion can bring an\notherwise-stiff character to life.\n\n## Applies when\nCharacter animation and any animated object where believability or life matters — especially\nidles, reactions, and moments the player watches closely.\n\n## Does not apply / Exceptions\nStylized and minimalist aesthetics deliberately omit or simplify secondary motion (snappy 2D,\ngeometric, retro styles read as intentional, not dead). Performance budgets limit how much\nprocedural secondary motion (cloth/hair sims) you can afford, especially with many characters\n(PERF). And gameplay-critical readability (ANIM-0003) takes priority — secondary motion must not\nobscure the primary action's tell.\n\n## Implementation (kept separate from the principle)\nLayer secondary motion on primary animation: procedural/physics cloth and hair, additive idle\nbreathing and weight shifts, follow-through and overlap, dynamic reactions. Keep it subordinate\nto gameplay readability (ANIM-0003) and within performance budget (PERF-0004). Even simple\nadditive idles and follow-through dramatically raise perceived life for low cost.\n\n## Disagreement\nRich secondary motion (life, believability, immersion — at performance/production cost) vs.\nminimal/stylized motion (snappy, cheap, intentional aesthetic). Realistic and\ncharacter-driven games lean rich; stylized and performance-constrained games lean minimal.\nConfidence 3: clearly effective, but how much secondary motion is right is highly\nstyle-and-budget-dependent.\n\n## Notes\nThe \"life\" contributor to the polish layer of game feel (FEEL-0001/0004); an application of the\noverlapping-action principle (ANIM-0001). Confidence 3.\n","searchText":"gdc-l1-anim-0005 life is in the secondary motion — animate more than the primary action animation secondary-motion overlapping-action polish life > believable characters and worlds come from secondary and overlapping motion — cloth, hair, follow-through, idle breathing, weight shifts, reactions — layered on top of the primary action. purely-primary motion reads as robotic; the incidental movement is what sells life. real bodies and objects don't move in one rigid piece: when a character stops, momentum carries their hair and coat a beat longer; when they stand still, they still breathe and shift weight; when hit, they react [s-thomas-johnston-animation]. this overlapping, secondary motion is a large part of what the eye reads as alive — its absence is exactly why stiff animation looks dead even with correct primary poses. in games this is often layered procedurally (physics on cloth/hair, additive idle motion, procedural reactions) so it responds dynamically to whatever the primary animation and gameplay do [s-cooper-game-anim]. it's a high-value part of the polish layer of game feel (feel-0004/feel-0001): relatively cheap secondary motion can bring an otherwise-stiff character to life. character animation and any animated object where believability or life matters — especially idles, reactions, and moments the player watches closely. stylized and minimalist aesthetics deliberately omit or simplify secondary motion (snappy 2d, geometric, retro styles read as intentional, not dead). performance budgets limit how much procedural secondary motion (cloth/hair sims) you can afford, especially with many characters (perf). and gameplay-critical readability (anim-0003) takes priority — secondary motion must not obscure the primary action's tell. layer secondary motion on primary animation: procedural/physics cloth and hair, additive idle breathing and weight shifts, follow-through and overlap, dynamic reactions. keep it subordinate to gameplay readability (anim-0003) and within performance budget (perf-0004). even simple additive idles and follow-through dramatically raise perceived life for low cost. rich secondary motion (life, believability, immersion — at performance/production cost) vs. minimal/stylized motion (snappy, cheap, intentional aesthetic). realistic and character-driven games lean rich; stylized and performance-constrained games lean minimal. confidence 3: clearly effective, but how much secondary motion is right is highly style-and-budget-dependent. the \"life\" contributor to the polish layer of game feel (feel-0001/0004); an application of the overlapping-action principle (anim-0001). confidence 3."}
{"id":"GDC-L1-AUDIO-0001","title":"Sound is feedback first — communicate action, state, and event","layer":"L1","domain":"AUDIO","subdomain":"sfx-as-feedback","type":"objective","confidence":4,"status":"canonical","tags":["audio","feedback","sfx","communication"],"related":["GDC-L1-FEEL-0004","GDC-L1-UX-0003","GDC-L1-SYS-0006"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-game-audio-practice","S-collins-game-sound"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-AUDIO-0001.md","statement":"The primary job of game audio is information: confirm that an action happened, signal state changes, and cue events the player must react to. Before sound is atmosphere or music, it is feedback — often the fastest and most reliable channel the player has, because the ear catches things the eye (fixed forward, easily busy) misses.","sections":{"Statement":"> The primary job of game audio is *information*: confirm that an action happened, signal\n> state changes, and cue events the player must react to. Before sound is atmosphere or\n> music, it is **feedback** — often the fastest and most reliable channel the player has,\n> because the ear catches things the eye (fixed forward, easily busy) misses.","Rationale":"A game is a stream of events the player must perceive to respond to, and audio is a superb\ncarrier: a weapon report, a footstep, a UI confirm, a low-health heartbeat, an ability's\ntell all inform the player about actions and consequences instantly and omnidirectionally\n[S-game-audio-practice]. Sound reaches the player even when the relevant thing is off-screen\nor behind other visuals, which is exactly when a purely visual cue fails. This is the audio\narm of the feedback principle (FEEL-0004) and of interface communication (UX-0003): every\nmeaningful event should have a distinct, legible sound so the player can *hear* the game\nstate. Treating audio as mere decoration wastes its most valuable function.","Applies when":"Every meaningful game event and player action — combat, movement, interaction, UI, state\nchanges, warnings. The more the player must react quickly or to off-screen events, the more\naudio feedback matters.","Does not apply / Exceptions":"Audio-free or minimal-audio contexts exist (silent play, accessibility for deaf/hard-of-\nhearing players — which is exactly why critical information must *never* be audio-*only*; pair\nit with visual cues, UX-0006). And not every event needs a sound; over-sonifying trivial\nevents clutters the mix and buries the signals that matter (AUDIO-0004). Atmosphere and music\nare real jobs too — this principle says feedback is the *first* job, not the only one.","Implementation (kept separate from the principle)":"Give each meaningful event a distinct, recognizable sound; make gameplay-critical cues\n(danger, low health, ability-ready) especially legible. Ensure critical information is never\nconveyed by sound alone — mirror it visually for accessibility (UX-0006). Keep sounds\ndistinguishable from each other so the player can parse a busy moment. Protect the important\ncues in the mix (AUDIO-0004).","Disagreement":"No serious dissent that audio's first duty is feedback; debate is about *how much* to sonify\n(rich, informative soundscape vs. sparse, atmospheric restraint — see AUDIO-0005) and how\nrealistic vs. exaggerated the cues should be.","Notes":"The audio face of feedback (FEEL-0004), communication (UX-0003), and legibility (SYS-0006);\nthe foundation the rest of the AUDIO domain builds on. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-AUDIO-0001\ntitle: Sound is feedback first — communicate action, state, and event\nlayer: L1\ndomain: AUDIO\nsubdomain: sfx-as-feedback\ntype: objective\nconfidence: 4\nstatus: canonical\ntags:\n  - audio\n  - feedback\n  - sfx\n  - communication\nrelated:\n  - GDC-L1-FEEL-0004\n  - GDC-L1-UX-0003\n  - GDC-L1-SYS-0006\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-game-audio-practice\n  - S-collins-game-sound\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> The primary job of game audio is *information*: confirm that an action happened, signal\n> state changes, and cue events the player must react to. Before sound is atmosphere or\n> music, it is **feedback** — often the fastest and most reliable channel the player has,\n> because the ear catches things the eye (fixed forward, easily busy) misses.\n\n## Rationale\nA game is a stream of events the player must perceive to respond to, and audio is a superb\ncarrier: a weapon report, a footstep, a UI confirm, a low-health heartbeat, an ability's\ntell all inform the player about actions and consequences instantly and omnidirectionally\n[S-game-audio-practice]. Sound reaches the player even when the relevant thing is off-screen\nor behind other visuals, which is exactly when a purely visual cue fails. This is the audio\narm of the feedback principle (FEEL-0004) and of interface communication (UX-0003): every\nmeaningful event should have a distinct, legible sound so the player can *hear* the game\nstate. Treating audio as mere decoration wastes its most valuable function.\n\n## Applies when\nEvery meaningful game event and player action — combat, movement, interaction, UI, state\nchanges, warnings. The more the player must react quickly or to off-screen events, the more\naudio feedback matters.\n\n## Does not apply / Exceptions\nAudio-free or minimal-audio contexts exist (silent play, accessibility for deaf/hard-of-\nhearing players — which is exactly why critical information must *never* be audio-*only*; pair\nit with visual cues, UX-0006). And not every event needs a sound; over-sonifying trivial\nevents clutters the mix and buries the signals that matter (AUDIO-0004). Atmosphere and music\nare real jobs too — this principle says feedback is the *first* job, not the only one.\n\n## Implementation (kept separate from the principle)\nGive each meaningful event a distinct, recognizable sound; make gameplay-critical cues\n(danger, low health, ability-ready) especially legible. Ensure critical information is never\nconveyed by sound alone — mirror it visually for accessibility (UX-0006). Keep sounds\ndistinguishable from each other so the player can parse a busy moment. Protect the important\ncues in the mix (AUDIO-0004).\n\n## Disagreement\nNo serious dissent that audio's first duty is feedback; debate is about *how much* to sonify\n(rich, informative soundscape vs. sparse, atmospheric restraint — see AUDIO-0005) and how\nrealistic vs. exaggerated the cues should be.\n\n## Notes\nThe audio face of feedback (FEEL-0004), communication (UX-0003), and legibility (SYS-0006);\nthe foundation the rest of the AUDIO domain builds on. Confidence 4.\n","searchText":"gdc-l1-audio-0001 sound is feedback first — communicate action, state, and event audio feedback sfx communication > the primary job of game audio is information: confirm that an action happened, signal state changes, and cue events the player must react to. before sound is atmosphere or music, it is feedback — often the fastest and most reliable channel the player has, because the ear catches things the eye (fixed forward, easily busy) misses. a game is a stream of events the player must perceive to respond to, and audio is a superb carrier: a weapon report, a footstep, a ui confirm, a low-health heartbeat, an ability's tell all inform the player about actions and consequences instantly and omnidirectionally [s-game-audio-practice]. sound reaches the player even when the relevant thing is off-screen or behind other visuals, which is exactly when a purely visual cue fails. this is the audio arm of the feedback principle (feel-0004) and of interface communication (ux-0003): every meaningful event should have a distinct, legible sound so the player can hear the game state. treating audio as mere decoration wastes its most valuable function. every meaningful game event and player action — combat, movement, interaction, ui, state changes, warnings. the more the player must react quickly or to off-screen events, the more audio feedback matters. audio-free or minimal-audio contexts exist (silent play, accessibility for deaf/hard-of- hearing players — which is exactly why critical information must never be audio-only; pair it with visual cues, ux-0006). and not every event needs a sound; over-sonifying trivial events clutters the mix and buries the signals that matter (audio-0004). atmosphere and music are real jobs too — this principle says feedback is the first job, not the only one. give each meaningful event a distinct, recognizable sound; make gameplay-critical cues (danger, low health, ability-ready) especially legible. ensure critical information is never conveyed by sound alone — mirror it visually for accessibility (ux-0006). keep sounds distinguishable from each other so the player can parse a busy moment. protect the important cues in the mix (audio-0004). no serious dissent that audio's first duty is feedback; debate is about how much to sonify (rich, informative soundscape vs. sparse, atmospheric restraint — see audio-0005) and how realistic vs. exaggerated the cues should be. the audio face of feedback (feel-0004), communication (ux-0003), and legibility (sys-0006); the foundation the rest of the audio domain builds on. confidence 4."}
{"id":"GDC-L1-AUDIO-0002","title":"Sound is the cheapest, highest-impact feel win — sell impact with audio","layer":"L1","domain":"AUDIO","subdomain":"sfx-as-feedback","type":"contextual","confidence":4,"status":"canonical","tags":["audio","game-feel","juice","impact","sfx"],"related":["GDC-L1-FEEL-0004","GDC-L1-FEEL-0005","GDC-L1-PROTO-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-nijman-screenshake"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-AUDIO-0002.md","statement":"Audio is disproportionately powerful for game feel. A punchy hit, a bass-heavy weapon, a crunchy impact, a satisfying pickup chime sell force and reward far more cheaply than new animation or VFX. When a moment feels flat, sound is usually the fastest, cheapest fix.","sections":{"Statement":"> Audio is disproportionately powerful for game feel. A punchy hit, a bass-heavy weapon, a\n> crunchy impact, a satisfying pickup chime sell force and reward far more cheaply than new\n> animation or VFX. When a moment feels flat, sound is usually the fastest, cheapest fix.","Rationale":"Impact is a perceptual illusion assembled from many cues, and audio is one of the strongest\nand cheapest to author — raising the bass on a gunshot or adding a meaty thud to a hit\ntransforms how forceful it feels, with none of the cost of new art [S-nijman-screenshake].\nThis is why the classic \"juice\" demonstrations lean so hard on sound, and why audio pairs so\nnaturally with hitstop (FEEL-0005): the freeze and the crunch land on the same frame and\namplify each other. For a small team especially, sound is the highest feel-per-hour\ninvestment available — a reason it's often the fastest win when a prototype's core loop feels\nlifeless (PROTO-0001).","Applies when":"Any impactful or rewarding moment — hits, kills, weapon fire, landings, pickups, ability\nactivations, successes. Highest-leverage exactly when a moment should feel powerful but\ndoesn't.","Does not apply / Exceptions":"Restraint-driven and quiet aesthetics deliberately *don't* punch up every event (AUDIO-0005),\nand over-juiced audio fatigues the ear and clutters the mix (AUDIO-0004) — more is not\nmonotonically better, same as visual juice (FEEL-0004). Mood-first games may want understated,\nrealistic sound rather than exaggerated impact.","Implementation (kept separate from the principle)":"Reach for sound early when tuning feel — often before new animation or VFX. Layer impact\nsounds (transient \"attack\" + body + tail), use low-end for weight, and sync them to the exact\nimpact frame and to hitstop (FEEL-0005). Keep the punchy sounds for the events that matter so\nthey stay special (AUDIO-0004/0005). Prototype feel with placeholder-but-punchy audio rather\nthan waiting for final assets.","Disagreement":"Exaggerated/hyperreal audio (maximum punch and satisfaction) vs. realistic/restrained audio\n(authenticity, mood) is a stylistic split — arcade and action lean hyperreal; sims, horror,\nand grounded games lean realistic. Both are valid; the choice follows the intended register.","Notes":"The feel/impact half of game audio (AUDIO-0001 is the information half), and a specific,\nhigh-ROI instance of FEEL-0004 (juice) that pairs with FEEL-0005 (hitstop). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-AUDIO-0002\ntitle: Sound is the cheapest, highest-impact feel win — sell impact with audio\nlayer: L1\ndomain: AUDIO\nsubdomain: sfx-as-feedback\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - audio\n  - game-feel\n  - juice\n  - impact\n  - sfx\nrelated:\n  - GDC-L1-FEEL-0004\n  - GDC-L1-FEEL-0005\n  - GDC-L1-PROTO-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-nijman-screenshake\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Audio is disproportionately powerful for game feel. A punchy hit, a bass-heavy weapon, a\n> crunchy impact, a satisfying pickup chime sell force and reward far more cheaply than new\n> animation or VFX. When a moment feels flat, sound is usually the fastest, cheapest fix.\n\n## Rationale\nImpact is a perceptual illusion assembled from many cues, and audio is one of the strongest\nand cheapest to author — raising the bass on a gunshot or adding a meaty thud to a hit\ntransforms how forceful it feels, with none of the cost of new art [S-nijman-screenshake].\nThis is why the classic \"juice\" demonstrations lean so hard on sound, and why audio pairs so\nnaturally with hitstop (FEEL-0005): the freeze and the crunch land on the same frame and\namplify each other. For a small team especially, sound is the highest feel-per-hour\ninvestment available — a reason it's often the fastest win when a prototype's core loop feels\nlifeless (PROTO-0001).\n\n## Applies when\nAny impactful or rewarding moment — hits, kills, weapon fire, landings, pickups, ability\nactivations, successes. Highest-leverage exactly when a moment should feel powerful but\ndoesn't.\n\n## Does not apply / Exceptions\nRestraint-driven and quiet aesthetics deliberately *don't* punch up every event (AUDIO-0005),\nand over-juiced audio fatigues the ear and clutters the mix (AUDIO-0004) — more is not\nmonotonically better, same as visual juice (FEEL-0004). Mood-first games may want understated,\nrealistic sound rather than exaggerated impact.\n\n## Implementation (kept separate from the principle)\nReach for sound early when tuning feel — often before new animation or VFX. Layer impact\nsounds (transient \"attack\" + body + tail), use low-end for weight, and sync them to the exact\nimpact frame and to hitstop (FEEL-0005). Keep the punchy sounds for the events that matter so\nthey stay special (AUDIO-0004/0005). Prototype feel with placeholder-but-punchy audio rather\nthan waiting for final assets.\n\n## Disagreement\nExaggerated/hyperreal audio (maximum punch and satisfaction) vs. realistic/restrained audio\n(authenticity, mood) is a stylistic split — arcade and action lean hyperreal; sims, horror,\nand grounded games lean realistic. Both are valid; the choice follows the intended register.\n\n## Notes\nThe feel/impact half of game audio (AUDIO-0001 is the information half), and a specific,\nhigh-ROI instance of FEEL-0004 (juice) that pairs with FEEL-0005 (hitstop). Confidence 4.\n","searchText":"gdc-l1-audio-0002 sound is the cheapest, highest-impact feel win — sell impact with audio audio game-feel juice impact sfx > audio is disproportionately powerful for game feel. a punchy hit, a bass-heavy weapon, a crunchy impact, a satisfying pickup chime sell force and reward far more cheaply than new animation or vfx. when a moment feels flat, sound is usually the fastest, cheapest fix. impact is a perceptual illusion assembled from many cues, and audio is one of the strongest and cheapest to author — raising the bass on a gunshot or adding a meaty thud to a hit transforms how forceful it feels, with none of the cost of new art [s-nijman-screenshake]. this is why the classic \"juice\" demonstrations lean so hard on sound, and why audio pairs so naturally with hitstop (feel-0005): the freeze and the crunch land on the same frame and amplify each other. for a small team especially, sound is the highest feel-per-hour investment available — a reason it's often the fastest win when a prototype's core loop feels lifeless (proto-0001). any impactful or rewarding moment — hits, kills, weapon fire, landings, pickups, ability activations, successes. highest-leverage exactly when a moment should feel powerful but doesn't. restraint-driven and quiet aesthetics deliberately don't punch up every event (audio-0005), and over-juiced audio fatigues the ear and clutters the mix (audio-0004) — more is not monotonically better, same as visual juice (feel-0004). mood-first games may want understated, realistic sound rather than exaggerated impact. reach for sound early when tuning feel — often before new animation or vfx. layer impact sounds (transient \"attack\" + body + tail), use low-end for weight, and sync them to the exact impact frame and to hitstop (feel-0005). keep the punchy sounds for the events that matter so they stay special (audio-0004/0005). prototype feel with placeholder-but-punchy audio rather than waiting for final assets. exaggerated/hyperreal audio (maximum punch and satisfaction) vs. realistic/restrained audio (authenticity, mood) is a stylistic split — arcade and action lean hyperreal; sims, horror, and grounded games lean realistic. both are valid; the choice follows the intended register. the feel/impact half of game audio (audio-0001 is the information half), and a specific, high-roi instance of feel-0004 (juice) that pairs with feel-0005 (hitstop). confidence 4."}
{"id":"GDC-L1-AUDIO-0003","title":"Make music adaptive — respond to game state","layer":"L1","domain":"AUDIO","subdomain":"adaptive-music","type":"contextual","confidence":4,"status":"canonical","tags":["audio","adaptive-music","dynamic-music","pacing","layering"],"related":["GDC-L1-LEVEL-0003","GDC-L1-DESIGN-0004","GDC-L1-SYS-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-collins-game-sound","S-game-audio-practice"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-AUDIO-0003.md","statement":"Music should respond to what's happening — intensity rising in combat, shifting by area, reacting to player actions — using layering and smooth transitions rather than static loops. Adaptive music reinforces pacing and emotion, and it dodges the deadening repetition that fixed tracks suffer under unpredictable play.","sections":{"Statement":"> Music should respond to what's happening — intensity rising in combat, shifting by area,\n> reacting to player actions — using layering and smooth transitions rather than static\n> loops. Adaptive music reinforces pacing and emotion, and it dodges the deadening repetition\n> that fixed tracks suffer under unpredictable play.","Rationale":"Games are non-linear — the player controls when and how long moments last — so a fixed linear\ntrack can't stay synchronized with the experience the way a film score can [S-collins-game-\nsound]. Adaptive music solves this two ways: **vertical** layering (adding or removing\ninstrumental stems, or changing their volume/panning, to raise or lower intensity in place)\nand **horizontal** resequencing (branching to different sections at musical boundaries).\nTogether they let the score track combat intensity, area, and danger, reinforcing the pacing\ncurve (LEVEL-0003) and the flow state (DESIGN-0004) instead of fighting them — and they keep a\nlong play session from wearing a loop into monotony. Music becomes a system that reacts, not a\nrecording that plays.","Applies when":"Games with substantial music and variable-length, player-driven moments — most action, RPG,\nadventure, and exploration games. The more the pacing varies with player choice, the more\nadaptive music pays.","Does not apply / Exceptions":"Some games use fixed, curated tracks to great effect (rhythm games, where the track *is* the\ngame; strongly-authored linear sequences; deliberately static retro or diegetic soundtracks).\nAdaptive systems add real production and implementation cost, so small-scope games may choose\nsimple looping or silence. And adaptive music can be over-engineered into mush if transitions\naren't musical — clumsy layering is worse than a good loop.","Implementation (kept separate from the principle)":"Compose in stems/layers designed to add and drop cleanly, and author transitions at musical\nboundaries (bars/beats) so changes don't jar. Map musical intensity to game state (combat,\ndanger, area, objective). Use middleware built for interactive music. Test transitions under\nreal, messy play — the failure mode is a jarring cut or a smear, both audible immediately.","Disagreement":"Adaptive/dynamic music (reactive, non-repetitive, expensive) vs. fixed/curated tracks\n(controlled, cheaper, sometimes more memorable). Rhythm and strongly-authored games lean\nfixed; systemic and long-session games lean adaptive. The tradeoff is reactivity and\nfreshness vs. production cost and authorial control.","Notes":"The music-system principle of AUDIO; reinforces pacing (LEVEL-0003) and flow (DESIGN-0004),\nand is itself a systemic, second-order design (SYS-0002 — you build the rules that generate\nthe score). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-AUDIO-0003\ntitle: Make music adaptive — respond to game state\nlayer: L1\ndomain: AUDIO\nsubdomain: adaptive-music\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - audio\n  - adaptive-music\n  - dynamic-music\n  - pacing\n  - layering\nrelated:\n  - GDC-L1-LEVEL-0003\n  - GDC-L1-DESIGN-0004\n  - GDC-L1-SYS-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-collins-game-sound\n  - S-game-audio-practice\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Music should respond to what's happening — intensity rising in combat, shifting by area,\n> reacting to player actions — using layering and smooth transitions rather than static\n> loops. Adaptive music reinforces pacing and emotion, and it dodges the deadening repetition\n> that fixed tracks suffer under unpredictable play.\n\n## Rationale\nGames are non-linear — the player controls when and how long moments last — so a fixed linear\ntrack can't stay synchronized with the experience the way a film score can [S-collins-game-\nsound]. Adaptive music solves this two ways: **vertical** layering (adding or removing\ninstrumental stems, or changing their volume/panning, to raise or lower intensity in place)\nand **horizontal** resequencing (branching to different sections at musical boundaries).\nTogether they let the score track combat intensity, area, and danger, reinforcing the pacing\ncurve (LEVEL-0003) and the flow state (DESIGN-0004) instead of fighting them — and they keep a\nlong play session from wearing a loop into monotony. Music becomes a system that reacts, not a\nrecording that plays.\n\n## Applies when\nGames with substantial music and variable-length, player-driven moments — most action, RPG,\nadventure, and exploration games. The more the pacing varies with player choice, the more\nadaptive music pays.\n\n## Does not apply / Exceptions\nSome games use fixed, curated tracks to great effect (rhythm games, where the track *is* the\ngame; strongly-authored linear sequences; deliberately static retro or diegetic soundtracks).\nAdaptive systems add real production and implementation cost, so small-scope games may choose\nsimple looping or silence. And adaptive music can be over-engineered into mush if transitions\naren't musical — clumsy layering is worse than a good loop.\n\n## Implementation (kept separate from the principle)\nCompose in stems/layers designed to add and drop cleanly, and author transitions at musical\nboundaries (bars/beats) so changes don't jar. Map musical intensity to game state (combat,\ndanger, area, objective). Use middleware built for interactive music. Test transitions under\nreal, messy play — the failure mode is a jarring cut or a smear, both audible immediately.\n\n## Disagreement\nAdaptive/dynamic music (reactive, non-repetitive, expensive) vs. fixed/curated tracks\n(controlled, cheaper, sometimes more memorable). Rhythm and strongly-authored games lean\nfixed; systemic and long-session games lean adaptive. The tradeoff is reactivity and\nfreshness vs. production cost and authorial control.\n\n## Notes\nThe music-system principle of AUDIO; reinforces pacing (LEVEL-0003) and flow (DESIGN-0004),\nand is itself a systemic, second-order design (SYS-0002 — you build the rules that generate\nthe score). Confidence 4.\n","searchText":"gdc-l1-audio-0003 make music adaptive — respond to game state audio adaptive-music dynamic-music pacing layering > music should respond to what's happening — intensity rising in combat, shifting by area, reacting to player actions — using layering and smooth transitions rather than static loops. adaptive music reinforces pacing and emotion, and it dodges the deadening repetition that fixed tracks suffer under unpredictable play. games are non-linear — the player controls when and how long moments last — so a fixed linear track can't stay synchronized with the experience the way a film score can [s-collins-game- sound]. adaptive music solves this two ways: vertical layering (adding or removing instrumental stems, or changing their volume/panning, to raise or lower intensity in place) and horizontal resequencing (branching to different sections at musical boundaries). together they let the score track combat intensity, area, and danger, reinforcing the pacing curve (level-0003) and the flow state (design-0004) instead of fighting them — and they keep a long play session from wearing a loop into monotony. music becomes a system that reacts, not a recording that plays. games with substantial music and variable-length, player-driven moments — most action, rpg, adventure, and exploration games. the more the pacing varies with player choice, the more adaptive music pays. some games use fixed, curated tracks to great effect (rhythm games, where the track is the game; strongly-authored linear sequences; deliberately static retro or diegetic soundtracks). adaptive systems add real production and implementation cost, so small-scope games may choose simple looping or silence. and adaptive music can be over-engineered into mush if transitions aren't musical — clumsy layering is worse than a good loop. compose in stems/layers designed to add and drop cleanly, and author transitions at musical boundaries (bars/beats) so changes don't jar. map musical intensity to game state (combat, danger, area, objective). use middleware built for interactive music. test transitions under real, messy play — the failure mode is a jarring cut or a smear, both audible immediately. adaptive/dynamic music (reactive, non-repetitive, expensive) vs. fixed/curated tracks (controlled, cheaper, sometimes more memorable). rhythm and strongly-authored games lean fixed; systemic and long-session games lean adaptive. the tradeoff is reactivity and freshness vs. production cost and authorial control. the music-system principle of audio; reinforces pacing (level-0003) and flow (design-0004), and is itself a systemic, second-order design (sys-0002 — you build the rules that generate the score). confidence 4."}
{"id":"GDC-L1-AUDIO-0004","title":"Mix for clarity — the player must always hear what matters","layer":"L1","domain":"AUDIO","subdomain":"mixing","type":"objective","confidence":4,"status":"canonical","tags":["audio","mixing","clarity","ducking","hdr","information-hierarchy"],"related":["GDC-L1-AUDIO-0001","GDC-L1-UX-0003","GDC-L1-UX-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-game-audio-practice"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-AUDIO-0004.md","statement":"In the chaotic, unpredictable soundscape of a game, mix dynamically so that gameplay-critical sounds always cut through. Establish an audio hierarchy and use real-time techniques — ducking, HDR/state mixing — so footsteps aren't buried under music and the sound that matters most in a given moment wins it.","sections":{"Statement":"> In the chaotic, unpredictable soundscape of a game, mix **dynamically** so that\n> gameplay-critical sounds always cut through. Establish an audio hierarchy and use real-time\n> techniques — ducking, HDR/state mixing — so footsteps aren't buried under music and the\n> sound that matters most in a given moment wins it.","Rationale":"Unlike film, a game's mix is unpredictable — any combination of sounds can fire at once — so a\nstatic mix will inevitably let something important get masked at the worst time\n[S-game-audio-practice]. The fix is a *prioritized, dynamic* mix: the engine decides in real\ntime which sounds matter now and makes room for them. Ducking attenuates background layers\n(music, ambience) when a higher-priority sound (a callout, a warning) plays; HDR audio\n\"declutters\" by making loud sounds louder and quiet ones quieter (muting footsteps under an\nexplosion, then restoring them). This is the audio expression of information hierarchy\n(UX-0003) and cognitive-load management (UX-0002): the player has limited auditory attention,\nso the mix must spend it on what matters. A mix where critical cues (AUDIO-0001) get masked is\na failure no matter how good the individual sounds are.","Applies when":"Any game with a busy or unpredictable soundscape — action, shooters, anything with\nsimultaneous combat, music, and ambience. Most critical where audio carries gameplay-relevant\ninformation (competitive footsteps, warnings).","Does not apply / Exceptions":"Sparse or highly-controlled soundscapes may not need aggressive dynamic mixing. And clarity\ncan be pushed too far — over-ducking or heavy HDR can make the mix feel pumpy, lifeless, or\nconstantly shifting; deliberate overwhelming chaos (a wall of sound for effect) is sometimes\nthe intent. Clarity is the default goal, not an absolute.","Implementation (kept separate from the principle)":"Assign priorities/categories to sounds and let a real-time system (ducking, HDR, state\nmixing) enforce them. Protect the always-must-hear cues (danger, footsteps, callouts). Mix\nand QA under real gameplay chaos, not on isolated sounds — the masking problems only appear in\ncombination. Give the player volume sliders per category (music/SFX/voice) for their own\nclarity and accessibility (UX-0006).","Disagreement":"Little on \"critical sounds must be audible\"; the nuance is *how much* dynamic processing\nbefore the mix feels artificial (pumpy ducking, over-aggressive HDR) — a taste-and-tuning\nquestion, plus the rare deliberate-chaos exception.","Notes":"The mixing principle that protects AUDIO-0001's feedback; the audio form of information\nhierarchy (UX-0003) and attention budgeting (UX-0002). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-AUDIO-0004\ntitle: Mix for clarity — the player must always hear what matters\nlayer: L1\ndomain: AUDIO\nsubdomain: mixing\ntype: objective\nconfidence: 4\nstatus: canonical\ntags:\n  - audio\n  - mixing\n  - clarity\n  - ducking\n  - hdr\n  - information-hierarchy\nrelated:\n  - GDC-L1-AUDIO-0001\n  - GDC-L1-UX-0003\n  - GDC-L1-UX-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-game-audio-practice\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> In the chaotic, unpredictable soundscape of a game, mix **dynamically** so that\n> gameplay-critical sounds always cut through. Establish an audio hierarchy and use real-time\n> techniques — ducking, HDR/state mixing — so footsteps aren't buried under music and the\n> sound that matters most in a given moment wins it.\n\n## Rationale\nUnlike film, a game's mix is unpredictable — any combination of sounds can fire at once — so a\nstatic mix will inevitably let something important get masked at the worst time\n[S-game-audio-practice]. The fix is a *prioritized, dynamic* mix: the engine decides in real\ntime which sounds matter now and makes room for them. Ducking attenuates background layers\n(music, ambience) when a higher-priority sound (a callout, a warning) plays; HDR audio\n\"declutters\" by making loud sounds louder and quiet ones quieter (muting footsteps under an\nexplosion, then restoring them). This is the audio expression of information hierarchy\n(UX-0003) and cognitive-load management (UX-0002): the player has limited auditory attention,\nso the mix must spend it on what matters. A mix where critical cues (AUDIO-0001) get masked is\na failure no matter how good the individual sounds are.\n\n## Applies when\nAny game with a busy or unpredictable soundscape — action, shooters, anything with\nsimultaneous combat, music, and ambience. Most critical where audio carries gameplay-relevant\ninformation (competitive footsteps, warnings).\n\n## Does not apply / Exceptions\nSparse or highly-controlled soundscapes may not need aggressive dynamic mixing. And clarity\ncan be pushed too far — over-ducking or heavy HDR can make the mix feel pumpy, lifeless, or\nconstantly shifting; deliberate overwhelming chaos (a wall of sound for effect) is sometimes\nthe intent. Clarity is the default goal, not an absolute.\n\n## Implementation (kept separate from the principle)\nAssign priorities/categories to sounds and let a real-time system (ducking, HDR, state\nmixing) enforce them. Protect the always-must-hear cues (danger, footsteps, callouts). Mix\nand QA under real gameplay chaos, not on isolated sounds — the masking problems only appear in\ncombination. Give the player volume sliders per category (music/SFX/voice) for their own\nclarity and accessibility (UX-0006).\n\n## Disagreement\nLittle on \"critical sounds must be audible\"; the nuance is *how much* dynamic processing\nbefore the mix feels artificial (pumpy ducking, over-aggressive HDR) — a taste-and-tuning\nquestion, plus the rare deliberate-chaos exception.\n\n## Notes\nThe mixing principle that protects AUDIO-0001's feedback; the audio form of information\nhierarchy (UX-0003) and attention budgeting (UX-0002). Confidence 4.\n","searchText":"gdc-l1-audio-0004 mix for clarity — the player must always hear what matters audio mixing clarity ducking hdr information-hierarchy > in the chaotic, unpredictable soundscape of a game, mix dynamically so that gameplay-critical sounds always cut through. establish an audio hierarchy and use real-time techniques — ducking, hdr/state mixing — so footsteps aren't buried under music and the sound that matters most in a given moment wins it. unlike film, a game's mix is unpredictable — any combination of sounds can fire at once — so a static mix will inevitably let something important get masked at the worst time [s-game-audio-practice]. the fix is a prioritized, dynamic mix: the engine decides in real time which sounds matter now and makes room for them. ducking attenuates background layers (music, ambience) when a higher-priority sound (a callout, a warning) plays; hdr audio \"declutters\" by making loud sounds louder and quiet ones quieter (muting footsteps under an explosion, then restoring them). this is the audio expression of information hierarchy (ux-0003) and cognitive-load management (ux-0002): the player has limited auditory attention, so the mix must spend it on what matters. a mix where critical cues (audio-0001) get masked is a failure no matter how good the individual sounds are. any game with a busy or unpredictable soundscape — action, shooters, anything with simultaneous combat, music, and ambience. most critical where audio carries gameplay-relevant information (competitive footsteps, warnings). sparse or highly-controlled soundscapes may not need aggressive dynamic mixing. and clarity can be pushed too far — over-ducking or heavy hdr can make the mix feel pumpy, lifeless, or constantly shifting; deliberate overwhelming chaos (a wall of sound for effect) is sometimes the intent. clarity is the default goal, not an absolute. assign priorities/categories to sounds and let a real-time system (ducking, hdr, state mixing) enforce them. protect the always-must-hear cues (danger, footsteps, callouts). mix and qa under real gameplay chaos, not on isolated sounds — the masking problems only appear in combination. give the player volume sliders per category (music/sfx/voice) for their own clarity and accessibility (ux-0006). little on \"critical sounds must be audible\"; the nuance is how much dynamic processing before the mix feels artificial (pumpy ducking, over-aggressive hdr) — a taste-and-tuning question, plus the rare deliberate-chaos exception. the mixing principle that protects audio-0001's feedback; the audio form of information hierarchy (ux-0003) and attention budgeting (ux-0002). confidence 4."}
{"id":"GDC-L1-AUDIO-0005","title":"Use silence and dynamic range — contrast gives sound its power","layer":"L1","domain":"AUDIO","subdomain":"silence","type":"contextual","confidence":4,"status":"canonical","tags":["audio","silence","dynamic-range","pacing","restraint"],"related":["GDC-L1-LEVEL-0003","GDC-L1-FEEL-0004","GDC-L1-AUDIO-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-game-audio-practice"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-AUDIO-0005.md","statement":"Silence and quiet are part of the composition. Wall-to-wall sound numbs the ear and flattens impact; restraint and dynamic range make loud moments land and give tension room to build. Design the absence of sound as deliberately as its presence.","sections":{"Statement":"> Silence and quiet are part of the composition. Wall-to-wall sound numbs the ear and\n> flattens impact; restraint and dynamic range make loud moments land and give tension room\n> to build. Design the *absence* of sound as deliberately as its presence.","Rationale":"Loudness is relative — a crescendo only hits if quiet preceded it, and a sudden sound only\nstartles against silence [S-game-audio-practice]. A mix that runs at full intensity constantly\nhas nowhere left to go: everything is loud, so nothing feels loud, and the ear fatigues and\ntunes out. Deliberate quiet does three things: it recharges the player's attention, it makes\nthe next loud event powerful by contrast, and it builds dread or anticipation in its own right\n(the held breath before the scare). This is the audio expression of pacing's tension-and-\nrelease (LEVEL-0003) and the \"don't over-juice\" caution (FEEL-0004): impact needs a baseline of\nrestraint to stand out from, exactly as the punchy sounds of AUDIO-0002 need quiet around them\nto stay special.","Applies when":"Any game with a dynamic emotional or intensity arc — horror and atmosphere especially, but\nalso action (the lull between fights) and exploration (ambient quiet punctuated by discovery).","Does not apply / Exceptions":"Some experiences want relentless, wall-to-wall intensity on purpose — bullet hells, rhythm\ngames, high-energy arcade action, a deliberately overwhelming set-piece. Constant music can\nalso be a stylistic identity. The principle is about *contrast serving the intended arc*; where\nthe arc is \"unrelenting,\" sustained sound is correct.","Implementation (kept separate from the principle)":"Build genuine quiet into the pacing — moments with little or no music, low ambient beds — so\npeaks have contrast to land against (align with LEVEL-0003's rest beats). Preserve dynamic\nrange rather than compressing everything loud (this is what HDR mixing, AUDIO-0004, protects).\nUse silence deliberately before big moments for anticipation or dread. Watch for\n\"music fatigue\" in long sessions — a constant score often wants breaks.","Disagreement":"Restraint/dynamic-range (contrast, breathing room, impactful peaks) vs. wall-to-wall sound\n(constant energy, identity, deliberate overwhelm). Horror and atmospheric design lean restraint;\nhigh-energy and rhythm design lean constant. The choice follows the intended emotional arc.","Notes":"The restraint principle of AUDIO; the counterweight to AUDIO-0002 (impact) and the audio form\nof pacing (LEVEL-0003) and anti-over-juice (FEEL-0004). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-AUDIO-0005\ntitle: Use silence and dynamic range — contrast gives sound its power\nlayer: L1\ndomain: AUDIO\nsubdomain: silence\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - audio\n  - silence\n  - dynamic-range\n  - pacing\n  - restraint\nrelated:\n  - GDC-L1-LEVEL-0003\n  - GDC-L1-FEEL-0004\n  - GDC-L1-AUDIO-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-game-audio-practice\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Silence and quiet are part of the composition. Wall-to-wall sound numbs the ear and\n> flattens impact; restraint and dynamic range make loud moments land and give tension room\n> to build. Design the *absence* of sound as deliberately as its presence.\n\n## Rationale\nLoudness is relative — a crescendo only hits if quiet preceded it, and a sudden sound only\nstartles against silence [S-game-audio-practice]. A mix that runs at full intensity constantly\nhas nowhere left to go: everything is loud, so nothing feels loud, and the ear fatigues and\ntunes out. Deliberate quiet does three things: it recharges the player's attention, it makes\nthe next loud event powerful by contrast, and it builds dread or anticipation in its own right\n(the held breath before the scare). This is the audio expression of pacing's tension-and-\nrelease (LEVEL-0003) and the \"don't over-juice\" caution (FEEL-0004): impact needs a baseline of\nrestraint to stand out from, exactly as the punchy sounds of AUDIO-0002 need quiet around them\nto stay special.\n\n## Applies when\nAny game with a dynamic emotional or intensity arc — horror and atmosphere especially, but\nalso action (the lull between fights) and exploration (ambient quiet punctuated by discovery).\n\n## Does not apply / Exceptions\nSome experiences want relentless, wall-to-wall intensity on purpose — bullet hells, rhythm\ngames, high-energy arcade action, a deliberately overwhelming set-piece. Constant music can\nalso be a stylistic identity. The principle is about *contrast serving the intended arc*; where\nthe arc is \"unrelenting,\" sustained sound is correct.\n\n## Implementation (kept separate from the principle)\nBuild genuine quiet into the pacing — moments with little or no music, low ambient beds — so\npeaks have contrast to land against (align with LEVEL-0003's rest beats). Preserve dynamic\nrange rather than compressing everything loud (this is what HDR mixing, AUDIO-0004, protects).\nUse silence deliberately before big moments for anticipation or dread. Watch for\n\"music fatigue\" in long sessions — a constant score often wants breaks.\n\n## Disagreement\nRestraint/dynamic-range (contrast, breathing room, impactful peaks) vs. wall-to-wall sound\n(constant energy, identity, deliberate overwhelm). Horror and atmospheric design lean restraint;\nhigh-energy and rhythm design lean constant. The choice follows the intended emotional arc.\n\n## Notes\nThe restraint principle of AUDIO; the counterweight to AUDIO-0002 (impact) and the audio form\nof pacing (LEVEL-0003) and anti-over-juice (FEEL-0004). Confidence 4.\n","searchText":"gdc-l1-audio-0005 use silence and dynamic range — contrast gives sound its power audio silence dynamic-range pacing restraint > silence and quiet are part of the composition. wall-to-wall sound numbs the ear and flattens impact; restraint and dynamic range make loud moments land and give tension room to build. design the absence of sound as deliberately as its presence. loudness is relative — a crescendo only hits if quiet preceded it, and a sudden sound only startles against silence [s-game-audio-practice]. a mix that runs at full intensity constantly has nowhere left to go: everything is loud, so nothing feels loud, and the ear fatigues and tunes out. deliberate quiet does three things: it recharges the player's attention, it makes the next loud event powerful by contrast, and it builds dread or anticipation in its own right (the held breath before the scare). this is the audio expression of pacing's tension-and- release (level-0003) and the \"don't over-juice\" caution (feel-0004): impact needs a baseline of restraint to stand out from, exactly as the punchy sounds of audio-0002 need quiet around them to stay special. any game with a dynamic emotional or intensity arc — horror and atmosphere especially, but also action (the lull between fights) and exploration (ambient quiet punctuated by discovery). some experiences want relentless, wall-to-wall intensity on purpose — bullet hells, rhythm games, high-energy arcade action, a deliberately overwhelming set-piece. constant music can also be a stylistic identity. the principle is about contrast serving the intended arc; where the arc is \"unrelenting,\" sustained sound is correct. build genuine quiet into the pacing — moments with little or no music, low ambient beds — so peaks have contrast to land against (align with level-0003's rest beats). preserve dynamic range rather than compressing everything loud (this is what hdr mixing, audio-0004, protects). use silence deliberately before big moments for anticipation or dread. watch for \"music fatigue\" in long sessions — a constant score often wants breaks. restraint/dynamic-range (contrast, breathing room, impactful peaks) vs. wall-to-wall sound (constant energy, identity, deliberate overwhelm). horror and atmospheric design lean restraint; high-energy and rhythm design lean constant. the choice follows the intended emotional arc. the restraint principle of audio; the counterweight to audio-0002 (impact) and the audio form of pacing (level-0003) and anti-over-juice (feel-0004). confidence 4."}
{"id":"GDC-L1-AUDIO-0006","title":"Place sound in space — spatialization conveys position and information","layer":"L1","domain":"AUDIO","subdomain":"spatialization","type":"contextual","confidence":4,"status":"canonical","tags":["audio","spatialization","3d-audio","positional","information"],"related":["GDC-L1-AUDIO-0001","GDC-L1-LEVEL-0002","GDC-L1-FEEL-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-collins-game-sound","S-game-audio-practice"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-AUDIO-0006.md","statement":"Position sound in 3D space so the player can locate events by ear: footsteps behind them, a threat off-screen, a pickup down the hall. Spatial audio is both immersion and information — and in competitive play, a fair and readable soundscape is effectively a core mechanic.","sections":{"Statement":"> Position sound in 3D space so the player can locate events by ear: footsteps behind them,\n> a threat off-screen, a pickup down the hall. Spatial audio is both immersion *and*\n> information — and in competitive play, a fair and readable soundscape is effectively a core\n> mechanic.","Rationale":"The ear locates sources the eye can't see, so spatialized audio extends the player's\nperception beyond the screen — a crucial advantage in any game where important things happen\noff-camera [S-collins-game-sound]. Spatial cues do double duty: they immerse (a world that\nsounds like it surrounds you), and they *inform* (which direction is that footstep? how far is\nthat roar?). In competitive games this becomes load-bearing — players make real decisions off\npositional audio (footstep direction, reload sounds), which means the soundscape must be\n*consistent and fair*, since an inaudible or misleading cue is a competitive defect, not just\nan aesthetic one [S-game-audio-practice]. Spatialization is also part of physicality and\ngame feel (FEEL-0001): sound that moves with the world makes the world feel real.","Applies when":"3D games, and any game where off-screen events matter — especially action, shooters, horror,\nand competitive multiplayer. The more the player must react to what they can't see, the more\npositional audio matters.","Does not apply / Exceptions":"Non-spatial or abstract games (many 2D, puzzle, and menu-driven experiences) get little from\n3D audio, and UI/music are often intentionally non-diegetic (not placed in the world).\nHardware and headphones-vs-speakers variance limits how much precise localization you can rely\non. And spatialization must not *hide* critical cues behind distance/occlusion — gameplay-\ncritical information sometimes needs to break realism to stay audible (a tension with\nAUDIO-0001).","Implementation (kept separate from the principle)":"Spatialize world sounds (attenuation, panning, occlusion, reverb by space) so position is\nreadable by ear. For competitive integrity, keep positional cues consistent and hard to\nmask (AUDIO-0004), and test them for fairness across setups. Keep UI and non-diegetic music\nout of the spatial field. Where a critical cue would be lost to distance/occlusion, bias\ntoward audibility over strict realism.","Disagreement":"Realistic spatialization (full occlusion/attenuation, immersive but sometimes hides cues) vs.\ngameplay-biased audio (readability and fairness first, even if less realistic) — competitive\ngames lean gameplay-biased; immersive single-player leans realistic. Also diegetic vs.\nnon-diegetic placement is a per-sound choice.","Notes":"The spatial principle of AUDIO; serves legibility (LEVEL-0002), feedback (AUDIO-0001),\nphysicality/feel (FEEL-0001), and — in competitive play — fairness. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-AUDIO-0006\ntitle: Place sound in space — spatialization conveys position and information\nlayer: L1\ndomain: AUDIO\nsubdomain: spatialization\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - audio\n  - spatialization\n  - 3d-audio\n  - positional\n  - information\nrelated:\n  - GDC-L1-AUDIO-0001\n  - GDC-L1-LEVEL-0002\n  - GDC-L1-FEEL-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-collins-game-sound\n  - S-game-audio-practice\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Position sound in 3D space so the player can locate events by ear: footsteps behind them,\n> a threat off-screen, a pickup down the hall. Spatial audio is both immersion *and*\n> information — and in competitive play, a fair and readable soundscape is effectively a core\n> mechanic.\n\n## Rationale\nThe ear locates sources the eye can't see, so spatialized audio extends the player's\nperception beyond the screen — a crucial advantage in any game where important things happen\noff-camera [S-collins-game-sound]. Spatial cues do double duty: they immerse (a world that\nsounds like it surrounds you), and they *inform* (which direction is that footstep? how far is\nthat roar?). In competitive games this becomes load-bearing — players make real decisions off\npositional audio (footstep direction, reload sounds), which means the soundscape must be\n*consistent and fair*, since an inaudible or misleading cue is a competitive defect, not just\nan aesthetic one [S-game-audio-practice]. Spatialization is also part of physicality and\ngame feel (FEEL-0001): sound that moves with the world makes the world feel real.\n\n## Applies when\n3D games, and any game where off-screen events matter — especially action, shooters, horror,\nand competitive multiplayer. The more the player must react to what they can't see, the more\npositional audio matters.\n\n## Does not apply / Exceptions\nNon-spatial or abstract games (many 2D, puzzle, and menu-driven experiences) get little from\n3D audio, and UI/music are often intentionally non-diegetic (not placed in the world).\nHardware and headphones-vs-speakers variance limits how much precise localization you can rely\non. And spatialization must not *hide* critical cues behind distance/occlusion — gameplay-\ncritical information sometimes needs to break realism to stay audible (a tension with\nAUDIO-0001).\n\n## Implementation (kept separate from the principle)\nSpatialize world sounds (attenuation, panning, occlusion, reverb by space) so position is\nreadable by ear. For competitive integrity, keep positional cues consistent and hard to\nmask (AUDIO-0004), and test them for fairness across setups. Keep UI and non-diegetic music\nout of the spatial field. Where a critical cue would be lost to distance/occlusion, bias\ntoward audibility over strict realism.\n\n## Disagreement\nRealistic spatialization (full occlusion/attenuation, immersive but sometimes hides cues) vs.\ngameplay-biased audio (readability and fairness first, even if less realistic) — competitive\ngames lean gameplay-biased; immersive single-player leans realistic. Also diegetic vs.\nnon-diegetic placement is a per-sound choice.\n\n## Notes\nThe spatial principle of AUDIO; serves legibility (LEVEL-0002), feedback (AUDIO-0001),\nphysicality/feel (FEEL-0001), and — in competitive play — fairness. Confidence 4.\n","searchText":"gdc-l1-audio-0006 place sound in space — spatialization conveys position and information audio spatialization 3d-audio positional information > position sound in 3d space so the player can locate events by ear: footsteps behind them, a threat off-screen, a pickup down the hall. spatial audio is both immersion and information — and in competitive play, a fair and readable soundscape is effectively a core mechanic. the ear locates sources the eye can't see, so spatialized audio extends the player's perception beyond the screen — a crucial advantage in any game where important things happen off-camera [s-collins-game-sound]. spatial cues do double duty: they immerse (a world that sounds like it surrounds you), and they inform (which direction is that footstep? how far is that roar?). in competitive games this becomes load-bearing — players make real decisions off positional audio (footstep direction, reload sounds), which means the soundscape must be consistent and fair, since an inaudible or misleading cue is a competitive defect, not just an aesthetic one [s-game-audio-practice]. spatialization is also part of physicality and game feel (feel-0001): sound that moves with the world makes the world feel real. 3d games, and any game where off-screen events matter — especially action, shooters, horror, and competitive multiplayer. the more the player must react to what they can't see, the more positional audio matters. non-spatial or abstract games (many 2d, puzzle, and menu-driven experiences) get little from 3d audio, and ui/music are often intentionally non-diegetic (not placed in the world). hardware and headphones-vs-speakers variance limits how much precise localization you can rely on. and spatialization must not hide critical cues behind distance/occlusion — gameplay- critical information sometimes needs to break realism to stay audible (a tension with audio-0001). spatialize world sounds (attenuation, panning, occlusion, reverb by space) so position is readable by ear. for competitive integrity, keep positional cues consistent and hard to mask (audio-0004), and test them for fairness across setups. keep ui and non-diegetic music out of the spatial field. where a critical cue would be lost to distance/occlusion, bias toward audibility over strict realism. realistic spatialization (full occlusion/attenuation, immersive but sometimes hides cues) vs. gameplay-biased audio (readability and fairness first, even if less realistic) — competitive games lean gameplay-biased; immersive single-player leans realistic. also diegetic vs. non-diegetic placement is a per-sound choice. the spatial principle of audio; serves legibility (level-0002), feedback (audio-0001), physicality/feel (feel-0001), and — in competitive play — fairness. confidence 4."}
{"id":"GDC-L1-CONTENT-0001","title":"Invest in tools — the pipeline is a force multiplier","layer":"L1","domain":"CONTENT","subdomain":"toolchain","type":"contextual","confidence":4,"status":"canonical","tags":["content","tooling","pipeline","iteration","productivity"],"related":["GDC-L1-ARCH-0005","GDC-L1-CONTENT-0002","GDC-L1-PROTO-0006"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-gregory-game-engine-arch"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-CONTENT-0001.md","statement":"Good tools multiply everything downstream. The content pipeline — editors, importers, build systems, validators, preview tools — is a force multiplier: time invested in tooling pays back across every asset and every iteration for the rest of the project. Treat tools as first-class, not as afterthoughts.","sections":{"Statement":"> Good tools multiply everything downstream. The content pipeline — editors, importers, build\n> systems, validators, preview tools — is a force multiplier: time invested in tooling pays back\n> across every asset and every iteration for the rest of the project. Treat tools as\n> first-class, not as afterthoughts.","Rationale":"A game is made of thousands of content operations, and each is gated by the tools that perform it,\nso a slow, manual, or fragile pipeline taxes every single one — while a good pipeline accelerates\nthem all [S-gregory-game-engine-arch]. This is leverage: an hour spent making asset import\nten seconds faster saves that ten seconds on every import for years. Tooling is also the enabler\nof iteration speed (ARCH-0005, PROTO-0006) and creator empowerment (CONTENT-0002) — you can only\niterate as fast as your tools let you build, preview, and validate. Under-investing in tools is a\nfalse economy that shows up as a slow, painful production; over the life of a project, the\npipeline is one of the highest-ROI investments a team makes.","Applies when":"Any content-heavy project (most games), and any team producing assets repeatedly. The more content\nand the longer the project, the higher the return on tooling.","Does not apply / Exceptions":"Very small or short projects may not recoup heavy tool investment — off-the-shelf engine tools\nsuffice, and building custom tooling would be over-engineering. There's a point of diminishing\nreturns (gold-plating a tool no one needs). And tools themselves must be maintained; a\nhalf-finished internal tool can cost more than it saves. Invest where content volume justifies it.","Implementation (kept separate from the principle)":"Identify the highest-frequency, highest-pain content operations and improve their tools first.\nMeasure pipeline times (import, build, preview) the way you'd measure the iteration loop\n(ARCH-0005). Prefer improving tools over grinding through manual work. Empower creators with the\ntools they need to work without programmers (CONTENT-0002). Keep tools maintained and validated\n(CONTENT-0004).","Disagreement":"Tool investment (multiplies output, enables iteration — but costs time and maintenance) vs.\nlean/off-the-shelf (start producing sooner — but slower per operation at scale). The return scales\nwith content volume and project length; tiny projects lean lean, content-heavy ones invest.","Notes":"The tooling principle of CONTENT; the pipeline enabler of iteration speed (ARCH-0005, PROTO-0006)\nand creator empowerment (CONTENT-0002). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-CONTENT-0001\ntitle: Invest in tools — the pipeline is a force multiplier\nlayer: L1\ndomain: CONTENT\nsubdomain: toolchain\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - content\n  - tooling\n  - pipeline\n  - iteration\n  - productivity\nrelated:\n  - GDC-L1-ARCH-0005\n  - GDC-L1-CONTENT-0002\n  - GDC-L1-PROTO-0006\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-gregory-game-engine-arch\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Good tools multiply everything downstream. The content pipeline — editors, importers, build\n> systems, validators, preview tools — is a force multiplier: time invested in tooling pays back\n> across every asset and every iteration for the rest of the project. Treat tools as\n> first-class, not as afterthoughts.\n\n## Rationale\nA game is made of thousands of content operations, and each is gated by the tools that perform it,\nso a slow, manual, or fragile pipeline taxes every single one — while a good pipeline accelerates\nthem all [S-gregory-game-engine-arch]. This is leverage: an hour spent making asset import\nten seconds faster saves that ten seconds on every import for years. Tooling is also the enabler\nof iteration speed (ARCH-0005, PROTO-0006) and creator empowerment (CONTENT-0002) — you can only\niterate as fast as your tools let you build, preview, and validate. Under-investing in tools is a\nfalse economy that shows up as a slow, painful production; over the life of a project, the\npipeline is one of the highest-ROI investments a team makes.\n\n## Applies when\nAny content-heavy project (most games), and any team producing assets repeatedly. The more content\nand the longer the project, the higher the return on tooling.\n\n## Does not apply / Exceptions\nVery small or short projects may not recoup heavy tool investment — off-the-shelf engine tools\nsuffice, and building custom tooling would be over-engineering. There's a point of diminishing\nreturns (gold-plating a tool no one needs). And tools themselves must be maintained; a\nhalf-finished internal tool can cost more than it saves. Invest where content volume justifies it.\n\n## Implementation (kept separate from the principle)\nIdentify the highest-frequency, highest-pain content operations and improve their tools first.\nMeasure pipeline times (import, build, preview) the way you'd measure the iteration loop\n(ARCH-0005). Prefer improving tools over grinding through manual work. Empower creators with the\ntools they need to work without programmers (CONTENT-0002). Keep tools maintained and validated\n(CONTENT-0004).\n\n## Disagreement\nTool investment (multiplies output, enables iteration — but costs time and maintenance) vs.\nlean/off-the-shelf (start producing sooner — but slower per operation at scale). The return scales\nwith content volume and project length; tiny projects lean lean, content-heavy ones invest.\n\n## Notes\nThe tooling principle of CONTENT; the pipeline enabler of iteration speed (ARCH-0005, PROTO-0006)\nand creator empowerment (CONTENT-0002). Confidence 4.\n","searchText":"gdc-l1-content-0001 invest in tools — the pipeline is a force multiplier content tooling pipeline iteration productivity > good tools multiply everything downstream. the content pipeline — editors, importers, build systems, validators, preview tools — is a force multiplier: time invested in tooling pays back across every asset and every iteration for the rest of the project. treat tools as first-class, not as afterthoughts. a game is made of thousands of content operations, and each is gated by the tools that perform it, so a slow, manual, or fragile pipeline taxes every single one — while a good pipeline accelerates them all [s-gregory-game-engine-arch]. this is leverage: an hour spent making asset import ten seconds faster saves that ten seconds on every import for years. tooling is also the enabler of iteration speed (arch-0005, proto-0006) and creator empowerment (content-0002) — you can only iterate as fast as your tools let you build, preview, and validate. under-investing in tools is a false economy that shows up as a slow, painful production; over the life of a project, the pipeline is one of the highest-roi investments a team makes. any content-heavy project (most games), and any team producing assets repeatedly. the more content and the longer the project, the higher the return on tooling. very small or short projects may not recoup heavy tool investment — off-the-shelf engine tools suffice, and building custom tooling would be over-engineering. there's a point of diminishing returns (gold-plating a tool no one needs). and tools themselves must be maintained; a half-finished internal tool can cost more than it saves. invest where content volume justifies it. identify the highest-frequency, highest-pain content operations and improve their tools first. measure pipeline times (import, build, preview) the way you'd measure the iteration loop (arch-0005). prefer improving tools over grinding through manual work. empower creators with the tools they need to work without programmers (content-0002). keep tools maintained and validated (content-0004). tool investment (multiplies output, enables iteration — but costs time and maintenance) vs. lean/off-the-shelf (start producing sooner — but slower per operation at scale). the return scales with content volume and project length; tiny projects lean lean, content-heavy ones invest. the tooling principle of content; the pipeline enabler of iteration speed (arch-0005, proto-0006) and creator empowerment (content-0002). confidence 4."}
{"id":"GDC-L1-CONTENT-0002","title":"Empower creators to build and iterate without programmers","layer":"L1","domain":"CONTENT","subdomain":"empowering-content-creators","type":"contextual","confidence":4,"status":"canonical","tags":["content","empowerment","data-driven","iteration","designers"],"related":["GDC-L1-ARCH-0001","GDC-L1-CONTENT-0001","GDC-L1-ARCH-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-gregory-game-engine-arch"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-CONTENT-0002.md","statement":"Design the pipeline so that designers and artists can create, tune, and iterate content without a programmer in the loop — through data, editors, and in-tool workflows. Every time content work requires a code change, iteration stalls and the people closest to the design lose agency over it.","sections":{"Statement":"> Design the pipeline so that designers and artists can create, tune, and iterate content\n> *without* a programmer in the loop — through data, editors, and in-tool workflows. Every time\n> content work requires a code change, iteration stalls and the people closest to the design lose\n> agency over it.","Rationale":"The people who best judge whether a level, ability, or encounter is right are the designers and\nartists making it, and they iterate fastest when they can change it directly — which is exactly\nwhat data-driven design enables (ARCH-0001): behavior in editable data, not compiled code\n[S-gregory-game-engine-arch]. A pipeline that routes every content tweak through an engineer\ncreates a bottleneck (the programmer becomes a gate on all iteration), slows the loop that makes\ngames good (ARCH-0005), and demoralizes creators who can't touch their own work. Empowering\ncreators — good editors, data assets, live tuning, in-engine authoring — removes the bottleneck\nand puts iteration where the judgment is. It's the human payoff of data-driven architecture and\ngood tooling (CONTENT-0001).","Applies when":"Any project where designers/artists iterate on content — which is nearly all of them. Most\nvaluable where content volume and iteration are high.","Does not apply / Exceptions":"Some deeply technical content genuinely requires engineering (novel systems, performance-critical\nwork) — not everything can or should be designer-editable. On tiny teams where the same person\ncodes and designs, the bottleneck disappears. And empowerment tools have a build cost\n(CONTENT-0001's investment) that must be justified by iteration volume.","Implementation (kept separate from the principle)":"Expose content and tuning as data (ARCH-0001) editable in good tools (CONTENT-0001), so creators\nwork without recompiling. Support live tuning and in-engine authoring (ARCH-0005). Design the\nprogrammer's job as *building the systems and seams*, and the designer's as *filling them with\ncontent* (the \"build the seam, fill it later\" split). Validate creator-authored data on load so\nmistakes fail loudly (CONTENT-0004).","Disagreement":"Creator-empowering pipelines (fast iteration, agency, but tool-building cost) vs. programmer-gated\ncontent (less tooling to build, but a bottleneck at scale). The tradeoff is tool investment vs.\niteration speed — content-heavy, iteration-driven games strongly favor empowerment.","Notes":"The human/agency payoff of data-driven design (ARCH-0001) and tooling (CONTENT-0001); the enabler\nof fast iteration (ARCH-0005). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-CONTENT-0002\ntitle: Empower creators to build and iterate without programmers\nlayer: L1\ndomain: CONTENT\nsubdomain: empowering-content-creators\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - content\n  - empowerment\n  - data-driven\n  - iteration\n  - designers\nrelated:\n  - GDC-L1-ARCH-0001\n  - GDC-L1-CONTENT-0001\n  - GDC-L1-ARCH-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-gregory-game-engine-arch\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Design the pipeline so that designers and artists can create, tune, and iterate content\n> *without* a programmer in the loop — through data, editors, and in-tool workflows. Every time\n> content work requires a code change, iteration stalls and the people closest to the design lose\n> agency over it.\n\n## Rationale\nThe people who best judge whether a level, ability, or encounter is right are the designers and\nartists making it, and they iterate fastest when they can change it directly — which is exactly\nwhat data-driven design enables (ARCH-0001): behavior in editable data, not compiled code\n[S-gregory-game-engine-arch]. A pipeline that routes every content tweak through an engineer\ncreates a bottleneck (the programmer becomes a gate on all iteration), slows the loop that makes\ngames good (ARCH-0005), and demoralizes creators who can't touch their own work. Empowering\ncreators — good editors, data assets, live tuning, in-engine authoring — removes the bottleneck\nand puts iteration where the judgment is. It's the human payoff of data-driven architecture and\ngood tooling (CONTENT-0001).\n\n## Applies when\nAny project where designers/artists iterate on content — which is nearly all of them. Most\nvaluable where content volume and iteration are high.\n\n## Does not apply / Exceptions\nSome deeply technical content genuinely requires engineering (novel systems, performance-critical\nwork) — not everything can or should be designer-editable. On tiny teams where the same person\ncodes and designs, the bottleneck disappears. And empowerment tools have a build cost\n(CONTENT-0001's investment) that must be justified by iteration volume.\n\n## Implementation (kept separate from the principle)\nExpose content and tuning as data (ARCH-0001) editable in good tools (CONTENT-0001), so creators\nwork without recompiling. Support live tuning and in-engine authoring (ARCH-0005). Design the\nprogrammer's job as *building the systems and seams*, and the designer's as *filling them with\ncontent* (the \"build the seam, fill it later\" split). Validate creator-authored data on load so\nmistakes fail loudly (CONTENT-0004).\n\n## Disagreement\nCreator-empowering pipelines (fast iteration, agency, but tool-building cost) vs. programmer-gated\ncontent (less tooling to build, but a bottleneck at scale). The tradeoff is tool investment vs.\niteration speed — content-heavy, iteration-driven games strongly favor empowerment.\n\n## Notes\nThe human/agency payoff of data-driven design (ARCH-0001) and tooling (CONTENT-0001); the enabler\nof fast iteration (ARCH-0005). Confidence 4.\n","searchText":"gdc-l1-content-0002 empower creators to build and iterate without programmers content empowerment data-driven iteration designers > design the pipeline so that designers and artists can create, tune, and iterate content without a programmer in the loop — through data, editors, and in-tool workflows. every time content work requires a code change, iteration stalls and the people closest to the design lose agency over it. the people who best judge whether a level, ability, or encounter is right are the designers and artists making it, and they iterate fastest when they can change it directly — which is exactly what data-driven design enables (arch-0001): behavior in editable data, not compiled code [s-gregory-game-engine-arch]. a pipeline that routes every content tweak through an engineer creates a bottleneck (the programmer becomes a gate on all iteration), slows the loop that makes games good (arch-0005), and demoralizes creators who can't touch their own work. empowering creators — good editors, data assets, live tuning, in-engine authoring — removes the bottleneck and puts iteration where the judgment is. it's the human payoff of data-driven architecture and good tooling (content-0001). any project where designers/artists iterate on content — which is nearly all of them. most valuable where content volume and iteration are high. some deeply technical content genuinely requires engineering (novel systems, performance-critical work) — not everything can or should be designer-editable. on tiny teams where the same person codes and designs, the bottleneck disappears. and empowerment tools have a build cost (content-0001's investment) that must be justified by iteration volume. expose content and tuning as data (arch-0001) editable in good tools (content-0001), so creators work without recompiling. support live tuning and in-engine authoring (arch-0005). design the programmer's job as building the systems and seams, and the designer's as filling them with content (the \"build the seam, fill it later\" split). validate creator-authored data on load so mistakes fail loudly (content-0004). creator-empowering pipelines (fast iteration, agency, but tool-building cost) vs. programmer-gated content (less tooling to build, but a bottleneck at scale). the tradeoff is tool investment vs. iteration speed — content-heavy, iteration-driven games strongly favor empowerment. the human/agency payoff of data-driven design (arch-0001) and tooling (content-0001); the enabler of fast iteration (arch-0005). confidence 4."}
{"id":"GDC-L1-CONTENT-0003","title":"Enforce naming and organization conventions — consistency scales, chaos compounds","layer":"L1","domain":"CONTENT","subdomain":"naming-and-organization","type":"contextual","confidence":4,"status":"canonical","tags":["content","naming","organization","conventions","maintainability"],"related":["GDC-L1-CONTENT-0001","GDC-L1-TEAM-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-gregory-game-engine-arch"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-CONTENT-0003.md","statement":"Adopt and enforce consistent naming and folder/organization conventions for assets, code, and data — early. Consistency scales gracefully as the project grows; inconsistency compounds into a mess where nobody can find anything, duplicates proliferate, and tools break. A convention followed is worth more than a perfect one ignored.","sections":{"Statement":"> Adopt and enforce consistent naming and folder/organization conventions for assets, code, and\n> data — early. Consistency scales gracefully as the project grows; inconsistency compounds into\n> a mess where nobody can find anything, duplicates proliferate, and tools break. A convention\n> followed is worth more than a perfect one ignored.","Rationale":"A game accumulates thousands of files, and the cost of disorganization grows super-linearly: finding assets, avoiding duplicates, wiring up tools, and onboarding people all get harder as the mess deepens [S-gregory-game-engine-arch]. Conventions are cheap to establish and enormously expensive to retrofit, so the time to set them is at the start. They pay off in searchability (you can *find* the thing), tool reliability (automated pipelines depend on predictable names and paths), and shared understanding (a team parallel to \"make decisions visible and durable,\" TEAM-0004 — the convention *is* durable shared knowledge).","Applies when":"Any project past trivial size, and especially any team or long-lived project. The larger the\ncontent and team, the more it matters — but it's cheapest to start on day one.","Does not apply / Exceptions":"A one-person weekend prototype can be loose about it (though even solo devs drift). And\nconventions can be over-engineered into bureaucracy that slows people down — the goal is\n*consistency that helps*, not a rulebook for its own sake. A simple convention everyone actually\nfollows beats an elaborate one they route around.","Implementation (kept separate from the principle)":"Keep them simple enough to follow. Enforce them via tooling/validation where possible (CONTENT-0004) rather than vigilance alone. Refactor toward the convention when things drift.","Disagreement":"Little on the value of conventions; the nuance is *how much* structure (lightweight vs. elaborate)\nand how strictly to enforce. Over-formalization can bureaucratize; under-structuring invites\nchaos. Match the rigor to team and project size.","Notes":"Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-CONTENT-0003\ntitle: Enforce naming and organization conventions — consistency scales, chaos compounds\nlayer: L1\ndomain: CONTENT\nsubdomain: naming-and-organization\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - content\n  - naming\n  - organization\n  - conventions\n  - maintainability\nrelated:\n  - GDC-L1-CONTENT-0001\n  - GDC-L1-TEAM-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-gregory-game-engine-arch\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Adopt and enforce consistent naming and folder/organization conventions for assets, code, and\n> data — early. Consistency scales gracefully as the project grows; inconsistency compounds into\n> a mess where nobody can find anything, duplicates proliferate, and tools break. A convention\n> followed is worth more than a perfect one ignored.\n\n## Rationale\nA game accumulates thousands of files, and the cost of disorganization grows super-linearly: finding assets, avoiding duplicates, wiring up tools, and onboarding people all get harder as the mess deepens [S-gregory-game-engine-arch]. Conventions are cheap to establish and enormously expensive to retrofit, so the time to set them is at the start. They pay off in searchability (you can *find* the thing), tool reliability (automated pipelines depend on predictable names and paths), and shared understanding (a team parallel to \"make decisions visible and durable,\" TEAM-0004 — the convention *is* durable shared knowledge).\n\n## Applies when\nAny project past trivial size, and especially any team or long-lived project. The larger the\ncontent and team, the more it matters — but it's cheapest to start on day one.\n\n## Does not apply / Exceptions\nA one-person weekend prototype can be loose about it (though even solo devs drift). And\nconventions can be over-engineered into bureaucracy that slows people down — the goal is\n*consistency that helps*, not a rulebook for its own sake. A simple convention everyone actually\nfollows beats an elaborate one they route around.\n\n## Implementation (kept separate from the principle)\nKeep them simple enough to follow. Enforce them via tooling/validation where possible (CONTENT-0004) rather than vigilance alone. Refactor toward the convention when things drift.\n\n## Disagreement\nLittle on the value of conventions; the nuance is *how much* structure (lightweight vs. elaborate)\nand how strictly to enforce. Over-formalization can bureaucratize; under-structuring invites\nchaos. Match the rigor to team and project size.\n\n## Notes\nConfidence 4.\n","searchText":"gdc-l1-content-0003 enforce naming and organization conventions — consistency scales, chaos compounds content naming organization conventions maintainability > adopt and enforce consistent naming and folder/organization conventions for assets, code, and data — early. consistency scales gracefully as the project grows; inconsistency compounds into a mess where nobody can find anything, duplicates proliferate, and tools break. a convention followed is worth more than a perfect one ignored. a game accumulates thousands of files, and the cost of disorganization grows super-linearly: finding assets, avoiding duplicates, wiring up tools, and onboarding people all get harder as the mess deepens [s-gregory-game-engine-arch]. conventions are cheap to establish and enormously expensive to retrofit, so the time to set them is at the start. they pay off in searchability (you can find the thing), tool reliability (automated pipelines depend on predictable names and paths), and shared understanding (a team parallel to \"make decisions visible and durable,\" team-0004 — the convention is durable shared knowledge). any project past trivial size, and especially any team or long-lived project. the larger the content and team, the more it matters — but it's cheapest to start on day one. a one-person weekend prototype can be loose about it (though even solo devs drift). and conventions can be over-engineered into bureaucracy that slows people down — the goal is consistency that helps, not a rulebook for its own sake. a simple convention everyone actually follows beats an elaborate one they route around. keep them simple enough to follow. enforce them via tooling/validation where possible (content-0004) rather than vigilance alone. refactor toward the convention when things drift. little on the value of conventions; the nuance is how much structure (lightweight vs. elaborate) and how strictly to enforce. over-formalization can bureaucratize; under-structuring invites chaos. match the rigor to team and project size. confidence 4."}
{"id":"GDC-L1-CONTENT-0004","title":"Validate content early — catch bad data on ingest, not at runtime","layer":"L1","domain":"CONTENT","subdomain":"asset-pipeline","type":"contextual","confidence":4,"status":"canonical","tags":["content","validation","data-integrity","pipeline","fail-fast"],"related":["GDC-L1-ARCH-0001","GDC-L1-CONTENT-0002","GDC-L1-QA-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-gregory-game-engine-arch"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-CONTENT-0004.md","statement":"Validate content as early as possible — on import, on save, in the build — so bad data fails loudly and immediately, at the point it was created, rather than silently causing a mysterious bug or crash at runtime hours later. Catch it where it's cheap to fix.","sections":{"Statement":"> Validate content as early as possible — on import, on save, in the build — so bad data fails\n> *loudly and immediately*, at the point it was created, rather than silently causing a mysterious\n> bug or crash at runtime hours later. Catch it where it's cheap to fix.","Rationale":"Data-driven design (ARCH-0001) and creator empowerment (CONTENT-0002) mean designers and artists\nauthor lots of data, and some of it will be wrong — a missing reference, an out-of-range value, a\nmalformed asset. If that error surfaces only at runtime (a crash, a broken level, a subtle\nwrong-number bug), it's expensive to trace back to its source and it may ship. Validating on\ningest inverts this: the error is reported to the person who made it, at the moment they made it,\nwith a clear message — cheap to fix and impossible to miss [S-gregory-game-engine-arch]. This is\nthe content-pipeline form of \"fail fast\" and of building quality in rather than testing it out\n(QA-0005): the earlier a defect is caught, the cheaper it is, and validation is how you push data\ndefects to the earliest possible point.","Applies when":"Any data-driven content pipeline — asset imports, data assets, level data, config. The more\ndesigner-authored data, the more validation pays.","Does not apply / Exceptions":"Trivial or one-off data may not justify formal validators. Over-strict validation can also block\nlegitimate work-in-progress (a designer mid-edit shouldn't be stopped by every transient\ninconsistency) — validation should distinguish \"broken and shippable\" from \"unfinished.\" And\nvalidators are code that must be maintained. Validate what actually breaks; don't gold-plate.","Implementation (kept separate from the principle)":"Add validation at ingest points (import, save) and in the build, reporting errors clearly to the\nauthor. Distinguish hard errors (block) from warnings (flag). Key runtime state by stable\nidentifiers so missing/renamed content fails cleanly (ARCH-0001/0006, CONTENT-0003). Make the\nbuild fail on invalid content rather than shipping it. Treat this as part of building quality in\n(QA-0005).","Disagreement":"Strict early validation (catches defects cheaply, but tooling cost and can block WIP) vs.\npermissive pipelines (less friction, but runtime surprises). The balance is validating what\ngenuinely breaks while not obstructing legitimate in-progress work. Content-heavy, data-driven\nprojects strongly favor validation.","Notes":"The data-integrity principle of CONTENT; the ingest-time application of fail-fast and \"build\nquality in\" (QA-0005), guarding data-driven content (ARCH-0001, CONTENT-0002). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-CONTENT-0004\ntitle: Validate content early — catch bad data on ingest, not at runtime\nlayer: L1\ndomain: CONTENT\nsubdomain: asset-pipeline\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - content\n  - validation\n  - data-integrity\n  - pipeline\n  - fail-fast\nrelated:\n  - GDC-L1-ARCH-0001\n  - GDC-L1-CONTENT-0002\n  - GDC-L1-QA-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-gregory-game-engine-arch\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Validate content as early as possible — on import, on save, in the build — so bad data fails\n> *loudly and immediately*, at the point it was created, rather than silently causing a mysterious\n> bug or crash at runtime hours later. Catch it where it's cheap to fix.\n\n## Rationale\nData-driven design (ARCH-0001) and creator empowerment (CONTENT-0002) mean designers and artists\nauthor lots of data, and some of it will be wrong — a missing reference, an out-of-range value, a\nmalformed asset. If that error surfaces only at runtime (a crash, a broken level, a subtle\nwrong-number bug), it's expensive to trace back to its source and it may ship. Validating on\ningest inverts this: the error is reported to the person who made it, at the moment they made it,\nwith a clear message — cheap to fix and impossible to miss [S-gregory-game-engine-arch]. This is\nthe content-pipeline form of \"fail fast\" and of building quality in rather than testing it out\n(QA-0005): the earlier a defect is caught, the cheaper it is, and validation is how you push data\ndefects to the earliest possible point.\n\n## Applies when\nAny data-driven content pipeline — asset imports, data assets, level data, config. The more\ndesigner-authored data, the more validation pays.\n\n## Does not apply / Exceptions\nTrivial or one-off data may not justify formal validators. Over-strict validation can also block\nlegitimate work-in-progress (a designer mid-edit shouldn't be stopped by every transient\ninconsistency) — validation should distinguish \"broken and shippable\" from \"unfinished.\" And\nvalidators are code that must be maintained. Validate what actually breaks; don't gold-plate.\n\n## Implementation (kept separate from the principle)\nAdd validation at ingest points (import, save) and in the build, reporting errors clearly to the\nauthor. Distinguish hard errors (block) from warnings (flag). Key runtime state by stable\nidentifiers so missing/renamed content fails cleanly (ARCH-0001/0006, CONTENT-0003). Make the\nbuild fail on invalid content rather than shipping it. Treat this as part of building quality in\n(QA-0005).\n\n## Disagreement\nStrict early validation (catches defects cheaply, but tooling cost and can block WIP) vs.\npermissive pipelines (less friction, but runtime surprises). The balance is validating what\ngenuinely breaks while not obstructing legitimate in-progress work. Content-heavy, data-driven\nprojects strongly favor validation.\n\n## Notes\nThe data-integrity principle of CONTENT; the ingest-time application of fail-fast and \"build\nquality in\" (QA-0005), guarding data-driven content (ARCH-0001, CONTENT-0002). Confidence 4.\n","searchText":"gdc-l1-content-0004 validate content early — catch bad data on ingest, not at runtime content validation data-integrity pipeline fail-fast > validate content as early as possible — on import, on save, in the build — so bad data fails loudly and immediately, at the point it was created, rather than silently causing a mysterious bug or crash at runtime hours later. catch it where it's cheap to fix. data-driven design (arch-0001) and creator empowerment (content-0002) mean designers and artists author lots of data, and some of it will be wrong — a missing reference, an out-of-range value, a malformed asset. if that error surfaces only at runtime (a crash, a broken level, a subtle wrong-number bug), it's expensive to trace back to its source and it may ship. validating on ingest inverts this: the error is reported to the person who made it, at the moment they made it, with a clear message — cheap to fix and impossible to miss [s-gregory-game-engine-arch]. this is the content-pipeline form of \"fail fast\" and of building quality in rather than testing it out (qa-0005): the earlier a defect is caught, the cheaper it is, and validation is how you push data defects to the earliest possible point. any data-driven content pipeline — asset imports, data assets, level data, config. the more designer-authored data, the more validation pays. trivial or one-off data may not justify formal validators. over-strict validation can also block legitimate work-in-progress (a designer mid-edit shouldn't be stopped by every transient inconsistency) — validation should distinguish \"broken and shippable\" from \"unfinished.\" and validators are code that must be maintained. validate what actually breaks; don't gold-plate. add validation at ingest points (import, save) and in the build, reporting errors clearly to the author. distinguish hard errors (block) from warnings (flag). key runtime state by stable identifiers so missing/renamed content fails cleanly (arch-0001/0006, content-0003). make the build fail on invalid content rather than shipping it. treat this as part of building quality in (qa-0005). strict early validation (catches defects cheaply, but tooling cost and can block wip) vs. permissive pipelines (less friction, but runtime surprises). the balance is validating what genuinely breaks while not obstructing legitimate in-progress work. content-heavy, data-driven projects strongly favor validation. the data-integrity principle of content; the ingest-time application of fail-fast and \"build quality in\" (qa-0005), guarding data-driven content (arch-0001, content-0002). confidence 4."}
{"id":"GDC-L1-CONTENT-0005","title":"Automate the repetitive and keep builds reproducible","layer":"L1","domain":"CONTENT","subdomain":"build-tooling","type":"contextual","confidence":4,"status":"canonical","tags":["content","automation","build","source-control","reproducibility"],"related":["GDC-L1-CONTENT-0001","GDC-L1-ARCH-0005","GDC-L1-QA-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-gregory-game-engine-arch"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-CONTENT-0005.md","statement":"Automate repetitive pipeline work (asset processing, builds, validation, deployment) and keep builds reproducible — same inputs, same output, from clean source control. Manual, non-reproducible builds waste time, hide \"works on my machine\" bugs, and make releases risky.","sections":{"Statement":"> Automate repetitive pipeline work (asset processing, builds, validation, deployment) and keep\n> builds **reproducible** — same inputs, same output, from clean source control. Manual,\n> non-reproducible builds waste time, hide \"works on my machine\" bugs, and make releases risky.","Rationale":"Anything done by hand repeatedly is slow, error-prone, and a person's time wasted; automation\nconverts that recurring cost into a one-time setup that runs reliably forever\n[S-gregory-game-engine-arch]. Reproducibility is the deeper requirement: if a build depends on\nundocumented local state, one machine's quirks, or manual steps, then bugs can't be reliably\nreproduced (QA-0003/0004), releases are gambles, and teammates get different results from the\nsame source. Automated, reproducible builds from version control give a single source of truth,\ncatch integration breakage early (continuous builds), and make shipping a routine rather than a\nritual. This is the build/deployment side of investing in tooling (CONTENT-0001) and of the\niteration-speed and quality-in commitments (ARCH-0005, QA-0005).","Applies when":"Any project past prototype scale, and essential for any team (where \"works on my machine\" bugs and\nintegration breakage multiply). The larger the team and the more frequent the builds, the more it\nmatters.","Does not apply / Exceptions":"A solo weekend prototype can build manually. Full CI/CD and elaborate automation have setup and\nmaintenance cost that tiny projects may not recoup. The principle is \"automate what's repetitive\nand keep builds reproducible,\" scaled to the project — not \"build a AAA build farm for a game\njam.\"","Implementation (kept separate from the principle)":"Put everything needed to build in version control; script the build so it's reproducible from a\nclean checkout. Automate asset processing, validation (CONTENT-0004), and (as the team grows)\ncontinuous integration. Use non-destructive workflows and source control for assets, not just\ncode. Make releases a repeatable, tested process (feeding QA-0004 and SHIP). Measure and shorten\nbuild times (part of iteration speed, ARCH-0005).","Disagreement":"Automation/CI investment (reliability, speed, reproducibility — but setup and maintenance cost)\nvs. lean manual builds (start sooner, less infrastructure — but brittle and unreproducible at\nscale). Scales with team size and build frequency; solo/tiny projects lean manual, teams\nautomate.","Notes":"The build/reproducibility principle of CONTENT; the deployment side of tooling investment\n(CONTENT-0001), enabling reliable bug repro (QA-0003/0004) and shipping (SHIP). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-CONTENT-0005\ntitle: Automate the repetitive and keep builds reproducible\nlayer: L1\ndomain: CONTENT\nsubdomain: build-tooling\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - content\n  - automation\n  - build\n  - source-control\n  - reproducibility\nrelated:\n  - GDC-L1-CONTENT-0001\n  - GDC-L1-ARCH-0005\n  - GDC-L1-QA-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-gregory-game-engine-arch\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Automate repetitive pipeline work (asset processing, builds, validation, deployment) and keep\n> builds **reproducible** — same inputs, same output, from clean source control. Manual,\n> non-reproducible builds waste time, hide \"works on my machine\" bugs, and make releases risky.\n\n## Rationale\nAnything done by hand repeatedly is slow, error-prone, and a person's time wasted; automation\nconverts that recurring cost into a one-time setup that runs reliably forever\n[S-gregory-game-engine-arch]. Reproducibility is the deeper requirement: if a build depends on\nundocumented local state, one machine's quirks, or manual steps, then bugs can't be reliably\nreproduced (QA-0003/0004), releases are gambles, and teammates get different results from the\nsame source. Automated, reproducible builds from version control give a single source of truth,\ncatch integration breakage early (continuous builds), and make shipping a routine rather than a\nritual. This is the build/deployment side of investing in tooling (CONTENT-0001) and of the\niteration-speed and quality-in commitments (ARCH-0005, QA-0005).\n\n## Applies when\nAny project past prototype scale, and essential for any team (where \"works on my machine\" bugs and\nintegration breakage multiply). The larger the team and the more frequent the builds, the more it\nmatters.\n\n## Does not apply / Exceptions\nA solo weekend prototype can build manually. Full CI/CD and elaborate automation have setup and\nmaintenance cost that tiny projects may not recoup. The principle is \"automate what's repetitive\nand keep builds reproducible,\" scaled to the project — not \"build a AAA build farm for a game\njam.\"\n\n## Implementation (kept separate from the principle)\nPut everything needed to build in version control; script the build so it's reproducible from a\nclean checkout. Automate asset processing, validation (CONTENT-0004), and (as the team grows)\ncontinuous integration. Use non-destructive workflows and source control for assets, not just\ncode. Make releases a repeatable, tested process (feeding QA-0004 and SHIP). Measure and shorten\nbuild times (part of iteration speed, ARCH-0005).\n\n## Disagreement\nAutomation/CI investment (reliability, speed, reproducibility — but setup and maintenance cost)\nvs. lean manual builds (start sooner, less infrastructure — but brittle and unreproducible at\nscale). Scales with team size and build frequency; solo/tiny projects lean manual, teams\nautomate.\n\n## Notes\nThe build/reproducibility principle of CONTENT; the deployment side of tooling investment\n(CONTENT-0001), enabling reliable bug repro (QA-0003/0004) and shipping (SHIP). Confidence 4.\n","searchText":"gdc-l1-content-0005 automate the repetitive and keep builds reproducible content automation build source-control reproducibility > automate repetitive pipeline work (asset processing, builds, validation, deployment) and keep builds reproducible — same inputs, same output, from clean source control. manual, non-reproducible builds waste time, hide \"works on my machine\" bugs, and make releases risky. anything done by hand repeatedly is slow, error-prone, and a person's time wasted; automation converts that recurring cost into a one-time setup that runs reliably forever [s-gregory-game-engine-arch]. reproducibility is the deeper requirement: if a build depends on undocumented local state, one machine's quirks, or manual steps, then bugs can't be reliably reproduced (qa-0003/0004), releases are gambles, and teammates get different results from the same source. automated, reproducible builds from version control give a single source of truth, catch integration breakage early (continuous builds), and make shipping a routine rather than a ritual. this is the build/deployment side of investing in tooling (content-0001) and of the iteration-speed and quality-in commitments (arch-0005, qa-0005). any project past prototype scale, and essential for any team (where \"works on my machine\" bugs and integration breakage multiply). the larger the team and the more frequent the builds, the more it matters. a solo weekend prototype can build manually. full ci/cd and elaborate automation have setup and maintenance cost that tiny projects may not recoup. the principle is \"automate what's repetitive and keep builds reproducible,\" scaled to the project — not \"build a aaa build farm for a game jam.\" put everything needed to build in version control; script the build so it's reproducible from a clean checkout. automate asset processing, validation (content-0004), and (as the team grows) continuous integration. use non-destructive workflows and source control for assets, not just code. make releases a repeatable, tested process (feeding qa-0004 and ship). measure and shorten build times (part of iteration speed, arch-0005). automation/ci investment (reliability, speed, reproducibility — but setup and maintenance cost) vs. lean manual builds (start sooner, less infrastructure — but brittle and unreproducible at scale). scales with team size and build frequency; solo/tiny projects lean manual, teams automate. the build/reproducibility principle of content; the deployment side of tooling investment (content-0001), enabling reliable bug repro (qa-0003/0004) and shipping (ship). confidence 4."}
{"id":"GDC-L1-PERF-0001","title":"Measure, don't guess — profile before you optimize","layer":"L1","domain":"PERF","subdomain":"profiling-first","type":"objective","confidence":5,"status":"canonical","tags":["performance","profiling","measure-dont-guess","optimization"],"related":["GDC-L1-PLAYTEST-0005","GDC-L1-PERF-0003","GDC-L1-ARCH-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-perf-profiling"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PERF-0001.md","statement":"Never optimize on intuition. Profile first to find where time actually goes, then optimize only what the profiler proves is slow. Your guess about the bottleneck is usually wrong — measurement is the only reliable guide to where speed lives.","sections":{"Statement":"> Never optimize on intuition. **Profile first** to find where time actually goes, then\n> optimize only what the profiler proves is slow. Your guess about the bottleneck is\n> usually wrong — measurement is the only reliable guide to where speed lives.","Rationale":"Human intuition about performance is notoriously unreliable: the code that *looks*\nexpensive often isn't, and the real cost hides somewhere unglamorous (a redundant load, a\ncache-hostile loop, an accidental per-frame allocation). Optimizing without measuring means\nyou spend effort on code that wasn't the problem, complicate the codebase, and frequently\ndon't move the frame rate at all [S-perf-profiling]. A profiler replaces the guess with a\nfact — *this* function, *this* system, *this* draw call is eating the frame — so every hour\nof optimization is aimed at something that matters. \"Measure, don't guess\" is the same\ndiscipline as judging design by observed play (DESIGN-0001) and player behavior\n(PLAYTEST-0001), applied to performance.","Applies when":"Any performance work, on any platform. The instant the question is \"why is this slow?\" the\nanswer is \"profile it,\" not \"I bet it's X.\"","Does not apply / Exceptions":"Obvious, cheap wins with known costs (don't load a 4K texture for a 32px icon) don't need a\nprofiling session — some things are known-slow by construction. And profiling itself must be\nrepresentative: profile on target hardware under real workloads, since a debug build on a\ndev machine can mislead. But even \"obvious\" fixes should be *verified* by measurement, since\nthe obvious cause is often not the actual one.","Implementation (kept separate from the principle)":"Profile on representative hardware and content, not a beefy dev box on an empty scene.\nIdentify the single biggest cost, fix it, then *re-profile* (the bottleneck moves — see\nPERF-0003). Distinguish CPU-bound from GPU-bound before choosing a fix (PERF-0004). Keep\nbefore/after measurements so you can prove a change helped rather than assuming it did.","Disagreement":"No serious dissent: profile-first is near-universal engineering practice. The only nuance is\nhow much \"obvious\" optimization to do without formal profiling — and even there, the safe\nanswer is to verify.","Notes":"The foundational PERF principle and the resolution of the `PERF-0001` forward-reference from\nPLAYTEST-0005 (telemetry/measurement). Shares the \"measure, don't guess\" ethos that runs\nthrough DESIGN-0001, PLAYTEST-0001/0005, and SYS-0002. Confidence 5."},"rawMarkdown":"---\nid: GDC-L1-PERF-0001\ntitle: Measure, don't guess — profile before you optimize\nlayer: L1\ndomain: PERF\nsubdomain: profiling-first\ntype: objective\nconfidence: 5\nstatus: canonical\ntags:\n  - performance\n  - profiling\n  - measure-dont-guess\n  - optimization\nrelated:\n  - GDC-L1-PLAYTEST-0005\n  - GDC-L1-PERF-0003\n  - GDC-L1-ARCH-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-perf-profiling\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Never optimize on intuition. **Profile first** to find where time actually goes, then\n> optimize only what the profiler proves is slow. Your guess about the bottleneck is\n> usually wrong — measurement is the only reliable guide to where speed lives.\n\n## Rationale\nHuman intuition about performance is notoriously unreliable: the code that *looks*\nexpensive often isn't, and the real cost hides somewhere unglamorous (a redundant load, a\ncache-hostile loop, an accidental per-frame allocation). Optimizing without measuring means\nyou spend effort on code that wasn't the problem, complicate the codebase, and frequently\ndon't move the frame rate at all [S-perf-profiling]. A profiler replaces the guess with a\nfact — *this* function, *this* system, *this* draw call is eating the frame — so every hour\nof optimization is aimed at something that matters. \"Measure, don't guess\" is the same\ndiscipline as judging design by observed play (DESIGN-0001) and player behavior\n(PLAYTEST-0001), applied to performance.\n\n## Applies when\nAny performance work, on any platform. The instant the question is \"why is this slow?\" the\nanswer is \"profile it,\" not \"I bet it's X.\"\n\n## Does not apply / Exceptions\nObvious, cheap wins with known costs (don't load a 4K texture for a 32px icon) don't need a\nprofiling session — some things are known-slow by construction. And profiling itself must be\nrepresentative: profile on target hardware under real workloads, since a debug build on a\ndev machine can mislead. But even \"obvious\" fixes should be *verified* by measurement, since\nthe obvious cause is often not the actual one.\n\n## Implementation (kept separate from the principle)\nProfile on representative hardware and content, not a beefy dev box on an empty scene.\nIdentify the single biggest cost, fix it, then *re-profile* (the bottleneck moves — see\nPERF-0003). Distinguish CPU-bound from GPU-bound before choosing a fix (PERF-0004). Keep\nbefore/after measurements so you can prove a change helped rather than assuming it did.\n\n## Disagreement\nNo serious dissent: profile-first is near-universal engineering practice. The only nuance is\nhow much \"obvious\" optimization to do without formal profiling — and even there, the safe\nanswer is to verify.\n\n## Notes\nThe foundational PERF principle and the resolution of the `PERF-0001` forward-reference from\nPLAYTEST-0005 (telemetry/measurement). Shares the \"measure, don't guess\" ethos that runs\nthrough DESIGN-0001, PLAYTEST-0001/0005, and SYS-0002. Confidence 5.\n","searchText":"gdc-l1-perf-0001 measure, don't guess — profile before you optimize performance profiling measure-dont-guess optimization > never optimize on intuition. profile first to find where time actually goes, then optimize only what the profiler proves is slow. your guess about the bottleneck is usually wrong — measurement is the only reliable guide to where speed lives. human intuition about performance is notoriously unreliable: the code that looks expensive often isn't, and the real cost hides somewhere unglamorous (a redundant load, a cache-hostile loop, an accidental per-frame allocation). optimizing without measuring means you spend effort on code that wasn't the problem, complicate the codebase, and frequently don't move the frame rate at all [s-perf-profiling]. a profiler replaces the guess with a fact — this function, this system, this draw call is eating the frame — so every hour of optimization is aimed at something that matters. \"measure, don't guess\" is the same discipline as judging design by observed play (design-0001) and player behavior (playtest-0001), applied to performance. any performance work, on any platform. the instant the question is \"why is this slow?\" the answer is \"profile it,\" not \"i bet it's x.\" obvious, cheap wins with known costs (don't load a 4k texture for a 32px icon) don't need a profiling session — some things are known-slow by construction. and profiling itself must be representative: profile on target hardware under real workloads, since a debug build on a dev machine can mislead. but even \"obvious\" fixes should be verified by measurement, since the obvious cause is often not the actual one. profile on representative hardware and content, not a beefy dev box on an empty scene. identify the single biggest cost, fix it, then re-profile (the bottleneck moves — see perf-0003). distinguish cpu-bound from gpu-bound before choosing a fix (perf-0004). keep before/after measurements so you can prove a change helped rather than assuming it did. no serious dissent: profile-first is near-universal engineering practice. the only nuance is how much \"obvious\" optimization to do without formal profiling — and even there, the safe answer is to verify. the foundational perf principle and the resolution of the perf-0001 forward-reference from playtest-0005 (telemetry/measurement). shares the \"measure, don't guess\" ethos that runs through design-0001, playtest-0001/0005, and sys-0002. confidence 5."}
{"id":"GDC-L1-PERF-0002","title":"Don't optimize prematurely — implement simply first","layer":"L1","domain":"PERF","subdomain":"optimization-timing","type":"contextual","confidence":4,"status":"canonical","tags":["performance","premature-optimization","simplicity","iteration"],"related":["GDC-L1-PERF-0001","GDC-L1-DESIGN-0007","GDC-L1-ARCH-0006"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-knuth-premature"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PERF-0002.md","statement":"Write clear, correct, simple code first; optimize later, and only where measurement demands it. Premature optimization wastes effort on code that will change, obscures the design, and usually targets the wrong thing — \"premature optimization is the root of all evil.\" Correctness and clarity come before speed.","sections":{"Statement":"> Write clear, correct, simple code first; optimize later, and only where measurement\n> demands it. Premature optimization wastes effort on code that will change, obscures the\n> design, and usually targets the wrong thing — \"premature optimization is the root of all\n> evil.\" Correctness and clarity come before speed.","Rationale":"Early in development the game is in flux — systems get rebuilt, content multiplies, the\nperformance profile shifts drastically — so optimizations made before the design settles are\noften rendered irrelevant or actively harmful by later changes [S-knuth-premature].\nOptimizing early also costs twice: once to write the complex fast version, and again to\nunderstand and maintain it, all while the simple version would have been fine (only a small\nfraction of code — Knuth's \"critical 3%\" — ever meaningfully affects runtime). Clear code is\nalso easier to *correctly* optimize later, once profiling (PERF-0001) shows where it's\nactually needed. Simplicity first keeps the code malleable during the iteration that makes\nthe game good (PROTO/ARCH-0005).","Applies when":"Most feature and gameplay code during active development, before the design and content have\nstabilized enough for the performance profile to be meaningful.","Does not apply / Exceptions":"Two important limits. First, *architectural* decisions that are expensive to reverse — core\ndata layout, threading model, entity architecture — must consider performance up front,\nbecause you can't \"profile it later\" your way out of a fundamentally wrong foundation\n(this is the counter-tension, and it's real). Second, avoid *premature pessimization*:\ndeliberately writing gratuitously wasteful code \"to optimize later\" is its own mistake —\ndon't optimize early, but don't be needlessly slow either. Known hot paths and shipping\nplatform limits also warrant earlier attention.","Implementation (kept separate from the principle)":"Default to the simplest correct implementation. Reserve optimization for what the profiler\nflags (PERF-0001) on the critical path (PERF-0003). *Do* think about performance for\nhard-to-change architecture (data layout, PERF-0005; state/serialization, ARCH-0006) early.\nOtherwise, keep code clear and change it when measurement says to.","Disagreement":"The genuine tension: \"premature optimization is evil\" (defer, measure, keep it simple) vs.\n\"architecture is destiny\" (some performance-shaping decisions are effectively permanent and\nmust be made early). The reconciliation most engineers accept: defer *local* optimizations\n(algorithms, micro-tuning) until measured, but make *structural* performance decisions\nconsciously up front. Judge which kind you're facing.","Notes":"Pairs with PERF-0001 (measure) and PERF-0003 (bottleneck); its \"architecture early\" exception\nconnects to ARCH-0006 (serialization/state) and PERF-0005 (data layout). Allies with\nelegance/simplicity (DESIGN-0007). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PERF-0002\ntitle: Don't optimize prematurely — implement simply first\nlayer: L1\ndomain: PERF\nsubdomain: optimization-timing\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - performance\n  - premature-optimization\n  - simplicity\n  - iteration\nrelated:\n  - GDC-L1-PERF-0001\n  - GDC-L1-DESIGN-0007\n  - GDC-L1-ARCH-0006\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-knuth-premature\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Write clear, correct, simple code first; optimize later, and only where measurement\n> demands it. Premature optimization wastes effort on code that will change, obscures the\n> design, and usually targets the wrong thing — \"premature optimization is the root of all\n> evil.\" Correctness and clarity come before speed.\n\n## Rationale\nEarly in development the game is in flux — systems get rebuilt, content multiplies, the\nperformance profile shifts drastically — so optimizations made before the design settles are\noften rendered irrelevant or actively harmful by later changes [S-knuth-premature].\nOptimizing early also costs twice: once to write the complex fast version, and again to\nunderstand and maintain it, all while the simple version would have been fine (only a small\nfraction of code — Knuth's \"critical 3%\" — ever meaningfully affects runtime). Clear code is\nalso easier to *correctly* optimize later, once profiling (PERF-0001) shows where it's\nactually needed. Simplicity first keeps the code malleable during the iteration that makes\nthe game good (PROTO/ARCH-0005).\n\n## Applies when\nMost feature and gameplay code during active development, before the design and content have\nstabilized enough for the performance profile to be meaningful.\n\n## Does not apply / Exceptions\nTwo important limits. First, *architectural* decisions that are expensive to reverse — core\ndata layout, threading model, entity architecture — must consider performance up front,\nbecause you can't \"profile it later\" your way out of a fundamentally wrong foundation\n(this is the counter-tension, and it's real). Second, avoid *premature pessimization*:\ndeliberately writing gratuitously wasteful code \"to optimize later\" is its own mistake —\ndon't optimize early, but don't be needlessly slow either. Known hot paths and shipping\nplatform limits also warrant earlier attention.\n\n## Implementation (kept separate from the principle)\nDefault to the simplest correct implementation. Reserve optimization for what the profiler\nflags (PERF-0001) on the critical path (PERF-0003). *Do* think about performance for\nhard-to-change architecture (data layout, PERF-0005; state/serialization, ARCH-0006) early.\nOtherwise, keep code clear and change it when measurement says to.\n\n## Disagreement\nThe genuine tension: \"premature optimization is evil\" (defer, measure, keep it simple) vs.\n\"architecture is destiny\" (some performance-shaping decisions are effectively permanent and\nmust be made early). The reconciliation most engineers accept: defer *local* optimizations\n(algorithms, micro-tuning) until measured, but make *structural* performance decisions\nconsciously up front. Judge which kind you're facing.\n\n## Notes\nPairs with PERF-0001 (measure) and PERF-0003 (bottleneck); its \"architecture early\" exception\nconnects to ARCH-0006 (serialization/state) and PERF-0005 (data layout). Allies with\nelegance/simplicity (DESIGN-0007). Confidence 4.\n","searchText":"gdc-l1-perf-0002 don't optimize prematurely — implement simply first performance premature-optimization simplicity iteration > write clear, correct, simple code first; optimize later, and only where measurement demands it. premature optimization wastes effort on code that will change, obscures the design, and usually targets the wrong thing — \"premature optimization is the root of all evil.\" correctness and clarity come before speed. early in development the game is in flux — systems get rebuilt, content multiplies, the performance profile shifts drastically — so optimizations made before the design settles are often rendered irrelevant or actively harmful by later changes [s-knuth-premature]. optimizing early also costs twice: once to write the complex fast version, and again to understand and maintain it, all while the simple version would have been fine (only a small fraction of code — knuth's \"critical 3%\" — ever meaningfully affects runtime). clear code is also easier to correctly optimize later, once profiling (perf-0001) shows where it's actually needed. simplicity first keeps the code malleable during the iteration that makes the game good (proto/arch-0005). most feature and gameplay code during active development, before the design and content have stabilized enough for the performance profile to be meaningful. two important limits. first, architectural decisions that are expensive to reverse — core data layout, threading model, entity architecture — must consider performance up front, because you can't \"profile it later\" your way out of a fundamentally wrong foundation (this is the counter-tension, and it's real). second, avoid premature pessimization: deliberately writing gratuitously wasteful code \"to optimize later\" is its own mistake — don't optimize early, but don't be needlessly slow either. known hot paths and shipping platform limits also warrant earlier attention. default to the simplest correct implementation. reserve optimization for what the profiler flags (perf-0001) on the critical path (perf-0003). do think about performance for hard-to-change architecture (data layout, perf-0005; state/serialization, arch-0006) early. otherwise, keep code clear and change it when measurement says to. the genuine tension: \"premature optimization is evil\" (defer, measure, keep it simple) vs. \"architecture is destiny\" (some performance-shaping decisions are effectively permanent and must be made early). the reconciliation most engineers accept: defer local optimizations (algorithms, micro-tuning) until measured, but make structural performance decisions consciously up front. judge which kind you're facing. pairs with perf-0001 (measure) and perf-0003 (bottleneck); its \"architecture early\" exception connects to arch-0006 (serialization/state) and perf-0005 (data layout). allies with elegance/simplicity (design-0007). confidence 4."}
{"id":"GDC-L1-PERF-0003","title":"Optimize the bottleneck — the critical few, not the trivial many","layer":"L1","domain":"PERF","subdomain":"optimization-timing","type":"objective","confidence":4,"status":"canonical","tags":["performance","bottleneck","profiling","diminishing-returns"],"related":["GDC-L1-PERF-0001","GDC-L1-PERF-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-perf-profiling","S-knuth-premature"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PERF-0003.md","statement":"Performance work has sharply diminishing returns off the critical path. Find the single biggest bottleneck, fix it, re-profile, and repeat. Time spent speeding up code that isn't the bottleneck buys nothing — the frame is only as fast as its slowest necessary part.","sections":{"Statement":"> Performance work has sharply diminishing returns off the critical path. Find the single\n> biggest bottleneck, fix it, **re-profile**, and repeat. Time spent speeding up code that\n> isn't the bottleneck buys nothing — the frame is only as fast as its slowest necessary\n> part.","Rationale":"Runtime is dominated by a small fraction of the code — Knuth's \"critical 3%\" — so a game's\nframe time is gated by whichever system takes longest, and shaving a function that isn't\nthat system changes the frame rate not at all [S-perf-profiling] [S-knuth-premature]. This\nmakes optimization a targeting problem: the payoff comes from attacking the *current* top\ncost, not from broad, even effort across the codebase. And bottlenecks move — fix the top\none and a different system becomes the new ceiling — which is why optimization is a *loop*\n(profile → fix the top cost → re-profile) rather than a single pass. Working the loop\nconcentrates every hour where it actually buys frame time.","Applies when":"Any optimization pass. The rule for *what* to optimize: whatever profiling currently shows\nas the largest cost on the critical path.","Does not apply / Exceptions":"Death by a thousand cuts is real: sometimes there is no single fat bottleneck but many small\ncosts (lots of tiny per-frame allocations, thousands of trivial draw calls), and the fix is\na systemic pattern change rather than one hot function. Frame-time *spikes* (hitches) also\nneed different treatment than steady-state cost — a rare 40 ms stall hurts more than a\nslightly higher average. And memory or load-time budgets are separate axes from frame time.","Implementation (kept separate from the principle)":"Profile (PERF-0001), fix the top cost, and immediately re-profile to find the new top cost —\ndon't optimize a list of pre-planned targets, follow the profiler. Watch for the\nmany-small-costs pattern (attack it structurally). Track spikes separately from averages.\nStop when the frame fits the budget (PERF-0004), not when the code is \"as fast as possible.\"","Disagreement":"Little on \"optimize the bottleneck\"; the practical nuance is single-fat-bottleneck (attack\nit directly) vs. many-small-costs (change the pattern) vs. spikes (hunt the stall) — different\nshapes of performance problem needing different responses, all still guided by measurement.","Notes":"Follows directly from PERF-0001 (measure) and feeds PERF-0004 (budget defines \"fast enough\").\nThe critical-few framing echoes elegance and focus elsewhere in the corpus. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PERF-0003\ntitle: Optimize the bottleneck — the critical few, not the trivial many\nlayer: L1\ndomain: PERF\nsubdomain: optimization-timing\ntype: objective\nconfidence: 4\nstatus: canonical\ntags:\n  - performance\n  - bottleneck\n  - profiling\n  - diminishing-returns\nrelated:\n  - GDC-L1-PERF-0001\n  - GDC-L1-PERF-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-perf-profiling\n  - S-knuth-premature\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Performance work has sharply diminishing returns off the critical path. Find the single\n> biggest bottleneck, fix it, **re-profile**, and repeat. Time spent speeding up code that\n> isn't the bottleneck buys nothing — the frame is only as fast as its slowest necessary\n> part.\n\n## Rationale\nRuntime is dominated by a small fraction of the code — Knuth's \"critical 3%\" — so a game's\nframe time is gated by whichever system takes longest, and shaving a function that isn't\nthat system changes the frame rate not at all [S-perf-profiling] [S-knuth-premature]. This\nmakes optimization a targeting problem: the payoff comes from attacking the *current* top\ncost, not from broad, even effort across the codebase. And bottlenecks move — fix the top\none and a different system becomes the new ceiling — which is why optimization is a *loop*\n(profile → fix the top cost → re-profile) rather than a single pass. Working the loop\nconcentrates every hour where it actually buys frame time.\n\n## Applies when\nAny optimization pass. The rule for *what* to optimize: whatever profiling currently shows\nas the largest cost on the critical path.\n\n## Does not apply / Exceptions\nDeath by a thousand cuts is real: sometimes there is no single fat bottleneck but many small\ncosts (lots of tiny per-frame allocations, thousands of trivial draw calls), and the fix is\na systemic pattern change rather than one hot function. Frame-time *spikes* (hitches) also\nneed different treatment than steady-state cost — a rare 40 ms stall hurts more than a\nslightly higher average. And memory or load-time budgets are separate axes from frame time.\n\n## Implementation (kept separate from the principle)\nProfile (PERF-0001), fix the top cost, and immediately re-profile to find the new top cost —\ndon't optimize a list of pre-planned targets, follow the profiler. Watch for the\nmany-small-costs pattern (attack it structurally). Track spikes separately from averages.\nStop when the frame fits the budget (PERF-0004), not when the code is \"as fast as possible.\"\n\n## Disagreement\nLittle on \"optimize the bottleneck\"; the practical nuance is single-fat-bottleneck (attack\nit directly) vs. many-small-costs (change the pattern) vs. spikes (hunt the stall) — different\nshapes of performance problem needing different responses, all still guided by measurement.\n\n## Notes\nFollows directly from PERF-0001 (measure) and feeds PERF-0004 (budget defines \"fast enough\").\nThe critical-few framing echoes elegance and focus elsewhere in the corpus. Confidence 4.\n","searchText":"gdc-l1-perf-0003 optimize the bottleneck — the critical few, not the trivial many performance bottleneck profiling diminishing-returns > performance work has sharply diminishing returns off the critical path. find the single biggest bottleneck, fix it, re-profile, and repeat. time spent speeding up code that isn't the bottleneck buys nothing — the frame is only as fast as its slowest necessary part. runtime is dominated by a small fraction of the code — knuth's \"critical 3%\" — so a game's frame time is gated by whichever system takes longest, and shaving a function that isn't that system changes the frame rate not at all [s-perf-profiling] [s-knuth-premature]. this makes optimization a targeting problem: the payoff comes from attacking the current top cost, not from broad, even effort across the codebase. and bottlenecks move — fix the top one and a different system becomes the new ceiling — which is why optimization is a loop (profile → fix the top cost → re-profile) rather than a single pass. working the loop concentrates every hour where it actually buys frame time. any optimization pass. the rule for what to optimize: whatever profiling currently shows as the largest cost on the critical path. death by a thousand cuts is real: sometimes there is no single fat bottleneck but many small costs (lots of tiny per-frame allocations, thousands of trivial draw calls), and the fix is a systemic pattern change rather than one hot function. frame-time spikes (hitches) also need different treatment than steady-state cost — a rare 40 ms stall hurts more than a slightly higher average. and memory or load-time budgets are separate axes from frame time. profile (perf-0001), fix the top cost, and immediately re-profile to find the new top cost — don't optimize a list of pre-planned targets, follow the profiler. watch for the many-small-costs pattern (attack it structurally). track spikes separately from averages. stop when the frame fits the budget (perf-0004), not when the code is \"as fast as possible.\" little on \"optimize the bottleneck\"; the practical nuance is single-fat-bottleneck (attack it directly) vs. many-small-costs (change the pattern) vs. spikes (hunt the stall) — different shapes of performance problem needing different responses, all still guided by measurement. follows directly from perf-0001 (measure) and feeds perf-0004 (budget defines \"fast enough\"). the critical-few framing echoes elegance and focus elsewhere in the corpus. confidence 4."}
{"id":"GDC-L1-PERF-0004","title":"Budget the frame — decide what each system may spend","layer":"L1","domain":"PERF","subdomain":"frame-budget","type":"contextual","confidence":4,"status":"canonical","tags":["performance","frame-budget","cpu-gpu-bound","platform-constraints"],"related":["GDC-L1-PERF-0001","GDC-L1-PERF-0003","GDC-L1-FEEL-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-perf-profiling"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PERF-0004.md","statement":"A target frame rate is a fixed time budget — 60 fps means every frame must finish in about 16.6 ms. Treat that budget like money: allocate it across systems and hold each to its share. And know whether you're CPU-bound or GPU-bound, because the two have completely different fixes.","sections":{"Statement":"> A target frame rate is a **fixed time budget** — 60 fps means every frame must finish in\n> about 16.6 ms. Treat that budget like money: allocate it across systems and hold each to\n> its share. And know whether you're **CPU-bound or GPU-bound**, because the two have\n> completely different fixes.","Rationale":"Frame rate isn't a vague \"make it fast\" goal; it's a hard deadline the game must hit every\nframe or it stutters. Framing it as a budget makes the tradeoffs explicit — if rendering\ntakes 10 ms, AI, physics, gameplay, and audio must share the remaining ~6 ms — and turns\n\"is this affordable?\" into a concrete question [S-perf-profiling]. The CPU/GPU distinction is\nequally practical: the frame is bound by whichever finishes last, and the fixes diverge\nsharply. CPU-bound → cut draw calls, batch/instance, reduce algorithmic work, pool objects;\nGPU-bound → simplify shaders, add LODs, cull aggressively, scale resolution. Optimizing the\nwrong side wastes effort (speeding up a GPU that's already waiting on the CPU changes\nnothing). A quick diagnostic: halve the resolution — a big FPS jump means GPU-bound, little\nchange means CPU-bound.","Applies when":"Any real-time game with a frame-rate target — which is nearly all of them — and especially on\nfixed hardware (console, mobile) where the budget is hard and known.","Does not apply / Exceptions":"Non-real-time or turn-based experiences have looser frame constraints. Targets vary by game\nand platform (30 vs 60 vs 120+ fps; VR demands far stricter, per-eye budgets). Variable-rate\nand frame-generation techniques complicate the simple \"16.6 ms\" model. And frame budget is\nonly one axis — memory and load-time budgets matter too, on their own terms.","Implementation (kept separate from the principle)":"Set a frame-time target and sub-budgets per system; profile against them (PERF-0001) and\ntreat an over-budget system as the bottleneck (PERF-0003). Determine CPU- vs GPU-bound early\n(the resolution test) and aim fixes at the bound side. Budget to the *target* hardware, not\nthe dev machine. Remember that responsiveness (FEEL-0002) also depends on frame time —\nperformance is a feel issue, not just a technical one.","Disagreement":"Little on the budget concept itself; debate is about *what target* to choose (30 vs 60 vs\nhigh-refresh, and the fidelity-vs-framerate tradeoff), which is a design/platform decision\nrather than an engineering one.","Notes":"Turns PERF-0001/0003 into a concrete goal (fit the budget), and links performance to feel\n(FEEL-0002 — latency and frame time are the same coin). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PERF-0004\ntitle: Budget the frame — decide what each system may spend\nlayer: L1\ndomain: PERF\nsubdomain: frame-budget\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - performance\n  - frame-budget\n  - cpu-gpu-bound\n  - platform-constraints\nrelated:\n  - GDC-L1-PERF-0001\n  - GDC-L1-PERF-0003\n  - GDC-L1-FEEL-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-perf-profiling\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A target frame rate is a **fixed time budget** — 60 fps means every frame must finish in\n> about 16.6 ms. Treat that budget like money: allocate it across systems and hold each to\n> its share. And know whether you're **CPU-bound or GPU-bound**, because the two have\n> completely different fixes.\n\n## Rationale\nFrame rate isn't a vague \"make it fast\" goal; it's a hard deadline the game must hit every\nframe or it stutters. Framing it as a budget makes the tradeoffs explicit — if rendering\ntakes 10 ms, AI, physics, gameplay, and audio must share the remaining ~6 ms — and turns\n\"is this affordable?\" into a concrete question [S-perf-profiling]. The CPU/GPU distinction is\nequally practical: the frame is bound by whichever finishes last, and the fixes diverge\nsharply. CPU-bound → cut draw calls, batch/instance, reduce algorithmic work, pool objects;\nGPU-bound → simplify shaders, add LODs, cull aggressively, scale resolution. Optimizing the\nwrong side wastes effort (speeding up a GPU that's already waiting on the CPU changes\nnothing). A quick diagnostic: halve the resolution — a big FPS jump means GPU-bound, little\nchange means CPU-bound.\n\n## Applies when\nAny real-time game with a frame-rate target — which is nearly all of them — and especially on\nfixed hardware (console, mobile) where the budget is hard and known.\n\n## Does not apply / Exceptions\nNon-real-time or turn-based experiences have looser frame constraints. Targets vary by game\nand platform (30 vs 60 vs 120+ fps; VR demands far stricter, per-eye budgets). Variable-rate\nand frame-generation techniques complicate the simple \"16.6 ms\" model. And frame budget is\nonly one axis — memory and load-time budgets matter too, on their own terms.\n\n## Implementation (kept separate from the principle)\nSet a frame-time target and sub-budgets per system; profile against them (PERF-0001) and\ntreat an over-budget system as the bottleneck (PERF-0003). Determine CPU- vs GPU-bound early\n(the resolution test) and aim fixes at the bound side. Budget to the *target* hardware, not\nthe dev machine. Remember that responsiveness (FEEL-0002) also depends on frame time —\nperformance is a feel issue, not just a technical one.\n\n## Disagreement\nLittle on the budget concept itself; debate is about *what target* to choose (30 vs 60 vs\nhigh-refresh, and the fidelity-vs-framerate tradeoff), which is a design/platform decision\nrather than an engineering one.\n\n## Notes\nTurns PERF-0001/0003 into a concrete goal (fit the budget), and links performance to feel\n(FEEL-0002 — latency and frame time are the same coin). Confidence 4.\n","searchText":"gdc-l1-perf-0004 budget the frame — decide what each system may spend performance frame-budget cpu-gpu-bound platform-constraints > a target frame rate is a fixed time budget — 60 fps means every frame must finish in about 16.6 ms. treat that budget like money: allocate it across systems and hold each to its share. and know whether you're cpu-bound or gpu-bound, because the two have completely different fixes. frame rate isn't a vague \"make it fast\" goal; it's a hard deadline the game must hit every frame or it stutters. framing it as a budget makes the tradeoffs explicit — if rendering takes 10 ms, ai, physics, gameplay, and audio must share the remaining ~6 ms — and turns \"is this affordable?\" into a concrete question [s-perf-profiling]. the cpu/gpu distinction is equally practical: the frame is bound by whichever finishes last, and the fixes diverge sharply. cpu-bound → cut draw calls, batch/instance, reduce algorithmic work, pool objects; gpu-bound → simplify shaders, add lods, cull aggressively, scale resolution. optimizing the wrong side wastes effort (speeding up a gpu that's already waiting on the cpu changes nothing). a quick diagnostic: halve the resolution — a big fps jump means gpu-bound, little change means cpu-bound. any real-time game with a frame-rate target — which is nearly all of them — and especially on fixed hardware (console, mobile) where the budget is hard and known. non-real-time or turn-based experiences have looser frame constraints. targets vary by game and platform (30 vs 60 vs 120+ fps; vr demands far stricter, per-eye budgets). variable-rate and frame-generation techniques complicate the simple \"16.6 ms\" model. and frame budget is only one axis — memory and load-time budgets matter too, on their own terms. set a frame-time target and sub-budgets per system; profile against them (perf-0001) and treat an over-budget system as the bottleneck (perf-0003). determine cpu- vs gpu-bound early (the resolution test) and aim fixes at the bound side. budget to the target hardware, not the dev machine. remember that responsiveness (feel-0002) also depends on frame time — performance is a feel issue, not just a technical one. little on the budget concept itself; debate is about what target to choose (30 vs 60 vs high-refresh, and the fidelity-vs-framerate tradeoff), which is a design/platform decision rather than an engineering one. turns perf-0001/0003 into a concrete goal (fit the budget), and links performance to feel (feel-0002 — latency and frame time are the same coin). confidence 4."}
{"id":"GDC-L1-PERF-0005","title":"Respect data locality — memory layout often beats instruction cleverness","layer":"L1","domain":"PERF","subdomain":"memory","type":"contextual","confidence":4,"status":"canonical","tags":["performance","data-locality","cache","data-oriented-design","memory"],"related":["GDC-L1-PERF-0001","GDC-L1-ARCH-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-nystrom-gpp","S-perf-profiling"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PERF-0005.md","statement":"On modern hardware, how data is laid out in memory frequently dominates performance more than how clever the code is. A cache miss costs hundreds of cycles while cache hits cost a few, so laying out hot data contiguously and touching it in order can beat micro-optimizing the instructions that touch it — often by multiples.","sections":{"Statement":"> On modern hardware, *how data is laid out in memory* frequently dominates performance\n> more than *how clever the code is*. A cache miss costs hundreds of cycles while cache hits\n> cost a few, so laying out hot data contiguously and touching it in order can beat\n> micro-optimizing the instructions that touch it — often by multiples.","Rationale":"Processors have gotten dramatically faster while main-memory latency has barely improved, so\nthe gap between a cache hit (a few cycles) and a main-memory fetch (hundreds) now dwarfs the\ncost of most arithmetic [S-nystrom-gpp]. Code that chases pointers through scattered objects\nstalls the CPU waiting on memory, no matter how tight the logic; code that streams through\ncontiguous arrays keeps the cache fed and the pipeline busy. Measured differences between\ncache-friendly (structure-of-arrays) and cache-hostile (array-of-structures) layouts run\naround 5–7× for hot iteration [S-perf-profiling]. This is why performance-critical systems\nthat iterate over many entities every frame (particles, physics, AI, ECS) care intensely\nabout layout — and why the fix for a slow hot loop is often \"reorganize the data,\" not\n\"rewrite the math.\"","Applies when":"Hot loops over many items every frame — particles, physics, large entity updates, rendering\ndata. The more items and the more often you iterate, the more layout dominates.","Does not apply / Exceptions":"Cold code, small collections, and rarely-run logic don't benefit from layout gymnastics —\ndata-oriented restructuring adds real complexity and shouldn't be applied where profiling\n(PERF-0001) doesn't show a memory-bound hot loop. This is where the \"don't optimize\nprematurely\" rule (PERF-0002) bites: reorganizing everything into SoA up front is\nover-engineering. Restructure the hot paths measurement identifies, not the whole codebase.","Implementation (kept separate from the principle)":"For memory-bound hot loops, prefer contiguous storage and sequential access; group the fields you touch together (hot/cold splitting; structure-of-arrays for the fields you iterate). Pool and reuse rather than scatter-allocate. Verify with the profiler that a loop is memory-bound before restructuring it.","Disagreement":"Data-oriented design (organize by data and access patterns for the cache) sits in tension\nwith classical object-oriented modeling and encapsulation (organize by conceptual objects) —\nand with a naive reading of \"composition over inheritance\" (ARCH-0002), where scattered\ncomponent objects can be cache-hostile. The reconciliation most teams reach: **ECS**\n(entity-component-*system*) gets both — composition's flexibility *and* data-oriented layout —\nand you apply DOD to the hot paths while keeping OOP clarity for the cold majority. It's a\nwhere-and-when tradeoff, not a war.","Notes":"Governed by PERF-0001 (measure first) and PERF-0002 (don't do it prematurely). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PERF-0005\ntitle: Respect data locality — memory layout often beats instruction cleverness\nlayer: L1\ndomain: PERF\nsubdomain: memory\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - performance\n  - data-locality\n  - cache\n  - data-oriented-design\n  - memory\nrelated:\n  - GDC-L1-PERF-0001\n  - GDC-L1-ARCH-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-nystrom-gpp\n  - S-perf-profiling\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> On modern hardware, *how data is laid out in memory* frequently dominates performance\n> more than *how clever the code is*. A cache miss costs hundreds of cycles while cache hits\n> cost a few, so laying out hot data contiguously and touching it in order can beat\n> micro-optimizing the instructions that touch it — often by multiples.\n\n## Rationale\nProcessors have gotten dramatically faster while main-memory latency has barely improved, so\nthe gap between a cache hit (a few cycles) and a main-memory fetch (hundreds) now dwarfs the\ncost of most arithmetic [S-nystrom-gpp]. Code that chases pointers through scattered objects\nstalls the CPU waiting on memory, no matter how tight the logic; code that streams through\ncontiguous arrays keeps the cache fed and the pipeline busy. Measured differences between\ncache-friendly (structure-of-arrays) and cache-hostile (array-of-structures) layouts run\naround 5–7× for hot iteration [S-perf-profiling]. This is why performance-critical systems\nthat iterate over many entities every frame (particles, physics, AI, ECS) care intensely\nabout layout — and why the fix for a slow hot loop is often \"reorganize the data,\" not\n\"rewrite the math.\"\n\n## Applies when\nHot loops over many items every frame — particles, physics, large entity updates, rendering\ndata. The more items and the more often you iterate, the more layout dominates.\n\n## Does not apply / Exceptions\nCold code, small collections, and rarely-run logic don't benefit from layout gymnastics —\ndata-oriented restructuring adds real complexity and shouldn't be applied where profiling\n(PERF-0001) doesn't show a memory-bound hot loop. This is where the \"don't optimize\nprematurely\" rule (PERF-0002) bites: reorganizing everything into SoA up front is\nover-engineering. Restructure the hot paths measurement identifies, not the whole codebase.\n\n## Implementation (kept separate from the principle)\nFor memory-bound hot loops, prefer contiguous storage and sequential access; group the fields you touch together (hot/cold splitting; structure-of-arrays for the fields you iterate). Pool and reuse rather than scatter-allocate. Verify with the profiler that a loop is memory-bound before restructuring it.\n\n## Disagreement\nData-oriented design (organize by data and access patterns for the cache) sits in tension\nwith classical object-oriented modeling and encapsulation (organize by conceptual objects) —\nand with a naive reading of \"composition over inheritance\" (ARCH-0002), where scattered\ncomponent objects can be cache-hostile. The reconciliation most teams reach: **ECS**\n(entity-component-*system*) gets both — composition's flexibility *and* data-oriented layout —\nand you apply DOD to the hot paths while keeping OOP clarity for the cold majority. It's a\nwhere-and-when tradeoff, not a war.\n\n## Notes\nGoverned by PERF-0001 (measure first) and PERF-0002 (don't do it prematurely). Confidence 4.\n","searchText":"gdc-l1-perf-0005 respect data locality — memory layout often beats instruction cleverness performance data-locality cache data-oriented-design memory > on modern hardware, how data is laid out in memory frequently dominates performance more than how clever the code is. a cache miss costs hundreds of cycles while cache hits cost a few, so laying out hot data contiguously and touching it in order can beat micro-optimizing the instructions that touch it — often by multiples. processors have gotten dramatically faster while main-memory latency has barely improved, so the gap between a cache hit (a few cycles) and a main-memory fetch (hundreds) now dwarfs the cost of most arithmetic [s-nystrom-gpp]. code that chases pointers through scattered objects stalls the cpu waiting on memory, no matter how tight the logic; code that streams through contiguous arrays keeps the cache fed and the pipeline busy. measured differences between cache-friendly (structure-of-arrays) and cache-hostile (array-of-structures) layouts run around 5–7× for hot iteration [s-perf-profiling]. this is why performance-critical systems that iterate over many entities every frame (particles, physics, ai, ecs) care intensely about layout — and why the fix for a slow hot loop is often \"reorganize the data,\" not \"rewrite the math.\" hot loops over many items every frame — particles, physics, large entity updates, rendering data. the more items and the more often you iterate, the more layout dominates. cold code, small collections, and rarely-run logic don't benefit from layout gymnastics — data-oriented restructuring adds real complexity and shouldn't be applied where profiling (perf-0001) doesn't show a memory-bound hot loop. this is where the \"don't optimize prematurely\" rule (perf-0002) bites: reorganizing everything into soa up front is over-engineering. restructure the hot paths measurement identifies, not the whole codebase. for memory-bound hot loops, prefer contiguous storage and sequential access; group the fields you touch together (hot/cold splitting; structure-of-arrays for the fields you iterate). pool and reuse rather than scatter-allocate. verify with the profiler that a loop is memory-bound before restructuring it. data-oriented design (organize by data and access patterns for the cache) sits in tension with classical object-oriented modeling and encapsulation (organize by conceptual objects) — and with a naive reading of \"composition over inheritance\" (arch-0002), where scattered component objects can be cache-hostile. the reconciliation most teams reach: ecs (entity-component-system) gets both — composition's flexibility and data-oriented layout — and you apply dod to the hot paths while keeping oop clarity for the cold majority. it's a where-and-when tradeoff, not a war. governed by perf-0001 (measure first) and perf-0002 (don't do it prematurely). confidence 4."}
{"id":"GDC-L1-QA-0001","title":"Match test rigor to risk","layer":"L1","domain":"QA","subdomain":"test-strategy","type":"contextual","confidence":4,"status":"canonical","tags":["qa","testing","risk","strategy","prioritization"],"related":["GDC-L1-PERF-0003","GDC-L1-PROTO-0002","GDC-L1-QA-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-games-user-research","S-scope-production"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-QA-0001.md","statement":"Spend testing effort where the risk is highest. Not everything needs the same rigor: the core loop, the systems everything depends on, the save/economy/networking that can corrupt or cheat, and the launch path deserve heavy testing; peripheral, low-impact, rarely-hit content deserves less. Test by risk, not uniformly.","sections":{"Statement":"> Spend testing effort where the risk is highest. Not everything needs the same rigor: the core\n> loop, the systems everything depends on, the save/economy/networking that can corrupt or cheat,\n> and the launch path deserve heavy testing; peripheral, low-impact, rarely-hit content deserves\n> less. Test by risk, not uniformly.","Rationale":"Testing is finite, and applying it evenly wastes it — the same failure-hunting logic as\noptimizing the bottleneck (PERF-0003) and prototyping the riskiest assumption first (PROTO-0002):\nthe payoff comes from attacking the highest (probability × impact) risks first [S-scope-production].\nA save-corruption or economy-exploit bug is catastrophic and worth deep testing; a cosmetic glitch\nin a rarely-visited room is not. Risk-based testing also directs *what kind* of testing to use\n(QA-0002): high-regression-risk systems want automation, feel/fun questions want human play. A test\nplan that ranks by risk finds the important bugs with the effort available, rather than exhausting\nitself on the trivial and missing the catastrophic.","Applies when":"Any test planning — deciding what to test, how hard, and with what method. Throughout development\nand especially before milestones and launch (SHIP-0001).","Does not apply / Exceptions":"Safety-, certification-, or compliance-critical areas may require uniform thoroughness regardless\nof apparent risk (platform cert, legal, accessibility conformance). And \"low risk\" can be\nmis-assessed — the point is *deliberate* risk assessment, not an excuse to skip testing you find\ninconvenient. Very small games test informally but should still weight the core loop heaviest.","Implementation (kept separate from the principle)":"Rank areas by (likelihood of failure) × (cost if it fails), and allocate testing accordingly.\nTest the core loop, dependency-heavy systems, and data-integrity/security/networking hardest.\nChoose method by risk type: automation for regression-prone systems (QA-0002), human testing for\nfeel and emergent behavior. Re-assess risk as the game changes. Meet certification/compliance\nthoroughness regardless.","Disagreement":"Risk-based testing (efficient, focuses effort — but depends on assessing risk correctly) vs.\nuniform/exhaustive testing (thorough, but expensive and often infeasible). Certification contexts\ndemand uniformity; most development benefits from risk prioritization. The nuance is getting the\nrisk assessment right.","Notes":"The strategy principle of QA; the testing form of \"attack the biggest risk first\" (PERF-0003,\nPROTO-0002). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-QA-0001\ntitle: Match test rigor to risk\nlayer: L1\ndomain: QA\nsubdomain: test-strategy\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - qa\n  - testing\n  - risk\n  - strategy\n  - prioritization\nrelated:\n  - GDC-L1-PERF-0003\n  - GDC-L1-PROTO-0002\n  - GDC-L1-QA-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-games-user-research\n  - S-scope-production\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Spend testing effort where the risk is highest. Not everything needs the same rigor: the core\n> loop, the systems everything depends on, the save/economy/networking that can corrupt or cheat,\n> and the launch path deserve heavy testing; peripheral, low-impact, rarely-hit content deserves\n> less. Test by risk, not uniformly.\n\n## Rationale\nTesting is finite, and applying it evenly wastes it — the same failure-hunting logic as\noptimizing the bottleneck (PERF-0003) and prototyping the riskiest assumption first (PROTO-0002):\nthe payoff comes from attacking the highest (probability × impact) risks first [S-scope-production].\nA save-corruption or economy-exploit bug is catastrophic and worth deep testing; a cosmetic glitch\nin a rarely-visited room is not. Risk-based testing also directs *what kind* of testing to use\n(QA-0002): high-regression-risk systems want automation, feel/fun questions want human play. A test\nplan that ranks by risk finds the important bugs with the effort available, rather than exhausting\nitself on the trivial and missing the catastrophic.\n\n## Applies when\nAny test planning — deciding what to test, how hard, and with what method. Throughout development\nand especially before milestones and launch (SHIP-0001).\n\n## Does not apply / Exceptions\nSafety-, certification-, or compliance-critical areas may require uniform thoroughness regardless\nof apparent risk (platform cert, legal, accessibility conformance). And \"low risk\" can be\nmis-assessed — the point is *deliberate* risk assessment, not an excuse to skip testing you find\ninconvenient. Very small games test informally but should still weight the core loop heaviest.\n\n## Implementation (kept separate from the principle)\nRank areas by (likelihood of failure) × (cost if it fails), and allocate testing accordingly.\nTest the core loop, dependency-heavy systems, and data-integrity/security/networking hardest.\nChoose method by risk type: automation for regression-prone systems (QA-0002), human testing for\nfeel and emergent behavior. Re-assess risk as the game changes. Meet certification/compliance\nthoroughness regardless.\n\n## Disagreement\nRisk-based testing (efficient, focuses effort — but depends on assessing risk correctly) vs.\nuniform/exhaustive testing (thorough, but expensive and often infeasible). Certification contexts\ndemand uniformity; most development benefits from risk prioritization. The nuance is getting the\nrisk assessment right.\n\n## Notes\nThe strategy principle of QA; the testing form of \"attack the biggest risk first\" (PERF-0003,\nPROTO-0002). Confidence 4.\n","searchText":"gdc-l1-qa-0001 match test rigor to risk qa testing risk strategy prioritization > spend testing effort where the risk is highest. not everything needs the same rigor: the core loop, the systems everything depends on, the save/economy/networking that can corrupt or cheat, and the launch path deserve heavy testing; peripheral, low-impact, rarely-hit content deserves less. test by risk, not uniformly. testing is finite, and applying it evenly wastes it — the same failure-hunting logic as optimizing the bottleneck (perf-0003) and prototyping the riskiest assumption first (proto-0002): the payoff comes from attacking the highest (probability × impact) risks first [s-scope-production]. a save-corruption or economy-exploit bug is catastrophic and worth deep testing; a cosmetic glitch in a rarely-visited room is not. risk-based testing also directs what kind of testing to use (qa-0002): high-regression-risk systems want automation, feel/fun questions want human play. a test plan that ranks by risk finds the important bugs with the effort available, rather than exhausting itself on the trivial and missing the catastrophic. any test planning — deciding what to test, how hard, and with what method. throughout development and especially before milestones and launch (ship-0001). safety-, certification-, or compliance-critical areas may require uniform thoroughness regardless of apparent risk (platform cert, legal, accessibility conformance). and \"low risk\" can be mis-assessed — the point is deliberate risk assessment, not an excuse to skip testing you find inconvenient. very small games test informally but should still weight the core loop heaviest. rank areas by (likelihood of failure) × (cost if it fails), and allocate testing accordingly. test the core loop, dependency-heavy systems, and data-integrity/security/networking hardest. choose method by risk type: automation for regression-prone systems (qa-0002), human testing for feel and emergent behavior. re-assess risk as the game changes. meet certification/compliance thoroughness regardless. risk-based testing (efficient, focuses effort — but depends on assessing risk correctly) vs. uniform/exhaustive testing (thorough, but expensive and often infeasible). certification contexts demand uniformity; most development benefits from risk prioritization. the nuance is getting the risk assessment right. the strategy principle of qa; the testing form of \"attack the biggest risk first\" (perf-0003, proto-0002). confidence 4."}
{"id":"GDC-L1-QA-0002","title":"Automate regression; human-test feel and emergence","layer":"L1","domain":"QA","subdomain":"automated-testing-of-games","type":"contextual","confidence":4,"status":"canonical","tags":["qa","automation","regression","playtesting","feel"],"related":["GDC-L1-PLAYTEST-0001","GDC-L1-QA-0001","GDC-L1-ARCH-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-games-user-research"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-QA-0002.md","statement":"Use the right kind of testing for the question. Automate what is deterministic and regression-prone — systems, math, save/load, builds — so it's checked cheaply and constantly. Use human testing for what machines can't judge: fun, feel, difficulty, and emergent behavior. Neither replaces the other.","sections":{"Statement":"> Use the right kind of testing for the question. **Automate** what is deterministic and\n> regression-prone — systems, math, save/load, builds — so it's checked cheaply and constantly.\n> Use **human testing** for what machines can't judge: fun, feel, difficulty, and emergent\n> behavior. Neither replaces the other.","Rationale":"Games have two very different testing needs. Deterministic correctness (does the damage formula\ncompute right? does save/load round-trip? did that refactor break anything?) is perfect for\nautomation — fast, repeatable, and it catches regressions the moment they appear, which protects\niteration speed (ARCH-0005). But the questions that most determine whether a game is *good* — is\nit fun, does it feel right, is the difficulty fair, what emerges when systems interact — are\nsubjective and situational, and only human play can answer them (which is why playtesting,\nPLAYTEST-0001, exists) [S-games-user-research]. Trying to automate \"is it fun\" fails; trying to\nmanually regression-test every build wastes people and misses things. Matching method to question\n(and to risk, QA-0001) gets both cheap regression safety and real judgment about the experience.","Applies when":"All testing. Automation scales with deterministic, regression-prone systems; human testing scales\nwith subjective/experiential and emergent aspects. Most games need both.","Does not apply / Exceptions":"Highly emergent or non-deterministic systems resist automated testing (and automating a fast-\nchanging prototype's tests can be wasted effort as it churns — automate *stable* things). Tiny\ngames may rely mostly on human testing. And automation has real setup/maintenance cost that must\nbe justified. The split is a guide, not a mandate to automate everything automatable.","Implementation (kept separate from the principle)":"Write automated tests for stable, deterministic, regression-prone systems (formulas, save/load,\ncore systems, build validation — CONTENT-0004/0005). Run them continuously (CONTENT-0005). Reserve\nhuman testing — structured playtests (PLAYTEST) and exploratory QA — for feel, fun, difficulty,\nand emergent/edge behavior. Prioritize both by risk (QA-0001).","Disagreement":"Test-automation-heavy (fast regression safety, but setup cost and can't judge fun) vs.\nhuman-testing-heavy (judges the experience, but slow and misses regressions). The synthesis —\nautomate the deterministic, human-test the experiential — is broadly held; the debate is how much\nto invest in automation for a medium where the most important qualities are subjective.","Notes":"The method principle of QA; pairs automation with human playtesting (PLAYTEST-0001) and protects\niteration (ARCH-0005) via regression safety. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-QA-0002\ntitle: Automate regression; human-test feel and emergence\nlayer: L1\ndomain: QA\nsubdomain: automated-testing-of-games\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - qa\n  - automation\n  - regression\n  - playtesting\n  - feel\nrelated:\n  - GDC-L1-PLAYTEST-0001\n  - GDC-L1-QA-0001\n  - GDC-L1-ARCH-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-games-user-research\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Use the right kind of testing for the question. **Automate** what is deterministic and\n> regression-prone — systems, math, save/load, builds — so it's checked cheaply and constantly.\n> Use **human testing** for what machines can't judge: fun, feel, difficulty, and emergent\n> behavior. Neither replaces the other.\n\n## Rationale\nGames have two very different testing needs. Deterministic correctness (does the damage formula\ncompute right? does save/load round-trip? did that refactor break anything?) is perfect for\nautomation — fast, repeatable, and it catches regressions the moment they appear, which protects\niteration speed (ARCH-0005). But the questions that most determine whether a game is *good* — is\nit fun, does it feel right, is the difficulty fair, what emerges when systems interact — are\nsubjective and situational, and only human play can answer them (which is why playtesting,\nPLAYTEST-0001, exists) [S-games-user-research]. Trying to automate \"is it fun\" fails; trying to\nmanually regression-test every build wastes people and misses things. Matching method to question\n(and to risk, QA-0001) gets both cheap regression safety and real judgment about the experience.\n\n## Applies when\nAll testing. Automation scales with deterministic, regression-prone systems; human testing scales\nwith subjective/experiential and emergent aspects. Most games need both.\n\n## Does not apply / Exceptions\nHighly emergent or non-deterministic systems resist automated testing (and automating a fast-\nchanging prototype's tests can be wasted effort as it churns — automate *stable* things). Tiny\ngames may rely mostly on human testing. And automation has real setup/maintenance cost that must\nbe justified. The split is a guide, not a mandate to automate everything automatable.\n\n## Implementation (kept separate from the principle)\nWrite automated tests for stable, deterministic, regression-prone systems (formulas, save/load,\ncore systems, build validation — CONTENT-0004/0005). Run them continuously (CONTENT-0005). Reserve\nhuman testing — structured playtests (PLAYTEST) and exploratory QA — for feel, fun, difficulty,\nand emergent/edge behavior. Prioritize both by risk (QA-0001).\n\n## Disagreement\nTest-automation-heavy (fast regression safety, but setup cost and can't judge fun) vs.\nhuman-testing-heavy (judges the experience, but slow and misses regressions). The synthesis —\nautomate the deterministic, human-test the experiential — is broadly held; the debate is how much\nto invest in automation for a medium where the most important qualities are subjective.\n\n## Notes\nThe method principle of QA; pairs automation with human playtesting (PLAYTEST-0001) and protects\niteration (ARCH-0005) via regression safety. Confidence 4.\n","searchText":"gdc-l1-qa-0002 automate regression; human-test feel and emergence qa automation regression playtesting feel > use the right kind of testing for the question. automate what is deterministic and regression-prone — systems, math, save/load, builds — so it's checked cheaply and constantly. use human testing for what machines can't judge: fun, feel, difficulty, and emergent behavior. neither replaces the other. games have two very different testing needs. deterministic correctness (does the damage formula compute right? does save/load round-trip? did that refactor break anything?) is perfect for automation — fast, repeatable, and it catches regressions the moment they appear, which protects iteration speed (arch-0005). but the questions that most determine whether a game is good — is it fun, does it feel right, is the difficulty fair, what emerges when systems interact — are subjective and situational, and only human play can answer them (which is why playtesting, playtest-0001, exists) [s-games-user-research]. trying to automate \"is it fun\" fails; trying to manually regression-test every build wastes people and misses things. matching method to question (and to risk, qa-0001) gets both cheap regression safety and real judgment about the experience. all testing. automation scales with deterministic, regression-prone systems; human testing scales with subjective/experiential and emergent aspects. most games need both. highly emergent or non-deterministic systems resist automated testing (and automating a fast- changing prototype's tests can be wasted effort as it churns — automate stable things). tiny games may rely mostly on human testing. and automation has real setup/maintenance cost that must be justified. the split is a guide, not a mandate to automate everything automatable. write automated tests for stable, deterministic, regression-prone systems (formulas, save/load, core systems, build validation — content-0004/0005). run them continuously (content-0005). reserve human testing — structured playtests (playtest) and exploratory qa — for feel, fun, difficulty, and emergent/edge behavior. prioritize both by risk (qa-0001). test-automation-heavy (fast regression safety, but setup cost and can't judge fun) vs. human-testing-heavy (judges the experience, but slow and misses regressions). the synthesis — automate the deterministic, human-test the experiential — is broadly held; the debate is how much to invest in automation for a medium where the most important qualities are subjective. the method principle of qa; pairs automation with human playtesting (playtest-0001) and protects iteration (arch-0005) via regression safety. confidence 4."}
{"id":"GDC-L1-QA-0003","title":"A bug you can't reproduce, you can't fix","layer":"L1","domain":"QA","subdomain":"repro-and-bug-tracking","type":"contextual","confidence":4,"status":"canonical","tags":["qa","reproduction","bug-tracking","determinism","logging"],"related":["GDC-L1-QA-0002","GDC-L1-CONTENT-0005","GDC-L1-TEAM-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-games-user-research"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-QA-0003.md","statement":"Reproduction is the heart of fixing bugs: a defect you can reliably trigger you can diagnose and verify fixed; one you can't reproduce you can only guess at. Invest in the things that make bugs reproducible — clear repro steps, determinism where feasible, good logging, and captured state — so bugs become tractable instead of haunting.","sections":{"Statement":"> Reproduction is the heart of fixing bugs: a defect you can reliably trigger you can diagnose and\n> verify fixed; one you can't reproduce you can only guess at. Invest in the things that make bugs\n> reproducible — clear repro steps, determinism where feasible, good logging, and captured state —\n> so bugs become tractable instead of haunting.","Rationale":"The debugging loop is reproduce → diagnose → fix → verify, and it stalls entirely at step one: if\nyou can't make the bug happen on demand, you can't watch it, can't be sure of the cause, and can't\nconfirm your fix actually worked [S-games-user-research]. So reproducibility is the single most\nvaluable property for bug-fixing, and it doesn't happen by accident — it's enabled by disciplined\nrepro steps in reports, determinism (same inputs → same behavior, which also aids automated\ntesting, QA-0002, and reproducible builds, CONTENT-0005), comprehensive logging, and the ability\nto capture and replay state. Non-reproducible bugs (\"it happened once\") are the ones that ship and\nrecur. Making bugs reproducible is upstream of fixing them.","Applies when":"All bug-fixing and QA. Especially critical for intermittent, timing-dependent, or emergent bugs,\nand for anything that must be verified fixed.","Does not apply / Exceptions":"Some bugs are genuinely rare/environmental and full determinism is impractical (network races,\nhardware-specific issues) — there you invest in *observability* (logging, crash dumps, telemetry)\nto reconstruct what happened, since you can't reproduce it directly. And chasing perfect\nreproducibility for a trivial cosmetic bug isn't worth it (risk-weight it, QA-0001).","Implementation (kept separate from the principle)":"Require clear repro steps in bug reports. Build for determinism where feasible (fixed seeds,\ndeterministic simulation) — it aids repro, automated testing (QA-0002), and reproducible builds\n(CONTENT-0005). Log richly and capture state/crash dumps so hard-to-repro bugs can be reconstructed\n(observability). Verify fixes by reproducing the original and confirming it's gone. Treat\nnon-reproducible recurring bugs as a signal to improve observability.","Disagreement":"Little on the principle; the nuance is how much to invest in determinism/observability infrastructure\nversus living with some irreproducible bugs. High-reliability and competitive/networked games invest\nheavily; smaller games lean on logging and accept some mystery bugs.","Notes":"The debugging-foundation principle of QA; enabled by determinism (shared with QA-0002 and\nCONTENT-0005) and observability. Pairs with blameless problem-solving (TEAM-0003 — reproduce and\nfix the system, don't blame). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-QA-0003\ntitle: A bug you can't reproduce, you can't fix\nlayer: L1\ndomain: QA\nsubdomain: repro-and-bug-tracking\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - qa\n  - reproduction\n  - bug-tracking\n  - determinism\n  - logging\nrelated:\n  - GDC-L1-QA-0002\n  - GDC-L1-CONTENT-0005\n  - GDC-L1-TEAM-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-games-user-research\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Reproduction is the heart of fixing bugs: a defect you can reliably trigger you can diagnose and\n> verify fixed; one you can't reproduce you can only guess at. Invest in the things that make bugs\n> reproducible — clear repro steps, determinism where feasible, good logging, and captured state —\n> so bugs become tractable instead of haunting.\n\n## Rationale\nThe debugging loop is reproduce → diagnose → fix → verify, and it stalls entirely at step one: if\nyou can't make the bug happen on demand, you can't watch it, can't be sure of the cause, and can't\nconfirm your fix actually worked [S-games-user-research]. So reproducibility is the single most\nvaluable property for bug-fixing, and it doesn't happen by accident — it's enabled by disciplined\nrepro steps in reports, determinism (same inputs → same behavior, which also aids automated\ntesting, QA-0002, and reproducible builds, CONTENT-0005), comprehensive logging, and the ability\nto capture and replay state. Non-reproducible bugs (\"it happened once\") are the ones that ship and\nrecur. Making bugs reproducible is upstream of fixing them.\n\n## Applies when\nAll bug-fixing and QA. Especially critical for intermittent, timing-dependent, or emergent bugs,\nand for anything that must be verified fixed.\n\n## Does not apply / Exceptions\nSome bugs are genuinely rare/environmental and full determinism is impractical (network races,\nhardware-specific issues) — there you invest in *observability* (logging, crash dumps, telemetry)\nto reconstruct what happened, since you can't reproduce it directly. And chasing perfect\nreproducibility for a trivial cosmetic bug isn't worth it (risk-weight it, QA-0001).\n\n## Implementation (kept separate from the principle)\nRequire clear repro steps in bug reports. Build for determinism where feasible (fixed seeds,\ndeterministic simulation) — it aids repro, automated testing (QA-0002), and reproducible builds\n(CONTENT-0005). Log richly and capture state/crash dumps so hard-to-repro bugs can be reconstructed\n(observability). Verify fixes by reproducing the original and confirming it's gone. Treat\nnon-reproducible recurring bugs as a signal to improve observability.\n\n## Disagreement\nLittle on the principle; the nuance is how much to invest in determinism/observability infrastructure\nversus living with some irreproducible bugs. High-reliability and competitive/networked games invest\nheavily; smaller games lean on logging and accept some mystery bugs.\n\n## Notes\nThe debugging-foundation principle of QA; enabled by determinism (shared with QA-0002 and\nCONTENT-0005) and observability. Pairs with blameless problem-solving (TEAM-0003 — reproduce and\nfix the system, don't blame). Confidence 4.\n","searchText":"gdc-l1-qa-0003 a bug you can't reproduce, you can't fix qa reproduction bug-tracking determinism logging > reproduction is the heart of fixing bugs: a defect you can reliably trigger you can diagnose and verify fixed; one you can't reproduce you can only guess at. invest in the things that make bugs reproducible — clear repro steps, determinism where feasible, good logging, and captured state — so bugs become tractable instead of haunting. the debugging loop is reproduce → diagnose → fix → verify, and it stalls entirely at step one: if you can't make the bug happen on demand, you can't watch it, can't be sure of the cause, and can't confirm your fix actually worked [s-games-user-research]. so reproducibility is the single most valuable property for bug-fixing, and it doesn't happen by accident — it's enabled by disciplined repro steps in reports, determinism (same inputs → same behavior, which also aids automated testing, qa-0002, and reproducible builds, content-0005), comprehensive logging, and the ability to capture and replay state. non-reproducible bugs (\"it happened once\") are the ones that ship and recur. making bugs reproducible is upstream of fixing them. all bug-fixing and qa. especially critical for intermittent, timing-dependent, or emergent bugs, and for anything that must be verified fixed. some bugs are genuinely rare/environmental and full determinism is impractical (network races, hardware-specific issues) — there you invest in observability (logging, crash dumps, telemetry) to reconstruct what happened, since you can't reproduce it directly. and chasing perfect reproducibility for a trivial cosmetic bug isn't worth it (risk-weight it, qa-0001). require clear repro steps in bug reports. build for determinism where feasible (fixed seeds, deterministic simulation) — it aids repro, automated testing (qa-0002), and reproducible builds (content-0005). log richly and capture state/crash dumps so hard-to-repro bugs can be reconstructed (observability). verify fixes by reproducing the original and confirming it's gone. treat non-reproducible recurring bugs as a signal to improve observability. little on the principle; the nuance is how much to invest in determinism/observability infrastructure versus living with some irreproducible bugs. high-reliability and competitive/networked games invest heavily; smaller games lean on logging and accept some mystery bugs. the debugging-foundation principle of qa; enabled by determinism (shared with qa-0002 and content-0005) and observability. pairs with blameless problem-solving (team-0003 — reproduce and fix the system, don't blame). confidence 4."}
{"id":"GDC-L1-QA-0004","title":"Test on target hardware and under real conditions","layer":"L1","domain":"QA","subdomain":"soak-and-stress","type":"contextual","confidence":4,"status":"canonical","tags":["qa","target-hardware","soak","stress","certification","real-conditions"],"related":["GDC-L1-PERF-0004","GDC-L1-PLAYTEST-0006","GDC-L1-QA-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-games-user-research","S-scope-production"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-QA-0004.md","statement":"The dev machine lies. Test on the target hardware and under real conditions — the platforms players use, real content volumes, long play sessions (soak), heavy load (stress), poor networks, and the certification requirements the game must pass. Problems that never appear in the studio appear constantly in the wild.","sections":{"Statement":"> The dev machine lies. Test on the **target hardware** and under **real conditions** — the\n> platforms players use, real content volumes, long play sessions (soak), heavy load (stress),\n> poor networks, and the certification requirements the game must pass. Problems that never appear\n> in the studio appear constantly in the wild.","Rationale":"Development happens on powerful, clean, well-connected machines running short sessions — conditions\nnothing like where the game actually ships [S-games-user-research] [S-scope-production]. Whole\nclasses of defects only surface off the dev box: performance and memory problems on\nminimum-spec/console/mobile hardware (a frame-budget reality, PERF-0004), memory leaks and state\ncorruption over long **soak** sessions, breakage under **stress** (many entities, full servers),\nfailures on bad networks, and platform-**certification** violations that block release. Testing\nonly where you develop is a form of the sampling bias that skews playtests (PLAYTEST-0006):\nthe dev environment is an unrepresentative sample of the shipping environment. Testing on target,\nat scale, and over time is how you catch the bugs that would otherwise be discovered by players at\nlaunch (SHIP-0001).","Applies when":"Throughout development, intensively before launch (SHIP-0001) — anything with fixed target\nhardware (console, mobile, VR), long sessions, networking, or platform certification.","Does not apply / Exceptions":"Early prototypes on a single dev platform can defer target testing (but shouldn't defer it\n*forever* — the longer you wait, the nastier the surprises). Single-platform PC games have a\nnarrower target range. Certification only applies to platforms that require it. Scale the effort to\nthe platforms and conditions the game will actually meet.","Implementation (kept separate from the principle)":"Test regularly on minimum-spec and each target platform, not just the dev machine. Run soak tests (long sessions, watch for leaks/degradation) and stress tests (peak load). Test on realistic networks (latency, loss) for multiplayer (MP-0004). Verify certification/compliance requirements early. Fold this into the launch-readiness plan (SHIP-0001).","Disagreement":"Little on the principle; the nuance is how early and how often to test on target (target hardware\nand cert kits cost money and time) vs. developing fast on dev machines. Console/mobile/VR force\nearly target testing; PC-only games have more slack. Risk-weight it (QA-0001).","Notes":"The real-conditions principle of QA; connects to performance budgeting on target (PERF-0004),\nsampling representativeness (PLAYTEST-0006), and launch readiness (SHIP-0001). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-QA-0004\ntitle: Test on target hardware and under real conditions\nlayer: L1\ndomain: QA\nsubdomain: soak-and-stress\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - qa\n  - target-hardware\n  - soak\n  - stress\n  - certification\n  - real-conditions\nrelated:\n  - GDC-L1-PERF-0004\n  - GDC-L1-PLAYTEST-0006\n  - GDC-L1-QA-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-games-user-research\n  - S-scope-production\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> The dev machine lies. Test on the **target hardware** and under **real conditions** — the\n> platforms players use, real content volumes, long play sessions (soak), heavy load (stress),\n> poor networks, and the certification requirements the game must pass. Problems that never appear\n> in the studio appear constantly in the wild.\n\n## Rationale\nDevelopment happens on powerful, clean, well-connected machines running short sessions — conditions\nnothing like where the game actually ships [S-games-user-research] [S-scope-production]. Whole\nclasses of defects only surface off the dev box: performance and memory problems on\nminimum-spec/console/mobile hardware (a frame-budget reality, PERF-0004), memory leaks and state\ncorruption over long **soak** sessions, breakage under **stress** (many entities, full servers),\nfailures on bad networks, and platform-**certification** violations that block release. Testing\nonly where you develop is a form of the sampling bias that skews playtests (PLAYTEST-0006):\nthe dev environment is an unrepresentative sample of the shipping environment. Testing on target,\nat scale, and over time is how you catch the bugs that would otherwise be discovered by players at\nlaunch (SHIP-0001).\n\n## Applies when\nThroughout development, intensively before launch (SHIP-0001) — anything with fixed target\nhardware (console, mobile, VR), long sessions, networking, or platform certification.\n\n## Does not apply / Exceptions\nEarly prototypes on a single dev platform can defer target testing (but shouldn't defer it\n*forever* — the longer you wait, the nastier the surprises). Single-platform PC games have a\nnarrower target range. Certification only applies to platforms that require it. Scale the effort to\nthe platforms and conditions the game will actually meet.\n\n## Implementation (kept separate from the principle)\nTest regularly on minimum-spec and each target platform, not just the dev machine. Run soak tests (long sessions, watch for leaks/degradation) and stress tests (peak load). Test on realistic networks (latency, loss) for multiplayer (MP-0004). Verify certification/compliance requirements early. Fold this into the launch-readiness plan (SHIP-0001).\n\n## Disagreement\nLittle on the principle; the nuance is how early and how often to test on target (target hardware\nand cert kits cost money and time) vs. developing fast on dev machines. Console/mobile/VR force\nearly target testing; PC-only games have more slack. Risk-weight it (QA-0001).\n\n## Notes\nThe real-conditions principle of QA; connects to performance budgeting on target (PERF-0004),\nsampling representativeness (PLAYTEST-0006), and launch readiness (SHIP-0001). Confidence 4.\n","searchText":"gdc-l1-qa-0004 test on target hardware and under real conditions qa target-hardware soak stress certification real-conditions > the dev machine lies. test on the target hardware and under real conditions — the platforms players use, real content volumes, long play sessions (soak), heavy load (stress), poor networks, and the certification requirements the game must pass. problems that never appear in the studio appear constantly in the wild. development happens on powerful, clean, well-connected machines running short sessions — conditions nothing like where the game actually ships [s-games-user-research] [s-scope-production]. whole classes of defects only surface off the dev box: performance and memory problems on minimum-spec/console/mobile hardware (a frame-budget reality, perf-0004), memory leaks and state corruption over long soak sessions, breakage under stress (many entities, full servers), failures on bad networks, and platform-certification violations that block release. testing only where you develop is a form of the sampling bias that skews playtests (playtest-0006): the dev environment is an unrepresentative sample of the shipping environment. testing on target, at scale, and over time is how you catch the bugs that would otherwise be discovered by players at launch (ship-0001). throughout development, intensively before launch (ship-0001) — anything with fixed target hardware (console, mobile, vr), long sessions, networking, or platform certification. early prototypes on a single dev platform can defer target testing (but shouldn't defer it forever — the longer you wait, the nastier the surprises). single-platform pc games have a narrower target range. certification only applies to platforms that require it. scale the effort to the platforms and conditions the game will actually meet. test regularly on minimum-spec and each target platform, not just the dev machine. run soak tests (long sessions, watch for leaks/degradation) and stress tests (peak load). test on realistic networks (latency, loss) for multiplayer (mp-0004). verify certification/compliance requirements early. fold this into the launch-readiness plan (ship-0001). little on the principle; the nuance is how early and how often to test on target (target hardware and cert kits cost money and time) vs. developing fast on dev machines. console/mobile/vr force early target testing; pc-only games have more slack. risk-weight it (qa-0001). the real-conditions principle of qa; connects to performance budgeting on target (perf-0004), sampling representativeness (playtest-0006), and launch readiness (ship-0001). confidence 4."}
{"id":"GDC-L1-QA-0005","title":"Build quality in — don't test it in at the end","layer":"L1","domain":"QA","subdomain":"test-strategy","type":"contextual","confidence":4,"status":"canonical","tags":["qa","shift-left","quality","process","prevention"],"related":["GDC-L1-TEAM-0003","GDC-L1-CONTENT-0004","GDC-L1-PROD-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-games-user-research"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-QA-0005.md","statement":"Quality is a process, not a final gate. Catch defects as early as possible — at authoring (validate content, CONTENT-0004), at commit (automated tests, QA-0002), in review — rather than relying on a QA pass at the end to find everything. A bug caught the day it's made is cheap; the same bug found at launch is expensive or unshippable.","sections":{"Statement":"> Quality is a *process*, not a final gate. Catch defects as early as possible — at authoring\n> (validate content, CONTENT-0004), at commit (automated tests, QA-0002), in review — rather than\n> relying on a QA pass at the end to find everything. A bug caught the day it's made is cheap; the\n> same bug found at launch is expensive or unshippable.","Rationale":"The cost of a defect rises steeply the longer it goes undetected: caught at authoring it's a quick\nedit; caught in a milestone build it's a bug hunt; caught by players at launch it's a crisis and a\nreputation hit (SHIP-0001) [S-games-user-research]. Treating QA as only an end-phase gate\nguarantees that defects accumulate cheaply-fixable-but-uncaught until they're expensive — so the\nbetter strategy is to push quality *upstream* (\"shift left\"): validate data on ingest\n(CONTENT-0004), run automated regression continuously (QA-0002), review changes, and make it safe\nto surface problems early (the blameless, learn-from-failure culture of TEAM-0003). This also\ndemands that schedules *budget* for quality throughout rather than assuming a magic QA phase at the\nend (PROD-0004). Building quality in makes the final QA a confirmation, not a rescue.","Applies when":"The whole development process — quality practices belong at every stage, not just before launch.","Does not apply / Exceptions":"A dedicated QA/hardening phase near launch is still valuable and necessary — \"build quality in\"\ncomplements it, it doesn't replace it. And prototypes deliberately run rough (quality-in would be\npremature polish on throwaway work, PROTO-0004). The principle is about not *deferring all* quality\nto the end, not about polishing prototypes.","Implementation (kept separate from the principle)":"Push defect-catching upstream: validate content at ingest (CONTENT-0004), automate regression tests\nrun on every change (QA-0002, CONTENT-0005), review code and design, and playtest early and often\n(PLAYTEST-0002). Make surfacing problems safe and blameless (TEAM-0003). Budget for quality\nthroughout the schedule (PROD-0004), not as a final phase alone. Use the end-phase QA to confirm,\nnot to discover everything.","Disagreement":"Shift-left/quality-as-process (cheaper defects, less end-crunch — but requires upstream discipline\nand tooling) vs. quality-as-final-gate (simpler process, defer QA cost — but expensive late defects\nand launch risk). Modern practice favors building quality in; the debate is how much upstream\ninvestment a given project can justify.","Notes":"The prevention/process principle of QA; unifies content validation (CONTENT-0004), automated\nregression (QA-0002), blameless learning (TEAM-0003), and quality-budgeted scheduling (PROD-0004).\nConfidence 4."},"rawMarkdown":"---\nid: GDC-L1-QA-0005\ntitle: Build quality in — don't test it in at the end\nlayer: L1\ndomain: QA\nsubdomain: test-strategy\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - qa\n  - shift-left\n  - quality\n  - process\n  - prevention\nrelated:\n  - GDC-L1-TEAM-0003\n  - GDC-L1-CONTENT-0004\n  - GDC-L1-PROD-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-games-user-research\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Quality is a *process*, not a final gate. Catch defects as early as possible — at authoring\n> (validate content, CONTENT-0004), at commit (automated tests, QA-0002), in review — rather than\n> relying on a QA pass at the end to find everything. A bug caught the day it's made is cheap; the\n> same bug found at launch is expensive or unshippable.\n\n## Rationale\nThe cost of a defect rises steeply the longer it goes undetected: caught at authoring it's a quick\nedit; caught in a milestone build it's a bug hunt; caught by players at launch it's a crisis and a\nreputation hit (SHIP-0001) [S-games-user-research]. Treating QA as only an end-phase gate\nguarantees that defects accumulate cheaply-fixable-but-uncaught until they're expensive — so the\nbetter strategy is to push quality *upstream* (\"shift left\"): validate data on ingest\n(CONTENT-0004), run automated regression continuously (QA-0002), review changes, and make it safe\nto surface problems early (the blameless, learn-from-failure culture of TEAM-0003). This also\ndemands that schedules *budget* for quality throughout rather than assuming a magic QA phase at the\nend (PROD-0004). Building quality in makes the final QA a confirmation, not a rescue.\n\n## Applies when\nThe whole development process — quality practices belong at every stage, not just before launch.\n\n## Does not apply / Exceptions\nA dedicated QA/hardening phase near launch is still valuable and necessary — \"build quality in\"\ncomplements it, it doesn't replace it. And prototypes deliberately run rough (quality-in would be\npremature polish on throwaway work, PROTO-0004). The principle is about not *deferring all* quality\nto the end, not about polishing prototypes.\n\n## Implementation (kept separate from the principle)\nPush defect-catching upstream: validate content at ingest (CONTENT-0004), automate regression tests\nrun on every change (QA-0002, CONTENT-0005), review code and design, and playtest early and often\n(PLAYTEST-0002). Make surfacing problems safe and blameless (TEAM-0003). Budget for quality\nthroughout the schedule (PROD-0004), not as a final phase alone. Use the end-phase QA to confirm,\nnot to discover everything.\n\n## Disagreement\nShift-left/quality-as-process (cheaper defects, less end-crunch — but requires upstream discipline\nand tooling) vs. quality-as-final-gate (simpler process, defer QA cost — but expensive late defects\nand launch risk). Modern practice favors building quality in; the debate is how much upstream\ninvestment a given project can justify.\n\n## Notes\nThe prevention/process principle of QA; unifies content validation (CONTENT-0004), automated\nregression (QA-0002), blameless learning (TEAM-0003), and quality-budgeted scheduling (PROD-0004).\nConfidence 4.\n","searchText":"gdc-l1-qa-0005 build quality in — don't test it in at the end qa shift-left quality process prevention > quality is a process, not a final gate. catch defects as early as possible — at authoring (validate content, content-0004), at commit (automated tests, qa-0002), in review — rather than relying on a qa pass at the end to find everything. a bug caught the day it's made is cheap; the same bug found at launch is expensive or unshippable. the cost of a defect rises steeply the longer it goes undetected: caught at authoring it's a quick edit; caught in a milestone build it's a bug hunt; caught by players at launch it's a crisis and a reputation hit (ship-0001) [s-games-user-research]. treating qa as only an end-phase gate guarantees that defects accumulate cheaply-fixable-but-uncaught until they're expensive — so the better strategy is to push quality upstream (\"shift left\"): validate data on ingest (content-0004), run automated regression continuously (qa-0002), review changes, and make it safe to surface problems early (the blameless, learn-from-failure culture of team-0003). this also demands that schedules budget for quality throughout rather than assuming a magic qa phase at the end (prod-0004). building quality in makes the final qa a confirmation, not a rescue. the whole development process — quality practices belong at every stage, not just before launch. a dedicated qa/hardening phase near launch is still valuable and necessary — \"build quality in\" complements it, it doesn't replace it. and prototypes deliberately run rough (quality-in would be premature polish on throwaway work, proto-0004). the principle is about not deferring all quality to the end, not about polishing prototypes. push defect-catching upstream: validate content at ingest (content-0004), automate regression tests run on every change (qa-0002, content-0005), review code and design, and playtest early and often (playtest-0002). make surfacing problems safe and blameless (team-0003). budget for quality throughout the schedule (prod-0004), not as a final phase alone. use the end-phase qa to confirm, not to discover everything. shift-left/quality-as-process (cheaper defects, less end-crunch — but requires upstream discipline and tooling) vs. quality-as-final-gate (simpler process, defer qa cost — but expensive late defects and launch risk). modern practice favors building quality in; the debate is how much upstream investment a given project can justify. the prevention/process principle of qa; unifies content validation (content-0004), automated regression (qa-0002), blameless learning (team-0003), and quality-budgeted scheduling (prod-0004). confidence 4."}
{"id":"GDC-L1-PROTO-0001","title":"Find the fun first — prove the core before building around it","layer":"L1","domain":"PROTO","subdomain":"prototyping","type":"objective","confidence":4,"status":"canonical","tags":["prototyping","find-the-fun","core-loop","iteration","vertical-slice"],"related":["GDC-L1-SYS-0001","GDC-L1-DESIGN-0001","GDC-L1-PROTO-0006"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-proto-vertical-slice","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROTO-0001.md","statement":"The purpose of a prototype is to find the fun as fast as possible. Before investing in content, art, story, or supporting systems, build the smallest playable thing that answers \"is the core actually fun?\" If the fun isn't there in the prototype, it will not appear later with polish.","sections":{"Statement":"> The purpose of a prototype is to **find the fun as fast as possible.** Before investing\n> in content, art, story, or supporting systems, build the smallest playable thing that\n> answers \"is the core actually fun?\" If the fun isn't there in the prototype, it will not\n> appear later with polish.","Rationale":"Fun lives in the core loop (SYS-0001), and whether that loop is fun is an empirical\nquestion only play can answer (DESIGN-0001) — so the cheapest, fastest way to a good game\nis to test the core in isolation before anything is built on it. Polish, content, and art\namplify a fun core; they cannot create one. Teams that build the game *around* an untested\ncore routinely discover, months and a fortune later, that the thing at the center was never\nfun — a discovery a week-one prototype would have delivered for almost nothing. \"Find the\nfun first\" front-loads the one risk that can sink everything.","Applies when":"The start of any project or major feature, and whenever the fundamental question is \"is\nthis fun?\" rather than \"how do we polish it?\"","Does not apply / Exceptions":"Some experiences aren't \"fun\" in the moment-to-moment sense — narrative, atmospheric, or\ncontemplative games seek a different core value (tension, meaning, mood), and the prototype\nshould target *that* value instead. And a few qualities can't be judged in a bare\nprototype: feel and mood partly depend on fidelity (see PROTO-0003). \"Find the fun\" then\ngeneralizes to \"prove the core value early,\" whatever that value is.","Implementation (kept separate from the principle)":"Build the core loop in greybox with no content (PROTO-0003), aim it at the riskiest\nassumption (PROTO-0002), and put it in front of players immediately (PLAYTEST-0002). Judge\nby whether it's compelling for a few minutes with nothing else attached. Note the related\ndistinction: a *prototype* answers \"*should* we make this game?\"; a *vertical slice* (a\npolished small demo at final quality) answers \"*can* we make it?\" — don't conflate the two,\nand don't polish while you're still finding the fun.","Disagreement":"Broad agreement that the core must be proven early; the nuance is which *value* to prove\nfor non-\"fun\" games, and how much fidelity a fair test of the core requires (PROTO-0003).","Notes":"The keystone of the PROTO domain and the practical front-end of SYS-0001 (perfect the core\nloop) and DESIGN-0001 (judge by the experience). Powered by the iteration loop (PROTO-0006).\nConfidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROTO-0001\ntitle: Find the fun first — prove the core before building around it\nlayer: L1\ndomain: PROTO\nsubdomain: prototyping\ntype: objective\nconfidence: 4\nstatus: canonical\ntags:\n  - prototyping\n  - find-the-fun\n  - core-loop\n  - iteration\n  - vertical-slice\nrelated:\n  - GDC-L1-SYS-0001\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-PROTO-0006\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-proto-vertical-slice\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> The purpose of a prototype is to **find the fun as fast as possible.** Before investing\n> in content, art, story, or supporting systems, build the smallest playable thing that\n> answers \"is the core actually fun?\" If the fun isn't there in the prototype, it will not\n> appear later with polish.\n\n## Rationale\nFun lives in the core loop (SYS-0001), and whether that loop is fun is an empirical\nquestion only play can answer (DESIGN-0001) — so the cheapest, fastest way to a good game\nis to test the core in isolation before anything is built on it. Polish, content, and art\namplify a fun core; they cannot create one. Teams that build the game *around* an untested\ncore routinely discover, months and a fortune later, that the thing at the center was never\nfun — a discovery a week-one prototype would have delivered for almost nothing. \"Find the\nfun first\" front-loads the one risk that can sink everything.\n\n## Applies when\nThe start of any project or major feature, and whenever the fundamental question is \"is\nthis fun?\" rather than \"how do we polish it?\"\n\n## Does not apply / Exceptions\nSome experiences aren't \"fun\" in the moment-to-moment sense — narrative, atmospheric, or\ncontemplative games seek a different core value (tension, meaning, mood), and the prototype\nshould target *that* value instead. And a few qualities can't be judged in a bare\nprototype: feel and mood partly depend on fidelity (see PROTO-0003). \"Find the fun\" then\ngeneralizes to \"prove the core value early,\" whatever that value is.\n\n## Implementation (kept separate from the principle)\nBuild the core loop in greybox with no content (PROTO-0003), aim it at the riskiest\nassumption (PROTO-0002), and put it in front of players immediately (PLAYTEST-0002). Judge\nby whether it's compelling for a few minutes with nothing else attached. Note the related\ndistinction: a *prototype* answers \"*should* we make this game?\"; a *vertical slice* (a\npolished small demo at final quality) answers \"*can* we make it?\" — don't conflate the two,\nand don't polish while you're still finding the fun.\n\n## Disagreement\nBroad agreement that the core must be proven early; the nuance is which *value* to prove\nfor non-\"fun\" games, and how much fidelity a fair test of the core requires (PROTO-0003).\n\n## Notes\nThe keystone of the PROTO domain and the practical front-end of SYS-0001 (perfect the core\nloop) and DESIGN-0001 (judge by the experience). Powered by the iteration loop (PROTO-0006).\nConfidence 4.\n","searchText":"gdc-l1-proto-0001 find the fun first — prove the core before building around it prototyping find-the-fun core-loop iteration vertical-slice > the purpose of a prototype is to find the fun as fast as possible. before investing in content, art, story, or supporting systems, build the smallest playable thing that answers \"is the core actually fun?\" if the fun isn't there in the prototype, it will not appear later with polish. fun lives in the core loop (sys-0001), and whether that loop is fun is an empirical question only play can answer (design-0001) — so the cheapest, fastest way to a good game is to test the core in isolation before anything is built on it. polish, content, and art amplify a fun core; they cannot create one. teams that build the game around an untested core routinely discover, months and a fortune later, that the thing at the center was never fun — a discovery a week-one prototype would have delivered for almost nothing. \"find the fun first\" front-loads the one risk that can sink everything. the start of any project or major feature, and whenever the fundamental question is \"is this fun?\" rather than \"how do we polish it?\" some experiences aren't \"fun\" in the moment-to-moment sense — narrative, atmospheric, or contemplative games seek a different core value (tension, meaning, mood), and the prototype should target that value instead. and a few qualities can't be judged in a bare prototype: feel and mood partly depend on fidelity (see proto-0003). \"find the fun\" then generalizes to \"prove the core value early,\" whatever that value is. build the core loop in greybox with no content (proto-0003), aim it at the riskiest assumption (proto-0002), and put it in front of players immediately (playtest-0002). judge by whether it's compelling for a few minutes with nothing else attached. note the related distinction: a prototype answers \"should we make this game?\"; a vertical slice (a polished small demo at final quality) answers \"can we make it?\" — don't conflate the two, and don't polish while you're still finding the fun. broad agreement that the core must be proven early; the nuance is which value to prove for non-\"fun\" games, and how much fidelity a fair test of the core requires (proto-0003). the keystone of the proto domain and the practical front-end of sys-0001 (perfect the core loop) and design-0001 (judge by the experience). powered by the iteration loop (proto-0006). confidence 4."}
{"id":"GDC-L1-PROTO-0002","title":"Prototype the riskiest assumption first","layer":"L1","domain":"PROTO","subdomain":"fail-fast","type":"objective","confidence":4,"status":"canonical","tags":["prototyping","risk","fail-fast","iteration"],"related":["GDC-L1-PROTO-0001","GDC-L1-PLAYTEST-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-proto-vertical-slice"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROTO-0002.md","statement":"Aim each prototype at the biggest open question or riskiest assumption — the thing that, if it turns out wrong, kills the project. Answer the scariest unknown early and cheaply, while changing course is still cheap.","sections":{"Statement":"> Aim each prototype at the biggest open question or riskiest assumption — the thing that,\n> if it turns out wrong, kills the project. Answer the scariest unknown early and cheaply,\n> while changing course is still cheap.","Rationale":"Risk is cheapest to retire early. The assumption that \"the core is fun,\" \"this control\nscheme works,\" \"players will understand this mechanic,\" or \"this tech is feasible\" is a\nloaded gun pointed at the project — and the longer it stays untested, the more you build on\ntop of a maybe [S-proto-vertical-slice]. Prototyping the *safe* parts first feels\nproductive but defers the decisions that actually determine whether the project should\ncontinue. Attacking the riskiest question first means you either de-risk it (and proceed\nwith confidence) or discover the problem while a pivot costs days instead of months. Fail\nfast on the things most likely to fail.","Applies when":"The start of a project or feature, and any time you're deciding what to build next under\nuncertainty. Prioritize by \"what's most likely to be wrong and most catastrophic if it is?\"","Does not apply / Exceptions":"Not everything is a risk worth a dedicated prototype — well-understood, low-uncertainty work\njust needs building, not validating. And \"riskiest first\" is about *project-killing*\nuncertainty; polishing-order and content decisions follow different logic. If two risks are\nentangled, you may need to prototype them together.","Implementation (kept separate from the principle)":"List the project's core assumptions and rank them by (likelihood of being wrong) × (cost if\nwrong). Build the cheapest experiment that resolves the top one. Prefer answering \"will this\neven work?\" before \"how good can we make it?\" Reassess the risk ranking after each\nprototype — retiring one risk often promotes another.","Disagreement":"Little in principle. The practical debate is how to weigh technical risk vs. design/fun risk\nfirst when both loom — usually the fun/design risk is primary for a game (a technically\nperfect un-fun game is still dead), but a project resting on unproven tech may need to\nretire that first.","Notes":"The prioritization rule that makes \"find the fun first\" (PROTO-0001) actionable — of all the\nthings to prototype, do the scariest. Pairs with early testing (PLAYTEST-0002). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROTO-0002\ntitle: Prototype the riskiest assumption first\nlayer: L1\ndomain: PROTO\nsubdomain: fail-fast\ntype: objective\nconfidence: 4\nstatus: canonical\ntags:\n  - prototyping\n  - risk\n  - fail-fast\n  - iteration\nrelated:\n  - GDC-L1-PROTO-0001\n  - GDC-L1-PLAYTEST-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-proto-vertical-slice\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Aim each prototype at the biggest open question or riskiest assumption — the thing that,\n> if it turns out wrong, kills the project. Answer the scariest unknown early and cheaply,\n> while changing course is still cheap.\n\n## Rationale\nRisk is cheapest to retire early. The assumption that \"the core is fun,\" \"this control\nscheme works,\" \"players will understand this mechanic,\" or \"this tech is feasible\" is a\nloaded gun pointed at the project — and the longer it stays untested, the more you build on\ntop of a maybe [S-proto-vertical-slice]. Prototyping the *safe* parts first feels\nproductive but defers the decisions that actually determine whether the project should\ncontinue. Attacking the riskiest question first means you either de-risk it (and proceed\nwith confidence) or discover the problem while a pivot costs days instead of months. Fail\nfast on the things most likely to fail.\n\n## Applies when\nThe start of a project or feature, and any time you're deciding what to build next under\nuncertainty. Prioritize by \"what's most likely to be wrong and most catastrophic if it is?\"\n\n## Does not apply / Exceptions\nNot everything is a risk worth a dedicated prototype — well-understood, low-uncertainty work\njust needs building, not validating. And \"riskiest first\" is about *project-killing*\nuncertainty; polishing-order and content decisions follow different logic. If two risks are\nentangled, you may need to prototype them together.\n\n## Implementation (kept separate from the principle)\nList the project's core assumptions and rank them by (likelihood of being wrong) × (cost if\nwrong). Build the cheapest experiment that resolves the top one. Prefer answering \"will this\neven work?\" before \"how good can we make it?\" Reassess the risk ranking after each\nprototype — retiring one risk often promotes another.\n\n## Disagreement\nLittle in principle. The practical debate is how to weigh technical risk vs. design/fun risk\nfirst when both loom — usually the fun/design risk is primary for a game (a technically\nperfect un-fun game is still dead), but a project resting on unproven tech may need to\nretire that first.\n\n## Notes\nThe prioritization rule that makes \"find the fun first\" (PROTO-0001) actionable — of all the\nthings to prototype, do the scariest. Pairs with early testing (PLAYTEST-0002). Confidence 4.\n","searchText":"gdc-l1-proto-0002 prototype the riskiest assumption first prototyping risk fail-fast iteration > aim each prototype at the biggest open question or riskiest assumption — the thing that, if it turns out wrong, kills the project. answer the scariest unknown early and cheaply, while changing course is still cheap. risk is cheapest to retire early. the assumption that \"the core is fun,\" \"this control scheme works,\" \"players will understand this mechanic,\" or \"this tech is feasible\" is a loaded gun pointed at the project — and the longer it stays untested, the more you build on top of a maybe [s-proto-vertical-slice]. prototyping the safe parts first feels productive but defers the decisions that actually determine whether the project should continue. attacking the riskiest question first means you either de-risk it (and proceed with confidence) or discover the problem while a pivot costs days instead of months. fail fast on the things most likely to fail. the start of a project or feature, and any time you're deciding what to build next under uncertainty. prioritize by \"what's most likely to be wrong and most catastrophic if it is?\" not everything is a risk worth a dedicated prototype — well-understood, low-uncertainty work just needs building, not validating. and \"riskiest first\" is about project-killing uncertainty; polishing-order and content decisions follow different logic. if two risks are entangled, you may need to prototype them together. list the project's core assumptions and rank them by (likelihood of being wrong) × (cost if wrong). build the cheapest experiment that resolves the top one. prefer answering \"will this even work?\" before \"how good can we make it?\" reassess the risk ranking after each prototype — retiring one risk often promotes another. little in principle. the practical debate is how to weigh technical risk vs. design/fun risk first when both loom — usually the fun/design risk is primary for a game (a technically perfect un-fun game is still dead), but a project resting on unproven tech may need to retire that first. the prioritization rule that makes \"find the fun first\" (proto-0001) actionable — of all the things to prototype, do the scariest. pairs with early testing (playtest-0002). confidence 4."}
{"id":"GDC-L1-PROTO-0003","title":"Greybox before you make it pretty — validate the design with placeholders","layer":"L1","domain":"PROTO","subdomain":"greyboxing","type":"contextual","confidence":4,"status":"canonical","tags":["greyboxing","prototyping","placeholders","iteration","kill-your-darlings"],"related":["GDC-L1-PROTO-0001","GDC-L1-PROTO-0005","GDC-L1-FEEL-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-proto-vertical-slice"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROTO-0003.md","statement":"Test mechanics and layouts in rough form — greybox geometry, placeholder art, ugly UI — before committing production assets. Validate that the design works while it's still cheap and unglamorous to change, and only then invest in making it beautiful.","sections":{"Statement":"> Test mechanics and layouts in rough form — greybox geometry, placeholder art, ugly UI —\n> before committing production assets. Validate that the *design* works while it's still\n> cheap and unglamorous to change, and only then invest in making it beautiful.","Rationale":"Art is expensive to make and expensive to abandon — both in hours and in attachment. Once a\nlevel is beautifully lit or a character lovingly animated, the team is far less willing to\nrip it up even when the underlying design is wrong (which is why greyboxing and\nkill-your-darlings, PROTO-0005, are siblings). Greyboxing keeps the question honest: does\nthis *space*, this *encounter*, this *mechanic* work, independent of how it looks?\n[S-proto-vertical-slice] It also keeps iteration fast — moving grey blocks is minutes,\nremaking finished art is weeks — so you get more loops (PROTO-0006) before anything is\nlocked. Pretty-first inverts the risk: you polish before you know if it's worth polishing.","Applies when":"Level design, encounter design, mechanic validation, UI flow — anywhere the design can be\njudged before final assets exist. The default order: greybox → validate → polish.","Does not apply / Exceptions":"Some qualities genuinely require fidelity to evaluate. **Game feel and mood** partly live in\nthe art and audio — a movement system or a horror atmosphere can't be fully judged in flat\ngrey (this is the fidelity caveat that also qualifies PLAYTEST-0002, and it directly touches\nFEEL-0001, where feel is the point). For those, prototype at enough fidelity to feel the\nthing, while keeping everything *else* rough. Highly art-driven experiences may also need\nearlier visual exploration.","Implementation (kept separate from the principle)":"Block out spaces and mechanics with primitive shapes and placeholder assets; lock the design\nin greybox before art passes begin. Raise fidelity only where fidelity is what you're\ntesting (feel, mood). Keep placeholders obviously placeholder so nobody mistakes them for\nfinal and gets attached. Validate with playtests (PLAYTEST-0001) on the greybox.","Disagreement":"Greybox-first is near-universal for mechanic- and layout-driven design; the honest exception\nis feel/mood/art-driven work, where too-rough a prototype gives a false negative. The\nreconciliation: greybox everything you *can* judge grey, and add fidelity only to the\nspecific quality that needs it.","Notes":"Keeps iteration cheap (PROTO-0006) and pairs with kill-your-darlings (PROTO-0005) — greybox\nis partly a device to avoid getting attached too early. Its FEEL-0001 caveat is a genuine,\nimportant limit. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROTO-0003\ntitle: Greybox before you make it pretty — validate the design with placeholders\nlayer: L1\ndomain: PROTO\nsubdomain: greyboxing\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - greyboxing\n  - prototyping\n  - placeholders\n  - iteration\n  - kill-your-darlings\nrelated:\n  - GDC-L1-PROTO-0001\n  - GDC-L1-PROTO-0005\n  - GDC-L1-FEEL-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-proto-vertical-slice\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Test mechanics and layouts in rough form — greybox geometry, placeholder art, ugly UI —\n> before committing production assets. Validate that the *design* works while it's still\n> cheap and unglamorous to change, and only then invest in making it beautiful.\n\n## Rationale\nArt is expensive to make and expensive to abandon — both in hours and in attachment. Once a\nlevel is beautifully lit or a character lovingly animated, the team is far less willing to\nrip it up even when the underlying design is wrong (which is why greyboxing and\nkill-your-darlings, PROTO-0005, are siblings). Greyboxing keeps the question honest: does\nthis *space*, this *encounter*, this *mechanic* work, independent of how it looks?\n[S-proto-vertical-slice] It also keeps iteration fast — moving grey blocks is minutes,\nremaking finished art is weeks — so you get more loops (PROTO-0006) before anything is\nlocked. Pretty-first inverts the risk: you polish before you know if it's worth polishing.\n\n## Applies when\nLevel design, encounter design, mechanic validation, UI flow — anywhere the design can be\njudged before final assets exist. The default order: greybox → validate → polish.\n\n## Does not apply / Exceptions\nSome qualities genuinely require fidelity to evaluate. **Game feel and mood** partly live in\nthe art and audio — a movement system or a horror atmosphere can't be fully judged in flat\ngrey (this is the fidelity caveat that also qualifies PLAYTEST-0002, and it directly touches\nFEEL-0001, where feel is the point). For those, prototype at enough fidelity to feel the\nthing, while keeping everything *else* rough. Highly art-driven experiences may also need\nearlier visual exploration.\n\n## Implementation (kept separate from the principle)\nBlock out spaces and mechanics with primitive shapes and placeholder assets; lock the design\nin greybox before art passes begin. Raise fidelity only where fidelity is what you're\ntesting (feel, mood). Keep placeholders obviously placeholder so nobody mistakes them for\nfinal and gets attached. Validate with playtests (PLAYTEST-0001) on the greybox.\n\n## Disagreement\nGreybox-first is near-universal for mechanic- and layout-driven design; the honest exception\nis feel/mood/art-driven work, where too-rough a prototype gives a false negative. The\nreconciliation: greybox everything you *can* judge grey, and add fidelity only to the\nspecific quality that needs it.\n\n## Notes\nKeeps iteration cheap (PROTO-0006) and pairs with kill-your-darlings (PROTO-0005) — greybox\nis partly a device to avoid getting attached too early. Its FEEL-0001 caveat is a genuine,\nimportant limit. Confidence 4.\n","searchText":"gdc-l1-proto-0003 greybox before you make it pretty — validate the design with placeholders greyboxing prototyping placeholders iteration kill-your-darlings > test mechanics and layouts in rough form — greybox geometry, placeholder art, ugly ui — before committing production assets. validate that the design works while it's still cheap and unglamorous to change, and only then invest in making it beautiful. art is expensive to make and expensive to abandon — both in hours and in attachment. once a level is beautifully lit or a character lovingly animated, the team is far less willing to rip it up even when the underlying design is wrong (which is why greyboxing and kill-your-darlings, proto-0005, are siblings). greyboxing keeps the question honest: does this space, this encounter, this mechanic work, independent of how it looks? [s-proto-vertical-slice] it also keeps iteration fast — moving grey blocks is minutes, remaking finished art is weeks — so you get more loops (proto-0006) before anything is locked. pretty-first inverts the risk: you polish before you know if it's worth polishing. level design, encounter design, mechanic validation, ui flow — anywhere the design can be judged before final assets exist. the default order: greybox → validate → polish. some qualities genuinely require fidelity to evaluate. game feel and mood partly live in the art and audio — a movement system or a horror atmosphere can't be fully judged in flat grey (this is the fidelity caveat that also qualifies playtest-0002, and it directly touches feel-0001, where feel is the point). for those, prototype at enough fidelity to feel the thing, while keeping everything else rough. highly art-driven experiences may also need earlier visual exploration. block out spaces and mechanics with primitive shapes and placeholder assets; lock the design in greybox before art passes begin. raise fidelity only where fidelity is what you're testing (feel, mood). keep placeholders obviously placeholder so nobody mistakes them for final and gets attached. validate with playtests (playtest-0001) on the greybox. greybox-first is near-universal for mechanic- and layout-driven design; the honest exception is feel/mood/art-driven work, where too-rough a prototype gives a false negative. the reconciliation: greybox everything you can judge grey, and add fidelity only to the specific quality that needs it. keeps iteration cheap (proto-0006) and pairs with kill-your-darlings (proto-0005) — greybox is partly a device to avoid getting attached too early. its feel-0001 caveat is a genuine, important limit. confidence 4."}
{"id":"GDC-L1-PROTO-0004","title":"Keep prototypes focused and disposable — one question, throwaway code","layer":"L1","domain":"PROTO","subdomain":"prototyping","type":"contextual","confidence":3,"status":"canonical","tags":["prototyping","focus","throwaway","scope","iteration"],"related":["GDC-L1-PROTO-0001","GDC-L1-PROTO-0002","GDC-L1-ARCH-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-proto-vertical-slice"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROTO-0004.md","statement":"A prototype exists to answer a question, not to become the game. Keep it narrow (validate one thing), build it cheap, and be ready to throw it away. The value of a prototype is the answer it produces, not the artifact — prototype code that hardens into the shipping codebase quietly drags production down.","sections":{"Statement":"> A prototype exists to answer a question, not to become the game. Keep it **narrow**\n> (validate one thing), build it **cheap**, and be ready to **throw it away**. The value of\n> a prototype is the *answer* it produces, not the artifact — prototype code that hardens\n> into the shipping codebase quietly drags production down.","Rationale":"Every extra feature in a prototype dilutes its focus and slows the iteration it exists to\naccelerate [S-proto-vertical-slice]. A prototype that tries to validate five things at once\nanswers none of them cleanly, and one built to \"not waste the code\" pressures the team to\nkeep hacks, shortcuts, and dead-ends that a throwaway would have discarded — technical debt\nborn at the worst possible time. Treating prototypes as disposable frees you to build them\nfast and dirty (their only job is to teach you something) and to discard them without\nsunk-cost grief once they have. The learning transfers to production; the code often\nshouldn't.","Applies when":"Any exploratory prototype whose purpose is to answer a design or feasibility question.","Does not apply / Exceptions":"This is the sharpest genuine debate in prototyping. **Evolutionary prototyping** — where a\npromising prototype is deliberately grown into the real product — is a legitimate and common\napproach, especially for solo devs and small teams for whom rebuilding is a luxury. The rule\nis really: *decide consciously* whether a prototype is throwaway or evolutionary, and if it's\nthrowaway, don't let sunk cost quietly promote it to production. Some prototypes also\nrightfully seed production assets or architecture.","Implementation (kept separate from the principle)":"Scope each prototype to a single question (pairs with PROTO-0002, the riskiest one). Build it\nin whatever is fastest, accepting messy code. Decide up front: throwaway or evolutionary. If\nthrowaway, extract the *lessons* and rebuild cleanly for production (where ARCH-0005's\niteration architecture pays off). If evolutionary, be honest that you're now paying to keep\nthe code good.","Disagreement":"Throwaway prototyping (learn then rebuild clean) vs. evolutionary prototyping (grow the\nprototype into the product) is a real, unresolved fork. Throwaway maximizes learning speed\nand code quality; evolutionary maximizes reuse and suits resource-constrained teams. Choose\nper prototype and per team — just choose consciously.","Notes":"The focus-and-scope discipline of prototyping; its throwaway-vs-evolutionary tension is why\nit's typed `contextual` at confidence 3. Connects to ARCH-0005 (the production codebase,\nunlike the prototype, should be built for iteration). Confidence 3."},"rawMarkdown":"---\nid: GDC-L1-PROTO-0004\ntitle: Keep prototypes focused and disposable — one question, throwaway code\nlayer: L1\ndomain: PROTO\nsubdomain: prototyping\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - prototyping\n  - focus\n  - throwaway\n  - scope\n  - iteration\nrelated:\n  - GDC-L1-PROTO-0001\n  - GDC-L1-PROTO-0002\n  - GDC-L1-ARCH-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-proto-vertical-slice\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A prototype exists to answer a question, not to become the game. Keep it **narrow**\n> (validate one thing), build it **cheap**, and be ready to **throw it away**. The value of\n> a prototype is the *answer* it produces, not the artifact — prototype code that hardens\n> into the shipping codebase quietly drags production down.\n\n## Rationale\nEvery extra feature in a prototype dilutes its focus and slows the iteration it exists to\naccelerate [S-proto-vertical-slice]. A prototype that tries to validate five things at once\nanswers none of them cleanly, and one built to \"not waste the code\" pressures the team to\nkeep hacks, shortcuts, and dead-ends that a throwaway would have discarded — technical debt\nborn at the worst possible time. Treating prototypes as disposable frees you to build them\nfast and dirty (their only job is to teach you something) and to discard them without\nsunk-cost grief once they have. The learning transfers to production; the code often\nshouldn't.\n\n## Applies when\nAny exploratory prototype whose purpose is to answer a design or feasibility question.\n\n## Does not apply / Exceptions\nThis is the sharpest genuine debate in prototyping. **Evolutionary prototyping** — where a\npromising prototype is deliberately grown into the real product — is a legitimate and common\napproach, especially for solo devs and small teams for whom rebuilding is a luxury. The rule\nis really: *decide consciously* whether a prototype is throwaway or evolutionary, and if it's\nthrowaway, don't let sunk cost quietly promote it to production. Some prototypes also\nrightfully seed production assets or architecture.\n\n## Implementation (kept separate from the principle)\nScope each prototype to a single question (pairs with PROTO-0002, the riskiest one). Build it\nin whatever is fastest, accepting messy code. Decide up front: throwaway or evolutionary. If\nthrowaway, extract the *lessons* and rebuild cleanly for production (where ARCH-0005's\niteration architecture pays off). If evolutionary, be honest that you're now paying to keep\nthe code good.\n\n## Disagreement\nThrowaway prototyping (learn then rebuild clean) vs. evolutionary prototyping (grow the\nprototype into the product) is a real, unresolved fork. Throwaway maximizes learning speed\nand code quality; evolutionary maximizes reuse and suits resource-constrained teams. Choose\nper prototype and per team — just choose consciously.\n\n## Notes\nThe focus-and-scope discipline of prototyping; its throwaway-vs-evolutionary tension is why\nit's typed `contextual` at confidence 3. Connects to ARCH-0005 (the production codebase,\nunlike the prototype, should be built for iteration). Confidence 3.\n","searchText":"gdc-l1-proto-0004 keep prototypes focused and disposable — one question, throwaway code prototyping focus throwaway scope iteration > a prototype exists to answer a question, not to become the game. keep it narrow (validate one thing), build it cheap, and be ready to throw it away. the value of a prototype is the answer it produces, not the artifact — prototype code that hardens into the shipping codebase quietly drags production down. every extra feature in a prototype dilutes its focus and slows the iteration it exists to accelerate [s-proto-vertical-slice]. a prototype that tries to validate five things at once answers none of them cleanly, and one built to \"not waste the code\" pressures the team to keep hacks, shortcuts, and dead-ends that a throwaway would have discarded — technical debt born at the worst possible time. treating prototypes as disposable frees you to build them fast and dirty (their only job is to teach you something) and to discard them without sunk-cost grief once they have. the learning transfers to production; the code often shouldn't. any exploratory prototype whose purpose is to answer a design or feasibility question. this is the sharpest genuine debate in prototyping. evolutionary prototyping — where a promising prototype is deliberately grown into the real product — is a legitimate and common approach, especially for solo devs and small teams for whom rebuilding is a luxury. the rule is really: decide consciously whether a prototype is throwaway or evolutionary, and if it's throwaway, don't let sunk cost quietly promote it to production. some prototypes also rightfully seed production assets or architecture. scope each prototype to a single question (pairs with proto-0002, the riskiest one). build it in whatever is fastest, accepting messy code. decide up front: throwaway or evolutionary. if throwaway, extract the lessons and rebuild cleanly for production (where arch-0005's iteration architecture pays off). if evolutionary, be honest that you're now paying to keep the code good. throwaway prototyping (learn then rebuild clean) vs. evolutionary prototyping (grow the prototype into the product) is a real, unresolved fork. throwaway maximizes learning speed and code quality; evolutionary maximizes reuse and suits resource-constrained teams. choose per prototype and per team — just choose consciously. the focus-and-scope discipline of prototyping; its throwaway-vs-evolutionary tension is why it's typed contextual at confidence 3. connects to arch-0005 (the production codebase, unlike the prototype, should be built for iteration). confidence 3."}
{"id":"GDC-L1-PROTO-0005","title":"Kill your darlings — cut what doesn't serve the game, however attached you are","layer":"L1","domain":"PROTO","subdomain":"kill-your-darlings","type":"contextual","confidence":4,"status":"canonical","tags":["kill-your-darlings","scope","elegance","cutting","iteration"],"related":["GDC-L1-DESIGN-0007","GDC-L1-SYS-0005","GDC-L1-PROTO-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-kill-your-darlings"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROTO-0005.md","statement":"Be willing to cut features, systems, and content you love when they don't serve the game. Emotional attachment and sunk cost are not design arguments. The discipline to remove a beloved-but-not-working element is often what separates a focused game from a bloated one.","sections":{"Statement":"> Be willing to cut features, systems, and content you love when they don't serve the game.\n> Emotional attachment and sunk cost are not design arguments. The discipline to remove a\n> beloved-but-not-working element is often what separates a focused game from a bloated one.","Rationale":"The ideas a team is most attached to are frequently the hardest to evaluate honestly — pride\nof authorship and the hours already spent both argue *for* keeping something regardless of\nwhether it earns its place [S-kill-your-darlings]. But a game is not the sum of its clever\nparts; it's a focused whole, and every element that doesn't pull its weight dilutes the ones\nthat do (the elegance argument, DESIGN-0007, and orthogonality, SYS-0005). \"Killing a\ndarling\" — a mechanic you invented, a level you polished, a system you championed — hurts\nprecisely because it was good in isolation; the point is that *good in isolation* isn't the\nbar. Cutting it usually strengthens the whole and sharpens what remains.","Applies when":"Scope decisions, feature reviews, and any moment a beloved element isn't working or is\npulling the design out of focus. Especially during production crunch and when the game feels\nbloated or unfocused.","Does not apply / Exceptions":"\"Kill your darlings\" is not \"cut everything distinctive.\" A game's boldest, most personal,\nmost *load-bearing* ideas are often its darlings *and* its reason to exist — reflexively\nsanding off everything you love produces a safe, characterless game (a real risk if the\nmaxim is over-applied). The test is service to the game, not attachment: cut darlings that\ndon't serve; fight for darlings that do. Distinguish \"this is precious and not working\" from\n\"this is precious and central.\"","Implementation (kept separate from the principle)":"Judge each element by its contribution to the whole, not by effort spent or affection felt\n(ignore sunk cost). Greybox and playtest to get honest evidence (PROTO-0003, PLAYTEST-0001)\nbefore defending or cutting. When cutting hurts, that's normal — save the idea in a \"cut\nfeatures\" file for a future game rather than forcing it into this one. Prefer cutting to\npropping up: a mechanic that needs three other mechanics to justify it is often a darling.","Disagreement":"The real tension is *what* to cut: ruthless-cutting culture (focus above all, cut freely)\nvs. protect-the-vision culture (a game's soul lives in its risky, beloved, distinctive\nparts). Both fail at the extreme — one into blandness, the other into bloat. The shared rule\nis \"serve the game,\" and the judgment call is which darlings do.","Notes":"The production/scope face of elegance (DESIGN-0007) and orthogonality (SYS-0005), and a\nsibling of greyboxing (PROTO-0003, which partly exists so you don't get attached too early).\nConfidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROTO-0005\ntitle: Kill your darlings — cut what doesn't serve the game, however attached you are\nlayer: L1\ndomain: PROTO\nsubdomain: kill-your-darlings\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - kill-your-darlings\n  - scope\n  - elegance\n  - cutting\n  - iteration\nrelated:\n  - GDC-L1-DESIGN-0007\n  - GDC-L1-SYS-0005\n  - GDC-L1-PROTO-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-kill-your-darlings\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Be willing to cut features, systems, and content you love when they don't serve the game.\n> Emotional attachment and sunk cost are not design arguments. The discipline to remove a\n> beloved-but-not-working element is often what separates a focused game from a bloated one.\n\n## Rationale\nThe ideas a team is most attached to are frequently the hardest to evaluate honestly — pride\nof authorship and the hours already spent both argue *for* keeping something regardless of\nwhether it earns its place [S-kill-your-darlings]. But a game is not the sum of its clever\nparts; it's a focused whole, and every element that doesn't pull its weight dilutes the ones\nthat do (the elegance argument, DESIGN-0007, and orthogonality, SYS-0005). \"Killing a\ndarling\" — a mechanic you invented, a level you polished, a system you championed — hurts\nprecisely because it was good in isolation; the point is that *good in isolation* isn't the\nbar. Cutting it usually strengthens the whole and sharpens what remains.\n\n## Applies when\nScope decisions, feature reviews, and any moment a beloved element isn't working or is\npulling the design out of focus. Especially during production crunch and when the game feels\nbloated or unfocused.\n\n## Does not apply / Exceptions\n\"Kill your darlings\" is not \"cut everything distinctive.\" A game's boldest, most personal,\nmost *load-bearing* ideas are often its darlings *and* its reason to exist — reflexively\nsanding off everything you love produces a safe, characterless game (a real risk if the\nmaxim is over-applied). The test is service to the game, not attachment: cut darlings that\ndon't serve; fight for darlings that do. Distinguish \"this is precious and not working\" from\n\"this is precious and central.\"\n\n## Implementation (kept separate from the principle)\nJudge each element by its contribution to the whole, not by effort spent or affection felt\n(ignore sunk cost). Greybox and playtest to get honest evidence (PROTO-0003, PLAYTEST-0001)\nbefore defending or cutting. When cutting hurts, that's normal — save the idea in a \"cut\nfeatures\" file for a future game rather than forcing it into this one. Prefer cutting to\npropping up: a mechanic that needs three other mechanics to justify it is often a darling.\n\n## Disagreement\nThe real tension is *what* to cut: ruthless-cutting culture (focus above all, cut freely)\nvs. protect-the-vision culture (a game's soul lives in its risky, beloved, distinctive\nparts). Both fail at the extreme — one into blandness, the other into bloat. The shared rule\nis \"serve the game,\" and the judgment call is which darlings do.\n\n## Notes\nThe production/scope face of elegance (DESIGN-0007) and orthogonality (SYS-0005), and a\nsibling of greyboxing (PROTO-0003, which partly exists so you don't get attached too early).\nConfidence 4.\n","searchText":"gdc-l1-proto-0005 kill your darlings — cut what doesn't serve the game, however attached you are kill-your-darlings scope elegance cutting iteration > be willing to cut features, systems, and content you love when they don't serve the game. emotional attachment and sunk cost are not design arguments. the discipline to remove a beloved-but-not-working element is often what separates a focused game from a bloated one. the ideas a team is most attached to are frequently the hardest to evaluate honestly — pride of authorship and the hours already spent both argue for keeping something regardless of whether it earns its place [s-kill-your-darlings]. but a game is not the sum of its clever parts; it's a focused whole, and every element that doesn't pull its weight dilutes the ones that do (the elegance argument, design-0007, and orthogonality, sys-0005). \"killing a darling\" — a mechanic you invented, a level you polished, a system you championed — hurts precisely because it was good in isolation; the point is that good in isolation isn't the bar. cutting it usually strengthens the whole and sharpens what remains. scope decisions, feature reviews, and any moment a beloved element isn't working or is pulling the design out of focus. especially during production crunch and when the game feels bloated or unfocused. \"kill your darlings\" is not \"cut everything distinctive.\" a game's boldest, most personal, most load-bearing ideas are often its darlings and its reason to exist — reflexively sanding off everything you love produces a safe, characterless game (a real risk if the maxim is over-applied). the test is service to the game, not attachment: cut darlings that don't serve; fight for darlings that do. distinguish \"this is precious and not working\" from \"this is precious and central.\" judge each element by its contribution to the whole, not by effort spent or affection felt (ignore sunk cost). greybox and playtest to get honest evidence (proto-0003, playtest-0001) before defending or cutting. when cutting hurts, that's normal — save the idea in a \"cut features\" file for a future game rather than forcing it into this one. prefer cutting to propping up: a mechanic that needs three other mechanics to justify it is often a darling. the real tension is what to cut: ruthless-cutting culture (focus above all, cut freely) vs. protect-the-vision culture (a game's soul lives in its risky, beloved, distinctive parts). both fail at the extreme — one into blandness, the other into bloat. the shared rule is \"serve the game,\" and the judgment call is which darlings do. the production/scope face of elegance (design-0007) and orthogonality (sys-0005), and a sibling of greyboxing (proto-0003, which partly exists so you don't get attached too early). confidence 4."}
{"id":"GDC-L1-PROTO-0006","title":"The iteration loop is the master tool — the more you test and refine, the better the game","layer":"L1","domain":"PROTO","subdomain":"iteration-loops","type":"objective","confidence":5,"status":"canonical","tags":["iteration","the-loop","prototyping","playtest","quality"],"related":["GDC-L1-DESIGN-0001","GDC-L1-ARCH-0005","GDC-L1-PLAYTEST-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROTO-0006.md","statement":"Game quality is largely a function of iteration count. Each build → test → learn → refine loop makes the game better, so the most important thing you can do is maximize how many good loops you complete. Protect the loop and shorten it above almost everything else.","sections":{"Statement":"> Game quality is largely a function of iteration count. Each build → test → learn → refine\n> loop makes the game better, so the most important thing you can do is **maximize how many\n> good loops you complete.** Protect the loop and shorten it above almost everything else.","Rationale":"No one designs a great game in one pass; great games are *converged upon* through repeated\ncycles of trying something, watching it played, learning, and adjusting (DESIGN-0001 — the\nexperience is discovered, not specified). If each loop improves the game, then total quality\nscales with the number of quality loops you can fit before ship — which makes *loop count*\nthe master variable and *loop length* the thing to attack. This is why iteration speed is an\narchitectural priority (ARCH-0005), why you test early and often (PLAYTEST-0002), and why\nprototypes stay cheap and disposable (PROTO-0004): every one of those is really about getting\nmore turns of the loop. Anything that lengthens the loop — slow builds, rare playtests,\nprecious un-cuttable work — is stealing quality from the finished game.","Applies when":"The entire development process, from first prototype to final polish. It is the meta-principle\nthe rest of the PROTO and PLAYTEST domains serve.","Does not apply / Exceptions":"Iteration needs *direction* — looping without a clear question or vision produces churn, not\nprogress (aimless tweaking, endless polish on the wrong thing). And there are diminishing\nreturns and a ship date: at some point another loop costs more than it adds, and \"iterate\nforever\" becomes a failure to finish. Maximize *good* loops with a clear target, not motion\nfor its own sake.","Implementation (kept separate from the principle)":"Measure and attack loop length: how long from \"I have an idea\" to \"I've seen it played and\nlearned something\"? Shorten it with fast builds, hot-reload, and data-driven tuning\n(ARCH-0005), standing playtest access (PLAYTEST-0002), and cheap prototypes (PROTO-0004). Aim\neach loop at a real question (PROTO-0002). Know when to stop looping and ship.","Notes":"The master principle of the PROTO domain and the throughline connecting PROTO, PLAYTEST, and\nARCH-0005 — they are all, ultimately, about turning the loop more times. Confidence 5: as\nclose to a law of game development as exists."},"rawMarkdown":"---\nid: GDC-L1-PROTO-0006\ntitle: The iteration loop is the master tool — the more you test and refine, the better the game\nlayer: L1\ndomain: PROTO\nsubdomain: iteration-loops\ntype: objective\nconfidence: 5\nstatus: canonical\ntags:\n  - iteration\n  - the-loop\n  - prototyping\n  - playtest\n  - quality\nrelated:\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-ARCH-0005\n  - GDC-L1-PLAYTEST-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Game quality is largely a function of iteration count. Each build → test → learn → refine\n> loop makes the game better, so the most important thing you can do is **maximize how many\n> good loops you complete.** Protect the loop and shorten it above almost everything else.\n\n## Rationale\nNo one designs a great game in one pass; great games are *converged upon* through repeated\ncycles of trying something, watching it played, learning, and adjusting (DESIGN-0001 — the\nexperience is discovered, not specified). If each loop improves the game, then total quality\nscales with the number of quality loops you can fit before ship — which makes *loop count*\nthe master variable and *loop length* the thing to attack. This is why iteration speed is an\narchitectural priority (ARCH-0005), why you test early and often (PLAYTEST-0002), and why\nprototypes stay cheap and disposable (PROTO-0004): every one of those is really about getting\nmore turns of the loop. Anything that lengthens the loop — slow builds, rare playtests,\nprecious un-cuttable work — is stealing quality from the finished game.\n\n## Applies when\nThe entire development process, from first prototype to final polish. It is the meta-principle\nthe rest of the PROTO and PLAYTEST domains serve.\n\n## Does not apply / Exceptions\nIteration needs *direction* — looping without a clear question or vision produces churn, not\nprogress (aimless tweaking, endless polish on the wrong thing). And there are diminishing\nreturns and a ship date: at some point another loop costs more than it adds, and \"iterate\nforever\" becomes a failure to finish. Maximize *good* loops with a clear target, not motion\nfor its own sake.\n\n## Implementation (kept separate from the principle)\nMeasure and attack loop length: how long from \"I have an idea\" to \"I've seen it played and\nlearned something\"? Shorten it with fast builds, hot-reload, and data-driven tuning\n(ARCH-0005), standing playtest access (PLAYTEST-0002), and cheap prototypes (PROTO-0004). Aim\neach loop at a real question (PROTO-0002). Know when to stop looping and ship.\n\n## Notes\nThe master principle of the PROTO domain and the throughline connecting PROTO, PLAYTEST, and\nARCH-0005 — they are all, ultimately, about turning the loop more times. Confidence 5: as\nclose to a law of game development as exists.\n","searchText":"gdc-l1-proto-0006 the iteration loop is the master tool — the more you test and refine, the better the game iteration the-loop prototyping playtest quality > game quality is largely a function of iteration count. each build → test → learn → refine loop makes the game better, so the most important thing you can do is maximize how many good loops you complete. protect the loop and shorten it above almost everything else. no one designs a great game in one pass; great games are converged upon through repeated cycles of trying something, watching it played, learning, and adjusting (design-0001 — the experience is discovered, not specified). if each loop improves the game, then total quality scales with the number of quality loops you can fit before ship — which makes loop count the master variable and loop length the thing to attack. this is why iteration speed is an architectural priority (arch-0005), why you test early and often (playtest-0002), and why prototypes stay cheap and disposable (proto-0004): every one of those is really about getting more turns of the loop. anything that lengthens the loop — slow builds, rare playtests, precious un-cuttable work — is stealing quality from the finished game. the entire development process, from first prototype to final polish. it is the meta-principle the rest of the proto and playtest domains serve. iteration needs direction — looping without a clear question or vision produces churn, not progress (aimless tweaking, endless polish on the wrong thing). and there are diminishing returns and a ship date: at some point another loop costs more than it adds, and \"iterate forever\" becomes a failure to finish. maximize good loops with a clear target, not motion for its own sake. measure and attack loop length: how long from \"i have an idea\" to \"i've seen it played and learned something\"? shorten it with fast builds, hot-reload, and data-driven tuning (arch-0005), standing playtest access (playtest-0002), and cheap prototypes (proto-0004). aim each loop at a real question (proto-0002). know when to stop looping and ship. the master principle of the proto domain and the throughline connecting proto, playtest, and arch-0005 — they are all, ultimately, about turning the loop more times. confidence 5: as close to a law of game development as exists."}
{"id":"GDC-L1-PLAYTEST-0001","title":"Watch what players do, not just what they say","layer":"L1","domain":"PLAYTEST","subdomain":"observing-vs-asking","type":"objective","confidence":5,"status":"canonical","tags":["playtest","observation","behavior","player-centric"],"related":["GDC-L1-DESIGN-0001","GDC-L1-PLAYTEST-0004","GDC-L1-PLAYTEST-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-games-user-research","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PLAYTEST-0001.md","statement":"The core of playtesting is observing behavior. What players do — where they hesitate, get lost, fail, quit, or light up — is more reliable evidence than what they say, because people rationalize, forget, and tell you what they think you want to hear. Treat observed behavior as primary data and stated opinion as secondary.","sections":{"Statement":"> The core of playtesting is observing **behavior**. What players *do* — where they\n> hesitate, get lost, fail, quit, or light up — is more reliable evidence than what they\n> *say*, because people rationalize, forget, and tell you what they think you want to hear.\n> Treat observed behavior as primary data and stated opinion as secondary.","Rationale":"This is the practical arm of DESIGN-0001 (judge by the experience produced): the produced\nexperience is visible in behavior, and behavior is far harder to fake than a verbal report\n[S-games-user-research]. A player who says \"the tutorial was fine\" but visibly floundered\nat step three has told you two things, and the flounder is the true one. Self-report is\ndistorted by politeness, poor introspective access, and memory; behavior under real play\nis the ground truth. This is why watching a first-time player struggle is worth more than a\npage of survey answers.","Applies when":"Every playtest. The moment a build is playable, the highest-value activity is watching\nreal players interact with it.","Does not apply / Exceptions":"Behavior tells you *what* happened but not always *why* — for motivation and feeling you\nstill need to ask (interviews, think-aloud) and combine the two (see PLAYTEST-0005). And\nobservation must be interpreted carefully: one player's stumble might be noise, not signal\n(PLAYTEST-0006). So \"watch, don't just ask\" doesn't mean \"never ask\" — it means weight\nbehavior over opinion when they conflict.","Implementation (kept separate from the principle)":"Record sessions (video/screen capture) and use an observation checklist for confusion\npoints, hesitations, failures, and delight. Note *where* on the screen and *when* things\ngo wrong. Compare what players do to the intended experience and treat divergence as a\ndesign signal, not player error. Save opinions for after you've seen the behavior, so the\nreport doesn't overwrite what you observed.","Disagreement":"No serious dissent that behavior beats opinion as evidence; the live nuance is how to\n*combine* behavioral and self-report data (PLAYTEST-0005) and how much a small sample's\nbehavior generalizes (PLAYTEST-0006).","Notes":"The principle DESIGN-0001 forward-referenced — it is that principle's operational method.\nAnchors the PLAYTEST domain. Confidence 5: universal across games user research and design\npractice."},"rawMarkdown":"---\nid: GDC-L1-PLAYTEST-0001\ntitle: Watch what players do, not just what they say\nlayer: L1\ndomain: PLAYTEST\nsubdomain: observing-vs-asking\ntype: objective\nconfidence: 5\nstatus: canonical\ntags:\n  - playtest\n  - observation\n  - behavior\n  - player-centric\nrelated:\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-PLAYTEST-0004\n  - GDC-L1-PLAYTEST-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-games-user-research\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> The core of playtesting is observing **behavior**. What players *do* — where they\n> hesitate, get lost, fail, quit, or light up — is more reliable evidence than what they\n> *say*, because people rationalize, forget, and tell you what they think you want to hear.\n> Treat observed behavior as primary data and stated opinion as secondary.\n\n## Rationale\nThis is the practical arm of DESIGN-0001 (judge by the experience produced): the produced\nexperience is visible in behavior, and behavior is far harder to fake than a verbal report\n[S-games-user-research]. A player who says \"the tutorial was fine\" but visibly floundered\nat step three has told you two things, and the flounder is the true one. Self-report is\ndistorted by politeness, poor introspective access, and memory; behavior under real play\nis the ground truth. This is why watching a first-time player struggle is worth more than a\npage of survey answers.\n\n## Applies when\nEvery playtest. The moment a build is playable, the highest-value activity is watching\nreal players interact with it.\n\n## Does not apply / Exceptions\nBehavior tells you *what* happened but not always *why* — for motivation and feeling you\nstill need to ask (interviews, think-aloud) and combine the two (see PLAYTEST-0005). And\nobservation must be interpreted carefully: one player's stumble might be noise, not signal\n(PLAYTEST-0006). So \"watch, don't just ask\" doesn't mean \"never ask\" — it means weight\nbehavior over opinion when they conflict.\n\n## Implementation (kept separate from the principle)\nRecord sessions (video/screen capture) and use an observation checklist for confusion\npoints, hesitations, failures, and delight. Note *where* on the screen and *when* things\ngo wrong. Compare what players do to the intended experience and treat divergence as a\ndesign signal, not player error. Save opinions for after you've seen the behavior, so the\nreport doesn't overwrite what you observed.\n\n## Disagreement\nNo serious dissent that behavior beats opinion as evidence; the live nuance is how to\n*combine* behavioral and self-report data (PLAYTEST-0005) and how much a small sample's\nbehavior generalizes (PLAYTEST-0006).\n\n## Notes\nThe principle DESIGN-0001 forward-referenced — it is that principle's operational method.\nAnchors the PLAYTEST domain. Confidence 5: universal across games user research and design\npractice.\n","searchText":"gdc-l1-playtest-0001 watch what players do, not just what they say playtest observation behavior player-centric > the core of playtesting is observing behavior. what players do — where they hesitate, get lost, fail, quit, or light up — is more reliable evidence than what they say, because people rationalize, forget, and tell you what they think you want to hear. treat observed behavior as primary data and stated opinion as secondary. this is the practical arm of design-0001 (judge by the experience produced): the produced experience is visible in behavior, and behavior is far harder to fake than a verbal report [s-games-user-research]. a player who says \"the tutorial was fine\" but visibly floundered at step three has told you two things, and the flounder is the true one. self-report is distorted by politeness, poor introspective access, and memory; behavior under real play is the ground truth. this is why watching a first-time player struggle is worth more than a page of survey answers. every playtest. the moment a build is playable, the highest-value activity is watching real players interact with it. behavior tells you what happened but not always why — for motivation and feeling you still need to ask (interviews, think-aloud) and combine the two (see playtest-0005). and observation must be interpreted carefully: one player's stumble might be noise, not signal (playtest-0006). so \"watch, don't just ask\" doesn't mean \"never ask\" — it means weight behavior over opinion when they conflict. record sessions (video/screen capture) and use an observation checklist for confusion points, hesitations, failures, and delight. note where on the screen and when things go wrong. compare what players do to the intended experience and treat divergence as a design signal, not player error. save opinions for after you've seen the behavior, so the report doesn't overwrite what you observed. no serious dissent that behavior beats opinion as evidence; the live nuance is how to combine behavioral and self-report data (playtest-0005) and how much a small sample's behavior generalizes (playtest-0006). the principle design-0001 forward-referenced — it is that principle's operational method. anchors the playtest domain. confidence 5: universal across games user research and design practice."}
{"id":"GDC-L1-PLAYTEST-0002","title":"Test early, often, and rough","layer":"L1","domain":"PLAYTEST","subdomain":"playtest-methods","type":"objective","confidence":4,"status":"canonical","tags":["playtest","iteration","early-testing","prototyping"],"related":["GDC-L1-PLAYTEST-0001","GDC-L1-DESIGN-0001","GDC-L1-ARCH-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-schell-artofgamedesign","S-games-user-research"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PLAYTEST-0002.md","statement":"Playtest as soon as the game is playable, and keep testing repeatedly with rough, unfinished builds. Frequent cheap tests catch problems while they're cheap to fix; waiting for polish means discovering fundamental flaws after they're expensive — or unfixable.","sections":{"Statement":"> Playtest as soon as the game is playable, and keep testing repeatedly with rough,\n> unfinished builds. Frequent cheap tests catch problems while they're cheap to fix;\n> waiting for polish means discovering fundamental flaws after they're expensive — or\n> unfixable.","Rationale":"The cost of fixing a design problem rises the longer it goes undetected: a broken core loop\nfound in a greybox prototype is a quick pivot; the same flaw found after months of content\nbuilt on top is a catastrophe. Because good games are found through iteration (DESIGN-0001),\nand each test is one iteration's worth of truth, testing *early and often* maximizes the\nnumber of corrections before commitments harden. Rough builds are a feature, not an excuse:\ntesters of an ugly prototype react to the *design*, and the team stays willing to change\nwhat isn't yet polished (nobody wants to kill a beautiful thing — see PROTO). Polished\nbuilds arrive with the expensive decisions already made.","Applies when":"From the first playable prototype through the whole of development. The earlier the flaw,\nthe cheaper the fix, so the value is highest at the start.","Does not apply / Exceptions":"Some questions genuinely require fidelity — final-feel tuning, performance, and\npolish-dependent reactions can't be judged in greybox. And testing has a cost per session;\ntiny solo projects may test informally. The principle is \"don't wait for polish to start,\"\nnot \"every test must be rough.\"","Implementation (kept separate from the principle)":"Build the smallest thing that answers your current question and put it in front of players\nnow (compare PROTO — prototype to find the fun). Test the riskiest assumption first.\nArchitect for fast iteration (ARCH-0005) so turning feedback into a new build is cheap. Run\nmany small tests rather than one big late one.","Disagreement":"Little on \"test early\"; the practical debate is *how* rough is useful for *which* question\n— core-loop and clarity questions test great in greybox, while feel and polish questions\nneed fidelity. Match build quality to the question, not to a calendar.","Notes":"Pairs behavior-first testing (PLAYTEST-0001) with the iteration architecture (ARCH-0005)\nand the prototyping discipline (PROTO, to come). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PLAYTEST-0002\ntitle: Test early, often, and rough\nlayer: L1\ndomain: PLAYTEST\nsubdomain: playtest-methods\ntype: objective\nconfidence: 4\nstatus: canonical\ntags:\n  - playtest\n  - iteration\n  - early-testing\n  - prototyping\nrelated:\n  - GDC-L1-PLAYTEST-0001\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-ARCH-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schell-artofgamedesign\n  - S-games-user-research\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Playtest as soon as the game is playable, and keep testing repeatedly with rough,\n> unfinished builds. Frequent cheap tests catch problems while they're cheap to fix;\n> waiting for polish means discovering fundamental flaws after they're expensive — or\n> unfixable.\n\n## Rationale\nThe cost of fixing a design problem rises the longer it goes undetected: a broken core loop\nfound in a greybox prototype is a quick pivot; the same flaw found after months of content\nbuilt on top is a catastrophe. Because good games are found through iteration (DESIGN-0001),\nand each test is one iteration's worth of truth, testing *early and often* maximizes the\nnumber of corrections before commitments harden. Rough builds are a feature, not an excuse:\ntesters of an ugly prototype react to the *design*, and the team stays willing to change\nwhat isn't yet polished (nobody wants to kill a beautiful thing — see PROTO). Polished\nbuilds arrive with the expensive decisions already made.\n\n## Applies when\nFrom the first playable prototype through the whole of development. The earlier the flaw,\nthe cheaper the fix, so the value is highest at the start.\n\n## Does not apply / Exceptions\nSome questions genuinely require fidelity — final-feel tuning, performance, and\npolish-dependent reactions can't be judged in greybox. And testing has a cost per session;\ntiny solo projects may test informally. The principle is \"don't wait for polish to start,\"\nnot \"every test must be rough.\"\n\n## Implementation (kept separate from the principle)\nBuild the smallest thing that answers your current question and put it in front of players\nnow (compare PROTO — prototype to find the fun). Test the riskiest assumption first.\nArchitect for fast iteration (ARCH-0005) so turning feedback into a new build is cheap. Run\nmany small tests rather than one big late one.\n\n## Disagreement\nLittle on \"test early\"; the practical debate is *how* rough is useful for *which* question\n— core-loop and clarity questions test great in greybox, while feel and polish questions\nneed fidelity. Match build quality to the question, not to a calendar.\n\n## Notes\nPairs behavior-first testing (PLAYTEST-0001) with the iteration architecture (ARCH-0005)\nand the prototyping discipline (PROTO, to come). Confidence 4.\n","searchText":"gdc-l1-playtest-0002 test early, often, and rough playtest iteration early-testing prototyping > playtest as soon as the game is playable, and keep testing repeatedly with rough, unfinished builds. frequent cheap tests catch problems while they're cheap to fix; waiting for polish means discovering fundamental flaws after they're expensive — or unfixable. the cost of fixing a design problem rises the longer it goes undetected: a broken core loop found in a greybox prototype is a quick pivot; the same flaw found after months of content built on top is a catastrophe. because good games are found through iteration (design-0001), and each test is one iteration's worth of truth, testing early and often maximizes the number of corrections before commitments harden. rough builds are a feature, not an excuse: testers of an ugly prototype react to the design, and the team stays willing to change what isn't yet polished (nobody wants to kill a beautiful thing — see proto). polished builds arrive with the expensive decisions already made. from the first playable prototype through the whole of development. the earlier the flaw, the cheaper the fix, so the value is highest at the start. some questions genuinely require fidelity — final-feel tuning, performance, and polish-dependent reactions can't be judged in greybox. and testing has a cost per session; tiny solo projects may test informally. the principle is \"don't wait for polish to start,\" not \"every test must be rough.\" build the smallest thing that answers your current question and put it in front of players now (compare proto — prototype to find the fun). test the riskiest assumption first. architect for fast iteration (arch-0005) so turning feedback into a new build is cheap. run many small tests rather than one big late one. little on \"test early\"; the practical debate is how rough is useful for which question — core-loop and clarity questions test great in greybox, while feel and polish questions need fidelity. match build quality to the question, not to a calendar. pairs behavior-first testing (playtest-0001) with the iteration architecture (arch-0005) and the prototyping discipline (proto, to come). confidence 4."}
{"id":"GDC-L1-PLAYTEST-0003","title":"Don't help, don't explain","layer":"L1","domain":"PLAYTEST","subdomain":"observing-vs-asking","type":"objective","confidence":5,"status":"canonical","tags":["playtest","first-time-user","onboarding","observation"],"related":["GDC-L1-PLAYTEST-0001","GDC-L1-DESIGN-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-games-user-research","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PLAYTEST-0003.md","statement":"During a playtest, resist the urge to coach, hint, or defend the design. The shipped game won't have you sitting beside the player. A test where you intervene measures your presence, not your game — so stay silent and let first-time users struggle. Their confusion is the finding.","sections":{"Statement":"> During a playtest, resist the urge to coach, hint, or defend the design. The shipped game\n> won't have you sitting beside the player. A test where you intervene measures your\n> presence, not your game — so stay silent and let first-time users struggle. Their\n> confusion is the finding.","Rationale":"The instinct to rescue a stuck tester (\"oh, you just press X there\") destroys the exact\ndata you came for: whether the game teaches itself [S-games-user-research]. Every time you\nexplain, you overwrite a real usability problem with a false success and blind yourself to\na flaw that every future player — playing without you — will hit. Silence is hard because\nwatching someone miss the obvious is uncomfortable, but that discomfort *is* the signal:\nwhat's obvious to you (the author, saturated in intent — DESIGN-0001) is invisible to them.\nFirst-time-user testing only works if the first-time experience is left intact.","Applies when":"Any test of onboarding, clarity, controls, or discoverability — and by default, any test at\nall, until the scripted portion you're observing is complete.","Does not apply / Exceptions":"Some methods deliberately invite talking — think-aloud protocols ask players to narrate,\nand post-session interviews are where you finally ask \"why.\" The rule is no *help* and no\n*defense* during the observed play; structured prompting to surface reasoning is different\nfrom coaching past an obstacle. If a tester is truly, unproductively stuck and the rest of\nthe session depends on progress, intervene minimally and note that you did.","Implementation (kept separate from the principle)":"Brief testers that you won't help and that being stuck is useful information, not failure.\nSit where you can see but not loom. Bite your tongue; write down what they tried instead of\ncorrecting it. Save all \"why did you…\" questions for after the observed segment. Treat every\nurge to explain as a bug report about the game.","Disagreement":"None on the core rule for usability/first-run testing. The only nuance is method choice:\nsilent observation vs. think-aloud vs. post-hoc interview each surface different things, and\ngood research uses more than one — but none of them means coaching the player past the\ndesign's own failures.","Notes":"The behavioral discipline that makes PLAYTEST-0001 work, and the direct antidote to the\nauthor's intent-contamination named in DESIGN-0001. Confidence 5."},"rawMarkdown":"---\nid: GDC-L1-PLAYTEST-0003\ntitle: Don't help, don't explain\nlayer: L1\ndomain: PLAYTEST\nsubdomain: observing-vs-asking\ntype: objective\nconfidence: 5\nstatus: canonical\ntags:\n  - playtest\n  - first-time-user\n  - onboarding\n  - observation\nrelated:\n  - GDC-L1-PLAYTEST-0001\n  - GDC-L1-DESIGN-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-games-user-research\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> During a playtest, resist the urge to coach, hint, or defend the design. The shipped game\n> won't have you sitting beside the player. A test where you intervene measures your\n> presence, not your game — so stay silent and let first-time users struggle. Their\n> confusion is the finding.\n\n## Rationale\nThe instinct to rescue a stuck tester (\"oh, you just press X there\") destroys the exact\ndata you came for: whether the game teaches itself [S-games-user-research]. Every time you\nexplain, you overwrite a real usability problem with a false success and blind yourself to\na flaw that every future player — playing without you — will hit. Silence is hard because\nwatching someone miss the obvious is uncomfortable, but that discomfort *is* the signal:\nwhat's obvious to you (the author, saturated in intent — DESIGN-0001) is invisible to them.\nFirst-time-user testing only works if the first-time experience is left intact.\n\n## Applies when\nAny test of onboarding, clarity, controls, or discoverability — and by default, any test at\nall, until the scripted portion you're observing is complete.\n\n## Does not apply / Exceptions\nSome methods deliberately invite talking — think-aloud protocols ask players to narrate,\nand post-session interviews are where you finally ask \"why.\" The rule is no *help* and no\n*defense* during the observed play; structured prompting to surface reasoning is different\nfrom coaching past an obstacle. If a tester is truly, unproductively stuck and the rest of\nthe session depends on progress, intervene minimally and note that you did.\n\n## Implementation (kept separate from the principle)\nBrief testers that you won't help and that being stuck is useful information, not failure.\nSit where you can see but not loom. Bite your tongue; write down what they tried instead of\ncorrecting it. Save all \"why did you…\" questions for after the observed segment. Treat every\nurge to explain as a bug report about the game.\n\n## Disagreement\nNone on the core rule for usability/first-run testing. The only nuance is method choice:\nsilent observation vs. think-aloud vs. post-hoc interview each surface different things, and\ngood research uses more than one — but none of them means coaching the player past the\ndesign's own failures.\n\n## Notes\nThe behavioral discipline that makes PLAYTEST-0001 work, and the direct antidote to the\nauthor's intent-contamination named in DESIGN-0001. Confidence 5.\n","searchText":"gdc-l1-playtest-0003 don't help, don't explain playtest first-time-user onboarding observation > during a playtest, resist the urge to coach, hint, or defend the design. the shipped game won't have you sitting beside the player. a test where you intervene measures your presence, not your game — so stay silent and let first-time users struggle. their confusion is the finding. the instinct to rescue a stuck tester (\"oh, you just press x there\") destroys the exact data you came for: whether the game teaches itself [s-games-user-research]. every time you explain, you overwrite a real usability problem with a false success and blind yourself to a flaw that every future player — playing without you — will hit. silence is hard because watching someone miss the obvious is uncomfortable, but that discomfort is the signal: what's obvious to you (the author, saturated in intent — design-0001) is invisible to them. first-time-user testing only works if the first-time experience is left intact. any test of onboarding, clarity, controls, or discoverability — and by default, any test at all, until the scripted portion you're observing is complete. some methods deliberately invite talking — think-aloud protocols ask players to narrate, and post-session interviews are where you finally ask \"why.\" the rule is no help and no defense during the observed play; structured prompting to surface reasoning is different from coaching past an obstacle. if a tester is truly, unproductively stuck and the rest of the session depends on progress, intervene minimally and note that you did. brief testers that you won't help and that being stuck is useful information, not failure. sit where you can see but not loom. bite your tongue; write down what they tried instead of correcting it. save all \"why did you…\" questions for after the observed segment. treat every urge to explain as a bug report about the game. none on the core rule for usability/first-run testing. the only nuance is method choice: silent observation vs. think-aloud vs. post-hoc interview each surface different things, and good research uses more than one — but none of them means coaching the player past the design's own failures. the behavioral discipline that makes playtest-0001 work, and the direct antidote to the author's intent-contamination named in design-0001. confidence 5."}
{"id":"GDC-L1-PLAYTEST-0004","title":"Listen to the problem, distrust the proposed solution","layer":"L1","domain":"PLAYTEST","subdomain":"interpreting-feedback","type":"objective","confidence":5,"status":"canonical","tags":["playtest","feedback","interpretation","player-centric"],"related":["GDC-L1-DESIGN-0001","GDC-L1-PLAYTEST-0001","GDC-L1-DESIGN-0006"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PLAYTEST-0004.md","statement":"Players reliably tell you where something feels wrong and unreliably tell you how to fix it. Take their reported problems seriously as symptoms; treat their proposed solutions as data about the symptom, not as design direction. The cure is yours to find.","sections":{"Statement":"> Players reliably tell you *where* something feels wrong and unreliably tell you *how* to\n> fix it. Take their reported problems seriously as symptoms; treat their proposed\n> solutions as data about the symptom, not as design direction. The cure is yours to find.","Rationale":"A player feels the pain of a design accurately — \"this fight is frustrating,\" \"I never\nknew where to go,\" \"the reward felt hollow\" — because they're the one experiencing it\n[S-schell-artofgamedesign]. But diagnosing the cause and prescribing the fix requires\nseeing the whole system, which they can't; so their proposed solution (\"make the boss\nweaker,\" \"add an arrow pointing to the door\") usually treats the symptom and often\nintroduces new problems or erodes the design's intent. This is exactly the reconciliation\nDESIGN-0001 reaches between listening to players and holding a vision: honor the reported\nexperience as truth, own the response. Dismiss the symptom and you're an arrogant auteur;\nimplement every prescribed fix and you design by committee into mush.","Applies when":"Interpreting all qualitative feedback — playtest comments, reviews, forums, surveys.","Does not apply / Exceptions":"Sometimes players *are* right about the fix, especially domain-expert testers or when many\nindependent players converge on the same concrete suggestion (convergence is itself\nsignal). And in usability specifics (a button they couldn't find, a control that felt\ninverted) the reported fix is often correct. The principle is about weighting, not\nignoring: distrust prescribed solutions by default, but don't reflexively reject them.","Implementation (kept separate from the principle)":"When you get feedback, extract the underlying experience (\"boss felt unfair\") from the\nproposed remedy (\"nerf the boss\"), and design against the experience. Look for *patterns*\nof symptoms across testers rather than reacting to one loud prescription. Ask \"what made it\nfeel that way?\" not \"what should I change?\" Watch behavior (PLAYTEST-0001) to locate the\nreal cause the words only point at.","Disagreement":"This *is* the resolution of the auteur-vs-data-driven debate from DESIGN-0001, and it's\nbroadly accepted. The residual disagreement is only about how much weight expert-tester\nprescriptions and strong player consensus should carry — more than a lone suggestion, less\nthan a mandate.","Notes":"Formalizes DESIGN-0001's \"listen to the symptom; own the cure\" into a playtest-interpretation\nrule. Confidence 5."},"rawMarkdown":"---\nid: GDC-L1-PLAYTEST-0004\ntitle: Listen to the problem, distrust the proposed solution\nlayer: L1\ndomain: PLAYTEST\nsubdomain: interpreting-feedback\ntype: objective\nconfidence: 5\nstatus: canonical\ntags:\n  - playtest\n  - feedback\n  - interpretation\n  - player-centric\nrelated:\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-PLAYTEST-0001\n  - GDC-L1-DESIGN-0006\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Players reliably tell you *where* something feels wrong and unreliably tell you *how* to\n> fix it. Take their reported problems seriously as symptoms; treat their proposed\n> solutions as data about the symptom, not as design direction. The cure is yours to find.\n\n## Rationale\nA player feels the pain of a design accurately — \"this fight is frustrating,\" \"I never\nknew where to go,\" \"the reward felt hollow\" — because they're the one experiencing it\n[S-schell-artofgamedesign]. But diagnosing the cause and prescribing the fix requires\nseeing the whole system, which they can't; so their proposed solution (\"make the boss\nweaker,\" \"add an arrow pointing to the door\") usually treats the symptom and often\nintroduces new problems or erodes the design's intent. This is exactly the reconciliation\nDESIGN-0001 reaches between listening to players and holding a vision: honor the reported\nexperience as truth, own the response. Dismiss the symptom and you're an arrogant auteur;\nimplement every prescribed fix and you design by committee into mush.\n\n## Applies when\nInterpreting all qualitative feedback — playtest comments, reviews, forums, surveys.\n\n## Does not apply / Exceptions\nSometimes players *are* right about the fix, especially domain-expert testers or when many\nindependent players converge on the same concrete suggestion (convergence is itself\nsignal). And in usability specifics (a button they couldn't find, a control that felt\ninverted) the reported fix is often correct. The principle is about weighting, not\nignoring: distrust prescribed solutions by default, but don't reflexively reject them.\n\n## Implementation (kept separate from the principle)\nWhen you get feedback, extract the underlying experience (\"boss felt unfair\") from the\nproposed remedy (\"nerf the boss\"), and design against the experience. Look for *patterns*\nof symptoms across testers rather than reacting to one loud prescription. Ask \"what made it\nfeel that way?\" not \"what should I change?\" Watch behavior (PLAYTEST-0001) to locate the\nreal cause the words only point at.\n\n## Disagreement\nThis *is* the resolution of the auteur-vs-data-driven debate from DESIGN-0001, and it's\nbroadly accepted. The residual disagreement is only about how much weight expert-tester\nprescriptions and strong player consensus should carry — more than a lone suggestion, less\nthan a mandate.\n\n## Notes\nFormalizes DESIGN-0001's \"listen to the symptom; own the cure\" into a playtest-interpretation\nrule. Confidence 5.\n","searchText":"gdc-l1-playtest-0004 listen to the problem, distrust the proposed solution playtest feedback interpretation player-centric > players reliably tell you where something feels wrong and unreliably tell you how to fix it. take their reported problems seriously as symptoms; treat their proposed solutions as data about the symptom, not as design direction. the cure is yours to find. a player feels the pain of a design accurately — \"this fight is frustrating,\" \"i never knew where to go,\" \"the reward felt hollow\" — because they're the one experiencing it [s-schell-artofgamedesign]. but diagnosing the cause and prescribing the fix requires seeing the whole system, which they can't; so their proposed solution (\"make the boss weaker,\" \"add an arrow pointing to the door\") usually treats the symptom and often introduces new problems or erodes the design's intent. this is exactly the reconciliation design-0001 reaches between listening to players and holding a vision: honor the reported experience as truth, own the response. dismiss the symptom and you're an arrogant auteur; implement every prescribed fix and you design by committee into mush. interpreting all qualitative feedback — playtest comments, reviews, forums, surveys. sometimes players are right about the fix, especially domain-expert testers or when many independent players converge on the same concrete suggestion (convergence is itself signal). and in usability specifics (a button they couldn't find, a control that felt inverted) the reported fix is often correct. the principle is about weighting, not ignoring: distrust prescribed solutions by default, but don't reflexively reject them. when you get feedback, extract the underlying experience (\"boss felt unfair\") from the proposed remedy (\"nerf the boss\"), and design against the experience. look for patterns of symptoms across testers rather than reacting to one loud prescription. ask \"what made it feel that way?\" not \"what should i change?\" watch behavior (playtest-0001) to locate the real cause the words only point at. this is the resolution of the auteur-vs-data-driven debate from design-0001, and it's broadly accepted. the residual disagreement is only about how much weight expert-tester prescriptions and strong player consensus should carry — more than a lone suggestion, less than a mandate. formalizes design-0001's \"listen to the symptom; own the cure\" into a playtest-interpretation rule. confidence 5."}
{"id":"GDC-L1-PLAYTEST-0005","title":"Combine telemetry with observation — the \"what\" needs the \"why\"","layer":"L1","domain":"PLAYTEST","subdomain":"telemetry-and-analytics","type":"contextual","confidence":4,"status":"canonical","tags":["playtest","telemetry","analytics","qualitative","quantitative","measure-dont-guess"],"related":["GDC-L1-PLAYTEST-0001","GDC-L1-PERF-0001","GDC-L1-SYS-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-games-user-research"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PLAYTEST-0005.md","statement":"Instrument the game to see what players do at scale — telemetry answers \"what\" and \"how many\" across whole populations. But pair it with qualitative observation to learn \"why.\" Numbers show where players drop off, quit, or cluster; only watching them shows what it felt like. Neither alone is enough.","sections":{"Statement":"> Instrument the game to see what players do at scale — telemetry answers \"what\" and \"how\n> many\" across whole populations. But pair it with qualitative observation to learn \"why.\"\n> Numbers show *where* players drop off, quit, or cluster; only watching them shows what it\n> *felt* like. Neither alone is enough.","Rationale":"Behavioral telemetry can now capture entire player populations, not just a lab sample,\nwhich makes it uniquely powerful for spotting *where* problems are: the level with the\n20% quit rate, the ability nobody uses, the difficulty spike where the curve craters\n[S-games-user-research]. But telemetry is mute on causation — it tells you the cliff\nexists, not why players fall off it (too hard? boring? confusing? a bug?). Qualitative\nmethods (observation, interviews, think-aloud) explain the why on a small sample.\nTriangulating the two — quantitative to find the where, qualitative to understand the why —\nis how you get both reliable signal and actionable understanding. Data-driven design\nwithout the qualitative side optimizes numbers while missing the experience.","Applies when":"Any game you can instrument, especially at scale — betas, live-service, or any build with\nenough players that patterns emerge. Even small tests benefit from basic metrics\n(completion, deaths, time-per-section).","Does not apply / Exceptions":"Early prototypes with few testers have too little data for telemetry to mean much — lean\nqualitative there. And metrics can mislead: optimizing purely for a measurable proxy\n(engagement time, retention) can steer a game away from being *good* (compare PROG-0004,\nwhere the metric and the player's interest can diverge). Measure to understand, not to\nchase a number.","Implementation (kept separate from the principle)":"Log the events that answer real questions (progression, deaths, drop-off, choices, ability\nuse), not everything. Use telemetry to *locate* problems, then observe or interview to\n*diagnose* them. Beware proxy metrics that reward the wrong thing. This is\n\"measure, don't guess\" (the PERF domain's ethos) applied to player experience.","Disagreement":"Data-first cultures trust metrics and A/B tests heavily; craft-first cultures worry that\nmetric-chasing produces soulless, over-optimized games. The synthesis this principle takes:\nquantitative finds the where, qualitative and design judgment decide the what — data\ninforms decisions, it doesn't make them.","Notes":"Extends behavior-over-opinion (PLAYTEST-0001) to population scale and connects to the\n\"measure, don't guess\" ethos shared with the PERF domain. Its caution mirrors PROG-0004\n(don't optimize for engagement at the player's expense). Confidence 4. Note: references\n`GDC-L1-PERF-0001`, to be authored in the PERF sweep (tracked as a pending forward-ref)."},"rawMarkdown":"---\nid: GDC-L1-PLAYTEST-0005\ntitle: Combine telemetry with observation — the \"what\" needs the \"why\"\nlayer: L1\ndomain: PLAYTEST\nsubdomain: telemetry-and-analytics\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - playtest\n  - telemetry\n  - analytics\n  - qualitative\n  - quantitative\n  - measure-dont-guess\nrelated:\n  - GDC-L1-PLAYTEST-0001\n  - GDC-L1-PERF-0001\n  - GDC-L1-SYS-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-games-user-research\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Instrument the game to see what players do at scale — telemetry answers \"what\" and \"how\n> many\" across whole populations. But pair it with qualitative observation to learn \"why.\"\n> Numbers show *where* players drop off, quit, or cluster; only watching them shows what it\n> *felt* like. Neither alone is enough.\n\n## Rationale\nBehavioral telemetry can now capture entire player populations, not just a lab sample,\nwhich makes it uniquely powerful for spotting *where* problems are: the level with the\n20% quit rate, the ability nobody uses, the difficulty spike where the curve craters\n[S-games-user-research]. But telemetry is mute on causation — it tells you the cliff\nexists, not why players fall off it (too hard? boring? confusing? a bug?). Qualitative\nmethods (observation, interviews, think-aloud) explain the why on a small sample.\nTriangulating the two — quantitative to find the where, qualitative to understand the why —\nis how you get both reliable signal and actionable understanding. Data-driven design\nwithout the qualitative side optimizes numbers while missing the experience.\n\n## Applies when\nAny game you can instrument, especially at scale — betas, live-service, or any build with\nenough players that patterns emerge. Even small tests benefit from basic metrics\n(completion, deaths, time-per-section).\n\n## Does not apply / Exceptions\nEarly prototypes with few testers have too little data for telemetry to mean much — lean\nqualitative there. And metrics can mislead: optimizing purely for a measurable proxy\n(engagement time, retention) can steer a game away from being *good* (compare PROG-0004,\nwhere the metric and the player's interest can diverge). Measure to understand, not to\nchase a number.\n\n## Implementation (kept separate from the principle)\nLog the events that answer real questions (progression, deaths, drop-off, choices, ability\nuse), not everything. Use telemetry to *locate* problems, then observe or interview to\n*diagnose* them. Beware proxy metrics that reward the wrong thing. This is\n\"measure, don't guess\" (the PERF domain's ethos) applied to player experience.\n\n## Disagreement\nData-first cultures trust metrics and A/B tests heavily; craft-first cultures worry that\nmetric-chasing produces soulless, over-optimized games. The synthesis this principle takes:\nquantitative finds the where, qualitative and design judgment decide the what — data\ninforms decisions, it doesn't make them.\n\n## Notes\nExtends behavior-over-opinion (PLAYTEST-0001) to population scale and connects to the\n\"measure, don't guess\" ethos shared with the PERF domain. Its caution mirrors PROG-0004\n(don't optimize for engagement at the player's expense). Confidence 4. Note: references\n`GDC-L1-PERF-0001`, to be authored in the PERF sweep (tracked as a pending forward-ref).\n","searchText":"gdc-l1-playtest-0005 combine telemetry with observation — the \"what\" needs the \"why\" playtest telemetry analytics qualitative quantitative measure-dont-guess > instrument the game to see what players do at scale — telemetry answers \"what\" and \"how many\" across whole populations. but pair it with qualitative observation to learn \"why.\" numbers show where players drop off, quit, or cluster; only watching them shows what it felt like. neither alone is enough. behavioral telemetry can now capture entire player populations, not just a lab sample, which makes it uniquely powerful for spotting where problems are: the level with the 20% quit rate, the ability nobody uses, the difficulty spike where the curve craters [s-games-user-research]. but telemetry is mute on causation — it tells you the cliff exists, not why players fall off it (too hard? boring? confusing? a bug?). qualitative methods (observation, interviews, think-aloud) explain the why on a small sample. triangulating the two — quantitative to find the where, qualitative to understand the why — is how you get both reliable signal and actionable understanding. data-driven design without the qualitative side optimizes numbers while missing the experience. any game you can instrument, especially at scale — betas, live-service, or any build with enough players that patterns emerge. even small tests benefit from basic metrics (completion, deaths, time-per-section). early prototypes with few testers have too little data for telemetry to mean much — lean qualitative there. and metrics can mislead: optimizing purely for a measurable proxy (engagement time, retention) can steer a game away from being good (compare prog-0004, where the metric and the player's interest can diverge). measure to understand, not to chase a number. log the events that answer real questions (progression, deaths, drop-off, choices, ability use), not everything. use telemetry to locate problems, then observe or interview to diagnose them. beware proxy metrics that reward the wrong thing. this is \"measure, don't guess\" (the perf domain's ethos) applied to player experience. data-first cultures trust metrics and a/b tests heavily; craft-first cultures worry that metric-chasing produces soulless, over-optimized games. the synthesis this principle takes: quantitative finds the where, qualitative and design judgment decide the what — data informs decisions, it doesn't make them. extends behavior-over-opinion (playtest-0001) to population scale and connects to the \"measure, don't guess\" ethos shared with the perf domain. its caution mirrors prog-0004 (don't optimize for engagement at the player's expense). confidence 4. note: references gdc-l1-perf-0001, to be authored in the perf sweep (tracked as a pending forward-ref)."}
{"id":"GDC-L1-PLAYTEST-0006","title":"Mind your sample and your biases","layer":"L1","domain":"PLAYTEST","subdomain":"sample-and-bias","type":"contextual","confidence":4,"status":"canonical","tags":["playtest","bias","sampling","research-rigor","verification"],"related":["GDC-L1-PLAYTEST-0001","GDC-L1-DESIGN-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-games-user-research","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PLAYTEST-0006.md","statement":"The designer is the worst test subject, and a handful of friends is a biased sample. Be deliberate about who you test with (are they representative of the target player?), wary of small-sample noise, and honest about your own eagerness to hear good news. Guard against reading tests to confirm what you already hoped.","sections":{"Statement":"> The designer is the worst test subject, and a handful of friends is a biased sample. Be\n> deliberate about *who* you test with (are they representative of the target player?),\n> wary of small-sample noise, and honest about your own eagerness to hear good news. Guard\n> against reading tests to confirm what you already hoped.","Rationale":"Playtest data is only as good as its sample and its interpreter. Three biases routinely\ncorrupt it. **The team is contaminated:** being close to the project blinds you to what a\nfresh player sees, so your own play (and your teammates') is nearly worthless as a\nfirst-run test. **Friendly samples flatter:** friends, fans, and people who resemble the\nteam react differently from the actual target audience and tend to be kind. **Confirmation\nbias interprets:** a designer hoping the game is good will over-weight the tester who loved\nit and explain away the three who bounced. None of this makes testing useless — it makes\n*rigor* necessary, so the signal isn't swamped by who you asked and what you wanted to hear.","Applies when":"Recruiting testers and interpreting any test result — especially decisions that hinge on a\nsmall number of sessions.","Does not apply / Exceptions":"Not every test needs a statistically clean sample; early, informal tests with whoever's\nhandy are still valuable for catching gross problems, as long as you *know* the sample is\nrough and don't over-generalize from it. Expert/target-representative testers are\ndisproportionately informative for specific questions. The point is calibrated confidence,\nnot paralysis.","Implementation (kept separate from the principle)":"Recruit testers who resemble the intended audience, not just people nearby. Treat a single\nsession as an anecdote and look for patterns across several before acting. Separate\nobserving from hoping — write down what happened before forming a verdict. For high-stakes\ncalls, get more and more representative testers rather than trusting a lucky sample. Fresh\nfirst-time testers are a renewable resource — don't burn them all early.","Disagreement":"Rigor-first researchers push for representative samples and statistical care; scrappy indie\npractice argues that *any* outside eyes beat none and that over-formalizing testing wastes\nscarce time. Both are right within their constraints — the shared rule is to *calibrate\nconfidence to sample quality*, not to demand lab conditions or to trust three friends\nblindly.","Notes":"The verification-and-rigor principle of the PLAYTEST domain; it keeps PLAYTEST-0001's\nbehavioral data honest and echoes DESIGN-0001 (the author's blind spot). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PLAYTEST-0006\ntitle: Mind your sample and your biases\nlayer: L1\ndomain: PLAYTEST\nsubdomain: sample-and-bias\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - playtest\n  - bias\n  - sampling\n  - research-rigor\n  - verification\nrelated:\n  - GDC-L1-PLAYTEST-0001\n  - GDC-L1-DESIGN-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-games-user-research\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> The designer is the worst test subject, and a handful of friends is a biased sample. Be\n> deliberate about *who* you test with (are they representative of the target player?),\n> wary of small-sample noise, and honest about your own eagerness to hear good news. Guard\n> against reading tests to confirm what you already hoped.\n\n## Rationale\nPlaytest data is only as good as its sample and its interpreter. Three biases routinely\ncorrupt it. **The team is contaminated:** being close to the project blinds you to what a\nfresh player sees, so your own play (and your teammates') is nearly worthless as a\nfirst-run test. **Friendly samples flatter:** friends, fans, and people who resemble the\nteam react differently from the actual target audience and tend to be kind. **Confirmation\nbias interprets:** a designer hoping the game is good will over-weight the tester who loved\nit and explain away the three who bounced. None of this makes testing useless — it makes\n*rigor* necessary, so the signal isn't swamped by who you asked and what you wanted to hear.\n\n## Applies when\nRecruiting testers and interpreting any test result — especially decisions that hinge on a\nsmall number of sessions.\n\n## Does not apply / Exceptions\nNot every test needs a statistically clean sample; early, informal tests with whoever's\nhandy are still valuable for catching gross problems, as long as you *know* the sample is\nrough and don't over-generalize from it. Expert/target-representative testers are\ndisproportionately informative for specific questions. The point is calibrated confidence,\nnot paralysis.\n\n## Implementation (kept separate from the principle)\nRecruit testers who resemble the intended audience, not just people nearby. Treat a single\nsession as an anecdote and look for patterns across several before acting. Separate\nobserving from hoping — write down what happened before forming a verdict. For high-stakes\ncalls, get more and more representative testers rather than trusting a lucky sample. Fresh\nfirst-time testers are a renewable resource — don't burn them all early.\n\n## Disagreement\nRigor-first researchers push for representative samples and statistical care; scrappy indie\npractice argues that *any* outside eyes beat none and that over-formalizing testing wastes\nscarce time. Both are right within their constraints — the shared rule is to *calibrate\nconfidence to sample quality*, not to demand lab conditions or to trust three friends\nblindly.\n\n## Notes\nThe verification-and-rigor principle of the PLAYTEST domain; it keeps PLAYTEST-0001's\nbehavioral data honest and echoes DESIGN-0001 (the author's blind spot). Confidence 4.\n","searchText":"gdc-l1-playtest-0006 mind your sample and your biases playtest bias sampling research-rigor verification > the designer is the worst test subject, and a handful of friends is a biased sample. be deliberate about who you test with (are they representative of the target player?), wary of small-sample noise, and honest about your own eagerness to hear good news. guard against reading tests to confirm what you already hoped. playtest data is only as good as its sample and its interpreter. three biases routinely corrupt it. the team is contaminated: being close to the project blinds you to what a fresh player sees, so your own play (and your teammates') is nearly worthless as a first-run test. friendly samples flatter: friends, fans, and people who resemble the team react differently from the actual target audience and tend to be kind. confirmation bias interprets: a designer hoping the game is good will over-weight the tester who loved it and explain away the three who bounced. none of this makes testing useless — it makes rigor necessary, so the signal isn't swamped by who you asked and what you wanted to hear. recruiting testers and interpreting any test result — especially decisions that hinge on a small number of sessions. not every test needs a statistically clean sample; early, informal tests with whoever's handy are still valuable for catching gross problems, as long as you know the sample is rough and don't over-generalize from it. expert/target-representative testers are disproportionately informative for specific questions. the point is calibrated confidence, not paralysis. recruit testers who resemble the intended audience, not just people nearby. treat a single session as an anecdote and look for patterns across several before acting. separate observing from hoping — write down what happened before forming a verdict. for high-stakes calls, get more and more representative testers rather than trusting a lucky sample. fresh first-time testers are a renewable resource — don't burn them all early. rigor-first researchers push for representative samples and statistical care; scrappy indie practice argues that any outside eyes beat none and that over-formalizing testing wastes scarce time. both are right within their constraints — the shared rule is to calibrate confidence to sample quality, not to demand lab conditions or to trust three friends blindly. the verification-and-rigor principle of the playtest domain; it keeps playtest-0001's behavioral data honest and echoes design-0001 (the author's blind spot). confidence 4."}
{"id":"GDC-L1-PROD-0001","title":"Scope is the primary risk — cut scope to protect quality and shipping","layer":"L1","domain":"PROD","subdomain":"scoping-and-cutting","type":"contextual","confidence":4,"status":"canonical","tags":["production","scope","iron-triangle","cutting","shipping"],"related":["GDC-L1-PROTO-0005","GDC-L1-DESIGN-0007","GDC-L1-VISION-0003","GDC-L1-PROD-0006"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-scope-production","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROD-0001.md","statement":"The most common way games fail is over-scoping. Scope, time, and resources form a triangle; under a fixed team and timeline, scope is the variable that must flex. When reality bites — and it will — cut scope to protect quality and the ship date, rather than sacrificing polish or crunching people.","sections":{"Statement":"> The most common way games fail is **over-scoping.** Scope, time, and resources form a\n> triangle; under a fixed team and timeline, **scope is the variable that must flex.** When\n> reality bites — and it will — cut scope to protect quality and the ship date, rather than\n> sacrificing polish or crunching people.","Rationale":"Almost every project underestimates how long things take, so the plan will exceed the\navailable time; the only question is what gives [S-scope-production]. There are three\noptions — extend time, add people (which often *slows* a late project), or cut scope — and\nfor most teams, especially small ones, cutting scope is the sustainable lever. The\nalternatives degrade the things that matter most: cutting quality ships a worse game, and\ncrunching (PROD-0005) burns the team. A smaller game done well beats a bigger game done\nbadly or not at all. Treating scope as the flex variable — deciding *in advance* what you'll\ncut if you must — turns the inevitable overrun from a crisis into a plan.","Applies when":"Every project with a deadline or finite resources — which is all of them. Most acute for\nsmall/indie teams and first projects, where scope discipline is the difference between\nshipping and development hell.","Does not apply / Exceptions":"Occasionally time or budget genuinely is the right lever (a funded team pushing a date for a\nclearly-worth-it feature). And \"cut scope\" is not \"cut everything distinctive\" — the cuts\nmust protect the vision's core (VISION-0003), not gut it. Research/exploration phases\ndeliberately keep scope open. The principle is about the *production* commitment, where the\nbar is quality-of-what-ships over quantity-of-what's-attempted.","Implementation (kept separate from the principle)":"Rank features by importance to the core experience and pre-decide the cut list. Define a\nMinimum Viable Product early and keep it visible. When you overrun, cut from the bottom\nrather than lowering quality across the board or extending indefinitely. Protect the vision's\ncore while cutting its periphery (VISION-0002/0003). Cutting well is a skill — expect to cut\nthings you love (PROTO-0005).","Disagreement":"Cut-scope-to-hit-the-date vs. push-the-date-for-the-content — both are valid levers, and\nfunded teams have more room to move the date. But the default, especially under real\nconstraints, is that scope flexes; the failure mode is treating scope as fixed and letting\nquality, the schedule, or the team absorb the overrun instead.","Notes":"The master production principle; partners with PROD-0002 (scope creep), PROD-0006 (finish),\nand the design-side cutting principles (DESIGN-0007 elegance, PROTO-0005 kill your darlings).\nConfidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROD-0001\ntitle: Scope is the primary risk — cut scope to protect quality and shipping\nlayer: L1\ndomain: PROD\nsubdomain: scoping-and-cutting\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - production\n  - scope\n  - iron-triangle\n  - cutting\n  - shipping\nrelated:\n  - GDC-L1-PROTO-0005\n  - GDC-L1-DESIGN-0007\n  - GDC-L1-VISION-0003\n  - GDC-L1-PROD-0006\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-scope-production\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> The most common way games fail is **over-scoping.** Scope, time, and resources form a\n> triangle; under a fixed team and timeline, **scope is the variable that must flex.** When\n> reality bites — and it will — cut scope to protect quality and the ship date, rather than\n> sacrificing polish or crunching people.\n\n## Rationale\nAlmost every project underestimates how long things take, so the plan will exceed the\navailable time; the only question is what gives [S-scope-production]. There are three\noptions — extend time, add people (which often *slows* a late project), or cut scope — and\nfor most teams, especially small ones, cutting scope is the sustainable lever. The\nalternatives degrade the things that matter most: cutting quality ships a worse game, and\ncrunching (PROD-0005) burns the team. A smaller game done well beats a bigger game done\nbadly or not at all. Treating scope as the flex variable — deciding *in advance* what you'll\ncut if you must — turns the inevitable overrun from a crisis into a plan.\n\n## Applies when\nEvery project with a deadline or finite resources — which is all of them. Most acute for\nsmall/indie teams and first projects, where scope discipline is the difference between\nshipping and development hell.\n\n## Does not apply / Exceptions\nOccasionally time or budget genuinely is the right lever (a funded team pushing a date for a\nclearly-worth-it feature). And \"cut scope\" is not \"cut everything distinctive\" — the cuts\nmust protect the vision's core (VISION-0003), not gut it. Research/exploration phases\ndeliberately keep scope open. The principle is about the *production* commitment, where the\nbar is quality-of-what-ships over quantity-of-what's-attempted.\n\n## Implementation (kept separate from the principle)\nRank features by importance to the core experience and pre-decide the cut list. Define a\nMinimum Viable Product early and keep it visible. When you overrun, cut from the bottom\nrather than lowering quality across the board or extending indefinitely. Protect the vision's\ncore while cutting its periphery (VISION-0002/0003). Cutting well is a skill — expect to cut\nthings you love (PROTO-0005).\n\n## Disagreement\nCut-scope-to-hit-the-date vs. push-the-date-for-the-content — both are valid levers, and\nfunded teams have more room to move the date. But the default, especially under real\nconstraints, is that scope flexes; the failure mode is treating scope as fixed and letting\nquality, the schedule, or the team absorb the overrun instead.\n\n## Notes\nThe master production principle; partners with PROD-0002 (scope creep), PROD-0006 (finish),\nand the design-side cutting principles (DESIGN-0007 elegance, PROTO-0005 kill your darlings).\nConfidence 4.\n","searchText":"gdc-l1-prod-0001 scope is the primary risk — cut scope to protect quality and shipping production scope iron-triangle cutting shipping > the most common way games fail is over-scoping. scope, time, and resources form a triangle; under a fixed team and timeline, scope is the variable that must flex. when reality bites — and it will — cut scope to protect quality and the ship date, rather than sacrificing polish or crunching people. almost every project underestimates how long things take, so the plan will exceed the available time; the only question is what gives [s-scope-production]. there are three options — extend time, add people (which often slows a late project), or cut scope — and for most teams, especially small ones, cutting scope is the sustainable lever. the alternatives degrade the things that matter most: cutting quality ships a worse game, and crunching (prod-0005) burns the team. a smaller game done well beats a bigger game done badly or not at all. treating scope as the flex variable — deciding in advance what you'll cut if you must — turns the inevitable overrun from a crisis into a plan. every project with a deadline or finite resources — which is all of them. most acute for small/indie teams and first projects, where scope discipline is the difference between shipping and development hell. occasionally time or budget genuinely is the right lever (a funded team pushing a date for a clearly-worth-it feature). and \"cut scope\" is not \"cut everything distinctive\" — the cuts must protect the vision's core (vision-0003), not gut it. research/exploration phases deliberately keep scope open. the principle is about the production commitment, where the bar is quality-of-what-ships over quantity-of-what's-attempted. rank features by importance to the core experience and pre-decide the cut list. define a minimum viable product early and keep it visible. when you overrun, cut from the bottom rather than lowering quality across the board or extending indefinitely. protect the vision's core while cutting its periphery (vision-0002/0003). cutting well is a skill — expect to cut things you love (proto-0005). cut-scope-to-hit-the-date vs. push-the-date-for-the-content — both are valid levers, and funded teams have more room to move the date. but the default, especially under real constraints, is that scope flexes; the failure mode is treating scope as fixed and letting quality, the schedule, or the team absorb the overrun instead. the master production principle; partners with prod-0002 (scope creep), prod-0006 (finish), and the design-side cutting principles (design-0007 elegance, proto-0005 kill your darlings). confidence 4."}
{"id":"GDC-L1-PROD-0002","title":"Fight scope creep — default to no; every feature has a hidden tail","layer":"L1","domain":"PROD","subdomain":"scope-creep","type":"contextual","confidence":4,"status":"canonical","tags":["production","scope-creep","features","discipline"],"related":["GDC-L1-PROD-0001","GDC-L1-VISION-0003","GDC-L1-DESIGN-0007"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-scope-production"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROD-0002.md","statement":"Features are easy to add and hard to remove, and each carries a hidden tail — integration, balance, polish, bug-fixing, testing, and maintenance — usually far larger than its build cost. Guard the scope actively. The default answer to a new feature added mid-project is no.","sections":{"Statement":"> Features are easy to add and hard to remove, and each carries a **hidden tail** —\n> integration, balance, polish, bug-fixing, testing, and maintenance — usually far larger\n> than its build cost. Guard the scope actively. The default answer to a new feature added\n> mid-project is **no**.","Rationale":"Scope creep is the slow accumulation of \"just one more thing,\" each individually reasonable,\nthat collectively unbalances the project into delays, crunch, or cancellation\n[S-scope-production]. The trap is that people estimate the *build* cost of a feature and\nignore its tail: a new mechanic must be integrated with every existing system, balanced,\npolished, taught (UX/onboarding), debugged, and maintained forever after. Ten \"small\"\nadditions can sink a schedule. Because the pressure to add is constant and the cost is\nhidden, the discipline has to be structural — a default of *no*, a filter every addition must\npass (the pillars, VISION-0002), and a conscious accounting of the tail before saying yes.","Applies when":"Throughout production, and especially in the messy middle where the game is playable enough\nto inspire endless \"wouldn't it be cool if\" additions.","Does not apply / Exceptions":"Not every addition is creep — sometimes a new feature is exactly what the game needs, and\nrigid feature-freezes can prevent genuine improvements found through iteration (PROTO-0006).\nPre-production and prototyping deliberately explore widely before locking scope. The rule is\n\"add deliberately, accounting for the tail,\" not \"never change the plan.\" The default is no;\nyes requires justification.","Implementation (kept separate from the principle)":"Run every proposed addition through the vision's pillars (VISION-0002) — does it serve *this*\ngame? Estimate the whole tail, not just the build. Prefer deepening existing systems over\nadding new ones. Keep a \"cut/later\" list so good-but-wrong ideas are captured without being\nbuilt now (PROTO-0005). Make adding scope a deliberate, visible decision, not a quiet drift.","Disagreement":"Firm scope discipline (protect the schedule and coherence) vs. openness to iteration-driven\nchange (the best features are often discovered mid-development, not planned). The\nreconciliation: distinguish *creep* (unaccounted accumulation) from *deliberate iteration*\n(a justified change that pays for its tail). Cut creep; welcome justified change.","Notes":"The active-defense partner to PROD-0001 (scope is the primary risk); its filter is the vision\n(VISION-0002/0003) and its spirit is elegance (DESIGN-0007). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROD-0002\ntitle: Fight scope creep — default to no; every feature has a hidden tail\nlayer: L1\ndomain: PROD\nsubdomain: scope-creep\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - production\n  - scope-creep\n  - features\n  - discipline\nrelated:\n  - GDC-L1-PROD-0001\n  - GDC-L1-VISION-0003\n  - GDC-L1-DESIGN-0007\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-scope-production\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Features are easy to add and hard to remove, and each carries a **hidden tail** —\n> integration, balance, polish, bug-fixing, testing, and maintenance — usually far larger\n> than its build cost. Guard the scope actively. The default answer to a new feature added\n> mid-project is **no**.\n\n## Rationale\nScope creep is the slow accumulation of \"just one more thing,\" each individually reasonable,\nthat collectively unbalances the project into delays, crunch, or cancellation\n[S-scope-production]. The trap is that people estimate the *build* cost of a feature and\nignore its tail: a new mechanic must be integrated with every existing system, balanced,\npolished, taught (UX/onboarding), debugged, and maintained forever after. Ten \"small\"\nadditions can sink a schedule. Because the pressure to add is constant and the cost is\nhidden, the discipline has to be structural — a default of *no*, a filter every addition must\npass (the pillars, VISION-0002), and a conscious accounting of the tail before saying yes.\n\n## Applies when\nThroughout production, and especially in the messy middle where the game is playable enough\nto inspire endless \"wouldn't it be cool if\" additions.\n\n## Does not apply / Exceptions\nNot every addition is creep — sometimes a new feature is exactly what the game needs, and\nrigid feature-freezes can prevent genuine improvements found through iteration (PROTO-0006).\nPre-production and prototyping deliberately explore widely before locking scope. The rule is\n\"add deliberately, accounting for the tail,\" not \"never change the plan.\" The default is no;\nyes requires justification.\n\n## Implementation (kept separate from the principle)\nRun every proposed addition through the vision's pillars (VISION-0002) — does it serve *this*\ngame? Estimate the whole tail, not just the build. Prefer deepening existing systems over\nadding new ones. Keep a \"cut/later\" list so good-but-wrong ideas are captured without being\nbuilt now (PROTO-0005). Make adding scope a deliberate, visible decision, not a quiet drift.\n\n## Disagreement\nFirm scope discipline (protect the schedule and coherence) vs. openness to iteration-driven\nchange (the best features are often discovered mid-development, not planned). The\nreconciliation: distinguish *creep* (unaccounted accumulation) from *deliberate iteration*\n(a justified change that pays for its tail). Cut creep; welcome justified change.\n\n## Notes\nThe active-defense partner to PROD-0001 (scope is the primary risk); its filter is the vision\n(VISION-0002/0003) and its spirit is elegance (DESIGN-0007). Confidence 4.\n","searchText":"gdc-l1-prod-0002 fight scope creep — default to no; every feature has a hidden tail production scope-creep features discipline > features are easy to add and hard to remove, and each carries a hidden tail — integration, balance, polish, bug-fixing, testing, and maintenance — usually far larger than its build cost. guard the scope actively. the default answer to a new feature added mid-project is no. scope creep is the slow accumulation of \"just one more thing,\" each individually reasonable, that collectively unbalances the project into delays, crunch, or cancellation [s-scope-production]. the trap is that people estimate the build cost of a feature and ignore its tail: a new mechanic must be integrated with every existing system, balanced, polished, taught (ux/onboarding), debugged, and maintained forever after. ten \"small\" additions can sink a schedule. because the pressure to add is constant and the cost is hidden, the discipline has to be structural — a default of no, a filter every addition must pass (the pillars, vision-0002), and a conscious accounting of the tail before saying yes. throughout production, and especially in the messy middle where the game is playable enough to inspire endless \"wouldn't it be cool if\" additions. not every addition is creep — sometimes a new feature is exactly what the game needs, and rigid feature-freezes can prevent genuine improvements found through iteration (proto-0006). pre-production and prototyping deliberately explore widely before locking scope. the rule is \"add deliberately, accounting for the tail,\" not \"never change the plan.\" the default is no; yes requires justification. run every proposed addition through the vision's pillars (vision-0002) — does it serve this game? estimate the whole tail, not just the build. prefer deepening existing systems over adding new ones. keep a \"cut/later\" list so good-but-wrong ideas are captured without being built now (proto-0005). make adding scope a deliberate, visible decision, not a quiet drift. firm scope discipline (protect the schedule and coherence) vs. openness to iteration-driven change (the best features are often discovered mid-development, not planned). the reconciliation: distinguish creep (unaccounted accumulation) from deliberate iteration (a justified change that pays for its tail). cut creep; welcome justified change. the active-defense partner to prod-0001 (scope is the primary risk); its filter is the vision (vision-0002/0003) and its spirit is elegance (design-0007). confidence 4."}
{"id":"GDC-L1-PROD-0003","title":"Build a vertical slice — prove one polished slice at target quality","layer":"L1","domain":"PROD","subdomain":"pre-production-vs-production","type":"contextual","confidence":4,"status":"canonical","tags":["production","vertical-slice","de-risking","quality-bar"],"related":["GDC-L1-PROTO-0001","GDC-L1-PROD-0004","GDC-L1-PROD-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-proto-vertical-slice","S-scope-production"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROD-0003.md","statement":"Before scaling to full production, build a vertical slice: a small piece of the game realized at final quality, cutting through every discipline. It answers \"can we actually make this?\", sets the quality bar for the whole team, and — for funding or recruiting — shows rather than tells.","sections":{"Statement":"> Before scaling to full production, build a **vertical slice**: a small piece of the game\n> realized at *final quality*, cutting through every discipline. It answers \"**can we\n> actually make this?**\", sets the quality bar for the whole team, and — for funding or\n> recruiting — shows rather than tells.","Rationale":"A prototype proves the game is *fun* (\"should we make this?\", PROTO-0001); a vertical slice\nproves the team can *produce* it at the intended quality (\"can we make it?\")\n[S-proto-vertical-slice]. It de-risks production by forcing every discipline — art, code,\naudio, design, UX — through one representative piece at shipping fidelity, surfacing the real\ncost and the real bottlenecks before they're multiplied across the whole game. It also aligns\nthe team on a concrete quality target (\"this good, everywhere\") far better than a document\ncan, and it's the most persuasive artifact for funding, publishers, and recruits because it\n*is* the game in miniature. Choosing a *tiny, representative* slice is the craft — the\ntemptation to show everything defeats the purpose.","Applies when":"The transition from pre-production to full production, and any point you need to prove\nfeasibility or the quality bar (pitching, funding, team alignment).","Does not apply / Exceptions":"Very small or experimental projects may go straight from prototype to building. A vertical\nslice is expensive (it's real production work), so it's overkill when feasibility isn't in\ndoubt. And a slice can become a trap if the team over-polishes it forever instead of using it\nto *validate and move on* — or if it's mistaken for a prototype and used to find the fun\n(that's PROTO-0001's job, done cheaper).","Implementation (kept separate from the principle)":"Pick the smallest slice that is *representative* of the whole game, and build it to final\nquality across all disciplines. Use it to measure real production cost and extrapolate the\nfull schedule (feeding PROD-0004). Treat it as a quality benchmark and a de-risking exercise,\nnot a demo to endlessly polish. Keep the prototype (fun) and vertical slice (feasibility)\ndistinct — they answer different questions.","Disagreement":"Slice-first (prove feasibility and bar before scaling) vs. lighter-weight approaches\n(prototype then build, common for tiny teams who can't afford a full slice). The value of a\nslice scales with the project's size and risk; for a solo micro-game it may be\nunnecessary ceremony.","Notes":"The production complement to PROTO-0001: prototype = \"should we?\", slice = \"can we?\". Feeds\nscheduling (PROD-0004) and the scope commitment (PROD-0001). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROD-0003\ntitle: Build a vertical slice — prove one polished slice at target quality\nlayer: L1\ndomain: PROD\nsubdomain: pre-production-vs-production\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - production\n  - vertical-slice\n  - de-risking\n  - quality-bar\nrelated:\n  - GDC-L1-PROTO-0001\n  - GDC-L1-PROD-0004\n  - GDC-L1-PROD-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-proto-vertical-slice\n  - S-scope-production\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Before scaling to full production, build a **vertical slice**: a small piece of the game\n> realized at *final quality*, cutting through every discipline. It answers \"**can we\n> actually make this?**\", sets the quality bar for the whole team, and — for funding or\n> recruiting — shows rather than tells.\n\n## Rationale\nA prototype proves the game is *fun* (\"should we make this?\", PROTO-0001); a vertical slice\nproves the team can *produce* it at the intended quality (\"can we make it?\")\n[S-proto-vertical-slice]. It de-risks production by forcing every discipline — art, code,\naudio, design, UX — through one representative piece at shipping fidelity, surfacing the real\ncost and the real bottlenecks before they're multiplied across the whole game. It also aligns\nthe team on a concrete quality target (\"this good, everywhere\") far better than a document\ncan, and it's the most persuasive artifact for funding, publishers, and recruits because it\n*is* the game in miniature. Choosing a *tiny, representative* slice is the craft — the\ntemptation to show everything defeats the purpose.\n\n## Applies when\nThe transition from pre-production to full production, and any point you need to prove\nfeasibility or the quality bar (pitching, funding, team alignment).\n\n## Does not apply / Exceptions\nVery small or experimental projects may go straight from prototype to building. A vertical\nslice is expensive (it's real production work), so it's overkill when feasibility isn't in\ndoubt. And a slice can become a trap if the team over-polishes it forever instead of using it\nto *validate and move on* — or if it's mistaken for a prototype and used to find the fun\n(that's PROTO-0001's job, done cheaper).\n\n## Implementation (kept separate from the principle)\nPick the smallest slice that is *representative* of the whole game, and build it to final\nquality across all disciplines. Use it to measure real production cost and extrapolate the\nfull schedule (feeding PROD-0004). Treat it as a quality benchmark and a de-risking exercise,\nnot a demo to endlessly polish. Keep the prototype (fun) and vertical slice (feasibility)\ndistinct — they answer different questions.\n\n## Disagreement\nSlice-first (prove feasibility and bar before scaling) vs. lighter-weight approaches\n(prototype then build, common for tiny teams who can't afford a full slice). The value of a\nslice scales with the project's size and risk; for a solo micro-game it may be\nunnecessary ceremony.\n\n## Notes\nThe production complement to PROTO-0001: prototype = \"should we?\", slice = \"can we?\". Feeds\nscheduling (PROD-0004) and the scope commitment (PROD-0001). Confidence 4.\n","searchText":"gdc-l1-prod-0003 build a vertical slice — prove one polished slice at target quality production vertical-slice de-risking quality-bar > before scaling to full production, build a vertical slice: a small piece of the game realized at final quality, cutting through every discipline. it answers \"can we actually make this?\", sets the quality bar for the whole team, and — for funding or recruiting — shows rather than tells. a prototype proves the game is fun (\"should we make this?\", proto-0001); a vertical slice proves the team can produce it at the intended quality (\"can we make it?\") [s-proto-vertical-slice]. it de-risks production by forcing every discipline — art, code, audio, design, ux — through one representative piece at shipping fidelity, surfacing the real cost and the real bottlenecks before they're multiplied across the whole game. it also aligns the team on a concrete quality target (\"this good, everywhere\") far better than a document can, and it's the most persuasive artifact for funding, publishers, and recruits because it is the game in miniature. choosing a tiny, representative slice is the craft — the temptation to show everything defeats the purpose. the transition from pre-production to full production, and any point you need to prove feasibility or the quality bar (pitching, funding, team alignment). very small or experimental projects may go straight from prototype to building. a vertical slice is expensive (it's real production work), so it's overkill when feasibility isn't in doubt. and a slice can become a trap if the team over-polishes it forever instead of using it to validate and move on — or if it's mistaken for a prototype and used to find the fun (that's proto-0001's job, done cheaper). pick the smallest slice that is representative of the whole game, and build it to final quality across all disciplines. use it to measure real production cost and extrapolate the full schedule (feeding prod-0004). treat it as a quality benchmark and a de-risking exercise, not a demo to endlessly polish. keep the prototype (fun) and vertical slice (feasibility) distinct — they answer different questions. slice-first (prove feasibility and bar before scaling) vs. lighter-weight approaches (prototype then build, common for tiny teams who can't afford a full slice). the value of a slice scales with the project's size and risk; for a solo micro-game it may be unnecessary ceremony. the production complement to proto-0001: prototype = \"should we?\", slice = \"can we?\". feeds scheduling (prod-0004) and the scope commitment (prod-0001). confidence 4."}
{"id":"GDC-L1-PROD-0004","title":"Plan for iteration and the unknown — schedules must budget discovery","layer":"L1","domain":"PROD","subdomain":"scheduling","type":"contextual","confidence":4,"status":"canonical","tags":["production","scheduling","iteration","risk-management","uncertainty"],"related":["GDC-L1-PROTO-0006","GDC-L1-ARCH-0005","GDC-L1-DESIGN-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-schell-artofgamedesign","S-scope-production"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROD-0004.md","statement":"Game development is discovery, not linear execution — the fun is found through iteration (PROTO-0006), not specified up front — so a schedule that assumes you already know the answer is fiction. Budget explicit time for iteration, failure, and re-work, and treat the plan as a living hypothesis, not a contract.","sections":{"Statement":"> Game development is *discovery*, not linear execution — the fun is found through iteration\n> (PROTO-0006), not specified up front — so a schedule that assumes you already know the\n> answer is fiction. Budget explicit time for iteration, failure, and re-work, and treat the\n> plan as a living hypothesis, not a contract.","Rationale":"The core activity of making a good game is finding out what's fun by trying, testing, and\nadjusting (DESIGN-0001, PROTO-0006), which is inherently unpredictable — you cannot schedule\n\"discover the fun\" like you schedule \"lay bricks.\" Plans that assume linear execution\ntherefore systematically under-budget the loops that actually produce quality, and the\noverrun shows up as crunch or cut quality [S-scope-production]. Planning for iteration means\nbuilding slack and re-work into the schedule, front-loading the riskiest unknowns\n(PROTO-0002), and updating the plan as discovery reveals reality. The schedule's job is to\nmanage uncertainty, not to deny it.","Applies when":"All game scheduling and production planning, especially for novel or design-risky games where\nmuch is genuinely unknown. Less so for well-understood, formulaic production (a known genre,\na sequel) where uncertainty is lower.","Does not apply / Exceptions":"Some work *is* predictable — porting, localization, well-understood content production — and\ncan be scheduled tightly. Highly derivative projects carry less discovery risk. And \"plan for\niteration\" is not license for endless drift (PROTO-0006's know-when-to-ship caveat): budgeted\niteration is bounded, aimed, and eventually stopped.","Implementation (kept separate from the principle)":"Identify what's genuinely unknown and schedule discovery/iteration time for it explicitly;\nschedule the known work normally. Front-load the riskiest unknowns (PROTO-0002) so surprises\narrive while cheap. Invest in iteration speed (ARCH-0005) to get more loops per unit time.\nRe-plan as reality is revealed — treat the schedule as a forecast you update, not a promise\nyou defend against the facts.","Disagreement":"Iteration-budgeted, adaptive planning (embrace uncertainty, re-plan often) vs. fixed\nmilestone planning (predictability for stakeholders, funding, coordination) — publishers and\nlarge teams need commitments the creative reality resists. Most teams blend: firm outer\nmilestones, adaptive iteration within them.","Notes":"The scheduling face of the iteration truth (PROTO-0006, DESIGN-0001); pairs with iteration-\nspeed architecture (ARCH-0005). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROD-0004\ntitle: Plan for iteration and the unknown — schedules must budget discovery\nlayer: L1\ndomain: PROD\nsubdomain: scheduling\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - production\n  - scheduling\n  - iteration\n  - risk-management\n  - uncertainty\nrelated:\n  - GDC-L1-PROTO-0006\n  - GDC-L1-ARCH-0005\n  - GDC-L1-DESIGN-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schell-artofgamedesign\n  - S-scope-production\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Game development is *discovery*, not linear execution — the fun is found through iteration\n> (PROTO-0006), not specified up front — so a schedule that assumes you already know the\n> answer is fiction. Budget explicit time for iteration, failure, and re-work, and treat the\n> plan as a living hypothesis, not a contract.\n\n## Rationale\nThe core activity of making a good game is finding out what's fun by trying, testing, and\nadjusting (DESIGN-0001, PROTO-0006), which is inherently unpredictable — you cannot schedule\n\"discover the fun\" like you schedule \"lay bricks.\" Plans that assume linear execution\ntherefore systematically under-budget the loops that actually produce quality, and the\noverrun shows up as crunch or cut quality [S-scope-production]. Planning for iteration means\nbuilding slack and re-work into the schedule, front-loading the riskiest unknowns\n(PROTO-0002), and updating the plan as discovery reveals reality. The schedule's job is to\nmanage uncertainty, not to deny it.\n\n## Applies when\nAll game scheduling and production planning, especially for novel or design-risky games where\nmuch is genuinely unknown. Less so for well-understood, formulaic production (a known genre,\na sequel) where uncertainty is lower.\n\n## Does not apply / Exceptions\nSome work *is* predictable — porting, localization, well-understood content production — and\ncan be scheduled tightly. Highly derivative projects carry less discovery risk. And \"plan for\niteration\" is not license for endless drift (PROTO-0006's know-when-to-ship caveat): budgeted\niteration is bounded, aimed, and eventually stopped.\n\n## Implementation (kept separate from the principle)\nIdentify what's genuinely unknown and schedule discovery/iteration time for it explicitly;\nschedule the known work normally. Front-load the riskiest unknowns (PROTO-0002) so surprises\narrive while cheap. Invest in iteration speed (ARCH-0005) to get more loops per unit time.\nRe-plan as reality is revealed — treat the schedule as a forecast you update, not a promise\nyou defend against the facts.\n\n## Disagreement\nIteration-budgeted, adaptive planning (embrace uncertainty, re-plan often) vs. fixed\nmilestone planning (predictability for stakeholders, funding, coordination) — publishers and\nlarge teams need commitments the creative reality resists. Most teams blend: firm outer\nmilestones, adaptive iteration within them.\n\n## Notes\nThe scheduling face of the iteration truth (PROTO-0006, DESIGN-0001); pairs with iteration-\nspeed architecture (ARCH-0005). Confidence 4.\n","searchText":"gdc-l1-prod-0004 plan for iteration and the unknown — schedules must budget discovery production scheduling iteration risk-management uncertainty > game development is discovery, not linear execution — the fun is found through iteration (proto-0006), not specified up front — so a schedule that assumes you already know the answer is fiction. budget explicit time for iteration, failure, and re-work, and treat the plan as a living hypothesis, not a contract. the core activity of making a good game is finding out what's fun by trying, testing, and adjusting (design-0001, proto-0006), which is inherently unpredictable — you cannot schedule \"discover the fun\" like you schedule \"lay bricks.\" plans that assume linear execution therefore systematically under-budget the loops that actually produce quality, and the overrun shows up as crunch or cut quality [s-scope-production]. planning for iteration means building slack and re-work into the schedule, front-loading the riskiest unknowns (proto-0002), and updating the plan as discovery reveals reality. the schedule's job is to manage uncertainty, not to deny it. all game scheduling and production planning, especially for novel or design-risky games where much is genuinely unknown. less so for well-understood, formulaic production (a known genre, a sequel) where uncertainty is lower. some work is predictable — porting, localization, well-understood content production — and can be scheduled tightly. highly derivative projects carry less discovery risk. and \"plan for iteration\" is not license for endless drift (proto-0006's know-when-to-ship caveat): budgeted iteration is bounded, aimed, and eventually stopped. identify what's genuinely unknown and schedule discovery/iteration time for it explicitly; schedule the known work normally. front-load the riskiest unknowns (proto-0002) so surprises arrive while cheap. invest in iteration speed (arch-0005) to get more loops per unit time. re-plan as reality is revealed — treat the schedule as a forecast you update, not a promise you defend against the facts. iteration-budgeted, adaptive planning (embrace uncertainty, re-plan often) vs. fixed milestone planning (predictability for stakeholders, funding, coordination) — publishers and large teams need commitments the creative reality resists. most teams blend: firm outer milestones, adaptive iteration within them. the scheduling face of the iteration truth (proto-0006, design-0001); pairs with iteration- speed architecture (arch-0005). confidence 4."}
{"id":"GDC-L1-PROD-0005","title":"Avoid crunch — sustained overwork is a planning failure, not a virtue","layer":"L1","domain":"PROD","subdomain":"crunch-avoidance","type":"contextual","confidence":4,"status":"canonical","tags":["production","crunch","sustainability","wellbeing","planning"],"related":["GDC-L1-PROD-0001","GDC-L1-TEAM-0001","GDC-L1-PROD-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-scope-production"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROD-0005.md","statement":"Crunch — sustained, mandatory overwork — degrades both the work and the people doing it, and it is a symptom of a scoping or planning failure (usually over-scope, PROD-0001), not a form of heroism. Protect a sustainable pace; the quality of the game and the health of the team both depend on it.","sections":{"Statement":"> Crunch — sustained, mandatory overwork — degrades both the work and the people doing it,\n> and it is a *symptom* of a scoping or planning failure (usually over-scope, PROD-0001), not\n> a form of heroism. Protect a sustainable pace; the quality of the game and the health of the\n> team both depend on it.","Rationale":"Tired people make worse decisions, write buggier code, and produce weaker work, so extended\ncrunch often *lowers* net output while burning out the team it depends on\n[S-scope-production]. It also masks the real problem: crunch is what happens when scope, time,\nand resources were never balanced (PROD-0001) and the gap gets absorbed by people's evenings\nand weekends instead of by a plan. Treating crunch as a virtue (\"we shipped through heroic\neffort\") rewards the planning failure that caused it and normalizes harm. The humane *and*\nthe effective choice is the same: plan realistically, cut scope, and keep the pace\nsustainable — which is also a wellbeing and ethics commitment, not just a productivity one.","Applies when":"All production planning and management. Most acute near milestones and launch, where the\ntemptation to \"just push through\" is strongest.","Does not apply / Exceptions":"Short, voluntary, well-compensated, genuinely-rare pushes (a true one-off before a hard\nexternal deadline) are different from chronic crunch culture — the harm is in the *sustained,\nmandatory* form. Passion-driven overwork that people freely choose exists, but leaders must be\ncareful not to launder mandatory crunch as \"passion.\" The principle targets crunch as a\n*planned-for* norm.","Implementation (kept separate from the principle)":"Plan for a sustainable pace and cut scope to hold it (PROD-0001/0004). Treat a looming crunch\nas a signal to re-scope, not to demand more hours. Track workload honestly. Build the schedule\nslack that PROD-0004 calls for so surprises don't land on people. Protect the team's health as\na first-order constraint (TEAM-0001), not a variable to spend.","Disagreement":"\"Crunch is sometimes necessary/worth it\" (deadlines are real; a final push can matter) vs.\n\"crunch is a failure of planning and a harm to avoid\" (the sustainable-development position).\nThe industry has moved decisively toward the latter; the honest middle acknowledges rare\nshort pushes while rejecting crunch as a planned norm or a badge of honor.","Notes":"A production principle with an explicit wellbeing/ethics dimension; the human counterpart of\nscope discipline (PROD-0001) and a team-health commitment (TEAM-0001). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROD-0005\ntitle: Avoid crunch — sustained overwork is a planning failure, not a virtue\nlayer: L1\ndomain: PROD\nsubdomain: crunch-avoidance\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - production\n  - crunch\n  - sustainability\n  - wellbeing\n  - planning\nrelated:\n  - GDC-L1-PROD-0001\n  - GDC-L1-TEAM-0001\n  - GDC-L1-PROD-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-scope-production\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Crunch — sustained, mandatory overwork — degrades both the work and the people doing it,\n> and it is a *symptom* of a scoping or planning failure (usually over-scope, PROD-0001), not\n> a form of heroism. Protect a sustainable pace; the quality of the game and the health of the\n> team both depend on it.\n\n## Rationale\nTired people make worse decisions, write buggier code, and produce weaker work, so extended\ncrunch often *lowers* net output while burning out the team it depends on\n[S-scope-production]. It also masks the real problem: crunch is what happens when scope, time,\nand resources were never balanced (PROD-0001) and the gap gets absorbed by people's evenings\nand weekends instead of by a plan. Treating crunch as a virtue (\"we shipped through heroic\neffort\") rewards the planning failure that caused it and normalizes harm. The humane *and*\nthe effective choice is the same: plan realistically, cut scope, and keep the pace\nsustainable — which is also a wellbeing and ethics commitment, not just a productivity one.\n\n## Applies when\nAll production planning and management. Most acute near milestones and launch, where the\ntemptation to \"just push through\" is strongest.\n\n## Does not apply / Exceptions\nShort, voluntary, well-compensated, genuinely-rare pushes (a true one-off before a hard\nexternal deadline) are different from chronic crunch culture — the harm is in the *sustained,\nmandatory* form. Passion-driven overwork that people freely choose exists, but leaders must be\ncareful not to launder mandatory crunch as \"passion.\" The principle targets crunch as a\n*planned-for* norm.\n\n## Implementation (kept separate from the principle)\nPlan for a sustainable pace and cut scope to hold it (PROD-0001/0004). Treat a looming crunch\nas a signal to re-scope, not to demand more hours. Track workload honestly. Build the schedule\nslack that PROD-0004 calls for so surprises don't land on people. Protect the team's health as\na first-order constraint (TEAM-0001), not a variable to spend.\n\n## Disagreement\n\"Crunch is sometimes necessary/worth it\" (deadlines are real; a final push can matter) vs.\n\"crunch is a failure of planning and a harm to avoid\" (the sustainable-development position).\nThe industry has moved decisively toward the latter; the honest middle acknowledges rare\nshort pushes while rejecting crunch as a planned norm or a badge of honor.\n\n## Notes\nA production principle with an explicit wellbeing/ethics dimension; the human counterpart of\nscope discipline (PROD-0001) and a team-health commitment (TEAM-0001). Confidence 4.\n","searchText":"gdc-l1-prod-0005 avoid crunch — sustained overwork is a planning failure, not a virtue production crunch sustainability wellbeing planning > crunch — sustained, mandatory overwork — degrades both the work and the people doing it, and it is a symptom of a scoping or planning failure (usually over-scope, prod-0001), not a form of heroism. protect a sustainable pace; the quality of the game and the health of the team both depend on it. tired people make worse decisions, write buggier code, and produce weaker work, so extended crunch often lowers net output while burning out the team it depends on [s-scope-production]. it also masks the real problem: crunch is what happens when scope, time, and resources were never balanced (prod-0001) and the gap gets absorbed by people's evenings and weekends instead of by a plan. treating crunch as a virtue (\"we shipped through heroic effort\") rewards the planning failure that caused it and normalizes harm. the humane and the effective choice is the same: plan realistically, cut scope, and keep the pace sustainable — which is also a wellbeing and ethics commitment, not just a productivity one. all production planning and management. most acute near milestones and launch, where the temptation to \"just push through\" is strongest. short, voluntary, well-compensated, genuinely-rare pushes (a true one-off before a hard external deadline) are different from chronic crunch culture — the harm is in the sustained, mandatory form. passion-driven overwork that people freely choose exists, but leaders must be careful not to launder mandatory crunch as \"passion.\" the principle targets crunch as a planned-for norm. plan for a sustainable pace and cut scope to hold it (prod-0001/0004). treat a looming crunch as a signal to re-scope, not to demand more hours. track workload honestly. build the schedule slack that prod-0004 calls for so surprises don't land on people. protect the team's health as a first-order constraint (team-0001), not a variable to spend. \"crunch is sometimes necessary/worth it\" (deadlines are real; a final push can matter) vs. \"crunch is a failure of planning and a harm to avoid\" (the sustainable-development position). the industry has moved decisively toward the latter; the honest middle acknowledges rare short pushes while rejecting crunch as a planned norm or a badge of honor. a production principle with an explicit wellbeing/ethics dimension; the human counterpart of scope discipline (prod-0001) and a team-health commitment (team-0001). confidence 4."}
{"id":"GDC-L1-PROD-0006","title":"Finish — shipping is its own skill","layer":"L1","domain":"PROD","subdomain":"scoping-and-cutting","type":"contextual","confidence":4,"status":"canonical","tags":["production","finishing","shipping","polish","cutting"],"related":["GDC-L1-PROTO-0006","GDC-L1-PROTO-0005","GDC-L1-PROD-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-scope-production","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-PROD-0006.md","statement":"A game that never ships helps no one, and finishing is a distinct, hard skill. The last stretch is dominated by cutting, polishing, and bug-fixing — not by adding. Decide what \"done\" means, cut ruthlessly to reach it, and actually release.","sections":{"Statement":"> A game that never ships helps no one, and **finishing is a distinct, hard skill.** The last\n> stretch is dominated by cutting, polishing, and bug-fixing — not by adding. Decide what\n> \"done\" means, cut ruthlessly to reach it, and actually release.","Rationale":"Starting is easy and finishing is where most projects die, because the end game is\npsychologically and practically different from the beginning: it's about *converging* —\nclosing off scope, fixing the long tail of bugs, polishing what exists, and letting go of what\nwon't make it — rather than the open-ended creativity of the start [S-scope-production]. The\n\"last 10%\" reliably takes far more than 10% of the effort, and inexperienced teams\nunderestimate it badly. Finishing requires a clear definition of done, the discipline to stop\nadding (and stop iterating — PROTO-0006's know-when-to-ship), and the willingness to cut\nbeloved-but-unfinished work (PROTO-0005) so the whole can ship. Shipping is a skill you build,\nand an unshipped game teaches almost nothing compared to a finished one.","Applies when":"The back half of any project, and the decision — recurring — of whether to add/iterate more or\nconverge and ship. Especially critical for first projects, which most often stall before the\nfinish.","Does not apply / Exceptions":"Live-service and early-access models blur \"finished\" deliberately (ship a viable core, keep\ndeveloping) — but even they must reach a *shippable* state, so the finishing discipline still\napplies to each release. Research prototypes are *meant* not to ship. And \"finish\" doesn't\nmean ship broken — it means converge on a defined, achievable \"done,\" which may itself be\nscoped down (PROD-0001).","Implementation (kept separate from the principle)":"Define \"done\" concretely and early enough to steer toward it. In the end game, switch from\nadding to converging: freeze scope, fix bugs, polish, and cut what won't make it (PROTO-0005).\nBudget realistically for the long tail (it's bigger than it looks). Know when iterating more\ncosts more than it adds (PROTO-0006) and ship. Treat *finishing* as a skill to practice on\nsmall projects before big ones.","Disagreement":"Ship-it discipline (finished-and-imperfect beats perfect-and-unreleased) vs. hold-for-quality\n(don't ship before it's good). Both fail at the extreme — premature shipping and endless\npolishing are both real. The reconciliation is a *defined, achievable* bar for \"done,\" reached\nby cutting rather than by indefinite extension.","Notes":"The convergence/ship discipline; the production partner of PROTO-0006 (stop looping) and\nPROTO-0005 (cut), and the endpoint of the scope story (PROD-0001). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-PROD-0006\ntitle: Finish — shipping is its own skill\nlayer: L1\ndomain: PROD\nsubdomain: scoping-and-cutting\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - production\n  - finishing\n  - shipping\n  - polish\n  - cutting\nrelated:\n  - GDC-L1-PROTO-0006\n  - GDC-L1-PROTO-0005\n  - GDC-L1-PROD-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-scope-production\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A game that never ships helps no one, and **finishing is a distinct, hard skill.** The last\n> stretch is dominated by cutting, polishing, and bug-fixing — not by adding. Decide what\n> \"done\" means, cut ruthlessly to reach it, and actually release.\n\n## Rationale\nStarting is easy and finishing is where most projects die, because the end game is\npsychologically and practically different from the beginning: it's about *converging* —\nclosing off scope, fixing the long tail of bugs, polishing what exists, and letting go of what\nwon't make it — rather than the open-ended creativity of the start [S-scope-production]. The\n\"last 10%\" reliably takes far more than 10% of the effort, and inexperienced teams\nunderestimate it badly. Finishing requires a clear definition of done, the discipline to stop\nadding (and stop iterating — PROTO-0006's know-when-to-ship), and the willingness to cut\nbeloved-but-unfinished work (PROTO-0005) so the whole can ship. Shipping is a skill you build,\nand an unshipped game teaches almost nothing compared to a finished one.\n\n## Applies when\nThe back half of any project, and the decision — recurring — of whether to add/iterate more or\nconverge and ship. Especially critical for first projects, which most often stall before the\nfinish.\n\n## Does not apply / Exceptions\nLive-service and early-access models blur \"finished\" deliberately (ship a viable core, keep\ndeveloping) — but even they must reach a *shippable* state, so the finishing discipline still\napplies to each release. Research prototypes are *meant* not to ship. And \"finish\" doesn't\nmean ship broken — it means converge on a defined, achievable \"done,\" which may itself be\nscoped down (PROD-0001).\n\n## Implementation (kept separate from the principle)\nDefine \"done\" concretely and early enough to steer toward it. In the end game, switch from\nadding to converging: freeze scope, fix bugs, polish, and cut what won't make it (PROTO-0005).\nBudget realistically for the long tail (it's bigger than it looks). Know when iterating more\ncosts more than it adds (PROTO-0006) and ship. Treat *finishing* as a skill to practice on\nsmall projects before big ones.\n\n## Disagreement\nShip-it discipline (finished-and-imperfect beats perfect-and-unreleased) vs. hold-for-quality\n(don't ship before it's good). Both fail at the extreme — premature shipping and endless\npolishing are both real. The reconciliation is a *defined, achievable* bar for \"done,\" reached\nby cutting rather than by indefinite extension.\n\n## Notes\nThe convergence/ship discipline; the production partner of PROTO-0006 (stop looping) and\nPROTO-0005 (cut), and the endpoint of the scope story (PROD-0001). Confidence 4.\n","searchText":"gdc-l1-prod-0006 finish — shipping is its own skill production finishing shipping polish cutting > a game that never ships helps no one, and finishing is a distinct, hard skill. the last stretch is dominated by cutting, polishing, and bug-fixing — not by adding. decide what \"done\" means, cut ruthlessly to reach it, and actually release. starting is easy and finishing is where most projects die, because the end game is psychologically and practically different from the beginning: it's about converging — closing off scope, fixing the long tail of bugs, polishing what exists, and letting go of what won't make it — rather than the open-ended creativity of the start [s-scope-production]. the \"last 10%\" reliably takes far more than 10% of the effort, and inexperienced teams underestimate it badly. finishing requires a clear definition of done, the discipline to stop adding (and stop iterating — proto-0006's know-when-to-ship), and the willingness to cut beloved-but-unfinished work (proto-0005) so the whole can ship. shipping is a skill you build, and an unshipped game teaches almost nothing compared to a finished one. the back half of any project, and the decision — recurring — of whether to add/iterate more or converge and ship. especially critical for first projects, which most often stall before the finish. live-service and early-access models blur \"finished\" deliberately (ship a viable core, keep developing) — but even they must reach a shippable state, so the finishing discipline still applies to each release. research prototypes are meant not to ship. and \"finish\" doesn't mean ship broken — it means converge on a defined, achievable \"done,\" which may itself be scoped down (prod-0001). define \"done\" concretely and early enough to steer toward it. in the end game, switch from adding to converging: freeze scope, fix bugs, polish, and cut what won't make it (proto-0005). budget realistically for the long tail (it's bigger than it looks). know when iterating more costs more than it adds (proto-0006) and ship. treat finishing as a skill to practice on small projects before big ones. ship-it discipline (finished-and-imperfect beats perfect-and-unreleased) vs. hold-for-quality (don't ship before it's good). both fail at the extreme — premature shipping and endless polishing are both real. the reconciliation is a defined, achievable bar for \"done,\" reached by cutting rather than by indefinite extension. the convergence/ship discipline; the production partner of proto-0006 (stop looping) and proto-0005 (cut), and the endpoint of the scope story (prod-0001). confidence 4."}
{"id":"GDC-L1-VISION-0001","title":"Hold a clear creative vision — a north star that resolves decisions","layer":"L1","domain":"VISION","subdomain":"vision-holding","type":"contextual","confidence":4,"status":"canonical","tags":["vision","creative-direction","coherence","north-star"],"related":["GDC-L1-DESIGN-0001","GDC-L1-VISION-0002","GDC-L1-VISION-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-design-pillars","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-VISION-0001.md","statement":"A coherent game needs a clear creative vision — a shared, specific idea of the intended experience — that ambiguous decisions can be measured against. Without it, every contributor quietly builds a slightly different game, and the whole loses coherence.","sections":{"Statement":"> A coherent game needs a clear creative **vision** — a shared, specific idea of the intended\n> experience — that ambiguous decisions can be measured against. Without it, every contributor\n> quietly builds a slightly different game, and the whole loses coherence.","Rationale":"A game is made of thousands of decisions by many people, and most of them are too small to\nescalate — so unless everyone shares the same mental picture of what the game *is*, each person\nresolves ambiguity toward their *own* version, and the results don't cohere\n[S-design-pillars]. A clear vision is the shared reference that lets distributed decisions\npoint the same way: when someone asks \"should the tone here be funny or grim? should this\nsystem be deep or simple?\", the vision answers. This is the creative counterpart of designing\nfor the intended experience (DESIGN-0001) — the vision is the *statement* of that intended\nexperience, held in common so the whole team can serve it. Coherence is not automatic; it is\nthe product of a shared, maintained vision.","Applies when":"Any project with more than one contributor, and any decision where \"what should this be?\" has\nno obvious answer. The larger and longer the project, the more a shared vision matters.","Does not apply / Exceptions":"A solo developer holds the vision implicitly and may not need to externalize it (though even\nsolo devs drift without one). Highly exploratory early phases deliberately keep the vision\nloose while searching for the game. And vision must not calcify into dogma that ignores what\nplaytesting reveals (DESIGN-0001) — it's a north star to steer by, updated as the game teaches\nyou what it wants to be.","Implementation (kept separate from the principle)":"Articulate the intended experience explicitly and share it widely. Distill it into pillars\n(VISION-0002) and a communicable hook (VISION-0005) so it's usable, not just aspirational. Use\nit to resolve ambiguous decisions, and revisit it when playtests reveal the real game. Give it\nan owner (VISION-0004) so it stays coherent.","Disagreement":"Strong up-front vision (coherence, direction) vs. emergent/discovered vision (let the game\nreveal itself through iteration) — auteur-led vs. discovery-led development. Most projects need\nsome of both: enough vision to align the team, enough openness to learn from the game. The risk\nat each extreme is incoherence (no vision) or rigidity (frozen vision).","Notes":"The anchor of the VISION domain and the creative statement of DESIGN-0001 (the intended\nexperience). Made practical by pillars (VISION-0002) and communication (VISION-0005), owned via\nVISION-0004. Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-VISION-0001\ntitle: Hold a clear creative vision — a north star that resolves decisions\nlayer: L1\ndomain: VISION\nsubdomain: vision-holding\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - vision\n  - creative-direction\n  - coherence\n  - north-star\nrelated:\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-VISION-0002\n  - GDC-L1-VISION-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-design-pillars\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A coherent game needs a clear creative **vision** — a shared, specific idea of the intended\n> experience — that ambiguous decisions can be measured against. Without it, every contributor\n> quietly builds a slightly different game, and the whole loses coherence.\n\n## Rationale\nA game is made of thousands of decisions by many people, and most of them are too small to\nescalate — so unless everyone shares the same mental picture of what the game *is*, each person\nresolves ambiguity toward their *own* version, and the results don't cohere\n[S-design-pillars]. A clear vision is the shared reference that lets distributed decisions\npoint the same way: when someone asks \"should the tone here be funny or grim? should this\nsystem be deep or simple?\", the vision answers. This is the creative counterpart of designing\nfor the intended experience (DESIGN-0001) — the vision is the *statement* of that intended\nexperience, held in common so the whole team can serve it. Coherence is not automatic; it is\nthe product of a shared, maintained vision.\n\n## Applies when\nAny project with more than one contributor, and any decision where \"what should this be?\" has\nno obvious answer. The larger and longer the project, the more a shared vision matters.\n\n## Does not apply / Exceptions\nA solo developer holds the vision implicitly and may not need to externalize it (though even\nsolo devs drift without one). Highly exploratory early phases deliberately keep the vision\nloose while searching for the game. And vision must not calcify into dogma that ignores what\nplaytesting reveals (DESIGN-0001) — it's a north star to steer by, updated as the game teaches\nyou what it wants to be.\n\n## Implementation (kept separate from the principle)\nArticulate the intended experience explicitly and share it widely. Distill it into pillars\n(VISION-0002) and a communicable hook (VISION-0005) so it's usable, not just aspirational. Use\nit to resolve ambiguous decisions, and revisit it when playtests reveal the real game. Give it\nan owner (VISION-0004) so it stays coherent.\n\n## Disagreement\nStrong up-front vision (coherence, direction) vs. emergent/discovered vision (let the game\nreveal itself through iteration) — auteur-led vs. discovery-led development. Most projects need\nsome of both: enough vision to align the team, enough openness to learn from the game. The risk\nat each extreme is incoherence (no vision) or rigidity (frozen vision).\n\n## Notes\nThe anchor of the VISION domain and the creative statement of DESIGN-0001 (the intended\nexperience). Made practical by pillars (VISION-0002) and communication (VISION-0005), owned via\nVISION-0004. Confidence 4.\n","searchText":"gdc-l1-vision-0001 hold a clear creative vision — a north star that resolves decisions vision creative-direction coherence north-star > a coherent game needs a clear creative vision — a shared, specific idea of the intended experience — that ambiguous decisions can be measured against. without it, every contributor quietly builds a slightly different game, and the whole loses coherence. a game is made of thousands of decisions by many people, and most of them are too small to escalate — so unless everyone shares the same mental picture of what the game is, each person resolves ambiguity toward their own version, and the results don't cohere [s-design-pillars]. a clear vision is the shared reference that lets distributed decisions point the same way: when someone asks \"should the tone here be funny or grim? should this system be deep or simple?\", the vision answers. this is the creative counterpart of designing for the intended experience (design-0001) — the vision is the statement of that intended experience, held in common so the whole team can serve it. coherence is not automatic; it is the product of a shared, maintained vision. any project with more than one contributor, and any decision where \"what should this be?\" has no obvious answer. the larger and longer the project, the more a shared vision matters. a solo developer holds the vision implicitly and may not need to externalize it (though even solo devs drift without one). highly exploratory early phases deliberately keep the vision loose while searching for the game. and vision must not calcify into dogma that ignores what playtesting reveals (design-0001) — it's a north star to steer by, updated as the game teaches you what it wants to be. articulate the intended experience explicitly and share it widely. distill it into pillars (vision-0002) and a communicable hook (vision-0005) so it's usable, not just aspirational. use it to resolve ambiguous decisions, and revisit it when playtests reveal the real game. give it an owner (vision-0004) so it stays coherent. strong up-front vision (coherence, direction) vs. emergent/discovered vision (let the game reveal itself through iteration) — auteur-led vs. discovery-led development. most projects need some of both: enough vision to align the team, enough openness to learn from the game. the risk at each extreme is incoherence (no vision) or rigidity (frozen vision). the anchor of the vision domain and the creative statement of design-0001 (the intended experience). made practical by pillars (vision-0002) and communication (vision-0005), owned via vision-0004. confidence 4."}
{"id":"GDC-L1-VISION-0002","title":"Define pillars — a few explicit principles every decision is checked against","layer":"L1","domain":"VISION","subdomain":"pillars","type":"contextual","confidence":4,"status":"canonical","tags":["vision","pillars","creative-direction","filter","coherence"],"related":["GDC-L1-VISION-0001","GDC-L1-VISION-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-design-pillars"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-VISION-0002.md","statement":"Distill the vision into a few explicit design pillars — the fundamental goals of the intended experience — and use them as a filter for every idea and decision. Pillars turn a vague vision into a practical test: does this serve the pillars?","sections":{"Statement":"> Distill the vision into a few explicit **design pillars** — the fundamental goals of the\n> intended experience — and use them as a filter for every idea and decision. Pillars turn a\n> vague vision into a practical test: *does this serve the pillars?*","Rationale":"A vision (VISION-0001) is only usable if it can be applied to concrete decisions, and pillars\nare how you make it applicable: a small set of guiding principles that every proposed mechanic,\nfeature, art choice, or cut can be checked against [S-design-pillars]. Pillars do two jobs.\nThey *align* — everyone measures against the same few goals, so decisions cohere. And they\n*filter* — an idea that doesn't serve a pillar doesn't belong, which is how you resist feature\ncreep (PROD-0002) without relitigating the vision every time. Crucially, pillars reframe\nrejection: they don't say an idea is *bad*, only that it doesn't fit *this* game — which makes\nsaying no (VISION-0003) defensible and impersonal. Few and sharp beats many and vague; three\nstrong pillars steer better than ten mushy ones.","Applies when":"Whenever you need to make the vision operational — evaluating features, resolving design\ndebates, prioritizing, and cutting. Valuable from pre-production through ship.","Does not apply / Exceptions":"Pillars can be over-formalized — a wall of vague, feel-good pillars that don't actually decide anything is worse than none. They must be *specific enough to reject things*. Very small or experimental projects may carry pillars informally.","Implementation (kept separate from the principle)":"Write a few (roughly 3–5) concrete, specific pillars that capture what the experience is *for*. Make them sharp enough to reject real ideas. Run features and cuts through them (VISION-0003, PROD-0002). Keep them visible to the whole team. Grow them when a decision can't be derived from them.","Disagreement":"Explicit pillars (shared filter, defensible nos) vs. holistic/tacit vision (some directors\ncarry coherence without formalizing it, and worry pillars ossify or oversimplify). Most teams\nbenefit from explicit pillars precisely because the vision must be shared across many people;\nsolo auteurs can carry it tacitly.","Notes":"The operational form of the vision (VISION-0001), the engine of principled nos (VISION-0003) and anti-creep (PROD-0002). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-VISION-0002\ntitle: Define pillars — a few explicit principles every decision is checked against\nlayer: L1\ndomain: VISION\nsubdomain: pillars\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - vision\n  - pillars\n  - creative-direction\n  - filter\n  - coherence\nrelated:\n  - GDC-L1-VISION-0001\n  - GDC-L1-VISION-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-design-pillars\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Distill the vision into a few explicit **design pillars** — the fundamental goals of the\n> intended experience — and use them as a filter for every idea and decision. Pillars turn a\n> vague vision into a practical test: *does this serve the pillars?*\n\n## Rationale\nA vision (VISION-0001) is only usable if it can be applied to concrete decisions, and pillars\nare how you make it applicable: a small set of guiding principles that every proposed mechanic,\nfeature, art choice, or cut can be checked against [S-design-pillars]. Pillars do two jobs.\nThey *align* — everyone measures against the same few goals, so decisions cohere. And they\n*filter* — an idea that doesn't serve a pillar doesn't belong, which is how you resist feature\ncreep (PROD-0002) without relitigating the vision every time. Crucially, pillars reframe\nrejection: they don't say an idea is *bad*, only that it doesn't fit *this* game — which makes\nsaying no (VISION-0003) defensible and impersonal. Few and sharp beats many and vague; three\nstrong pillars steer better than ten mushy ones.\n\n## Applies when\nWhenever you need to make the vision operational — evaluating features, resolving design\ndebates, prioritizing, and cutting. Valuable from pre-production through ship.\n\n## Does not apply / Exceptions\nPillars can be over-formalized — a wall of vague, feel-good pillars that don't actually decide anything is worse than none. They must be *specific enough to reject things*. Very small or experimental projects may carry pillars informally.\n\n## Implementation (kept separate from the principle)\nWrite a few (roughly 3–5) concrete, specific pillars that capture what the experience is *for*. Make them sharp enough to reject real ideas. Run features and cuts through them (VISION-0003, PROD-0002). Keep them visible to the whole team. Grow them when a decision can't be derived from them.\n\n## Disagreement\nExplicit pillars (shared filter, defensible nos) vs. holistic/tacit vision (some directors\ncarry coherence without formalizing it, and worry pillars ossify or oversimplify). Most teams\nbenefit from explicit pillars precisely because the vision must be shared across many people;\nsolo auteurs can carry it tacitly.\n\n## Notes\nThe operational form of the vision (VISION-0001), the engine of principled nos (VISION-0003) and anti-creep (PROD-0002). Confidence 4.\n","searchText":"gdc-l1-vision-0002 define pillars — a few explicit principles every decision is checked against vision pillars creative-direction filter coherence > distill the vision into a few explicit design pillars — the fundamental goals of the intended experience — and use them as a filter for every idea and decision. pillars turn a vague vision into a practical test: does this serve the pillars? a vision (vision-0001) is only usable if it can be applied to concrete decisions, and pillars are how you make it applicable: a small set of guiding principles that every proposed mechanic, feature, art choice, or cut can be checked against [s-design-pillars]. pillars do two jobs. they align — everyone measures against the same few goals, so decisions cohere. and they filter — an idea that doesn't serve a pillar doesn't belong, which is how you resist feature creep (prod-0002) without relitigating the vision every time. crucially, pillars reframe rejection: they don't say an idea is bad, only that it doesn't fit this game — which makes saying no (vision-0003) defensible and impersonal. few and sharp beats many and vague; three strong pillars steer better than ten mushy ones. whenever you need to make the vision operational — evaluating features, resolving design debates, prioritizing, and cutting. valuable from pre-production through ship. pillars can be over-formalized — a wall of vague, feel-good pillars that don't actually decide anything is worse than none. they must be specific enough to reject things. very small or experimental projects may carry pillars informally. write a few (roughly 3–5) concrete, specific pillars that capture what the experience is for. make them sharp enough to reject real ideas. run features and cuts through them (vision-0003, prod-0002). keep them visible to the whole team. grow them when a decision can't be derived from them. explicit pillars (shared filter, defensible nos) vs. holistic/tacit vision (some directors carry coherence without formalizing it, and worry pillars ossify or oversimplify). most teams benefit from explicit pillars precisely because the vision must be shared across many people; solo auteurs can carry it tacitly. the operational form of the vision (vision-0001), the engine of principled nos (vision-0003) and anti-creep (prod-0002). confidence 4."}
{"id":"GDC-L1-VISION-0003","title":"Say no to protect coherence — a game is defined by what it excludes","layer":"L1","domain":"VISION","subdomain":"saying-no","type":"contextual","confidence":4,"status":"canonical","tags":["vision","saying-no","coherence","focus","cutting"],"related":["GDC-L1-DESIGN-0007","GDC-L1-PROTO-0005","GDC-L1-PROD-0002"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-design-pillars"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-VISION-0003.md","statement":"A great game is shaped as much by what it leaves out as by what it includes. Good ideas arrive endlessly; the vision's job is to reject the ones that don't fit — not because they're bad, but because they don't serve this game. Saying no is how coherence survives contact with a hundred good ideas.","sections":{"Statement":"> A great game is shaped as much by what it leaves out as by what it includes. Good ideas\n> arrive endlessly; the vision's job is to **reject the ones that don't fit** — not because\n> they're bad, but because they don't serve *this* game. Saying no is how coherence survives\n> contact with a hundred good ideas.","Rationale":"The threat to a game's coherence is rarely bad ideas — it's an abundance of *good* ones, each\nof which pulls the design a little toward a different game until it becomes an incoherent pile\nof features that don't harmonize [S-design-pillars]. So the discipline of exclusion is not\nnegativity; it's authorship. Pillars (VISION-0002) make the no defensible and impersonal: the\nanswer isn't \"your idea is bad,\" it's \"that doesn't fit this game,\" which protects both the\nvision and the relationship. This is the vision-side expression of elegance (DESIGN-0007) and\nkill-your-darlings (PROTO-0005): a focused game that does a few things brilliantly beats a\ndiffuse one that does many things adequately, and getting there requires saying no far more\noften than yes.","Applies when":"Every point where ideas are proposed and decisions made — design reviews, feature requests,\nscope decisions. Especially where the director/vision-holder is \"bombarded with ideas.\"","Does not apply / Exceptions":"Saying no must not become reflexive rejection that starves the game of genuine improvement —\nsome ideas *should* change the vision, and iteration reveals features worth adding (PROTO-0006,\nPROD-0002's caveat). The skill is discerning ideas that don't fit from ideas that reveal the\ngame should grow. And no should be *reasoned* (against the pillars), not authoritarian whim —\nthat's what keeps it legitimate.","Implementation (kept separate from the principle)":"Filter ideas through the pillars (VISION-0002) and reject what doesn't serve them, framing the\nno as \"doesn't fit *this* game.\" Keep a \"cut/later\" list so rejected-but-good ideas are honored\nwithout being built now (PROTO-0005). Distinguish \"doesn't fit\" (cut) from \"the game should\nchange\" (a vision decision, VISION-0001). Protect the core while trimming the periphery\n(PROD-0001).","Disagreement":"Tight, exclusionary focus (coherence, elegance, a game that does a few things brilliantly) vs.\ninclusive, maximalist abundance (richness through many systems — DESIGN-0007's stylistic\ncounter-pole). Both produce great games; the failure modes are blandness (over-cutting the\nsoul) and incoherence (never saying no). The vision decides which the game wants.","Notes":"The vision-side of elegance (DESIGN-0007) and cutting (PROTO-0005, PROD-0002); powered by\npillars (VISION-0002). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-VISION-0003\ntitle: Say no to protect coherence — a game is defined by what it excludes\nlayer: L1\ndomain: VISION\nsubdomain: saying-no\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - vision\n  - saying-no\n  - coherence\n  - focus\n  - cutting\nrelated:\n  - GDC-L1-DESIGN-0007\n  - GDC-L1-PROTO-0005\n  - GDC-L1-PROD-0002\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-design-pillars\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A great game is shaped as much by what it leaves out as by what it includes. Good ideas\n> arrive endlessly; the vision's job is to **reject the ones that don't fit** — not because\n> they're bad, but because they don't serve *this* game. Saying no is how coherence survives\n> contact with a hundred good ideas.\n\n## Rationale\nThe threat to a game's coherence is rarely bad ideas — it's an abundance of *good* ones, each\nof which pulls the design a little toward a different game until it becomes an incoherent pile\nof features that don't harmonize [S-design-pillars]. So the discipline of exclusion is not\nnegativity; it's authorship. Pillars (VISION-0002) make the no defensible and impersonal: the\nanswer isn't \"your idea is bad,\" it's \"that doesn't fit this game,\" which protects both the\nvision and the relationship. This is the vision-side expression of elegance (DESIGN-0007) and\nkill-your-darlings (PROTO-0005): a focused game that does a few things brilliantly beats a\ndiffuse one that does many things adequately, and getting there requires saying no far more\noften than yes.\n\n## Applies when\nEvery point where ideas are proposed and decisions made — design reviews, feature requests,\nscope decisions. Especially where the director/vision-holder is \"bombarded with ideas.\"\n\n## Does not apply / Exceptions\nSaying no must not become reflexive rejection that starves the game of genuine improvement —\nsome ideas *should* change the vision, and iteration reveals features worth adding (PROTO-0006,\nPROD-0002's caveat). The skill is discerning ideas that don't fit from ideas that reveal the\ngame should grow. And no should be *reasoned* (against the pillars), not authoritarian whim —\nthat's what keeps it legitimate.\n\n## Implementation (kept separate from the principle)\nFilter ideas through the pillars (VISION-0002) and reject what doesn't serve them, framing the\nno as \"doesn't fit *this* game.\" Keep a \"cut/later\" list so rejected-but-good ideas are honored\nwithout being built now (PROTO-0005). Distinguish \"doesn't fit\" (cut) from \"the game should\nchange\" (a vision decision, VISION-0001). Protect the core while trimming the periphery\n(PROD-0001).\n\n## Disagreement\nTight, exclusionary focus (coherence, elegance, a game that does a few things brilliantly) vs.\ninclusive, maximalist abundance (richness through many systems — DESIGN-0007's stylistic\ncounter-pole). Both produce great games; the failure modes are blandness (over-cutting the\nsoul) and incoherence (never saying no). The vision decides which the game wants.\n\n## Notes\nThe vision-side of elegance (DESIGN-0007) and cutting (PROTO-0005, PROD-0002); powered by\npillars (VISION-0002). Confidence 4.\n","searchText":"gdc-l1-vision-0003 say no to protect coherence — a game is defined by what it excludes vision saying-no coherence focus cutting > a great game is shaped as much by what it leaves out as by what it includes. good ideas arrive endlessly; the vision's job is to reject the ones that don't fit — not because they're bad, but because they don't serve this game. saying no is how coherence survives contact with a hundred good ideas. the threat to a game's coherence is rarely bad ideas — it's an abundance of good ones, each of which pulls the design a little toward a different game until it becomes an incoherent pile of features that don't harmonize [s-design-pillars]. so the discipline of exclusion is not negativity; it's authorship. pillars (vision-0002) make the no defensible and impersonal: the answer isn't \"your idea is bad,\" it's \"that doesn't fit this game,\" which protects both the vision and the relationship. this is the vision-side expression of elegance (design-0007) and kill-your-darlings (proto-0005): a focused game that does a few things brilliantly beats a diffuse one that does many things adequately, and getting there requires saying no far more often than yes. every point where ideas are proposed and decisions made — design reviews, feature requests, scope decisions. especially where the director/vision-holder is \"bombarded with ideas.\" saying no must not become reflexive rejection that starves the game of genuine improvement — some ideas should change the vision, and iteration reveals features worth adding (proto-0006, prod-0002's caveat). the skill is discerning ideas that don't fit from ideas that reveal the game should grow. and no should be reasoned (against the pillars), not authoritarian whim — that's what keeps it legitimate. filter ideas through the pillars (vision-0002) and reject what doesn't serve them, framing the no as \"doesn't fit this game.\" keep a \"cut/later\" list so rejected-but-good ideas are honored without being built now (proto-0005). distinguish \"doesn't fit\" (cut) from \"the game should change\" (a vision decision, vision-0001). protect the core while trimming the periphery (prod-0001). tight, exclusionary focus (coherence, elegance, a game that does a few things brilliantly) vs. inclusive, maximalist abundance (richness through many systems — design-0007's stylistic counter-pole). both produce great games; the failure modes are blandness (over-cutting the soul) and incoherence (never saying no). the vision decides which the game wants. the vision-side of elegance (design-0007) and cutting (proto-0005, prod-0002); powered by pillars (vision-0002). confidence 4."}
{"id":"GDC-L1-VISION-0004","title":"Give the vision an owner — coherence needs decision authority","layer":"L1","domain":"VISION","subdomain":"decision-making-authority","type":"stylistic","confidence":3,"status":"canonical","tags":["vision","authority","director","decision-making","coherence"],"related":["GDC-L1-VISION-0001","GDC-L1-TEAM-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-design-pillars"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-VISION-0004.md","statement":"Someone must own the creative vision and hold final say on ambiguous calls. When no one is accountable for coherence, design-by-committee dilutes the vision into a compromise that serves everyone's preferences and no clear experience. A vision-holder keeps the game pointing one direction — while still listening.","sections":{"Statement":"> Someone must **own** the creative vision and hold final say on ambiguous calls. When no one\n> is accountable for coherence, design-by-committee dilutes the vision into a compromise that\n> serves everyone's preferences and no clear experience. A vision-holder keeps the game\n> pointing one direction — while still listening.","Rationale":"Coherence (VISION-0001) requires that conflicting good ideas be *resolved*, not averaged, and\naveraging is what happens when authority is diffuse — every stakeholder gets a piece, and the\nresult points nowhere in particular [S-design-pillars]. A clear owner (a creative/game\ndirector) provides a single point of accountability for the whole experience, so hard calls get\nmade decisively and the game keeps its identity. Crucially, \"owner\" is not \"dictator\": the best\nvision-holders listen hard, delegate, and change their minds on evidence (DESIGN-0001,\nPLAYTEST-0004) — they own the *decision*, not every idea. The point is that *someone* is\nresponsible for coherence, so it doesn't fall through the cracks between equals.","Applies when":"Any multi-person project where creative decisions conflict — which is all of them. The larger\nand more cross-disciplinary the team, the more a clear vision-holder matters.","Does not apply / Exceptions":"This is genuinely contested (hence stylistic). Flat, highly-collaborative, and small\npeer-teams can hold a shared vision without a single boss, and some celebrated studios work\ncollectively; concentrated authority can also become an ego bottleneck or silence the team\n(harming psychological safety, TEAM-0001). The principle is that *coherence needs an owner*,\nnot that one person should dominate — and that owner can be a tight, aligned group rather than\nan individual.","Implementation (kept separate from the principle)":"Name who owns the vision and holds final say on ambiguous creative calls. Pair the authority\nwith genuine listening and safety to disagree (TEAM-0001) so it aggregates the team's insight\nrather than overriding it. Delegate freely within the pillars (VISION-0002). Use authority to\n*resolve*, not to *dictate* — decide when there's genuine ambiguity, not to win arguments.","Disagreement":"Auteur/director model (single clear vision-holder — coherence, decisiveness, identity) vs. collaborative/flat model (shared ownership — buy-in, resilience, more voices; risk of design-by-committee). Both have produced masterpieces. Typed `stylistic` because it's a real values choice.","Notes":"Where VISION meets TEAM — authority (this) must be balanced with psychological safety\n(TEAM-0001) to avoid becoming a bottleneck. Confidence 3: genuinely contested organizational\nquestion, not weak evidence."},"rawMarkdown":"---\nid: GDC-L1-VISION-0004\ntitle: Give the vision an owner — coherence needs decision authority\nlayer: L1\ndomain: VISION\nsubdomain: decision-making-authority\ntype: stylistic\nconfidence: 3\nstatus: canonical\ntags:\n  - vision\n  - authority\n  - director\n  - decision-making\n  - coherence\nrelated:\n  - GDC-L1-VISION-0001\n  - GDC-L1-TEAM-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-design-pillars\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Someone must **own** the creative vision and hold final say on ambiguous calls. When no one\n> is accountable for coherence, design-by-committee dilutes the vision into a compromise that\n> serves everyone's preferences and no clear experience. A vision-holder keeps the game\n> pointing one direction — while still listening.\n\n## Rationale\nCoherence (VISION-0001) requires that conflicting good ideas be *resolved*, not averaged, and\naveraging is what happens when authority is diffuse — every stakeholder gets a piece, and the\nresult points nowhere in particular [S-design-pillars]. A clear owner (a creative/game\ndirector) provides a single point of accountability for the whole experience, so hard calls get\nmade decisively and the game keeps its identity. Crucially, \"owner\" is not \"dictator\": the best\nvision-holders listen hard, delegate, and change their minds on evidence (DESIGN-0001,\nPLAYTEST-0004) — they own the *decision*, not every idea. The point is that *someone* is\nresponsible for coherence, so it doesn't fall through the cracks between equals.\n\n## Applies when\nAny multi-person project where creative decisions conflict — which is all of them. The larger\nand more cross-disciplinary the team, the more a clear vision-holder matters.\n\n## Does not apply / Exceptions\nThis is genuinely contested (hence stylistic). Flat, highly-collaborative, and small\npeer-teams can hold a shared vision without a single boss, and some celebrated studios work\ncollectively; concentrated authority can also become an ego bottleneck or silence the team\n(harming psychological safety, TEAM-0001). The principle is that *coherence needs an owner*,\nnot that one person should dominate — and that owner can be a tight, aligned group rather than\nan individual.\n\n## Implementation (kept separate from the principle)\nName who owns the vision and holds final say on ambiguous creative calls. Pair the authority\nwith genuine listening and safety to disagree (TEAM-0001) so it aggregates the team's insight\nrather than overriding it. Delegate freely within the pillars (VISION-0002). Use authority to\n*resolve*, not to *dictate* — decide when there's genuine ambiguity, not to win arguments.\n\n## Disagreement\nAuteur/director model (single clear vision-holder — coherence, decisiveness, identity) vs. collaborative/flat model (shared ownership — buy-in, resilience, more voices; risk of design-by-committee). Both have produced masterpieces. Typed `stylistic` because it's a real values choice.\n\n## Notes\nWhere VISION meets TEAM — authority (this) must be balanced with psychological safety\n(TEAM-0001) to avoid becoming a bottleneck. Confidence 3: genuinely contested organizational\nquestion, not weak evidence.\n","searchText":"gdc-l1-vision-0004 give the vision an owner — coherence needs decision authority vision authority director decision-making coherence > someone must own the creative vision and hold final say on ambiguous calls. when no one is accountable for coherence, design-by-committee dilutes the vision into a compromise that serves everyone's preferences and no clear experience. a vision-holder keeps the game pointing one direction — while still listening. coherence (vision-0001) requires that conflicting good ideas be resolved, not averaged, and averaging is what happens when authority is diffuse — every stakeholder gets a piece, and the result points nowhere in particular [s-design-pillars]. a clear owner (a creative/game director) provides a single point of accountability for the whole experience, so hard calls get made decisively and the game keeps its identity. crucially, \"owner\" is not \"dictator\": the best vision-holders listen hard, delegate, and change their minds on evidence (design-0001, playtest-0004) — they own the decision, not every idea. the point is that someone is responsible for coherence, so it doesn't fall through the cracks between equals. any multi-person project where creative decisions conflict — which is all of them. the larger and more cross-disciplinary the team, the more a clear vision-holder matters. this is genuinely contested (hence stylistic). flat, highly-collaborative, and small peer-teams can hold a shared vision without a single boss, and some celebrated studios work collectively; concentrated authority can also become an ego bottleneck or silence the team (harming psychological safety, team-0001). the principle is that coherence needs an owner, not that one person should dominate — and that owner can be a tight, aligned group rather than an individual. name who owns the vision and holds final say on ambiguous creative calls. pair the authority with genuine listening and safety to disagree (team-0001) so it aggregates the team's insight rather than overriding it. delegate freely within the pillars (vision-0002). use authority to resolve, not to dictate — decide when there's genuine ambiguity, not to win arguments. auteur/director model (single clear vision-holder — coherence, decisiveness, identity) vs. collaborative/flat model (shared ownership — buy-in, resilience, more voices; risk of design-by-committee). both have produced masterpieces. typed stylistic because it's a real values choice. where vision meets team — authority (this) must be balanced with psychological safety (team-0001) to avoid becoming a bottleneck. confidence 3: genuinely contested organizational question, not weak evidence."}
{"id":"GDC-L1-VISION-0005","title":"Make the vision communicable — if you can't say it simply, it isn't clear","layer":"L1","domain":"VISION","subdomain":"the-hook","type":"contextual","confidence":3,"status":"canonical","tags":["vision","communication","hook","pitch","alignment"],"related":["GDC-L1-VISION-0001","GDC-L1-UX-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-design-pillars","S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-VISION-0005.md","statement":"A vision only aligns a team if it can be communicated. Distill it to a short, sharp statement — the hook, the elevator pitch — that everyone can hold in their head. If you can't say what the game is in a sentence or two, the vision isn't yet clear enough to build from.","sections":{"Statement":"> A vision only aligns a team if it can be *communicated*. Distill it to a short, sharp\n> statement — the hook, the elevator pitch — that everyone can hold in their head. If you can't\n> say what the game is in a sentence or two, the vision isn't yet clear enough to build from.","Rationale":"A vision that lives only in the director's head, or in a fifty-page document no one internalizes,\ncan't do its job of aligning distributed decisions (VISION-0001) [S-design-pillars]. The\ndiscipline of compressing it to a hook is also a test *of* the vision: if you can't state the\ngame crisply, that usually means the concept itself is muddy, not merely under-described. A\nstrong, memorable statement of the intended experience becomes the thing every team member\ncarries and checks against, the pitch that sells the game to funders and players, and the filter\nthat makes pillars (VISION-0002) and nos (VISION-0003) legible. Clarity of expression and\nclarity of thought reinforce each other.","Applies when":"Communicating the vision to the team, to stakeholders, and to yourself as a clarity check.\nValuable from the first pitch through shipping and marketing.","Does not apply / Exceptions":"Some genuinely novel or experiential games resist one-sentence pitches, and forcing a glib hook\ncan trivialize a subtle experience — \"can't be pitched in a sentence\" is not always \"unclear\nvision\" (some art is exactly the experience of playing it). Solo devs may not need to externalize\nthe pitch. And a catchy hook is not sufficient — it must be *true* to a real, coherent vision,\nnot marketing over emptiness.","Implementation (kept separate from the principle)":"Write the game as a short hook / elevator pitch and refine it until it's sharp and true. Use it\nto onboard team members and align stakeholders. Treat difficulty compressing it as a signal to\nclarify the *concept*, not just the wording (a clarity check on VISION-0001). Pair it with the\npillars (VISION-0002) for the operational detail. Good communication here is the same discipline\nas good UX (UX-0003): make the important idea legible at a glance.","Disagreement":"Pitchable clarity (a sharp hook aligns and sells; if you can't say it, it's muddy) vs.\nirreducible experiences (some deep or novel games genuinely can't be captured in a sentence, and\ndemanding a hook can cheapen them). The tension is realest for experimental and art games; for\nmost commercial games, a clear hook is a genuine asset and a useful clarity test.","Notes":"The communication face of the vision (VISION-0001) and an application of UX-0003 (communicate the\nimportant thing clearly) to the vision itself. Confidence 3: broadly useful, but the\n\"irreducible experience\" exception is real for some games."},"rawMarkdown":"---\nid: GDC-L1-VISION-0005\ntitle: Make the vision communicable — if you can't say it simply, it isn't clear\nlayer: L1\ndomain: VISION\nsubdomain: the-hook\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - vision\n  - communication\n  - hook\n  - pitch\n  - alignment\nrelated:\n  - GDC-L1-VISION-0001\n  - GDC-L1-UX-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-design-pillars\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A vision only aligns a team if it can be *communicated*. Distill it to a short, sharp\n> statement — the hook, the elevator pitch — that everyone can hold in their head. If you can't\n> say what the game is in a sentence or two, the vision isn't yet clear enough to build from.\n\n## Rationale\nA vision that lives only in the director's head, or in a fifty-page document no one internalizes,\ncan't do its job of aligning distributed decisions (VISION-0001) [S-design-pillars]. The\ndiscipline of compressing it to a hook is also a test *of* the vision: if you can't state the\ngame crisply, that usually means the concept itself is muddy, not merely under-described. A\nstrong, memorable statement of the intended experience becomes the thing every team member\ncarries and checks against, the pitch that sells the game to funders and players, and the filter\nthat makes pillars (VISION-0002) and nos (VISION-0003) legible. Clarity of expression and\nclarity of thought reinforce each other.\n\n## Applies when\nCommunicating the vision to the team, to stakeholders, and to yourself as a clarity check.\nValuable from the first pitch through shipping and marketing.\n\n## Does not apply / Exceptions\nSome genuinely novel or experiential games resist one-sentence pitches, and forcing a glib hook\ncan trivialize a subtle experience — \"can't be pitched in a sentence\" is not always \"unclear\nvision\" (some art is exactly the experience of playing it). Solo devs may not need to externalize\nthe pitch. And a catchy hook is not sufficient — it must be *true* to a real, coherent vision,\nnot marketing over emptiness.\n\n## Implementation (kept separate from the principle)\nWrite the game as a short hook / elevator pitch and refine it until it's sharp and true. Use it\nto onboard team members and align stakeholders. Treat difficulty compressing it as a signal to\nclarify the *concept*, not just the wording (a clarity check on VISION-0001). Pair it with the\npillars (VISION-0002) for the operational detail. Good communication here is the same discipline\nas good UX (UX-0003): make the important idea legible at a glance.\n\n## Disagreement\nPitchable clarity (a sharp hook aligns and sells; if you can't say it, it's muddy) vs.\nirreducible experiences (some deep or novel games genuinely can't be captured in a sentence, and\ndemanding a hook can cheapen them). The tension is realest for experimental and art games; for\nmost commercial games, a clear hook is a genuine asset and a useful clarity test.\n\n## Notes\nThe communication face of the vision (VISION-0001) and an application of UX-0003 (communicate the\nimportant thing clearly) to the vision itself. Confidence 3: broadly useful, but the\n\"irreducible experience\" exception is real for some games.\n","searchText":"gdc-l1-vision-0005 make the vision communicable — if you can't say it simply, it isn't clear vision communication hook pitch alignment > a vision only aligns a team if it can be communicated. distill it to a short, sharp statement — the hook, the elevator pitch — that everyone can hold in their head. if you can't say what the game is in a sentence or two, the vision isn't yet clear enough to build from. a vision that lives only in the director's head, or in a fifty-page document no one internalizes, can't do its job of aligning distributed decisions (vision-0001) [s-design-pillars]. the discipline of compressing it to a hook is also a test of the vision: if you can't state the game crisply, that usually means the concept itself is muddy, not merely under-described. a strong, memorable statement of the intended experience becomes the thing every team member carries and checks against, the pitch that sells the game to funders and players, and the filter that makes pillars (vision-0002) and nos (vision-0003) legible. clarity of expression and clarity of thought reinforce each other. communicating the vision to the team, to stakeholders, and to yourself as a clarity check. valuable from the first pitch through shipping and marketing. some genuinely novel or experiential games resist one-sentence pitches, and forcing a glib hook can trivialize a subtle experience — \"can't be pitched in a sentence\" is not always \"unclear vision\" (some art is exactly the experience of playing it). solo devs may not need to externalize the pitch. and a catchy hook is not sufficient — it must be true to a real, coherent vision, not marketing over emptiness. write the game as a short hook / elevator pitch and refine it until it's sharp and true. use it to onboard team members and align stakeholders. treat difficulty compressing it as a signal to clarify the concept, not just the wording (a clarity check on vision-0001). pair it with the pillars (vision-0002) for the operational detail. good communication here is the same discipline as good ux (ux-0003): make the important idea legible at a glance. pitchable clarity (a sharp hook aligns and sells; if you can't say it, it's muddy) vs. irreducible experiences (some deep or novel games genuinely can't be captured in a sentence, and demanding a hook can cheapen them). the tension is realest for experimental and art games; for most commercial games, a clear hook is a genuine asset and a useful clarity test. the communication face of the vision (vision-0001) and an application of ux-0003 (communicate the important thing clearly) to the vision itself. confidence 3: broadly useful, but the \"irreducible experience\" exception is real for some games."}
{"id":"GDC-L1-TEAM-0001","title":"Psychological safety is the foundation of good teamwork","layer":"L1","domain":"TEAM","subdomain":"psychological-safety","type":"contextual","confidence":4,"status":"canonical","tags":["team","psychological-safety","culture","collaboration"],"related":["GDC-L1-TEAM-0002","GDC-L1-TEAM-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-edmondson-psych-safety"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-TEAM-0001.md","statement":"Teams do their best work when members feel safe to speak up, disagree, ask \"obvious\" questions, admit mistakes, and take interpersonal risks without fear of humiliation or punishment. Psychological safety — the shared belief that the team is safe for that risk — is a foundational condition for effective teamwork. Protect it deliberately.","sections":{"Statement":"> Teams do their best work when members feel safe to speak up, disagree, ask \"obvious\"\n> questions, admit mistakes, and take interpersonal risks without fear of humiliation or\n> punishment. **Psychological safety** — the shared belief that the team is safe for that risk\n> — is a foundational condition for effective teamwork. Protect it deliberately.","Rationale":"Google's Project Aristotle ranked psychological safety first among five internal dynamics it\nassociated with effective teams, building on Amy Edmondson's research into learning behavior\n[S-edmondson-psych-safety]. The mechanism is direct: making games well depends on people\nsurfacing problems early, challenging bad ideas, admitting when they're stuck, and proposing\nrisky creative bets — and *all* of that requires feeling safe to do it. In an unsafe team,\npeople hide mistakes (which then compound), stay quiet about problems they see, defer to the\nloudest voice, and avoid the creative risks that good games need. Safety isn't softness; it's\nthe precondition for the honest disagreement and fast failure that quality actually requires.","Applies when":"Every team, at every scale — and especially any team doing creative, uncertain work where\nspeaking up, disagreeing, and failing are part of the job (i.e. all game development).","Does not apply / Exceptions":"Psychological safety is not the absence of standards or accountability — it's what lets high\nstandards be *pursued honestly* (you can admit a miss and fix it) rather than hidden. It is also\nnot \"no conflict\"; healthy teams disagree vigorously *because* it's safe to. The failure mode to\navoid is confusing safety with comfort or with never being challenged — safety enables challenge,\nit doesn't forbid it.","Implementation (kept separate from the principle)":"Leaders model fallibility (admit their own mistakes and unknowns), invite dissent explicitly, and respond to bad news with curiosity rather than blame (TEAM-0003). Create deliberate opportunities for quieter voices to contribute. Separate critique of the work from the person (TEAM-0002).","Disagreement":"Little serious dissent that psychological safety helps; the nuance is guarding against its\n*misreading* as low standards or conflict-avoidance. High-performing cultures pair high safety\nwith high standards — safety to speak, rigor about the work.","Notes":"Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-TEAM-0001\ntitle: Psychological safety is the foundation of good teamwork\nlayer: L1\ndomain: TEAM\nsubdomain: psychological-safety\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - team\n  - psychological-safety\n  - culture\n  - collaboration\nrelated:\n  - GDC-L1-TEAM-0002\n  - GDC-L1-TEAM-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-edmondson-psych-safety\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Teams do their best work when members feel safe to speak up, disagree, ask \"obvious\"\n> questions, admit mistakes, and take interpersonal risks without fear of humiliation or\n> punishment. **Psychological safety** — the shared belief that the team is safe for that risk\n> — is a foundational condition for effective teamwork. Protect it deliberately.\n\n## Rationale\nGoogle's Project Aristotle ranked psychological safety first among five internal dynamics it\nassociated with effective teams, building on Amy Edmondson's research into learning behavior\n[S-edmondson-psych-safety]. The mechanism is direct: making games well depends on people\nsurfacing problems early, challenging bad ideas, admitting when they're stuck, and proposing\nrisky creative bets — and *all* of that requires feeling safe to do it. In an unsafe team,\npeople hide mistakes (which then compound), stay quiet about problems they see, defer to the\nloudest voice, and avoid the creative risks that good games need. Safety isn't softness; it's\nthe precondition for the honest disagreement and fast failure that quality actually requires.\n\n## Applies when\nEvery team, at every scale — and especially any team doing creative, uncertain work where\nspeaking up, disagreeing, and failing are part of the job (i.e. all game development).\n\n## Does not apply / Exceptions\nPsychological safety is not the absence of standards or accountability — it's what lets high\nstandards be *pursued honestly* (you can admit a miss and fix it) rather than hidden. It is also\nnot \"no conflict\"; healthy teams disagree vigorously *because* it's safe to. The failure mode to\navoid is confusing safety with comfort or with never being challenged — safety enables challenge,\nit doesn't forbid it.\n\n## Implementation (kept separate from the principle)\nLeaders model fallibility (admit their own mistakes and unknowns), invite dissent explicitly, and respond to bad news with curiosity rather than blame (TEAM-0003). Create deliberate opportunities for quieter voices to contribute. Separate critique of the work from the person (TEAM-0002).\n\n## Disagreement\nLittle serious dissent that psychological safety helps; the nuance is guarding against its\n*misreading* as low standards or conflict-avoidance. High-performing cultures pair high safety\nwith high standards — safety to speak, rigor about the work.\n\n## Notes\nConfidence 4.\n","searchText":"gdc-l1-team-0001 psychological safety is the foundation of good teamwork team psychological-safety culture collaboration > teams do their best work when members feel safe to speak up, disagree, ask \"obvious\" questions, admit mistakes, and take interpersonal risks without fear of humiliation or punishment. psychological safety — the shared belief that the team is safe for that risk — is a foundational condition for effective teamwork. protect it deliberately. google's project aristotle ranked psychological safety first among five internal dynamics it associated with effective teams, building on amy edmondson's research into learning behavior [s-edmondson-psych-safety]. the mechanism is direct: making games well depends on people surfacing problems early, challenging bad ideas, admitting when they're stuck, and proposing risky creative bets — and all of that requires feeling safe to do it. in an unsafe team, people hide mistakes (which then compound), stay quiet about problems they see, defer to the loudest voice, and avoid the creative risks that good games need. safety isn't softness; it's the precondition for the honest disagreement and fast failure that quality actually requires. every team, at every scale — and especially any team doing creative, uncertain work where speaking up, disagreeing, and failing are part of the job (i.e. all game development). psychological safety is not the absence of standards or accountability — it's what lets high standards be pursued honestly (you can admit a miss and fix it) rather than hidden. it is also not \"no conflict\"; healthy teams disagree vigorously because it's safe to. the failure mode to avoid is confusing safety with comfort or with never being challenged — safety enables challenge, it doesn't forbid it. leaders model fallibility (admit their own mistakes and unknowns), invite dissent explicitly, and respond to bad news with curiosity rather than blame (team-0003). create deliberate opportunities for quieter voices to contribute. separate critique of the work from the person (team-0002). little serious dissent that psychological safety helps; the nuance is guarding against its misreading as low standards or conflict-avoidance. high-performing cultures pair high safety with high standards — safety to speak, rigor about the work. confidence 4."}
{"id":"GDC-L1-TEAM-0002","title":"Critique the work, not the person","layer":"L1","domain":"TEAM","subdomain":"feedback-culture","type":"contextual","confidence":4,"status":"canonical","tags":["team","feedback","critique","egoless","culture"],"related":["GDC-L1-TEAM-0001","GDC-L1-PROTO-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-edmondson-psych-safety"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-TEAM-0002.md","statement":"Separate the idea from the person who had it. Honest, direct critique of the work is how it gets better; attacks on the person shut down the safety that makes critique possible. Give and receive feedback about the thing, not the maker — and hold your own ideas loosely enough to let them be cut.","sections":{"Statement":"> Separate the idea from the person who had it. Honest, direct critique of *the work* is how it\n> gets better; attacks on *the person* shut down the safety that makes critique possible. Give\n> and receive feedback about the thing, not the maker — and hold your own ideas loosely enough\n> to let them be cut.","Rationale":"A team improves its work through candid evaluation, but candor only survives if it's aimed at the\nwork rather than the worker: \"this mechanic is confusing\" invites improvement, while \"you're a\nbad designer\" invites defensiveness and silence [S-edmondson-psych-safety]. Keeping critique\negoless protects psychological safety (TEAM-0001) *and* the quality of the feedback — people can\nhear hard truths about their work when their standing isn't under attack, and they can *give*\nhard truths when doing so isn't read as a personal assault. It also requires the receiving side:\nholding your ideas loosely (not fusing your identity to them) is what lets you kill your own\ndarlings (PROTO-0005) and take feedback as help rather than threat. The goal is a team that can\nbe ruthless about the work precisely *because* it's kind to the people.","Applies when":"Every review, critique, playtest debrief, and design debate — any moment feedback is exchanged.","Does not apply / Exceptions":"Sometimes feedback *is* rightly about a person's behavior or growth (a pattern of missed commitments, a skill to develop) — but that's a direct, private, growth-framed conversation, not public critique disguised as work-feedback. Kind to people, rigorous about the work — not the reverse.","Implementation (kept separate from the principle)":"Frame feedback about the artifact and its effect (\"this reads as X\", \"players got lost here\"), not the author's character. Critique your *own* work in the same egoless terms to model it. Build rituals (design reviews, playtest debriefs) where critiquing the work is normal and expected. Separate identity from idea so cutting a feature (PROTO-0005) isn't experienced as a personal loss.","Disagreement":"Little on the principle; the nuance is calibrating *directness* — some cultures prize blunt\ncandor, others gentler framing, and individuals differ. The invariant is target-the-work; the\ntone is a cultural and personal variable.","Notes":"Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-TEAM-0002\ntitle: Critique the work, not the person\nlayer: L1\ndomain: TEAM\nsubdomain: feedback-culture\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - team\n  - feedback\n  - critique\n  - egoless\n  - culture\nrelated:\n  - GDC-L1-TEAM-0001\n  - GDC-L1-PROTO-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-edmondson-psych-safety\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Separate the idea from the person who had it. Honest, direct critique of *the work* is how it\n> gets better; attacks on *the person* shut down the safety that makes critique possible. Give\n> and receive feedback about the thing, not the maker — and hold your own ideas loosely enough\n> to let them be cut.\n\n## Rationale\nA team improves its work through candid evaluation, but candor only survives if it's aimed at the\nwork rather than the worker: \"this mechanic is confusing\" invites improvement, while \"you're a\nbad designer\" invites defensiveness and silence [S-edmondson-psych-safety]. Keeping critique\negoless protects psychological safety (TEAM-0001) *and* the quality of the feedback — people can\nhear hard truths about their work when their standing isn't under attack, and they can *give*\nhard truths when doing so isn't read as a personal assault. It also requires the receiving side:\nholding your ideas loosely (not fusing your identity to them) is what lets you kill your own\ndarlings (PROTO-0005) and take feedback as help rather than threat. The goal is a team that can\nbe ruthless about the work precisely *because* it's kind to the people.\n\n## Applies when\nEvery review, critique, playtest debrief, and design debate — any moment feedback is exchanged.\n\n## Does not apply / Exceptions\nSometimes feedback *is* rightly about a person's behavior or growth (a pattern of missed commitments, a skill to develop) — but that's a direct, private, growth-framed conversation, not public critique disguised as work-feedback. Kind to people, rigorous about the work — not the reverse.\n\n## Implementation (kept separate from the principle)\nFrame feedback about the artifact and its effect (\"this reads as X\", \"players got lost here\"), not the author's character. Critique your *own* work in the same egoless terms to model it. Build rituals (design reviews, playtest debriefs) where critiquing the work is normal and expected. Separate identity from idea so cutting a feature (PROTO-0005) isn't experienced as a personal loss.\n\n## Disagreement\nLittle on the principle; the nuance is calibrating *directness* — some cultures prize blunt\ncandor, others gentler framing, and individuals differ. The invariant is target-the-work; the\ntone is a cultural and personal variable.\n\n## Notes\nConfidence 4.\n","searchText":"gdc-l1-team-0002 critique the work, not the person team feedback critique egoless culture > separate the idea from the person who had it. honest, direct critique of the work is how it gets better; attacks on the person shut down the safety that makes critique possible. give and receive feedback about the thing, not the maker — and hold your own ideas loosely enough to let them be cut. a team improves its work through candid evaluation, but candor only survives if it's aimed at the work rather than the worker: \"this mechanic is confusing\" invites improvement, while \"you're a bad designer\" invites defensiveness and silence [s-edmondson-psych-safety]. keeping critique egoless protects psychological safety (team-0001) and the quality of the feedback — people can hear hard truths about their work when their standing isn't under attack, and they can give hard truths when doing so isn't read as a personal assault. it also requires the receiving side: holding your ideas loosely (not fusing your identity to them) is what lets you kill your own darlings (proto-0005) and take feedback as help rather than threat. the goal is a team that can be ruthless about the work precisely because it's kind to the people. every review, critique, playtest debrief, and design debate — any moment feedback is exchanged. sometimes feedback is rightly about a person's behavior or growth (a pattern of missed commitments, a skill to develop) — but that's a direct, private, growth-framed conversation, not public critique disguised as work-feedback. kind to people, rigorous about the work — not the reverse. frame feedback about the artifact and its effect (\"this reads as x\", \"players got lost here\"), not the author's character. critique your own work in the same egoless terms to model it. build rituals (design reviews, playtest debriefs) where critiquing the work is normal and expected. separate identity from idea so cutting a feature (proto-0005) isn't experienced as a personal loss. little on the principle; the nuance is calibrating directness — some cultures prize blunt candor, others gentler framing, and individuals differ. the invariant is target-the-work; the tone is a cultural and personal variable. confidence 4."}
{"id":"GDC-L1-TEAM-0003","title":"Run blameless postmortems — treat failure as a system to fix","layer":"L1","domain":"TEAM","subdomain":"conflict","type":"contextual","confidence":4,"status":"canonical","tags":["team","postmortem","blameless","learning","culture"],"related":["GDC-L1-TEAM-0001","GDC-L1-DESIGN-0001","GDC-L1-PLAYTEST-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-google-sre-postmortem"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-TEAM-0003.md","statement":"When something goes wrong, focus on understanding the contributing causes and improving the system, not on assigning fault. Blameless postmortems surface the real, fixable causes because people can be honest; blame drives problems underground, where they repeat.","sections":{"Statement":"> When something goes wrong, focus on understanding the *contributing causes* and improving the\n> *system*, not on assigning fault. **Blameless postmortems** surface the real, fixable causes\n> because people can be honest; blame drives problems underground, where they repeat.","Rationale":"Most failures are produced by systems and circumstances, not villains, and the fastest way to\n*hide* a failure's true causes is to punish the person nearest to it [S-google-sre-postmortem].\nWhen blame is the response, people conceal mistakes, omit the awkward details, and defend\nthemselves instead of explaining what actually happened — so the organization never learns, and\nthe same failure recurs. A blameless stance flips this: by treating an incident as a\nlearning opportunity about the system (\"what let this happen, and how do we make it not happen\nagain?\"), you get the honesty required to actually fix root causes. It's the team-process form of\nthe same commitment that runs through the whole constitution — learn from what *actually\nhappened* (DESIGN-0001, PLAYTEST-0001), not from what should have.","Applies when":"After any significant failure, incident, bug, missed milestone, or bad launch — and as a standing\ncultural default for how the team responds to things going wrong.","Does not apply / Exceptions":"Blameless is about *learning*, not the absence of accountability — repeated negligence or bad-faith\nbehavior is a real management issue, handled directly and (usually) privately. And blameless does\nnot mean consequence-free for the *system*: the point is to change the process so the failure\ncan't recur. The invariant is: attack the cause, not the person, so the truth comes out.","Implementation (kept separate from the principle)":"After a failure, ask \"what contributing causes let this happen?\" rather than \"whose fault was\nit?\" Write it down and change the system (process, tooling, checks) so it can't recur. Make it\nsafe to report problems early (TEAM-0001) by responding to bad news with curiosity, not\npunishment. Separate the incident-learning from any genuine personnel issue (handle the latter\ndirectly and privately, TEAM-0002).","Disagreement":"Little serious dissent in modern practice; the tension is only the misread that \"blameless\" means\n\"no accountability.\" Healthy cultures keep accountability for *behavior* while keeping the\n*learning* process blameless — the two aren't in conflict.","Notes":"The failure-learning practice built on psychological safety (TEAM-0001); the team-process echo of\n\"judge by what actually happened\" (DESIGN-0001, PLAYTEST-0001). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-TEAM-0003\ntitle: Run blameless postmortems — treat failure as a system to fix\nlayer: L1\ndomain: TEAM\nsubdomain: conflict\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - team\n  - postmortem\n  - blameless\n  - learning\n  - culture\nrelated:\n  - GDC-L1-TEAM-0001\n  - GDC-L1-DESIGN-0001\n  - GDC-L1-PLAYTEST-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-google-sre-postmortem\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> When something goes wrong, focus on understanding the *contributing causes* and improving the\n> *system*, not on assigning fault. **Blameless postmortems** surface the real, fixable causes\n> because people can be honest; blame drives problems underground, where they repeat.\n\n## Rationale\nMost failures are produced by systems and circumstances, not villains, and the fastest way to\n*hide* a failure's true causes is to punish the person nearest to it [S-google-sre-postmortem].\nWhen blame is the response, people conceal mistakes, omit the awkward details, and defend\nthemselves instead of explaining what actually happened — so the organization never learns, and\nthe same failure recurs. A blameless stance flips this: by treating an incident as a\nlearning opportunity about the system (\"what let this happen, and how do we make it not happen\nagain?\"), you get the honesty required to actually fix root causes. It's the team-process form of\nthe same commitment that runs through the whole constitution — learn from what *actually\nhappened* (DESIGN-0001, PLAYTEST-0001), not from what should have.\n\n## Applies when\nAfter any significant failure, incident, bug, missed milestone, or bad launch — and as a standing\ncultural default for how the team responds to things going wrong.\n\n## Does not apply / Exceptions\nBlameless is about *learning*, not the absence of accountability — repeated negligence or bad-faith\nbehavior is a real management issue, handled directly and (usually) privately. And blameless does\nnot mean consequence-free for the *system*: the point is to change the process so the failure\ncan't recur. The invariant is: attack the cause, not the person, so the truth comes out.\n\n## Implementation (kept separate from the principle)\nAfter a failure, ask \"what contributing causes let this happen?\" rather than \"whose fault was\nit?\" Write it down and change the system (process, tooling, checks) so it can't recur. Make it\nsafe to report problems early (TEAM-0001) by responding to bad news with curiosity, not\npunishment. Separate the incident-learning from any genuine personnel issue (handle the latter\ndirectly and privately, TEAM-0002).\n\n## Disagreement\nLittle serious dissent in modern practice; the tension is only the misread that \"blameless\" means\n\"no accountability.\" Healthy cultures keep accountability for *behavior* while keeping the\n*learning* process blameless — the two aren't in conflict.\n\n## Notes\nThe failure-learning practice built on psychological safety (TEAM-0001); the team-process echo of\n\"judge by what actually happened\" (DESIGN-0001, PLAYTEST-0001). Confidence 4.\n","searchText":"gdc-l1-team-0003 run blameless postmortems — treat failure as a system to fix team postmortem blameless learning culture > when something goes wrong, focus on understanding the contributing causes and improving the system, not on assigning fault. blameless postmortems surface the real, fixable causes because people can be honest; blame drives problems underground, where they repeat. most failures are produced by systems and circumstances, not villains, and the fastest way to hide a failure's true causes is to punish the person nearest to it [s-google-sre-postmortem]. when blame is the response, people conceal mistakes, omit the awkward details, and defend themselves instead of explaining what actually happened — so the organization never learns, and the same failure recurs. a blameless stance flips this: by treating an incident as a learning opportunity about the system (\"what let this happen, and how do we make it not happen again?\"), you get the honesty required to actually fix root causes. it's the team-process form of the same commitment that runs through the whole constitution — learn from what actually happened (design-0001, playtest-0001), not from what should have. after any significant failure, incident, bug, missed milestone, or bad launch — and as a standing cultural default for how the team responds to things going wrong. blameless is about learning, not the absence of accountability — repeated negligence or bad-faith behavior is a real management issue, handled directly and (usually) privately. and blameless does not mean consequence-free for the system: the point is to change the process so the failure can't recur. the invariant is: attack the cause, not the person, so the truth comes out. after a failure, ask \"what contributing causes let this happen?\" rather than \"whose fault was it?\" write it down and change the system (process, tooling, checks) so it can't recur. make it safe to report problems early (team-0001) by responding to bad news with curiosity, not punishment. separate the incident-learning from any genuine personnel issue (handle the latter directly and privately, team-0002). little serious dissent in modern practice; the tension is only the misread that \"blameless\" means \"no accountability.\" healthy cultures keep accountability for behavior while keeping the learning process blameless — the two aren't in conflict. the failure-learning practice built on psychological safety (team-0001); the team-process echo of \"judge by what actually happened\" (design-0001, playtest-0001). confidence 4."}
{"id":"GDC-L1-TEAM-0004","title":"Make decisions shared, visible, and durable","layer":"L1","domain":"TEAM","subdomain":"communication","type":"contextual","confidence":4,"status":"canonical","tags":["team","communication","documentation","alignment","decisions"],"related":["GDC-L1-VISION-0001","GDC-L1-TEAM-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-schell-artofgamedesign"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-TEAM-0004.md","statement":"A team can only align on decisions it can see and remember. Record settled decisions where everyone can find them, and make the reasoning visible — shared understanding, not private knowledge, is what keeps a distributed effort coherent. Undocumented decisions are lost decisions.","sections":{"Statement":"> A team can only align on decisions it can *see* and *remember*. Record settled decisions where\n> everyone can find them, and make the reasoning visible — shared understanding, not private\n> knowledge, is what keeps a distributed effort coherent. Undocumented decisions are lost\n> decisions.","Rationale":"Coherence (VISION-0001) is a property of shared understanding, and understanding that lives only\nin one person's head or in a hallway conversation doesn't scale past that moment\n[S-schell-artofgamedesign]. Decisions get re-litigated, contradicted, or silently forgotten;\nnew members and future-you can't reconstruct *why* something is the way it is; and the same\ndebates recur. Making decisions visible and durable — written down, findable, with their\nreasoning — turns the team's accumulated choices into a shared, persistent memory that keeps\neveryone building the same game. It also enables honest disagreement to *resolve* rather than\nrecur, because a settled decision is recorded rather than perpetually reopened. (This\nconstitution — and its `STATUS.md` session tracker — is itself an instance of the principle.)","Applies when":"Any team with more than a couple of people, any project spanning enough time that people forget,\nand especially distributed, async, or long-lived efforts. The larger and longer, the more it\nmatters.","Does not apply / Exceptions":"Over-documentation is a real cost — a team can drown in process and write docs no one reads, which\nis its own failure. The bar is *decisions and their reasoning*, not every detail; capture what\nfuture-you and new members genuinely need. Very small, co-located teams can hold much in shared\nconversation, though even they drift without some durable record.","Implementation (kept separate from the principle)":"Record settled decisions and *why* somewhere findable (a design doc, a decision log, a tracker). Make the reasoning visible, not just the conclusion. Keep it lightweight enough that it's actually maintained. Revisit and update as decisions change — a stale record misleads.","Disagreement":"Documentation-heavy (durable, scalable, but risks process bloat and unread docs) vs. lightweight/\nconversational (fast, low-overhead, but forgetful and hard to scale). The balance depends on team\nsize, distribution, and project length — more of both as those grow.","Notes":"Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-TEAM-0004\ntitle: Make decisions shared, visible, and durable\nlayer: L1\ndomain: TEAM\nsubdomain: communication\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - team\n  - communication\n  - documentation\n  - alignment\n  - decisions\nrelated:\n  - GDC-L1-VISION-0001\n  - GDC-L1-TEAM-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-schell-artofgamedesign\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A team can only align on decisions it can *see* and *remember*. Record settled decisions where\n> everyone can find them, and make the reasoning visible — shared understanding, not private\n> knowledge, is what keeps a distributed effort coherent. Undocumented decisions are lost\n> decisions.\n\n## Rationale\nCoherence (VISION-0001) is a property of shared understanding, and understanding that lives only\nin one person's head or in a hallway conversation doesn't scale past that moment\n[S-schell-artofgamedesign]. Decisions get re-litigated, contradicted, or silently forgotten;\nnew members and future-you can't reconstruct *why* something is the way it is; and the same\ndebates recur. Making decisions visible and durable — written down, findable, with their\nreasoning — turns the team's accumulated choices into a shared, persistent memory that keeps\neveryone building the same game. It also enables honest disagreement to *resolve* rather than\nrecur, because a settled decision is recorded rather than perpetually reopened. (This\nconstitution — and its `STATUS.md` session tracker — is itself an instance of the principle.)\n\n## Applies when\nAny team with more than a couple of people, any project spanning enough time that people forget,\nand especially distributed, async, or long-lived efforts. The larger and longer, the more it\nmatters.\n\n## Does not apply / Exceptions\nOver-documentation is a real cost — a team can drown in process and write docs no one reads, which\nis its own failure. The bar is *decisions and their reasoning*, not every detail; capture what\nfuture-you and new members genuinely need. Very small, co-located teams can hold much in shared\nconversation, though even they drift without some durable record.\n\n## Implementation (kept separate from the principle)\nRecord settled decisions and *why* somewhere findable (a design doc, a decision log, a tracker). Make the reasoning visible, not just the conclusion. Keep it lightweight enough that it's actually maintained. Revisit and update as decisions change — a stale record misleads.\n\n## Disagreement\nDocumentation-heavy (durable, scalable, but risks process bloat and unread docs) vs. lightweight/\nconversational (fast, low-overhead, but forgetful and hard to scale). The balance depends on team\nsize, distribution, and project length — more of both as those grow.\n\n## Notes\nConfidence 4.\n","searchText":"gdc-l1-team-0004 make decisions shared, visible, and durable team communication documentation alignment decisions > a team can only align on decisions it can see and remember. record settled decisions where everyone can find them, and make the reasoning visible — shared understanding, not private knowledge, is what keeps a distributed effort coherent. undocumented decisions are lost decisions. coherence (vision-0001) is a property of shared understanding, and understanding that lives only in one person's head or in a hallway conversation doesn't scale past that moment [s-schell-artofgamedesign]. decisions get re-litigated, contradicted, or silently forgotten; new members and future-you can't reconstruct why something is the way it is; and the same debates recur. making decisions visible and durable — written down, findable, with their reasoning — turns the team's accumulated choices into a shared, persistent memory that keeps everyone building the same game. it also enables honest disagreement to resolve rather than recur, because a settled decision is recorded rather than perpetually reopened. (this constitution — and its status.md session tracker — is itself an instance of the principle.) any team with more than a couple of people, any project spanning enough time that people forget, and especially distributed, async, or long-lived efforts. the larger and longer, the more it matters. over-documentation is a real cost — a team can drown in process and write docs no one reads, which is its own failure. the bar is decisions and their reasoning, not every detail; capture what future-you and new members genuinely need. very small, co-located teams can hold much in shared conversation, though even they drift without some durable record. record settled decisions and why somewhere findable (a design doc, a decision log, a tracker). make the reasoning visible, not just the conclusion. keep it lightweight enough that it's actually maintained. revisit and update as decisions change — a stale record misleads. documentation-heavy (durable, scalable, but risks process bloat and unread docs) vs. lightweight/ conversational (fast, low-overhead, but forgetful and hard to scale). the balance depends on team size, distribution, and project length — more of both as those grow. confidence 4."}
{"id":"GDC-L1-TEAM-0005","title":"Prefer small, empowered, cross-disciplinary teams","layer":"L1","domain":"TEAM","subdomain":"collaboration","type":"stylistic","confidence":3,"status":"canonical","tags":["team","small-teams","autonomy","cross-discipline","communication-cost"],"related":["GDC-L1-TEAM-0001","GDC-L1-PROD-0001"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-edmondson-psych-safety"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-TEAM-0005.md","statement":"Small teams with autonomy and mixed disciplines tend to move faster and stay more coherent than large, siloed, permission-gated ones. Communication cost grows with team size; empowerment and cross-discipline collaboration keep decisions close to the work and the vision easy to share.","sections":{"Statement":"> Small teams with autonomy and mixed disciplines tend to move faster and stay more coherent than\n> large, siloed, permission-gated ones. Communication cost grows with team size; empowerment and\n> cross-discipline collaboration keep decisions close to the work and the vision easy to share.","Rationale":"The number of communication links in a team grows combinatorially with its size, so every added\nperson raises coordination overhead and dilutes shared context — which is why small teams can\nhold a vision (VISION-0001) in common almost effortlessly while large ones need heavy process to\napproximate it. Autonomy compounds the benefit: when a small team can decide and act without\ngatekeeping, decisions stay close to the people doing the work and the feedback loop tightens.\nCross-discipline collaboration (designers, artists, engineers working *together* rather than\nhanding off over walls) surfaces problems and opportunities that siloed pipelines miss. None of\nthis makes big teams *wrong* — they're necessary for large-scope games — but it explains why small,\nempowered, mixed teams punch above their weight and why scaling a team has real costs, not just\nbenefits.","Applies when":"Team structure and org decisions, and the recurring \"should we add people?\" question (recall that\nadding people to a late project often *slows* it — PROD's staffing caution). Especially relevant\nto indie and small-studio contexts.","Does not apply / Exceptions":"Large-scope games (big-budget AAA) genuinely require large teams, and at scale you *need*\nstructure, specialization, and process that a small team can skip — so this is a preference, not a\nlaw (hence stylistic). Deep specialization also has real value that pure generalist small teams\nlack. The principle is \"keep teams as small and empowered as the scope allows,\" not \"small is\nalways better regardless of scope.\"","Implementation (kept separate from the principle)":"Keep teams as small as the scope permits; resist adding people as a reflex (scope down instead, PROD-0001). Grant autonomy — decisions close to the work. Compose teams cross-functionally so disciplines collaborate rather than hand off.","Disagreement":"Small-and-autonomous (speed, coherence, low overhead, but limited capacity and depth) vs.\nlarge-and-specialized (scale, deep expertise, but coordination cost and diluted context). The\nright structure follows the scope; the failure modes are under-capacity (too small for the\nambition) and coordination-collapse (too big without structure). Typed stylistic as a genuine\norg-design values choice.","Notes":"Confidence 3: a real preference, genuinely bounded by project scope."},"rawMarkdown":"---\nid: GDC-L1-TEAM-0005\ntitle: Prefer small, empowered, cross-disciplinary teams\nlayer: L1\ndomain: TEAM\nsubdomain: collaboration\ntype: stylistic\nconfidence: 3\nstatus: canonical\ntags:\n  - team\n  - small-teams\n  - autonomy\n  - cross-discipline\n  - communication-cost\nrelated:\n  - GDC-L1-TEAM-0001\n  - GDC-L1-PROD-0001\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-edmondson-psych-safety\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Small teams with autonomy and mixed disciplines tend to move faster and stay more coherent than\n> large, siloed, permission-gated ones. Communication cost grows with team size; empowerment and\n> cross-discipline collaboration keep decisions close to the work and the vision easy to share.\n\n## Rationale\nThe number of communication links in a team grows combinatorially with its size, so every added\nperson raises coordination overhead and dilutes shared context — which is why small teams can\nhold a vision (VISION-0001) in common almost effortlessly while large ones need heavy process to\napproximate it. Autonomy compounds the benefit: when a small team can decide and act without\ngatekeeping, decisions stay close to the people doing the work and the feedback loop tightens.\nCross-discipline collaboration (designers, artists, engineers working *together* rather than\nhanding off over walls) surfaces problems and opportunities that siloed pipelines miss. None of\nthis makes big teams *wrong* — they're necessary for large-scope games — but it explains why small,\nempowered, mixed teams punch above their weight and why scaling a team has real costs, not just\nbenefits.\n\n## Applies when\nTeam structure and org decisions, and the recurring \"should we add people?\" question (recall that\nadding people to a late project often *slows* it — PROD's staffing caution). Especially relevant\nto indie and small-studio contexts.\n\n## Does not apply / Exceptions\nLarge-scope games (big-budget AAA) genuinely require large teams, and at scale you *need*\nstructure, specialization, and process that a small team can skip — so this is a preference, not a\nlaw (hence stylistic). Deep specialization also has real value that pure generalist small teams\nlack. The principle is \"keep teams as small and empowered as the scope allows,\" not \"small is\nalways better regardless of scope.\"\n\n## Implementation (kept separate from the principle)\nKeep teams as small as the scope permits; resist adding people as a reflex (scope down instead, PROD-0001). Grant autonomy — decisions close to the work. Compose teams cross-functionally so disciplines collaborate rather than hand off.\n\n## Disagreement\nSmall-and-autonomous (speed, coherence, low overhead, but limited capacity and depth) vs.\nlarge-and-specialized (scale, deep expertise, but coordination cost and diluted context). The\nright structure follows the scope; the failure modes are under-capacity (too small for the\nambition) and coordination-collapse (too big without structure). Typed stylistic as a genuine\norg-design values choice.\n\n## Notes\nConfidence 3: a real preference, genuinely bounded by project scope.\n","searchText":"gdc-l1-team-0005 prefer small, empowered, cross-disciplinary teams team small-teams autonomy cross-discipline communication-cost > small teams with autonomy and mixed disciplines tend to move faster and stay more coherent than large, siloed, permission-gated ones. communication cost grows with team size; empowerment and cross-discipline collaboration keep decisions close to the work and the vision easy to share. the number of communication links in a team grows combinatorially with its size, so every added person raises coordination overhead and dilutes shared context — which is why small teams can hold a vision (vision-0001) in common almost effortlessly while large ones need heavy process to approximate it. autonomy compounds the benefit: when a small team can decide and act without gatekeeping, decisions stay close to the people doing the work and the feedback loop tightens. cross-discipline collaboration (designers, artists, engineers working together rather than handing off over walls) surfaces problems and opportunities that siloed pipelines miss. none of this makes big teams wrong — they're necessary for large-scope games — but it explains why small, empowered, mixed teams punch above their weight and why scaling a team has real costs, not just benefits. team structure and org decisions, and the recurring \"should we add people?\" question (recall that adding people to a late project often slows it — prod's staffing caution). especially relevant to indie and small-studio contexts. large-scope games (big-budget aaa) genuinely require large teams, and at scale you need structure, specialization, and process that a small team can skip — so this is a preference, not a law (hence stylistic). deep specialization also has real value that pure generalist small teams lack. the principle is \"keep teams as small and empowered as the scope allows,\" not \"small is always better regardless of scope.\" keep teams as small as the scope permits; resist adding people as a reflex (scope down instead, prod-0001). grant autonomy — decisions close to the work. compose teams cross-functionally so disciplines collaborate rather than hand off. small-and-autonomous (speed, coherence, low overhead, but limited capacity and depth) vs. large-and-specialized (scale, deep expertise, but coordination cost and diluted context). the right structure follows the scope; the failure modes are under-capacity (too small for the ambition) and coordination-collapse (too big without structure). typed stylistic as a genuine org-design values choice. confidence 3: a real preference, genuinely bounded by project scope."}
{"id":"GDC-L1-SHIP-0001","title":"You get one first impression — the launch state shapes the game's reception","layer":"L1","domain":"SHIP","subdomain":"launch-readiness","type":"contextual","confidence":4,"status":"canonical","tags":["shipping","launch","first-impression","stability","reputation"],"related":["GDC-L1-QA-0004","GDC-L1-UX-0001","GDC-L1-PROD-0006"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-scope-production"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-SHIP-0001.md","statement":"A game gets one launch, and its state at that moment — stability, performance, onboarding, and polish of the first hour — disproportionately shapes reviews, word of mouth, and long-term reception. First impressions are sticky and costly to reverse. Treat launch readiness as a deliberate goal, not the moment you happen to run out of time.","sections":{"Statement":"> A game gets one launch, and its state at that moment — stability, performance, onboarding, and\n> polish of the first hour — disproportionately shapes reviews, word of mouth, and long-term\n> reception. First impressions are sticky and costly to reverse. Treat launch readiness as a\n> deliberate goal, not the moment you happen to run out of time.","Rationale":"Launch is when the largest audience arrives at once, forms opinions fast, and broadcasts them\n(reviews, streams, social) — and those early opinions harden into the game's reputation, which is\nextremely hard to change later even if the game improves [S-scope-production]. A broken, sluggish,\nor confusing launch (crashes, bad performance on common hardware — QA-0004, a baffling first hour —\nUX-0001) squanders the one moment of peak attention, while a solid launch compounds into momentum.\nThis raises the stakes on finishing well (PROD-0006), on testing under real conditions before\nrelease (QA-0004), and on the onboarding experience specifically (UX-0001), because the first hour\nis what most players judge on. \"We'll patch it later\" underestimates how much the *first* impression\npersists.","Applies when":"Any release to a real audience — launch especially, but also major updates, betas, and demos that\ncreate first impressions.","Does not apply / Exceptions":"Early-access and live-service models deliberately launch *unfinished* — but they set the\nexpectation explicitly and still must nail the first impression *for what they claim to be*\n(a rough early-access launch that oversells itself still burns trust). And no launch is\nbug-free; the bar is \"good enough that the first impression is positive,\" not \"perfect.\" Small or\nniche launches carry lower stakes but the same logic.","Implementation (kept separate from the principle)":"Define launch-readiness criteria (stability, performance on target hardware — QA-0004, a strong\nfirst hour — UX-0001) and hold the release to them; if you can't hit them, cut scope or delay\nrather than launch broken (PROD-0001/0006). Prioritize the first-hour experience and common-case\nstability. Prepare day-one support (SHIP-0004). Set honest expectations for what the launch *is*\n(especially for early access).","Disagreement":"Ship-when-ready/delay-for-quality (protect the first impression — but cost of delay, missed windows)\nvs. ship-on-date-and-patch (hit the market/marketing window — but risk a bad first impression that\npatches can't fully undo). Live-service blurs this. The stakes of the first impression push toward\nreadiness, weighed against real business timing.","Notes":"The launch-stakes principle of SHIP; raises the bar on finishing (PROD-0006), real-conditions\ntesting (QA-0004), and onboarding (UX-0001). Confidence 4."},"rawMarkdown":"---\nid: GDC-L1-SHIP-0001\ntitle: You get one first impression — the launch state shapes the game's reception\nlayer: L1\ndomain: SHIP\nsubdomain: launch-readiness\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - shipping\n  - launch\n  - first-impression\n  - stability\n  - reputation\nrelated:\n  - GDC-L1-QA-0004\n  - GDC-L1-UX-0001\n  - GDC-L1-PROD-0006\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-scope-production\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A game gets one launch, and its state at that moment — stability, performance, onboarding, and\n> polish of the first hour — disproportionately shapes reviews, word of mouth, and long-term\n> reception. First impressions are sticky and costly to reverse. Treat launch readiness as a\n> deliberate goal, not the moment you happen to run out of time.\n\n## Rationale\nLaunch is when the largest audience arrives at once, forms opinions fast, and broadcasts them\n(reviews, streams, social) — and those early opinions harden into the game's reputation, which is\nextremely hard to change later even if the game improves [S-scope-production]. A broken, sluggish,\nor confusing launch (crashes, bad performance on common hardware — QA-0004, a baffling first hour —\nUX-0001) squanders the one moment of peak attention, while a solid launch compounds into momentum.\nThis raises the stakes on finishing well (PROD-0006), on testing under real conditions before\nrelease (QA-0004), and on the onboarding experience specifically (UX-0001), because the first hour\nis what most players judge on. \"We'll patch it later\" underestimates how much the *first* impression\npersists.\n\n## Applies when\nAny release to a real audience — launch especially, but also major updates, betas, and demos that\ncreate first impressions.\n\n## Does not apply / Exceptions\nEarly-access and live-service models deliberately launch *unfinished* — but they set the\nexpectation explicitly and still must nail the first impression *for what they claim to be*\n(a rough early-access launch that oversells itself still burns trust). And no launch is\nbug-free; the bar is \"good enough that the first impression is positive,\" not \"perfect.\" Small or\nniche launches carry lower stakes but the same logic.\n\n## Implementation (kept separate from the principle)\nDefine launch-readiness criteria (stability, performance on target hardware — QA-0004, a strong\nfirst hour — UX-0001) and hold the release to them; if you can't hit them, cut scope or delay\nrather than launch broken (PROD-0001/0006). Prioritize the first-hour experience and common-case\nstability. Prepare day-one support (SHIP-0004). Set honest expectations for what the launch *is*\n(especially for early access).\n\n## Disagreement\nShip-when-ready/delay-for-quality (protect the first impression — but cost of delay, missed windows)\nvs. ship-on-date-and-patch (hit the market/marketing window — but risk a bad first impression that\npatches can't fully undo). Live-service blurs this. The stakes of the first impression push toward\nreadiness, weighed against real business timing.\n\n## Notes\nThe launch-stakes principle of SHIP; raises the bar on finishing (PROD-0006), real-conditions\ntesting (QA-0004), and onboarding (UX-0001). Confidence 4.\n","searchText":"gdc-l1-ship-0001 you get one first impression — the launch state shapes the game's reception shipping launch first-impression stability reputation > a game gets one launch, and its state at that moment — stability, performance, onboarding, and polish of the first hour — disproportionately shapes reviews, word of mouth, and long-term reception. first impressions are sticky and costly to reverse. treat launch readiness as a deliberate goal, not the moment you happen to run out of time. launch is when the largest audience arrives at once, forms opinions fast, and broadcasts them (reviews, streams, social) — and those early opinions harden into the game's reputation, which is extremely hard to change later even if the game improves [s-scope-production]. a broken, sluggish, or confusing launch (crashes, bad performance on common hardware — qa-0004, a baffling first hour — ux-0001) squanders the one moment of peak attention, while a solid launch compounds into momentum. this raises the stakes on finishing well (prod-0006), on testing under real conditions before release (qa-0004), and on the onboarding experience specifically (ux-0001), because the first hour is what most players judge on. \"we'll patch it later\" underestimates how much the first impression persists. any release to a real audience — launch especially, but also major updates, betas, and demos that create first impressions. early-access and live-service models deliberately launch unfinished — but they set the expectation explicitly and still must nail the first impression for what they claim to be (a rough early-access launch that oversells itself still burns trust). and no launch is bug-free; the bar is \"good enough that the first impression is positive,\" not \"perfect.\" small or niche launches carry lower stakes but the same logic. define launch-readiness criteria (stability, performance on target hardware — qa-0004, a strong first hour — ux-0001) and hold the release to them; if you can't hit them, cut scope or delay rather than launch broken (prod-0001/0006). prioritize the first-hour experience and common-case stability. prepare day-one support (ship-0004). set honest expectations for what the launch is (especially for early access). ship-when-ready/delay-for-quality (protect the first impression — but cost of delay, missed windows) vs. ship-on-date-and-patch (hit the market/marketing window — but risk a bad first impression that patches can't fully undo). live-service blurs this. the stakes of the first impression push toward readiness, weighed against real business timing. the launch-stakes principle of ship; raises the bar on finishing (prod-0006), real-conditions testing (qa-0004), and onboarding (ux-0001). confidence 4."}
{"id":"GDC-L1-SHIP-0002","title":"For live games, launch is a beginning — plan post-launch from the start","layer":"L1","domain":"SHIP","subdomain":"post-launch","type":"contextual","confidence":4,"status":"canonical","tags":["shipping","live-service","post-launch","planning"],"related":["GDC-L1-SHIP-0003","GDC-L1-ARCH-0006","GDC-L1-PROD-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-scope-production"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-SHIP-0002.md","statement":"For live and ongoing games, launch is the start of the game's life, not the finish line. Plan for post-launch — updates, content, balance, events, support, and the systems that enable them — from the beginning. A game meant to live for years must be built to be maintained and extended, not just shipped once.","sections":{"Statement":"> For live and ongoing games, launch is the *start* of the game's life, not the finish line. Plan\n> for post-launch — updates, content, balance, events, support, and the systems that enable them —\n> from the beginning. A game meant to live for years must be *built* to be maintained and extended,\n> not just shipped once.","Rationale":"A live game spends most of its life *after* launch, and the decisions that determine whether that\nlife is sustainable are made *before* it: an architecture that supports live updates and\ndata-driven content (ARCH-0001/0006), the tooling to produce content at cadence (CONTENT-0001), the\ntelemetry to understand players (SHIP-0004), and the team and schedule to sustain it (PROD-0004)\nall have to exist by launch [S-scope-production]. Teams that treat launch as the end and bolt on\nlive operations afterward struggle — the game wasn't built to be fed. Planning post-launch from the\nstart means designing for extension (the \"build the seam\" logic again), budgeting the ongoing team,\nand sequencing content beyond day one. Even non-live games benefit from planning the inevitable\nlaunch patches; for live games it's existential.","Applies when":"Any live-service, ongoing, or long-tail game — and to a lesser degree any game expecting\npost-launch patches and support (i.e. almost all).","Does not apply / Exceptions":"A finite, premium, one-and-done game genuinely can treat launch as (nearly) the end — it still\nplans launch patches (SHIP-0001), but not perpetual operations. Building heavy live-ops\ninfrastructure into a game that won't use it is over-engineering. The principle scales with how\n\"live\" the game is meant to be — match the post-launch investment to the model (MON-0001).","Implementation (kept separate from the principle)":"Decide the live/finite model early (MON-0001) and build accordingly: architecture for live updates\nand data-driven content (ARCH-0001/0006), pipelines to produce content at cadence (CONTENT-0001),\ntelemetry for post-launch understanding (SHIP-0004), and a staffed, budgeted post-launch plan\n(PROD-0004). Sequence content beyond launch. Even for finite games, plan the day-one/first-weeks\npatch support.","Disagreement":"Live-service/GaaS (ongoing revenue and evolving experience — but perpetual cost, commitment, and\nthe temptation toward extractive live monetization, MON-0003) vs. finite/premium (a complete,\nauthored experience that ends — but no ongoing revenue). A fundamental business-model and design\nchoice (MON-0001), not a quality question.","Notes":"The post-launch-planning principle of SHIP; depends on extensible architecture (ARCH-0001/0006),\ncontent pipelines (CONTENT-0001), telemetry (SHIP-0004), and sustained planning (PROD-0004).\nConfidence 4."},"rawMarkdown":"---\nid: GDC-L1-SHIP-0002\ntitle: For live games, launch is a beginning — plan post-launch from the start\nlayer: L1\ndomain: SHIP\nsubdomain: post-launch\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - shipping\n  - live-service\n  - post-launch\n  - planning\nrelated:\n  - GDC-L1-SHIP-0003\n  - GDC-L1-ARCH-0006\n  - GDC-L1-PROD-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-scope-production\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> For live and ongoing games, launch is the *start* of the game's life, not the finish line. Plan\n> for post-launch — updates, content, balance, events, support, and the systems that enable them —\n> from the beginning. A game meant to live for years must be *built* to be maintained and extended,\n> not just shipped once.\n\n## Rationale\nA live game spends most of its life *after* launch, and the decisions that determine whether that\nlife is sustainable are made *before* it: an architecture that supports live updates and\ndata-driven content (ARCH-0001/0006), the tooling to produce content at cadence (CONTENT-0001), the\ntelemetry to understand players (SHIP-0004), and the team and schedule to sustain it (PROD-0004)\nall have to exist by launch [S-scope-production]. Teams that treat launch as the end and bolt on\nlive operations afterward struggle — the game wasn't built to be fed. Planning post-launch from the\nstart means designing for extension (the \"build the seam\" logic again), budgeting the ongoing team,\nand sequencing content beyond day one. Even non-live games benefit from planning the inevitable\nlaunch patches; for live games it's existential.\n\n## Applies when\nAny live-service, ongoing, or long-tail game — and to a lesser degree any game expecting\npost-launch patches and support (i.e. almost all).\n\n## Does not apply / Exceptions\nA finite, premium, one-and-done game genuinely can treat launch as (nearly) the end — it still\nplans launch patches (SHIP-0001), but not perpetual operations. Building heavy live-ops\ninfrastructure into a game that won't use it is over-engineering. The principle scales with how\n\"live\" the game is meant to be — match the post-launch investment to the model (MON-0001).\n\n## Implementation (kept separate from the principle)\nDecide the live/finite model early (MON-0001) and build accordingly: architecture for live updates\nand data-driven content (ARCH-0001/0006), pipelines to produce content at cadence (CONTENT-0001),\ntelemetry for post-launch understanding (SHIP-0004), and a staffed, budgeted post-launch plan\n(PROD-0004). Sequence content beyond launch. Even for finite games, plan the day-one/first-weeks\npatch support.\n\n## Disagreement\nLive-service/GaaS (ongoing revenue and evolving experience — but perpetual cost, commitment, and\nthe temptation toward extractive live monetization, MON-0003) vs. finite/premium (a complete,\nauthored experience that ends — but no ongoing revenue). A fundamental business-model and design\nchoice (MON-0001), not a quality question.\n\n## Notes\nThe post-launch-planning principle of SHIP; depends on extensible architecture (ARCH-0001/0006),\ncontent pipelines (CONTENT-0001), telemetry (SHIP-0004), and sustained planning (PROD-0004).\nConfidence 4.\n","searchText":"gdc-l1-ship-0002 for live games, launch is a beginning — plan post-launch from the start shipping live-service post-launch planning > for live and ongoing games, launch is the start of the game's life, not the finish line. plan for post-launch — updates, content, balance, events, support, and the systems that enable them — from the beginning. a game meant to live for years must be built to be maintained and extended, not just shipped once. a live game spends most of its life after launch, and the decisions that determine whether that life is sustainable are made before it: an architecture that supports live updates and data-driven content (arch-0001/0006), the tooling to produce content at cadence (content-0001), the telemetry to understand players (ship-0004), and the team and schedule to sustain it (prod-0004) all have to exist by launch [s-scope-production]. teams that treat launch as the end and bolt on live operations afterward struggle — the game wasn't built to be fed. planning post-launch from the start means designing for extension (the \"build the seam\" logic again), budgeting the ongoing team, and sequencing content beyond day one. even non-live games benefit from planning the inevitable launch patches; for live games it's existential. any live-service, ongoing, or long-tail game — and to a lesser degree any game expecting post-launch patches and support (i.e. almost all). a finite, premium, one-and-done game genuinely can treat launch as (nearly) the end — it still plans launch patches (ship-0001), but not perpetual operations. building heavy live-ops infrastructure into a game that won't use it is over-engineering. the principle scales with how \"live\" the game is meant to be — match the post-launch investment to the model (mon-0001). decide the live/finite model early (mon-0001) and build accordingly: architecture for live updates and data-driven content (arch-0001/0006), pipelines to produce content at cadence (content-0001), telemetry for post-launch understanding (ship-0004), and a staffed, budgeted post-launch plan (prod-0004). sequence content beyond launch. even for finite games, plan the day-one/first-weeks patch support. live-service/gaas (ongoing revenue and evolving experience — but perpetual cost, commitment, and the temptation toward extractive live monetization, mon-0003) vs. finite/premium (a complete, authored experience that ends — but no ongoing revenue). a fundamental business-model and design choice (mon-0001), not a quality question. the post-launch-planning principle of ship; depends on extensible architecture (arch-0001/0006), content pipelines (content-0001), telemetry (ship-0004), and sustained planning (prod-0004). confidence 4."}
{"id":"GDC-L1-SHIP-0003","title":"Run live ops as a service — sustain content, balance, and communication","layer":"L1","domain":"SHIP","subdomain":"live-ops","type":"contextual","confidence":3,"status":"canonical","tags":["shipping","live-ops","content-cadence","balance","community"],"related":["GDC-L1-SHIP-0002","GDC-L1-SHIP-0004","GDC-L1-BAL-0005"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-scope-production"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-SHIP-0003.md","statement":"A live game is a service: keeping it healthy takes a sustained cadence of content, ongoing balance, events, and honest communication with the community. Players stay for a game that keeps giving them reasons to return and visibly cares; they leave a game that stalls or goes silent.","sections":{"Statement":"> A live game is a *service*: keeping it healthy takes a sustained cadence of content, ongoing\n> balance, events, and honest communication with the community. Players stay for a game that keeps\n> giving them reasons to return and visibly cares; they leave a game that stalls or goes silent.","Rationale":"Live games retain players through a rhythm of fresh reasons to play — new content, seasonal events,\nbalance updates that keep the meta alive (BAL), responsive fixes — and through a relationship with\nthe community maintained by communication [S-scope-production]. A live game that ships and then goes\nquiet decays: the content gets exhausted, the balance staleness or exploits accumulate (BAL-0002,\nBAL-0006), and players drift to games that are still evolving. Running live ops well means treating\nthe post-launch game as an ongoing production with its own cadence, informed by what players\nactually do (telemetry and feedback, SHIP-0004). It's demanding — a real, sustained team cost — but\nfor a live game it's not optional; the service *is* the product after launch.","Applies when":"Live-service, seasonal, and ongoing multiplayer games — anything designed to be played and updated\nfor a long time.","Does not apply / Exceptions":"Finite/premium games don't run live ops (SHIP-0002) — they ship, patch, and are done, and forcing\nlive-ops cadence onto them wastes effort. Live ops also has a dark side to avoid: cadence and events\ndriven by *extraction* (FOMO, manufactured urgency) rather than genuine value cross into dark\npatterns (MON-0003). Healthy live ops gives players real reasons to return, not manufactured\ncompulsion. Small live games run lighter cadences scaled to their team.","Implementation (kept separate from the principle)":"Plan an achievable, sustainable content/event cadence (don't over-promise — a burnt-out live team\nserves no one, PROD-0005). Keep balance fresh and exploit-free (BAL-0002/0006), informed by\ntelemetry and feedback (SHIP-0004, BAL-0005). Communicate honestly and regularly with the community.\nEnsure cadence delivers genuine value, not manufactured urgency (MON-0003). Staff and budget it as\nongoing production (SHIP-0002).","Disagreement":"Heavy live-ops cadence (retention, evolving game, revenue — but high sustained cost and burnout/\nextraction risk) vs. lighter-touch or finite (lower ongoing cost, but decay without updates). And\nvalue-driven vs. extraction-driven live ops (MON-0003). The right cadence scales with the model and\nteam; the ethics line is real reasons-to-return over manufactured compulsion.","Notes":"The live-operations principle of SHIP; depends on post-launch planning (SHIP-0002), telemetry-driven\niteration (SHIP-0004, BAL-0005), and honest (non-extractive, MON-0003) engagement. Confidence 3 —\nlive-ops practice is model-dependent and fast-evolving."},"rawMarkdown":"---\nid: GDC-L1-SHIP-0003\ntitle: Run live ops as a service — sustain content, balance, and communication\nlayer: L1\ndomain: SHIP\nsubdomain: live-ops\ntype: contextual\nconfidence: 3\nstatus: canonical\ntags:\n  - shipping\n  - live-ops\n  - content-cadence\n  - balance\n  - community\nrelated:\n  - GDC-L1-SHIP-0002\n  - GDC-L1-SHIP-0004\n  - GDC-L1-BAL-0005\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-scope-production\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> A live game is a *service*: keeping it healthy takes a sustained cadence of content, ongoing\n> balance, events, and honest communication with the community. Players stay for a game that keeps\n> giving them reasons to return and visibly cares; they leave a game that stalls or goes silent.\n\n## Rationale\nLive games retain players through a rhythm of fresh reasons to play — new content, seasonal events,\nbalance updates that keep the meta alive (BAL), responsive fixes — and through a relationship with\nthe community maintained by communication [S-scope-production]. A live game that ships and then goes\nquiet decays: the content gets exhausted, the balance staleness or exploits accumulate (BAL-0002,\nBAL-0006), and players drift to games that are still evolving. Running live ops well means treating\nthe post-launch game as an ongoing production with its own cadence, informed by what players\nactually do (telemetry and feedback, SHIP-0004). It's demanding — a real, sustained team cost — but\nfor a live game it's not optional; the service *is* the product after launch.\n\n## Applies when\nLive-service, seasonal, and ongoing multiplayer games — anything designed to be played and updated\nfor a long time.\n\n## Does not apply / Exceptions\nFinite/premium games don't run live ops (SHIP-0002) — they ship, patch, and are done, and forcing\nlive-ops cadence onto them wastes effort. Live ops also has a dark side to avoid: cadence and events\ndriven by *extraction* (FOMO, manufactured urgency) rather than genuine value cross into dark\npatterns (MON-0003). Healthy live ops gives players real reasons to return, not manufactured\ncompulsion. Small live games run lighter cadences scaled to their team.\n\n## Implementation (kept separate from the principle)\nPlan an achievable, sustainable content/event cadence (don't over-promise — a burnt-out live team\nserves no one, PROD-0005). Keep balance fresh and exploit-free (BAL-0002/0006), informed by\ntelemetry and feedback (SHIP-0004, BAL-0005). Communicate honestly and regularly with the community.\nEnsure cadence delivers genuine value, not manufactured urgency (MON-0003). Staff and budget it as\nongoing production (SHIP-0002).\n\n## Disagreement\nHeavy live-ops cadence (retention, evolving game, revenue — but high sustained cost and burnout/\nextraction risk) vs. lighter-touch or finite (lower ongoing cost, but decay without updates). And\nvalue-driven vs. extraction-driven live ops (MON-0003). The right cadence scales with the model and\nteam; the ethics line is real reasons-to-return over manufactured compulsion.\n\n## Notes\nThe live-operations principle of SHIP; depends on post-launch planning (SHIP-0002), telemetry-driven\niteration (SHIP-0004, BAL-0005), and honest (non-extractive, MON-0003) engagement. Confidence 3 —\nlive-ops practice is model-dependent and fast-evolving.\n","searchText":"gdc-l1-ship-0003 run live ops as a service — sustain content, balance, and communication shipping live-ops content-cadence balance community > a live game is a service: keeping it healthy takes a sustained cadence of content, ongoing balance, events, and honest communication with the community. players stay for a game that keeps giving them reasons to return and visibly cares; they leave a game that stalls or goes silent. live games retain players through a rhythm of fresh reasons to play — new content, seasonal events, balance updates that keep the meta alive (bal), responsive fixes — and through a relationship with the community maintained by communication [s-scope-production]. a live game that ships and then goes quiet decays: the content gets exhausted, the balance staleness or exploits accumulate (bal-0002, bal-0006), and players drift to games that are still evolving. running live ops well means treating the post-launch game as an ongoing production with its own cadence, informed by what players actually do (telemetry and feedback, ship-0004). it's demanding — a real, sustained team cost — but for a live game it's not optional; the service is the product after launch. live-service, seasonal, and ongoing multiplayer games — anything designed to be played and updated for a long time. finite/premium games don't run live ops (ship-0002) — they ship, patch, and are done, and forcing live-ops cadence onto them wastes effort. live ops also has a dark side to avoid: cadence and events driven by extraction (fomo, manufactured urgency) rather than genuine value cross into dark patterns (mon-0003). healthy live ops gives players real reasons to return, not manufactured compulsion. small live games run lighter cadences scaled to their team. plan an achievable, sustainable content/event cadence (don't over-promise — a burnt-out live team serves no one, prod-0005). keep balance fresh and exploit-free (bal-0002/0006), informed by telemetry and feedback (ship-0004, bal-0005). communicate honestly and regularly with the community. ensure cadence delivers genuine value, not manufactured urgency (mon-0003). staff and budget it as ongoing production (ship-0002). heavy live-ops cadence (retention, evolving game, revenue — but high sustained cost and burnout/ extraction risk) vs. lighter-touch or finite (lower ongoing cost, but decay without updates). and value-driven vs. extraction-driven live ops (mon-0003). the right cadence scales with the model and team; the ethics line is real reasons-to-return over manufactured compulsion. the live-operations principle of ship; depends on post-launch planning (ship-0002), telemetry-driven iteration (ship-0004, bal-0005), and honest (non-extractive, mon-0003) engagement. confidence 3 — live-ops practice is model-dependent and fast-evolving."}
{"id":"GDC-L1-SHIP-0004","title":"Close the loop after launch — telemetry and community feedback into responsive patching","layer":"L1","domain":"SHIP","subdomain":"post-launch","type":"contextual","confidence":4,"status":"canonical","tags":["shipping","telemetry","feedback","patching","community"],"related":["GDC-L1-PLAYTEST-0005","GDC-L1-PLAYTEST-0004","GDC-L1-SHIP-0003"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-scope-production","S-games-user-research"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-SHIP-0004.md","statement":"After launch, keep the iteration loop running: gather what players do (telemetry) and what they say (community feedback), and turn it into responsive fixes and improvements. Launch multiplies your player base — and thus your data — enormously; a responsive post-launch loop turns a rough launch into a recovery and a good one into a great one.","sections":{"Statement":"> After launch, keep the iteration loop running: gather what players *do* (telemetry) and what they\n> *say* (community feedback), and turn it into responsive fixes and improvements. Launch multiplies\n> your player base — and thus your data — enormously; a responsive post-launch loop turns a rough\n> launch into a recovery and a good one into a great one.","Rationale":"Launch is the biggest playtest the game will ever get (PLAYTEST-0005): millions of real players in\nreal conditions surface the balance problems, exploits, pain points, and crashes that no internal\ntest found. A team that watches this — telemetry for the *what* (where players quit, what they use,\nwhere they crash) plus community feedback for the *why* — and patches responsively can fix a shaky\nlaunch and keep a strong one improving [S-scope-production] [S-games-user-research]. This is the\npost-launch continuation of the whole iteration ethos (PROTO-0006) and the playtest principles:\nwatch behavior over opinion (PLAYTEST-0001/0005), and listen to the problem while distrusting the\nprescribed fix (PLAYTEST-0004). A responsive, visible post-launch loop also signals to the community\nthat the game is cared for (SHIP-0003), which retains players through the rocky early weeks.","Applies when":"The post-launch period of any game, and continuously for live games. Most critical in the first days\nand weeks when the largest audience and the most data arrive at once.","Does not apply / Exceptions":"Finite games close the loop for a limited support window rather than forever. And responsiveness has\nlimits: not every loud complaint warrants a change (PLAYTEST-0004 — distrust the prescribed fix),\nand knee-jerk patching can destabilize a game or chase a vocal minority. The loop should be\n*responsive and judged*, not reflexive. Telemetry can also mislead if optimized for the wrong metric\n(PROG-0004's caution).","Implementation (kept separate from the principle)":"Instrument the game for post-launch telemetry (crashes, drop-off, usage, balance data — build it in\nbefore launch, SHIP-0002). Monitor community channels for the *why*. Combine both (PLAYTEST-0005),\nand patch responsively — prioritizing crashes, exploits, and the worst pain points. Listen to the\nproblem, own the fix (PLAYTEST-0004). Communicate what you're doing (SHIP-0003). Avoid\nmetric-chasing at the experience's expense (PROG-0004).","Disagreement":"Highly responsive patching (recover launches, retain players, show care — but risk instability,\nchasing vocal minorities, and over-reacting) vs. measured/deliberate updates (stability, considered\nchanges — but slower to fix real problems). The synthesis: fast on crashes/exploits, deliberate on\ndesign changes, always judging feedback (PLAYTEST-0004) rather than obeying it.","Notes":"The post-launch iteration principle of SHIP; the launch-scale continuation of playtesting\n(PLAYTEST-0001/0004/0005) and the iteration loop (PROTO-0006), feeding live ops (SHIP-0003).\nConfidence 4."},"rawMarkdown":"---\nid: GDC-L1-SHIP-0004\ntitle: Close the loop after launch — telemetry and community feedback into responsive patching\nlayer: L1\ndomain: SHIP\nsubdomain: post-launch\ntype: contextual\nconfidence: 4\nstatus: canonical\ntags:\n  - shipping\n  - telemetry\n  - feedback\n  - patching\n  - community\nrelated:\n  - GDC-L1-PLAYTEST-0005\n  - GDC-L1-PLAYTEST-0004\n  - GDC-L1-SHIP-0003\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-scope-production\n  - S-games-user-research\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> After launch, keep the iteration loop running: gather what players *do* (telemetry) and what they\n> *say* (community feedback), and turn it into responsive fixes and improvements. Launch multiplies\n> your player base — and thus your data — enormously; a responsive post-launch loop turns a rough\n> launch into a recovery and a good one into a great one.\n\n## Rationale\nLaunch is the biggest playtest the game will ever get (PLAYTEST-0005): millions of real players in\nreal conditions surface the balance problems, exploits, pain points, and crashes that no internal\ntest found. A team that watches this — telemetry for the *what* (where players quit, what they use,\nwhere they crash) plus community feedback for the *why* — and patches responsively can fix a shaky\nlaunch and keep a strong one improving [S-scope-production] [S-games-user-research]. This is the\npost-launch continuation of the whole iteration ethos (PROTO-0006) and the playtest principles:\nwatch behavior over opinion (PLAYTEST-0001/0005), and listen to the problem while distrusting the\nprescribed fix (PLAYTEST-0004). A responsive, visible post-launch loop also signals to the community\nthat the game is cared for (SHIP-0003), which retains players through the rocky early weeks.\n\n## Applies when\nThe post-launch period of any game, and continuously for live games. Most critical in the first days\nand weeks when the largest audience and the most data arrive at once.\n\n## Does not apply / Exceptions\nFinite games close the loop for a limited support window rather than forever. And responsiveness has\nlimits: not every loud complaint warrants a change (PLAYTEST-0004 — distrust the prescribed fix),\nand knee-jerk patching can destabilize a game or chase a vocal minority. The loop should be\n*responsive and judged*, not reflexive. Telemetry can also mislead if optimized for the wrong metric\n(PROG-0004's caution).\n\n## Implementation (kept separate from the principle)\nInstrument the game for post-launch telemetry (crashes, drop-off, usage, balance data — build it in\nbefore launch, SHIP-0002). Monitor community channels for the *why*. Combine both (PLAYTEST-0005),\nand patch responsively — prioritizing crashes, exploits, and the worst pain points. Listen to the\nproblem, own the fix (PLAYTEST-0004). Communicate what you're doing (SHIP-0003). Avoid\nmetric-chasing at the experience's expense (PROG-0004).\n\n## Disagreement\nHighly responsive patching (recover launches, retain players, show care — but risk instability,\nchasing vocal minorities, and over-reacting) vs. measured/deliberate updates (stability, considered\nchanges — but slower to fix real problems). The synthesis: fast on crashes/exploits, deliberate on\ndesign changes, always judging feedback (PLAYTEST-0004) rather than obeying it.\n\n## Notes\nThe post-launch iteration principle of SHIP; the launch-scale continuation of playtesting\n(PLAYTEST-0001/0004/0005) and the iteration loop (PROTO-0006), feeding live ops (SHIP-0003).\nConfidence 4.\n","searchText":"gdc-l1-ship-0004 close the loop after launch — telemetry and community feedback into responsive patching shipping telemetry feedback patching community > after launch, keep the iteration loop running: gather what players do (telemetry) and what they say (community feedback), and turn it into responsive fixes and improvements. launch multiplies your player base — and thus your data — enormously; a responsive post-launch loop turns a rough launch into a recovery and a good one into a great one. launch is the biggest playtest the game will ever get (playtest-0005): millions of real players in real conditions surface the balance problems, exploits, pain points, and crashes that no internal test found. a team that watches this — telemetry for the what (where players quit, what they use, where they crash) plus community feedback for the why — and patches responsively can fix a shaky launch and keep a strong one improving [s-scope-production] [s-games-user-research]. this is the post-launch continuation of the whole iteration ethos (proto-0006) and the playtest principles: watch behavior over opinion (playtest-0001/0005), and listen to the problem while distrusting the prescribed fix (playtest-0004). a responsive, visible post-launch loop also signals to the community that the game is cared for (ship-0003), which retains players through the rocky early weeks. the post-launch period of any game, and continuously for live games. most critical in the first days and weeks when the largest audience and the most data arrive at once. finite games close the loop for a limited support window rather than forever. and responsiveness has limits: not every loud complaint warrants a change (playtest-0004 — distrust the prescribed fix), and knee-jerk patching can destabilize a game or chase a vocal minority. the loop should be responsive and judged, not reflexive. telemetry can also mislead if optimized for the wrong metric (prog-0004's caution). instrument the game for post-launch telemetry (crashes, drop-off, usage, balance data — build it in before launch, ship-0002). monitor community channels for the why. combine both (playtest-0005), and patch responsively — prioritizing crashes, exploits, and the worst pain points. listen to the problem, own the fix (playtest-0004). communicate what you're doing (ship-0003). avoid metric-chasing at the experience's expense (prog-0004). highly responsive patching (recover launches, retain players, show care — but risk instability, chasing vocal minorities, and over-reacting) vs. measured/deliberate updates (stability, considered changes — but slower to fix real problems). the synthesis: fast on crashes/exploits, deliberate on design changes, always judging feedback (playtest-0004) rather than obeying it. the post-launch iteration principle of ship; the launch-scale continuation of playtesting (playtest-0001/0004/0005) and the iteration loop (proto-0006), feeding live ops (ship-0003). confidence 4."}
{"id":"GDC-L1-SHIP-0005","title":"Sunset with respect — plan the end of life","layer":"L1","domain":"SHIP","subdomain":"sunsetting","type":"stylistic","confidence":3,"status":"canonical","tags":["shipping","sunset","end-of-life","preservation","player-respect"],"related":["GDC-L1-SHIP-0002","GDC-L1-MON-0002","GDC-L1-PLAYTEST-0004"],"depends_on":[],"conflicts_with":[],"supersedes":[],"sources":["S-scope-production"],"first_added":"2026-07-14","last_verified":"2026-07-14","file":"GDC-L1-SHIP-0005.md","statement":"Every live game ends. Plan the end of life with respect: give honest, early communication, honor what players spent (money and time), and where feasible preserve access — an offline mode, extended notice, or archival — rather than switching the servers off and erasing what people paid for and cared about.","sections":{"Statement":"> Every live game ends. Plan the end of life with respect: give honest, early communication, honor\n> what players spent (money and time), and where feasible preserve access — an offline mode,\n> extended notice, or archival — rather than switching the servers off and erasing what people\n> paid for and cared about.","Rationale":"Live games depend on servers and services that won't run forever, and how a studio handles the end\nis a real test of the respect it claims for its players (MON-0002) — a game that vanishes overnight,\ntaking players' purchases and progress with it and with little warning, breaks the trust the whole\nrelationship was built on [S-scope-production]. Players invest money *and* years of time and\nattachment; treating that investment as disposable at sunset is the opposite of the value exchange\nand player respect the constitution argues for. A respectful sunset — ample notice, honoring\nspends, and preserving what can be preserved (offline continuation, private servers, archival) —\nprotects the studio's reputation, respects the community, and contributes to the medium's\npreservation. It's also increasingly a consumer-rights and regulatory concern.","Applies when":"The end of life of any live/server-dependent game or service — and the *planning* for it should\nbegin when the live model is chosen (SHIP-0002), not scrambled at shutdown.","Does not apply / Exceptions":"Finite/offline games don't sunset in this sense — they simply remain playable (their preservation\nconcern is compatibility over time, not server shutdown). Genuine constraints exist: some games are\ntechnically or legally hard to preserve (licensed content, deep server dependencies), and a studio\nmay lack resources to maintain an offline mode. The principle is \"sunset with as much respect and\npreservation as feasible,\" not \"keep every game alive forever.\"","Implementation (kept separate from the principle)":"Plan for end-of-life when adopting a live model (SHIP-0002): consider an eventual offline/private-\nserver path, and design to make graceful shutdown possible. At sunset, give early, honest notice;\nhonor recent purchases (refunds/consideration); preserve access where feasible. Communicate with the\ncommunity as you would at launch (SHIP-0003/0004) — the end deserves the same care as the beginning.","Disagreement":"Preservation/respect-first sunsetting (honor players' investment, protect reputation and the medium\n— but real cost and technical/legal barriers) vs. clean-shutdown pragmatism (lower cost, simpler —\nbut breaks trust and erases what players paid for). A values-and-feasibility split (hence stylistic);\nthis constitution leans toward respect and preservation within what's feasible, echoing MON-0002.","Notes":"The end-of-life principle of SHIP; the sunset application of player respect (MON-0002) and the\nbookend to launch (SHIP-0001) — begin and end the game's life with equal care. Confidence 3 —\nclearly the respectful ideal, but genuinely constrained by cost and technical/legal reality."},"rawMarkdown":"---\nid: GDC-L1-SHIP-0005\ntitle: Sunset with respect — plan the end of life\nlayer: L1\ndomain: SHIP\nsubdomain: sunsetting\ntype: stylistic\nconfidence: 3\nstatus: canonical\ntags:\n  - shipping\n  - sunset\n  - end-of-life\n  - preservation\n  - player-respect\nrelated:\n  - GDC-L1-SHIP-0002\n  - GDC-L1-MON-0002\n  - GDC-L1-PLAYTEST-0004\ndepends_on: []\nconflicts_with: []\nsupersedes: []\nsources:\n  - S-scope-production\nfirst_added: 2026-07-14\nlast_verified: 2026-07-14\n---\n\n## Statement\n> Every live game ends. Plan the end of life with respect: give honest, early communication, honor\n> what players spent (money and time), and where feasible preserve access — an offline mode,\n> extended notice, or archival — rather than switching the servers off and erasing what people\n> paid for and cared about.\n\n## Rationale\nLive games depend on servers and services that won't run forever, and how a studio handles the end\nis a real test of the respect it claims for its players (MON-0002) — a game that vanishes overnight,\ntaking players' purchases and progress with it and with little warning, breaks the trust the whole\nrelationship was built on [S-scope-production]. Players invest money *and* years of time and\nattachment; treating that investment as disposable at sunset is the opposite of the value exchange\nand player respect the constitution argues for. A respectful sunset — ample notice, honoring\nspends, and preserving what can be preserved (offline continuation, private servers, archival) —\nprotects the studio's reputation, respects the community, and contributes to the medium's\npreservation. It's also increasingly a consumer-rights and regulatory concern.\n\n## Applies when\nThe end of life of any live/server-dependent game or service — and the *planning* for it should\nbegin when the live model is chosen (SHIP-0002), not scrambled at shutdown.\n\n## Does not apply / Exceptions\nFinite/offline games don't sunset in this sense — they simply remain playable (their preservation\nconcern is compatibility over time, not server shutdown). Genuine constraints exist: some games are\ntechnically or legally hard to preserve (licensed content, deep server dependencies), and a studio\nmay lack resources to maintain an offline mode. The principle is \"sunset with as much respect and\npreservation as feasible,\" not \"keep every game alive forever.\"\n\n## Implementation (kept separate from the principle)\nPlan for end-of-life when adopting a live model (SHIP-0002): consider an eventual offline/private-\nserver path, and design to make graceful shutdown possible. At sunset, give early, honest notice;\nhonor recent purchases (refunds/consideration); preserve access where feasible. Communicate with the\ncommunity as you would at launch (SHIP-0003/0004) — the end deserves the same care as the beginning.\n\n## Disagreement\nPreservation/respect-first sunsetting (honor players' investment, protect reputation and the medium\n— but real cost and technical/legal barriers) vs. clean-shutdown pragmatism (lower cost, simpler —\nbut breaks trust and erases what players paid for). A values-and-feasibility split (hence stylistic);\nthis constitution leans toward respect and preservation within what's feasible, echoing MON-0002.\n\n## Notes\nThe end-of-life principle of SHIP; the sunset application of player respect (MON-0002) and the\nbookend to launch (SHIP-0001) — begin and end the game's life with equal care. Confidence 3 —\nclearly the respectful ideal, but genuinely constrained by cost and technical/legal reality.\n","searchText":"gdc-l1-ship-0005 sunset with respect — plan the end of life shipping sunset end-of-life preservation player-respect > every live game ends. plan the end of life with respect: give honest, early communication, honor what players spent (money and time), and where feasible preserve access — an offline mode, extended notice, or archival — rather than switching the servers off and erasing what people paid for and cared about. live games depend on servers and services that won't run forever, and how a studio handles the end is a real test of the respect it claims for its players (mon-0002) — a game that vanishes overnight, taking players' purchases and progress with it and with little warning, breaks the trust the whole relationship was built on [s-scope-production]. players invest money and years of time and attachment; treating that investment as disposable at sunset is the opposite of the value exchange and player respect the constitution argues for. a respectful sunset — ample notice, honoring spends, and preserving what can be preserved (offline continuation, private servers, archival) — protects the studio's reputation, respects the community, and contributes to the medium's preservation. it's also increasingly a consumer-rights and regulatory concern. the end of life of any live/server-dependent game or service — and the planning for it should begin when the live model is chosen (ship-0002), not scrambled at shutdown. finite/offline games don't sunset in this sense — they simply remain playable (their preservation concern is compatibility over time, not server shutdown). genuine constraints exist: some games are technically or legally hard to preserve (licensed content, deep server dependencies), and a studio may lack resources to maintain an offline mode. the principle is \"sunset with as much respect and preservation as feasible,\" not \"keep every game alive forever.\" plan for end-of-life when adopting a live model (ship-0002): consider an eventual offline/private- server path, and design to make graceful shutdown possible. at sunset, give early, honest notice; honor recent purchases (refunds/consideration); preserve access where feasible. communicate with the community as you would at launch (ship-0003/0004) — the end deserves the same care as the beginning. preservation/respect-first sunsetting (honor players' investment, protect reputation and the medium — but real cost and technical/legal barriers) vs. clean-shutdown pragmatism (lower cost, simpler — but breaks trust and erases what players paid for). a values-and-feasibility split (hence stylistic); this constitution leans toward respect and preservation within what's feasible, echoing mon-0002. the end-of-life principle of ship; the sunset application of player respect (mon-0002) and the bookend to launch (ship-0001) — begin and end the game's life with equal care. confidence 3 — clearly the respectful ideal, but genuinely constrained by cost and technical/legal reality."}