Prototype the riskiest assumption first

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.

---
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
---

## 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.

## Rationale
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.

## Applies when
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?"

## Does not apply / Exceptions
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.

## Implementation (kept separate from the principle)
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.

## Disagreement
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.

## Notes
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.

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.


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.

---
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
---

## 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.

## Rationale
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.

## Applies when
Level design, encounter design, mechanic validation, UI flow — anywhere the design can be
judged 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
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.

## Implementation (kept separate from the principle)
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.

## Disagreement
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.

## Notes
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.

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.


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.

---
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
---

## 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.

## Rationale
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.

## 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
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.

## Implementation (kept separate from the principle)
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.

## Disagreement
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.

## Notes
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.

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.


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.

---
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
---

## 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.

## Rationale
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.

## Applies when
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.

## Does not apply / Exceptions
"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."

## Implementation (kept separate from the principle)
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.

## Disagreement
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.

## Notes
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.

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.


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.

---
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
---

## 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.

## Rationale
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.

## Applies when
The entire development process, from first prototype to final polish. It is the meta-principle
the 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
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.

## 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
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.

## Notes
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.

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.


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.

---
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
---

## 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.

## Rationale
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.

## Applies when
Every playtest. The moment a build is playable, the highest-value activity is watching
real players interact with it.

## Does not apply / Exceptions
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.

## Implementation (kept separate from the principle)
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.

## Disagreement
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).

## Notes
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.

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.


Test early, often, and rough

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.

---
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
---

## 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.

## Rationale
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.

## Applies when
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.

## Does not apply / Exceptions
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."

## Implementation (kept separate from the principle)
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.

## Disagreement
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.

## Notes
Pairs behavior-first testing (PLAYTEST-0001) with the iteration architecture (ARCH-0005)
and the prototyping discipline (PROTO, to come). Confidence 4.

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.


Don't help, don't explain

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.

---
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
---

## 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.

## Rationale
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.

## Applies when
Any test of onboarding, clarity, controls, or discoverability — and by default, any test at
all, 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,
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.

## Implementation (kept separate from the principle)
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.

## Disagreement
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.

## Notes
The behavioral discipline that makes PLAYTEST-0001 work, and the direct antidote to the
author's intent-contamination named in DESIGN-0001. Confidence 5.

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.


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.

---
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
---

## 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.

## Rationale
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.

## 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
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.

## Implementation (kept separate from the principle)
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.

## Disagreement
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.

## Notes
Formalizes DESIGN-0001's "listen to the symptom; own the cure" into a playtest-interpretation
rule. Confidence 5.

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.


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.

---
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
---

## 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.

## Rationale
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.

## Applies when
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).

## Does not apply / Exceptions
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.

## Implementation (kept separate from the principle)
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.

## Disagreement
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.

## Notes
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).

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).


Mind your sample and your biases

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.

---
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
---

## 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.

## Rationale
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.

## Applies when
Recruiting testers and interpreting any test result — especially decisions that hinge on a
small number of sessions.

## Does not apply / Exceptions
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.

## Implementation (kept separate from the principle)
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.

## Disagreement
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.

## Notes
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.

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.


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.

---
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
---

## 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.

## Rationale
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.

## Applies when
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.

## Does not apply / Exceptions
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.

## Implementation (kept separate from the principle)
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).

## Disagreement
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.

## Notes
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.

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.


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.

---
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
---

## 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**.

## Rationale
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.

## Applies when
Throughout production, and especially in the messy middle where the game is playable enough
to 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
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.

## Implementation (kept separate from the principle)
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.

## Disagreement
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.

## Notes
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.

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.


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.

---
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
---

## 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.

## Rationale
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.

## Applies when
The transition from pre-production to full production, and any point you need to prove
feasibility 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
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).

## Implementation (kept separate from the principle)
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.

## Disagreement
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.

## Notes
The production complement to PROTO-0001: prototype = "should we?", slice = "can we?". Feeds
scheduling (PROD-0004) and the scope commitment (PROD-0001). Confidence 4.

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.


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.

---
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
---

## 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.

## Rationale
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.

## Applies when
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.

## Does not apply / Exceptions
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.

## Implementation (kept separate from the principle)
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.

## Disagreement
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.

## Notes
The scheduling face of the iteration truth (PROTO-0006, DESIGN-0001); pairs with iteration-
speed architecture (ARCH-0005). Confidence 4.

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.


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.

---
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
---

## 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.

## Rationale
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.

## Applies when
All production planning and management. Most acute near milestones and launch, where the
temptation to "just push through" is strongest.

## Does not apply / Exceptions
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.

## Implementation (kept separate from the principle)
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.

## Disagreement
"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.

## Notes
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.

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.


Finish — shipping is its own skill

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.

---
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
---

## 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.

## Rationale
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.

## Applies when
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.

## Does not apply / Exceptions
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).

## Implementation (kept separate from the principle)
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.

## Disagreement
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.

## Notes
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.

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.