A coherent game needs a clear creative vision — a shared, specific idea of the intended experience — that ambiguous decisions can be measured against. Without it, every contributor quietly builds a slightly different game, and the whole loses coherence.

---
id: GDC-L1-VISION-0001
title: Hold a clear creative vision — a north star that resolves decisions
layer: L1
domain: VISION
subdomain: vision-holding
type: contextual
confidence: 4
status: canonical
tags:
  - vision
  - creative-direction
  - coherence
  - north-star
related:
  - GDC-L1-DESIGN-0001
  - GDC-L1-VISION-0002
  - GDC-L1-VISION-0005
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-design-pillars
  - S-schell-artofgamedesign
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> A coherent game needs a clear creative **vision** — a shared, specific idea of the intended
> experience — that ambiguous decisions can be measured against. Without it, every contributor
> quietly builds a slightly different game, and the whole loses coherence.

## Rationale
A game is made of thousands of decisions by many people, and most of them are too small to
escalate — so unless everyone shares the same mental picture of what the game *is*, each person
resolves ambiguity toward their *own* version, and the results don't cohere
[S-design-pillars]. A clear vision is the shared reference that lets distributed decisions
point the same way: when someone asks "should the tone here be funny or grim? should this
system be deep or simple?", the vision answers. This is the creative counterpart of designing
for the intended experience (DESIGN-0001) — the vision is the *statement* of that intended
experience, held in common so the whole team can serve it. Coherence is not automatic; it is
the product of a shared, maintained vision.

## Applies when
Any project with more than one contributor, and any decision where "what should this be?" has
no obvious answer. The larger and longer the project, the more a shared vision matters.

## Does not apply / Exceptions
A solo developer holds the vision implicitly and may not need to externalize it (though even
solo devs drift without one). Highly exploratory early phases deliberately keep the vision
loose while searching for the game. And vision must not calcify into dogma that ignores what
playtesting reveals (DESIGN-0001) — it's a north star to steer by, updated as the game teaches
you what it wants to be.

## Implementation (kept separate from the principle)
Articulate the intended experience explicitly and share it widely. Distill it into pillars
(VISION-0002) and a communicable hook (VISION-0005) so it's usable, not just aspirational. Use
it to resolve ambiguous decisions, and revisit it when playtests reveal the real game. Give it
an owner (VISION-0004) so it stays coherent.

## Disagreement
Strong up-front vision (coherence, direction) vs. emergent/discovered vision (let the game
reveal itself through iteration) — auteur-led vs. discovery-led development. Most projects need
some of both: enough vision to align the team, enough openness to learn from the game. The risk
at each extreme is incoherence (no vision) or rigidity (frozen vision).

## Notes
The anchor of the VISION domain and the creative statement of DESIGN-0001 (the intended
experience). Made practical by pillars (VISION-0002) and communication (VISION-0005), owned via
VISION-0004. Confidence 4.

gdc-l1-vision-0001 hold a clear creative vision — a north star that resolves decisions vision creative-direction coherence north-star > a coherent game needs a clear creative vision — a shared, specific idea of the intended experience — that ambiguous decisions can be measured against. without it, every contributor quietly builds a slightly different game, and the whole loses coherence. a game is made of thousands of decisions by many people, and most of them are too small to escalate — so unless everyone shares the same mental picture of what the game is, each person resolves ambiguity toward their own version, and the results don't cohere [s-design-pillars]. a clear vision is the shared reference that lets distributed decisions point the same way: when someone asks "should the tone here be funny or grim? should this system be deep or simple?", the vision answers. this is the creative counterpart of designing for the intended experience (design-0001) — the vision is the statement of that intended experience, held in common so the whole team can serve it. coherence is not automatic; it is the product of a shared, maintained vision. any project with more than one contributor, and any decision where "what should this be?" has no obvious answer. the larger and longer the project, the more a shared vision matters. a solo developer holds the vision implicitly and may not need to externalize it (though even solo devs drift without one). highly exploratory early phases deliberately keep the vision loose while searching for the game. and vision must not calcify into dogma that ignores what playtesting reveals (design-0001) — it's a north star to steer by, updated as the game teaches you what it wants to be. articulate the intended experience explicitly and share it widely. distill it into pillars (vision-0002) and a communicable hook (vision-0005) so it's usable, not just aspirational. use it to resolve ambiguous decisions, and revisit it when playtests reveal the real game. give it an owner (vision-0004) so it stays coherent. strong up-front vision (coherence, direction) vs. emergent/discovered vision (let the game reveal itself through iteration) — auteur-led vs. discovery-led development. most projects need some of both: enough vision to align the team, enough openness to learn from the game. the risk at each extreme is incoherence (no vision) or rigidity (frozen vision). the anchor of the vision domain and the creative statement of design-0001 (the intended experience). made practical by pillars (vision-0002) and communication (vision-0005), owned via vision-0004. confidence 4.


Distill the vision into a few explicit design pillars — the fundamental goals of the intended experience — and use them as a filter for every idea and decision. Pillars turn a vague vision into a practical test: does this serve the pillars?

---
id: GDC-L1-VISION-0002
title: Define pillars — a few explicit principles every decision is checked against
layer: L1
domain: VISION
subdomain: pillars
type: contextual
confidence: 4
status: canonical
tags:
  - vision
  - pillars
  - creative-direction
  - filter
  - coherence
related:
  - GDC-L1-VISION-0001
  - GDC-L1-VISION-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-design-pillars
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Distill the vision into a few explicit **design pillars** — the fundamental goals of the
> intended experience — and use them as a filter for every idea and decision. Pillars turn a
> vague vision into a practical test: *does this serve the pillars?*

## Rationale
A vision (VISION-0001) is only usable if it can be applied to concrete decisions, and pillars
are how you make it applicable: a small set of guiding principles that every proposed mechanic,
feature, art choice, or cut can be checked against [S-design-pillars]. Pillars do two jobs.
They *align* — everyone measures against the same few goals, so decisions cohere. And they
*filter* — an idea that doesn't serve a pillar doesn't belong, which is how you resist feature
creep (PROD-0002) without relitigating the vision every time. Crucially, pillars reframe
rejection: they don't say an idea is *bad*, only that it doesn't fit *this* game — which makes
saying no (VISION-0003) defensible and impersonal. Few and sharp beats many and vague; three
strong pillars steer better than ten mushy ones.

## Applies when
Whenever you need to make the vision operational — evaluating features, resolving design
debates, prioritizing, and cutting. Valuable from pre-production through ship.

## Does not apply / Exceptions
Pillars can be over-formalized — a wall of vague, feel-good pillars that don't actually decide anything is worse than none. They must be *specific enough to reject things*. Very small or experimental projects may carry pillars informally.

## Implementation (kept separate from the principle)
Write a few (roughly 3–5) concrete, specific pillars that capture what the experience is *for*. Make them sharp enough to reject real ideas. Run features and cuts through them (VISION-0003, PROD-0002). Keep them visible to the whole team. Grow them when a decision can't be derived from them.

## Disagreement
Explicit pillars (shared filter, defensible nos) vs. holistic/tacit vision (some directors
carry coherence without formalizing it, and worry pillars ossify or oversimplify). Most teams
benefit from explicit pillars precisely because the vision must be shared across many people;
solo auteurs can carry it tacitly.

## Notes
The operational form of the vision (VISION-0001), the engine of principled nos (VISION-0003) and anti-creep (PROD-0002). Confidence 4.

gdc-l1-vision-0002 define pillars — a few explicit principles every decision is checked against vision pillars creative-direction filter coherence > distill the vision into a few explicit design pillars — the fundamental goals of the intended experience — and use them as a filter for every idea and decision. pillars turn a vague vision into a practical test: does this serve the pillars? a vision (vision-0001) is only usable if it can be applied to concrete decisions, and pillars are how you make it applicable: a small set of guiding principles that every proposed mechanic, feature, art choice, or cut can be checked against [s-design-pillars]. pillars do two jobs. they align — everyone measures against the same few goals, so decisions cohere. and they filter — an idea that doesn't serve a pillar doesn't belong, which is how you resist feature creep (prod-0002) without relitigating the vision every time. crucially, pillars reframe rejection: they don't say an idea is bad, only that it doesn't fit this game — which makes saying no (vision-0003) defensible and impersonal. few and sharp beats many and vague; three strong pillars steer better than ten mushy ones. whenever you need to make the vision operational — evaluating features, resolving design debates, prioritizing, and cutting. valuable from pre-production through ship. pillars can be over-formalized — a wall of vague, feel-good pillars that don't actually decide anything is worse than none. they must be specific enough to reject things. very small or experimental projects may carry pillars informally. write a few (roughly 3–5) concrete, specific pillars that capture what the experience is for. make them sharp enough to reject real ideas. run features and cuts through them (vision-0003, prod-0002). keep them visible to the whole team. grow them when a decision can't be derived from them. explicit pillars (shared filter, defensible nos) vs. holistic/tacit vision (some directors carry coherence without formalizing it, and worry pillars ossify or oversimplify). most teams benefit from explicit pillars precisely because the vision must be shared across many people; solo auteurs can carry it tacitly. the operational form of the vision (vision-0001), the engine of principled nos (vision-0003) and anti-creep (prod-0002). confidence 4.


A great game is shaped as much by what it leaves out as by what it includes. Good ideas arrive endlessly; the vision's job is to reject the ones that don't fit — not because they're bad, but because they don't serve this game. Saying no is how coherence survives contact with a hundred good ideas.

---
id: GDC-L1-VISION-0003
title: Say no to protect coherence — a game is defined by what it excludes
layer: L1
domain: VISION
subdomain: saying-no
type: contextual
confidence: 4
status: canonical
tags:
  - vision
  - saying-no
  - coherence
  - focus
  - cutting
related:
  - GDC-L1-DESIGN-0007
  - GDC-L1-PROTO-0005
  - GDC-L1-PROD-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-design-pillars
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> A great game is shaped as much by what it leaves out as by what it includes. Good ideas
> arrive endlessly; the vision's job is to **reject the ones that don't fit** — not because
> they're bad, but because they don't serve *this* game. Saying no is how coherence survives
> contact with a hundred good ideas.

## Rationale
The threat to a game's coherence is rarely bad ideas — it's an abundance of *good* ones, each
of which pulls the design a little toward a different game until it becomes an incoherent pile
of features that don't harmonize [S-design-pillars]. So the discipline of exclusion is not
negativity; it's authorship. Pillars (VISION-0002) make the no defensible and impersonal: the
answer isn't "your idea is bad," it's "that doesn't fit this game," which protects both the
vision and the relationship. This is the vision-side expression of elegance (DESIGN-0007) and
kill-your-darlings (PROTO-0005): a focused game that does a few things brilliantly beats a
diffuse one that does many things adequately, and getting there requires saying no far more
often than yes.

## Applies when
Every point where ideas are proposed and decisions made — design reviews, feature requests,
scope decisions. Especially where the director/vision-holder is "bombarded with ideas."

## Does not apply / Exceptions
Saying no must not become reflexive rejection that starves the game of genuine improvement —
some ideas *should* change the vision, and iteration reveals features worth adding (PROTO-0006,
PROD-0002's caveat). The skill is discerning ideas that don't fit from ideas that reveal the
game should grow. And no should be *reasoned* (against the pillars), not authoritarian whim —
that's what keeps it legitimate.

## Implementation (kept separate from the principle)
Filter ideas through the pillars (VISION-0002) and reject what doesn't serve them, framing the
no as "doesn't fit *this* game." Keep a "cut/later" list so rejected-but-good ideas are honored
without being built now (PROTO-0005). Distinguish "doesn't fit" (cut) from "the game should
change" (a vision decision, VISION-0001). Protect the core while trimming the periphery
(PROD-0001).

## Disagreement
Tight, exclusionary focus (coherence, elegance, a game that does a few things brilliantly) vs.
inclusive, maximalist abundance (richness through many systems — DESIGN-0007's stylistic
counter-pole). Both produce great games; the failure modes are blandness (over-cutting the
soul) and incoherence (never saying no). The vision decides which the game wants.

## Notes
The vision-side of elegance (DESIGN-0007) and cutting (PROTO-0005, PROD-0002); powered by
pillars (VISION-0002). Confidence 4.

gdc-l1-vision-0003 say no to protect coherence — a game is defined by what it excludes vision saying-no coherence focus cutting > a great game is shaped as much by what it leaves out as by what it includes. good ideas arrive endlessly; the vision's job is to reject the ones that don't fit — not because they're bad, but because they don't serve this game. saying no is how coherence survives contact with a hundred good ideas. the threat to a game's coherence is rarely bad ideas — it's an abundance of good ones, each of which pulls the design a little toward a different game until it becomes an incoherent pile of features that don't harmonize [s-design-pillars]. so the discipline of exclusion is not negativity; it's authorship. pillars (vision-0002) make the no defensible and impersonal: the answer isn't "your idea is bad," it's "that doesn't fit this game," which protects both the vision and the relationship. this is the vision-side expression of elegance (design-0007) and kill-your-darlings (proto-0005): a focused game that does a few things brilliantly beats a diffuse one that does many things adequately, and getting there requires saying no far more often than yes. every point where ideas are proposed and decisions made — design reviews, feature requests, scope decisions. especially where the director/vision-holder is "bombarded with ideas." saying no must not become reflexive rejection that starves the game of genuine improvement — some ideas should change the vision, and iteration reveals features worth adding (proto-0006, prod-0002's caveat). the skill is discerning ideas that don't fit from ideas that reveal the game should grow. and no should be reasoned (against the pillars), not authoritarian whim — that's what keeps it legitimate. filter ideas through the pillars (vision-0002) and reject what doesn't serve them, framing the no as "doesn't fit this game." keep a "cut/later" list so rejected-but-good ideas are honored without being built now (proto-0005). distinguish "doesn't fit" (cut) from "the game should change" (a vision decision, vision-0001). protect the core while trimming the periphery (prod-0001). tight, exclusionary focus (coherence, elegance, a game that does a few things brilliantly) vs. inclusive, maximalist abundance (richness through many systems — design-0007's stylistic counter-pole). both produce great games; the failure modes are blandness (over-cutting the soul) and incoherence (never saying no). the vision decides which the game wants. the vision-side of elegance (design-0007) and cutting (proto-0005, prod-0002); powered by pillars (vision-0002). confidence 4.


Someone must own the creative vision and hold final say on ambiguous calls. When no one is accountable for coherence, design-by-committee dilutes the vision into a compromise that serves everyone's preferences and no clear experience. A vision-holder keeps the game pointing one direction — while still listening.

---
id: GDC-L1-VISION-0004
title: Give the vision an owner — coherence needs decision authority
layer: L1
domain: VISION
subdomain: decision-making-authority
type: stylistic
confidence: 3
status: canonical
tags:
  - vision
  - authority
  - director
  - decision-making
  - coherence
related:
  - GDC-L1-VISION-0001
  - GDC-L1-TEAM-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-design-pillars
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Someone must **own** the creative vision and hold final say on ambiguous calls. When no one
> is accountable for coherence, design-by-committee dilutes the vision into a compromise that
> serves everyone's preferences and no clear experience. A vision-holder keeps the game
> pointing one direction — while still listening.

## Rationale
Coherence (VISION-0001) requires that conflicting good ideas be *resolved*, not averaged, and
averaging is what happens when authority is diffuse — every stakeholder gets a piece, and the
result points nowhere in particular [S-design-pillars]. A clear owner (a creative/game
director) provides a single point of accountability for the whole experience, so hard calls get
made decisively and the game keeps its identity. Crucially, "owner" is not "dictator": the best
vision-holders listen hard, delegate, and change their minds on evidence (DESIGN-0001,
PLAYTEST-0004) — they own the *decision*, not every idea. The point is that *someone* is
responsible for coherence, so it doesn't fall through the cracks between equals.

## Applies when
Any multi-person project where creative decisions conflict — which is all of them. The larger
and more cross-disciplinary the team, the more a clear vision-holder matters.

## Does not apply / Exceptions
This is genuinely contested (hence stylistic). Flat, highly-collaborative, and small
peer-teams can hold a shared vision without a single boss, and some celebrated studios work
collectively; concentrated authority can also become an ego bottleneck or silence the team
(harming psychological safety, TEAM-0001). The principle is that *coherence needs an owner*,
not that one person should dominate — and that owner can be a tight, aligned group rather than
an individual.

## Implementation (kept separate from the principle)
Name who owns the vision and holds final say on ambiguous creative calls. Pair the authority
with genuine listening and safety to disagree (TEAM-0001) so it aggregates the team's insight
rather than overriding it. Delegate freely within the pillars (VISION-0002). Use authority to
*resolve*, not to *dictate* — decide when there's genuine ambiguity, not to win arguments.

## Disagreement
Auteur/director model (single clear vision-holder — coherence, decisiveness, identity) vs. collaborative/flat model (shared ownership — buy-in, resilience, more voices; risk of design-by-committee). Both have produced masterpieces. Typed `stylistic` because it's a real values choice.

## Notes
Where VISION meets TEAM — authority (this) must be balanced with psychological safety
(TEAM-0001) to avoid becoming a bottleneck. Confidence 3: genuinely contested organizational
question, not weak evidence.

gdc-l1-vision-0004 give the vision an owner — coherence needs decision authority vision authority director decision-making coherence > someone must own the creative vision and hold final say on ambiguous calls. when no one is accountable for coherence, design-by-committee dilutes the vision into a compromise that serves everyone's preferences and no clear experience. a vision-holder keeps the game pointing one direction — while still listening. coherence (vision-0001) requires that conflicting good ideas be resolved, not averaged, and averaging is what happens when authority is diffuse — every stakeholder gets a piece, and the result points nowhere in particular [s-design-pillars]. a clear owner (a creative/game director) provides a single point of accountability for the whole experience, so hard calls get made decisively and the game keeps its identity. crucially, "owner" is not "dictator": the best vision-holders listen hard, delegate, and change their minds on evidence (design-0001, playtest-0004) — they own the decision, not every idea. the point is that someone is responsible for coherence, so it doesn't fall through the cracks between equals. any multi-person project where creative decisions conflict — which is all of them. the larger and more cross-disciplinary the team, the more a clear vision-holder matters. this is genuinely contested (hence stylistic). flat, highly-collaborative, and small peer-teams can hold a shared vision without a single boss, and some celebrated studios work collectively; concentrated authority can also become an ego bottleneck or silence the team (harming psychological safety, team-0001). the principle is that coherence needs an owner, not that one person should dominate — and that owner can be a tight, aligned group rather than an individual. name who owns the vision and holds final say on ambiguous creative calls. pair the authority with genuine listening and safety to disagree (team-0001) so it aggregates the team's insight rather than overriding it. delegate freely within the pillars (vision-0002). use authority to resolve, not to dictate — decide when there's genuine ambiguity, not to win arguments. auteur/director model (single clear vision-holder — coherence, decisiveness, identity) vs. collaborative/flat model (shared ownership — buy-in, resilience, more voices; risk of design-by-committee). both have produced masterpieces. typed stylistic because it's a real values choice. where vision meets team — authority (this) must be balanced with psychological safety (team-0001) to avoid becoming a bottleneck. confidence 3: genuinely contested organizational question, not weak evidence.


A vision only aligns a team if it can be communicated. Distill it to a short, sharp statement — the hook, the elevator pitch — that everyone can hold in their head. If you can't say what the game is in a sentence or two, the vision isn't yet clear enough to build from.

---
id: GDC-L1-VISION-0005
title: Make the vision communicable — if you can't say it simply, it isn't clear
layer: L1
domain: VISION
subdomain: the-hook
type: contextual
confidence: 3
status: canonical
tags:
  - vision
  - communication
  - hook
  - pitch
  - alignment
related:
  - GDC-L1-VISION-0001
  - GDC-L1-UX-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-design-pillars
  - S-schell-artofgamedesign
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> A vision only aligns a team if it can be *communicated*. Distill it to a short, sharp
> statement — the hook, the elevator pitch — that everyone can hold in their head. If you can't
> say what the game is in a sentence or two, the vision isn't yet clear enough to build from.

## Rationale
A vision that lives only in the director's head, or in a fifty-page document no one internalizes,
can't do its job of aligning distributed decisions (VISION-0001) [S-design-pillars]. The
discipline of compressing it to a hook is also a test *of* the vision: if you can't state the
game crisply, that usually means the concept itself is muddy, not merely under-described. A
strong, memorable statement of the intended experience becomes the thing every team member
carries and checks against, the pitch that sells the game to funders and players, and the filter
that makes pillars (VISION-0002) and nos (VISION-0003) legible. Clarity of expression and
clarity of thought reinforce each other.

## Applies when
Communicating the vision to the team, to stakeholders, and to yourself as a clarity check.
Valuable from the first pitch through shipping and marketing.

## Does not apply / Exceptions
Some genuinely novel or experiential games resist one-sentence pitches, and forcing a glib hook
can trivialize a subtle experience — "can't be pitched in a sentence" is not always "unclear
vision" (some art is exactly the experience of playing it). Solo devs may not need to externalize
the pitch. And a catchy hook is not sufficient — it must be *true* to a real, coherent vision,
not marketing over emptiness.

## Implementation (kept separate from the principle)
Write the game as a short hook / elevator pitch and refine it until it's sharp and true. Use it
to onboard team members and align stakeholders. Treat difficulty compressing it as a signal to
clarify the *concept*, not just the wording (a clarity check on VISION-0001). Pair it with the
pillars (VISION-0002) for the operational detail. Good communication here is the same discipline
as good UX (UX-0003): make the important idea legible at a glance.

## Disagreement
Pitchable clarity (a sharp hook aligns and sells; if you can't say it, it's muddy) vs.
irreducible experiences (some deep or novel games genuinely can't be captured in a sentence, and
demanding a hook can cheapen them). The tension is realest for experimental and art games; for
most commercial games, a clear hook is a genuine asset and a useful clarity test.

## Notes
The communication face of the vision (VISION-0001) and an application of UX-0003 (communicate the
important thing clearly) to the vision itself. Confidence 3: broadly useful, but the
"irreducible experience" exception is real for some games.

gdc-l1-vision-0005 make the vision communicable — if you can't say it simply, it isn't clear vision communication hook pitch alignment > a vision only aligns a team if it can be communicated. distill it to a short, sharp statement — the hook, the elevator pitch — that everyone can hold in their head. if you can't say what the game is in a sentence or two, the vision isn't yet clear enough to build from. a vision that lives only in the director's head, or in a fifty-page document no one internalizes, can't do its job of aligning distributed decisions (vision-0001) [s-design-pillars]. the discipline of compressing it to a hook is also a test of the vision: if you can't state the game crisply, that usually means the concept itself is muddy, not merely under-described. a strong, memorable statement of the intended experience becomes the thing every team member carries and checks against, the pitch that sells the game to funders and players, and the filter that makes pillars (vision-0002) and nos (vision-0003) legible. clarity of expression and clarity of thought reinforce each other. communicating the vision to the team, to stakeholders, and to yourself as a clarity check. valuable from the first pitch through shipping and marketing. some genuinely novel or experiential games resist one-sentence pitches, and forcing a glib hook can trivialize a subtle experience — "can't be pitched in a sentence" is not always "unclear vision" (some art is exactly the experience of playing it). solo devs may not need to externalize the pitch. and a catchy hook is not sufficient — it must be true to a real, coherent vision, not marketing over emptiness. write the game as a short hook / elevator pitch and refine it until it's sharp and true. use it to onboard team members and align stakeholders. treat difficulty compressing it as a signal to clarify the concept, not just the wording (a clarity check on vision-0001). pair it with the pillars (vision-0002) for the operational detail. good communication here is the same discipline as good ux (ux-0003): make the important idea legible at a glance. pitchable clarity (a sharp hook aligns and sells; if you can't say it, it's muddy) vs. irreducible experiences (some deep or novel games genuinely can't be captured in a sentence, and demanding a hook can cheapen them). the tension is realest for experimental and art games; for most commercial games, a clear hook is a genuine asset and a useful clarity test. the communication face of the vision (vision-0001) and an application of ux-0003 (communicate the important thing clearly) to the vision itself. confidence 3: broadly useful, but the "irreducible experience" exception is real for some games.


Teams do their best work when members feel safe to speak up, disagree, ask "obvious" questions, admit mistakes, and take interpersonal risks without fear of humiliation or punishment. Psychological safety — the shared belief that the team is safe for that risk — is a foundational condition for effective teamwork. Protect it deliberately.

---
id: GDC-L1-TEAM-0001
title: Psychological safety is the foundation of good teamwork
layer: L1
domain: TEAM
subdomain: psychological-safety
type: contextual
confidence: 4
status: canonical
tags:
  - team
  - psychological-safety
  - culture
  - collaboration
related:
  - GDC-L1-TEAM-0002
  - GDC-L1-TEAM-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-edmondson-psych-safety
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Teams do their best work when members feel safe to speak up, disagree, ask "obvious"
> questions, admit mistakes, and take interpersonal risks without fear of humiliation or
> punishment. **Psychological safety** — the shared belief that the team is safe for that risk
> — is a foundational condition for effective teamwork. Protect it deliberately.

## Rationale
Google's Project Aristotle ranked psychological safety first among five internal dynamics it
associated with effective teams, building on Amy Edmondson's research into learning behavior
[S-edmondson-psych-safety]. The mechanism is direct: making games well depends on people
surfacing problems early, challenging bad ideas, admitting when they're stuck, and proposing
risky creative bets — and *all* of that requires feeling safe to do it. In an unsafe team,
people hide mistakes (which then compound), stay quiet about problems they see, defer to the
loudest voice, and avoid the creative risks that good games need. Safety isn't softness; it's
the precondition for the honest disagreement and fast failure that quality actually requires.

## Applies when
Every team, at every scale — and especially any team doing creative, uncertain work where
speaking up, disagreeing, and failing are part of the job (i.e. all game development).

## Does not apply / Exceptions
Psychological safety is not the absence of standards or accountability — it's what lets high
standards be *pursued honestly* (you can admit a miss and fix it) rather than hidden. It is also
not "no conflict"; healthy teams disagree vigorously *because* it's safe to. The failure mode to
avoid is confusing safety with comfort or with never being challenged — safety enables challenge,
it doesn't forbid it.

## Implementation (kept separate from the principle)
Leaders model fallibility (admit their own mistakes and unknowns), invite dissent explicitly, and respond to bad news with curiosity rather than blame (TEAM-0003). Create deliberate opportunities for quieter voices to contribute. Separate critique of the work from the person (TEAM-0002).

## Disagreement
Little serious dissent that psychological safety helps; the nuance is guarding against its
*misreading* as low standards or conflict-avoidance. High-performing cultures pair high safety
with high standards — safety to speak, rigor about the work.

## Notes
Confidence 4.

gdc-l1-team-0001 psychological safety is the foundation of good teamwork team psychological-safety culture collaboration > teams do their best work when members feel safe to speak up, disagree, ask "obvious" questions, admit mistakes, and take interpersonal risks without fear of humiliation or punishment. psychological safety — the shared belief that the team is safe for that risk — is a foundational condition for effective teamwork. protect it deliberately. google's project aristotle ranked psychological safety first among five internal dynamics it associated with effective teams, building on amy edmondson's research into learning behavior [s-edmondson-psych-safety]. the mechanism is direct: making games well depends on people surfacing problems early, challenging bad ideas, admitting when they're stuck, and proposing risky creative bets — and all of that requires feeling safe to do it. in an unsafe team, people hide mistakes (which then compound), stay quiet about problems they see, defer to the loudest voice, and avoid the creative risks that good games need. safety isn't softness; it's the precondition for the honest disagreement and fast failure that quality actually requires. every team, at every scale — and especially any team doing creative, uncertain work where speaking up, disagreeing, and failing are part of the job (i.e. all game development). psychological safety is not the absence of standards or accountability — it's what lets high standards be pursued honestly (you can admit a miss and fix it) rather than hidden. it is also not "no conflict"; healthy teams disagree vigorously because it's safe to. the failure mode to avoid is confusing safety with comfort or with never being challenged — safety enables challenge, it doesn't forbid it. leaders model fallibility (admit their own mistakes and unknowns), invite dissent explicitly, and respond to bad news with curiosity rather than blame (team-0003). create deliberate opportunities for quieter voices to contribute. separate critique of the work from the person (team-0002). little serious dissent that psychological safety helps; the nuance is guarding against its misreading as low standards or conflict-avoidance. high-performing cultures pair high safety with high standards — safety to speak, rigor about the work. confidence 4.


Critique the work, not the person

Separate the idea from the person who had it. Honest, direct critique of the work is how it gets better; attacks on the person shut down the safety that makes critique possible. Give and receive feedback about the thing, not the maker — and hold your own ideas loosely enough to let them be cut.

---
id: GDC-L1-TEAM-0002
title: Critique the work, not the person
layer: L1
domain: TEAM
subdomain: feedback-culture
type: contextual
confidence: 4
status: canonical
tags:
  - team
  - feedback
  - critique
  - egoless
  - culture
related:
  - GDC-L1-TEAM-0001
  - GDC-L1-PROTO-0005
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-edmondson-psych-safety
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Separate the idea from the person who had it. Honest, direct critique of *the work* is how it
> gets better; attacks on *the person* shut down the safety that makes critique possible. Give
> and receive feedback about the thing, not the maker — and hold your own ideas loosely enough
> to let them be cut.

## Rationale
A team improves its work through candid evaluation, but candor only survives if it's aimed at the
work rather than the worker: "this mechanic is confusing" invites improvement, while "you're a
bad designer" invites defensiveness and silence [S-edmondson-psych-safety]. Keeping critique
egoless protects psychological safety (TEAM-0001) *and* the quality of the feedback — people can
hear hard truths about their work when their standing isn't under attack, and they can *give*
hard truths when doing so isn't read as a personal assault. It also requires the receiving side:
holding your ideas loosely (not fusing your identity to them) is what lets you kill your own
darlings (PROTO-0005) and take feedback as help rather than threat. The goal is a team that can
be ruthless about the work precisely *because* it's kind to the people.

## Applies when
Every review, critique, playtest debrief, and design debate — any moment feedback is exchanged.

## Does not apply / Exceptions
Sometimes feedback *is* rightly about a person's behavior or growth (a pattern of missed commitments, a skill to develop) — but that's a direct, private, growth-framed conversation, not public critique disguised as work-feedback. Kind to people, rigorous about the work — not the reverse.

## Implementation (kept separate from the principle)
Frame feedback about the artifact and its effect ("this reads as X", "players got lost here"), not the author's character. Critique your *own* work in the same egoless terms to model it. Build rituals (design reviews, playtest debriefs) where critiquing the work is normal and expected. Separate identity from idea so cutting a feature (PROTO-0005) isn't experienced as a personal loss.

## Disagreement
Little on the principle; the nuance is calibrating *directness* — some cultures prize blunt
candor, others gentler framing, and individuals differ. The invariant is target-the-work; the
tone is a cultural and personal variable.

## Notes
Confidence 4.

gdc-l1-team-0002 critique the work, not the person team feedback critique egoless culture > separate the idea from the person who had it. honest, direct critique of the work is how it gets better; attacks on the person shut down the safety that makes critique possible. give and receive feedback about the thing, not the maker — and hold your own ideas loosely enough to let them be cut. a team improves its work through candid evaluation, but candor only survives if it's aimed at the work rather than the worker: "this mechanic is confusing" invites improvement, while "you're a bad designer" invites defensiveness and silence [s-edmondson-psych-safety]. keeping critique egoless protects psychological safety (team-0001) and the quality of the feedback — people can hear hard truths about their work when their standing isn't under attack, and they can give hard truths when doing so isn't read as a personal assault. it also requires the receiving side: holding your ideas loosely (not fusing your identity to them) is what lets you kill your own darlings (proto-0005) and take feedback as help rather than threat. the goal is a team that can be ruthless about the work precisely because it's kind to the people. every review, critique, playtest debrief, and design debate — any moment feedback is exchanged. sometimes feedback is rightly about a person's behavior or growth (a pattern of missed commitments, a skill to develop) — but that's a direct, private, growth-framed conversation, not public critique disguised as work-feedback. kind to people, rigorous about the work — not the reverse. frame feedback about the artifact and its effect ("this reads as x", "players got lost here"), not the author's character. critique your own work in the same egoless terms to model it. build rituals (design reviews, playtest debriefs) where critiquing the work is normal and expected. separate identity from idea so cutting a feature (proto-0005) isn't experienced as a personal loss. little on the principle; the nuance is calibrating directness — some cultures prize blunt candor, others gentler framing, and individuals differ. the invariant is target-the-work; the tone is a cultural and personal variable. confidence 4.


When something goes wrong, focus on understanding the contributing causes and improving the system, not on assigning fault. Blameless postmortems surface the real, fixable causes because people can be honest; blame drives problems underground, where they repeat.

---
id: GDC-L1-TEAM-0003
title: Run blameless postmortems — treat failure as a system to fix
layer: L1
domain: TEAM
subdomain: conflict
type: contextual
confidence: 4
status: canonical
tags:
  - team
  - postmortem
  - blameless
  - learning
  - culture
related:
  - GDC-L1-TEAM-0001
  - GDC-L1-DESIGN-0001
  - GDC-L1-PLAYTEST-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-google-sre-postmortem
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> When something goes wrong, focus on understanding the *contributing causes* and improving the
> *system*, not on assigning fault. **Blameless postmortems** surface the real, fixable causes
> because people can be honest; blame drives problems underground, where they repeat.

## Rationale
Most failures are produced by systems and circumstances, not villains, and the fastest way to
*hide* a failure's true causes is to punish the person nearest to it [S-google-sre-postmortem].
When blame is the response, people conceal mistakes, omit the awkward details, and defend
themselves instead of explaining what actually happened — so the organization never learns, and
the same failure recurs. A blameless stance flips this: by treating an incident as a
learning opportunity about the system ("what let this happen, and how do we make it not happen
again?"), you get the honesty required to actually fix root causes. It's the team-process form of
the same commitment that runs through the whole constitution — learn from what *actually
happened* (DESIGN-0001, PLAYTEST-0001), not from what should have.

## Applies when
After any significant failure, incident, bug, missed milestone, or bad launch — and as a standing
cultural default for how the team responds to things going wrong.

## Does not apply / Exceptions
Blameless is about *learning*, not the absence of accountability — repeated negligence or bad-faith
behavior is a real management issue, handled directly and (usually) privately. And blameless does
not mean consequence-free for the *system*: the point is to change the process so the failure
can't recur. The invariant is: attack the cause, not the person, so the truth comes out.

## Implementation (kept separate from the principle)
After a failure, ask "what contributing causes let this happen?" rather than "whose fault was
it?" Write it down and change the system (process, tooling, checks) so it can't recur. Make it
safe to report problems early (TEAM-0001) by responding to bad news with curiosity, not
punishment. Separate the incident-learning from any genuine personnel issue (handle the latter
directly and privately, TEAM-0002).

## Disagreement
Little serious dissent in modern practice; the tension is only the misread that "blameless" means
"no accountability." Healthy cultures keep accountability for *behavior* while keeping the
*learning* process blameless — the two aren't in conflict.

## Notes
The failure-learning practice built on psychological safety (TEAM-0001); the team-process echo of
"judge by what actually happened" (DESIGN-0001, PLAYTEST-0001). Confidence 4.

gdc-l1-team-0003 run blameless postmortems — treat failure as a system to fix team postmortem blameless learning culture > when something goes wrong, focus on understanding the contributing causes and improving the system, not on assigning fault. blameless postmortems surface the real, fixable causes because people can be honest; blame drives problems underground, where they repeat. most failures are produced by systems and circumstances, not villains, and the fastest way to hide a failure's true causes is to punish the person nearest to it [s-google-sre-postmortem]. when blame is the response, people conceal mistakes, omit the awkward details, and defend themselves instead of explaining what actually happened — so the organization never learns, and the same failure recurs. a blameless stance flips this: by treating an incident as a learning opportunity about the system ("what let this happen, and how do we make it not happen again?"), you get the honesty required to actually fix root causes. it's the team-process form of the same commitment that runs through the whole constitution — learn from what actually happened (design-0001, playtest-0001), not from what should have. after any significant failure, incident, bug, missed milestone, or bad launch — and as a standing cultural default for how the team responds to things going wrong. blameless is about learning, not the absence of accountability — repeated negligence or bad-faith behavior is a real management issue, handled directly and (usually) privately. and blameless does not mean consequence-free for the system: the point is to change the process so the failure can't recur. the invariant is: attack the cause, not the person, so the truth comes out. after a failure, ask "what contributing causes let this happen?" rather than "whose fault was it?" write it down and change the system (process, tooling, checks) so it can't recur. make it safe to report problems early (team-0001) by responding to bad news with curiosity, not punishment. separate the incident-learning from any genuine personnel issue (handle the latter directly and privately, team-0002). little serious dissent in modern practice; the tension is only the misread that "blameless" means "no accountability." healthy cultures keep accountability for behavior while keeping the learning process blameless — the two aren't in conflict. the failure-learning practice built on psychological safety (team-0001); the team-process echo of "judge by what actually happened" (design-0001, playtest-0001). confidence 4.


A team can only align on decisions it can see and remember. Record settled decisions where everyone can find them, and make the reasoning visible — shared understanding, not private knowledge, is what keeps a distributed effort coherent. Undocumented decisions are lost decisions.

---
id: GDC-L1-TEAM-0004
title: Make decisions shared, visible, and durable
layer: L1
domain: TEAM
subdomain: communication
type: contextual
confidence: 4
status: canonical
tags:
  - team
  - communication
  - documentation
  - alignment
  - decisions
related:
  - GDC-L1-VISION-0001
  - GDC-L1-TEAM-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-schell-artofgamedesign
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> A team can only align on decisions it can *see* and *remember*. Record settled decisions where
> everyone can find them, and make the reasoning visible — shared understanding, not private
> knowledge, is what keeps a distributed effort coherent. Undocumented decisions are lost
> decisions.

## Rationale
Coherence (VISION-0001) is a property of shared understanding, and understanding that lives only
in one person's head or in a hallway conversation doesn't scale past that moment
[S-schell-artofgamedesign]. Decisions get re-litigated, contradicted, or silently forgotten;
new members and future-you can't reconstruct *why* something is the way it is; and the same
debates recur. Making decisions visible and durable — written down, findable, with their
reasoning — turns the team's accumulated choices into a shared, persistent memory that keeps
everyone building the same game. It also enables honest disagreement to *resolve* rather than
recur, because a settled decision is recorded rather than perpetually reopened. (This
constitution — and its `STATUS.md` session tracker — is itself an instance of the principle.)

## Applies when
Any team with more than a couple of people, any project spanning enough time that people forget,
and especially distributed, async, or long-lived efforts. The larger and longer, the more it
matters.

## Does not apply / Exceptions
Over-documentation is a real cost — a team can drown in process and write docs no one reads, which
is its own failure. The bar is *decisions and their reasoning*, not every detail; capture what
future-you and new members genuinely need. Very small, co-located teams can hold much in shared
conversation, though even they drift without some durable record.

## Implementation (kept separate from the principle)
Record settled decisions and *why* somewhere findable (a design doc, a decision log, a tracker). Make the reasoning visible, not just the conclusion. Keep it lightweight enough that it's actually maintained. Revisit and update as decisions change — a stale record misleads.

## Disagreement
Documentation-heavy (durable, scalable, but risks process bloat and unread docs) vs. lightweight/
conversational (fast, low-overhead, but forgetful and hard to scale). The balance depends on team
size, distribution, and project length — more of both as those grow.

## Notes
Confidence 4.

gdc-l1-team-0004 make decisions shared, visible, and durable team communication documentation alignment decisions > a team can only align on decisions it can see and remember. record settled decisions where everyone can find them, and make the reasoning visible — shared understanding, not private knowledge, is what keeps a distributed effort coherent. undocumented decisions are lost decisions. coherence (vision-0001) is a property of shared understanding, and understanding that lives only in one person's head or in a hallway conversation doesn't scale past that moment [s-schell-artofgamedesign]. decisions get re-litigated, contradicted, or silently forgotten; new members and future-you can't reconstruct why something is the way it is; and the same debates recur. making decisions visible and durable — written down, findable, with their reasoning — turns the team's accumulated choices into a shared, persistent memory that keeps everyone building the same game. it also enables honest disagreement to resolve rather than recur, because a settled decision is recorded rather than perpetually reopened. (this constitution — and its status.md session tracker — is itself an instance of the principle.) any team with more than a couple of people, any project spanning enough time that people forget, and especially distributed, async, or long-lived efforts. the larger and longer, the more it matters. over-documentation is a real cost — a team can drown in process and write docs no one reads, which is its own failure. the bar is decisions and their reasoning, not every detail; capture what future-you and new members genuinely need. very small, co-located teams can hold much in shared conversation, though even they drift without some durable record. record settled decisions and why somewhere findable (a design doc, a decision log, a tracker). make the reasoning visible, not just the conclusion. keep it lightweight enough that it's actually maintained. revisit and update as decisions change — a stale record misleads. documentation-heavy (durable, scalable, but risks process bloat and unread docs) vs. lightweight/ conversational (fast, low-overhead, but forgetful and hard to scale). the balance depends on team size, distribution, and project length — more of both as those grow. confidence 4.


Small teams with autonomy and mixed disciplines tend to move faster and stay more coherent than large, siloed, permission-gated ones. Communication cost grows with team size; empowerment and cross-discipline collaboration keep decisions close to the work and the vision easy to share.

---
id: GDC-L1-TEAM-0005
title: Prefer small, empowered, cross-disciplinary teams
layer: L1
domain: TEAM
subdomain: collaboration
type: stylistic
confidence: 3
status: canonical
tags:
  - team
  - small-teams
  - autonomy
  - cross-discipline
  - communication-cost
related:
  - GDC-L1-TEAM-0001
  - GDC-L1-PROD-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-edmondson-psych-safety
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Small teams with autonomy and mixed disciplines tend to move faster and stay more coherent than
> large, siloed, permission-gated ones. Communication cost grows with team size; empowerment and
> cross-discipline collaboration keep decisions close to the work and the vision easy to share.

## Rationale
The number of communication links in a team grows combinatorially with its size, so every added
person raises coordination overhead and dilutes shared context — which is why small teams can
hold a vision (VISION-0001) in common almost effortlessly while large ones need heavy process to
approximate it. Autonomy compounds the benefit: when a small team can decide and act without
gatekeeping, decisions stay close to the people doing the work and the feedback loop tightens.
Cross-discipline collaboration (designers, artists, engineers working *together* rather than
handing off over walls) surfaces problems and opportunities that siloed pipelines miss. None of
this makes big teams *wrong* — they're necessary for large-scope games — but it explains why small,
empowered, mixed teams punch above their weight and why scaling a team has real costs, not just
benefits.

## Applies when
Team structure and org decisions, and the recurring "should we add people?" question (recall that
adding people to a late project often *slows* it — PROD's staffing caution). Especially relevant
to indie and small-studio contexts.

## Does not apply / Exceptions
Large-scope games (big-budget AAA) genuinely require large teams, and at scale you *need*
structure, specialization, and process that a small team can skip — so this is a preference, not a
law (hence stylistic). Deep specialization also has real value that pure generalist small teams
lack. The principle is "keep teams as small and empowered as the scope allows," not "small is
always better regardless of scope."

## Implementation (kept separate from the principle)
Keep teams as small as the scope permits; resist adding people as a reflex (scope down instead, PROD-0001). Grant autonomy — decisions close to the work. Compose teams cross-functionally so disciplines collaborate rather than hand off.

## Disagreement
Small-and-autonomous (speed, coherence, low overhead, but limited capacity and depth) vs.
large-and-specialized (scale, deep expertise, but coordination cost and diluted context). The
right structure follows the scope; the failure modes are under-capacity (too small for the
ambition) and coordination-collapse (too big without structure). Typed stylistic as a genuine
org-design values choice.

## Notes
Confidence 3: a real preference, genuinely bounded by project scope.

gdc-l1-team-0005 prefer small, empowered, cross-disciplinary teams team small-teams autonomy cross-discipline communication-cost > small teams with autonomy and mixed disciplines tend to move faster and stay more coherent than large, siloed, permission-gated ones. communication cost grows with team size; empowerment and cross-discipline collaboration keep decisions close to the work and the vision easy to share. the number of communication links in a team grows combinatorially with its size, so every added person raises coordination overhead and dilutes shared context — which is why small teams can hold a vision (vision-0001) in common almost effortlessly while large ones need heavy process to approximate it. autonomy compounds the benefit: when a small team can decide and act without gatekeeping, decisions stay close to the people doing the work and the feedback loop tightens. cross-discipline collaboration (designers, artists, engineers working together rather than handing off over walls) surfaces problems and opportunities that siloed pipelines miss. none of this makes big teams wrong — they're necessary for large-scope games — but it explains why small, empowered, mixed teams punch above their weight and why scaling a team has real costs, not just benefits. team structure and org decisions, and the recurring "should we add people?" question (recall that adding people to a late project often slows it — prod's staffing caution). especially relevant to indie and small-studio contexts. large-scope games (big-budget aaa) genuinely require large teams, and at scale you need structure, specialization, and process that a small team can skip — so this is a preference, not a law (hence stylistic). deep specialization also has real value that pure generalist small teams lack. the principle is "keep teams as small and empowered as the scope allows," not "small is always better regardless of scope." keep teams as small as the scope permits; resist adding people as a reflex (scope down instead, prod-0001). grant autonomy — decisions close to the work. compose teams cross-functionally so disciplines collaborate rather than hand off. small-and-autonomous (speed, coherence, low overhead, but limited capacity and depth) vs. large-and-specialized (scale, deep expertise, but coordination cost and diluted context). the right structure follows the scope; the failure modes are under-capacity (too small for the ambition) and coordination-collapse (too big without structure). typed stylistic as a genuine org-design values choice. confidence 3: a real preference, genuinely bounded by project scope.


A game gets one launch, and its state at that moment — stability, performance, onboarding, and polish of the first hour — disproportionately shapes reviews, word of mouth, and long-term reception. First impressions are sticky and costly to reverse. Treat launch readiness as a deliberate goal, not the moment you happen to run out of time.

---
id: GDC-L1-SHIP-0001
title: You get one first impression — the launch state shapes the game's reception
layer: L1
domain: SHIP
subdomain: launch-readiness
type: contextual
confidence: 4
status: canonical
tags:
  - shipping
  - launch
  - first-impression
  - stability
  - reputation
related:
  - GDC-L1-QA-0004
  - GDC-L1-UX-0001
  - GDC-L1-PROD-0006
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-scope-production
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> A game gets one launch, and its state at that moment — stability, performance, onboarding, and
> polish of the first hour — disproportionately shapes reviews, word of mouth, and long-term
> reception. First impressions are sticky and costly to reverse. Treat launch readiness as a
> deliberate goal, not the moment you happen to run out of time.

## Rationale
Launch is when the largest audience arrives at once, forms opinions fast, and broadcasts them
(reviews, streams, social) — and those early opinions harden into the game's reputation, which is
extremely hard to change later even if the game improves [S-scope-production]. A broken, sluggish,
or confusing launch (crashes, bad performance on common hardware — QA-0004, a baffling first hour —
UX-0001) squanders the one moment of peak attention, while a solid launch compounds into momentum.
This raises the stakes on finishing well (PROD-0006), on testing under real conditions before
release (QA-0004), and on the onboarding experience specifically (UX-0001), because the first hour
is what most players judge on. "We'll patch it later" underestimates how much the *first* impression
persists.

## Applies when
Any release to a real audience — launch especially, but also major updates, betas, and demos that
create first impressions.

## Does not apply / Exceptions
Early-access and live-service models deliberately launch *unfinished* — but they set the
expectation explicitly and still must nail the first impression *for what they claim to be*
(a rough early-access launch that oversells itself still burns trust). And no launch is
bug-free; the bar is "good enough that the first impression is positive," not "perfect." Small or
niche launches carry lower stakes but the same logic.

## Implementation (kept separate from the principle)
Define launch-readiness criteria (stability, performance on target hardware — QA-0004, a strong
first hour — UX-0001) and hold the release to them; if you can't hit them, cut scope or delay
rather than launch broken (PROD-0001/0006). Prioritize the first-hour experience and common-case
stability. Prepare day-one support (SHIP-0004). Set honest expectations for what the launch *is*
(especially for early access).

## Disagreement
Ship-when-ready/delay-for-quality (protect the first impression — but cost of delay, missed windows)
vs. ship-on-date-and-patch (hit the market/marketing window — but risk a bad first impression that
patches can't fully undo). Live-service blurs this. The stakes of the first impression push toward
readiness, weighed against real business timing.

## Notes
The launch-stakes principle of SHIP; raises the bar on finishing (PROD-0006), real-conditions
testing (QA-0004), and onboarding (UX-0001). Confidence 4.

gdc-l1-ship-0001 you get one first impression — the launch state shapes the game's reception shipping launch first-impression stability reputation > a game gets one launch, and its state at that moment — stability, performance, onboarding, and polish of the first hour — disproportionately shapes reviews, word of mouth, and long-term reception. first impressions are sticky and costly to reverse. treat launch readiness as a deliberate goal, not the moment you happen to run out of time. launch is when the largest audience arrives at once, forms opinions fast, and broadcasts them (reviews, streams, social) — and those early opinions harden into the game's reputation, which is extremely hard to change later even if the game improves [s-scope-production]. a broken, sluggish, or confusing launch (crashes, bad performance on common hardware — qa-0004, a baffling first hour — ux-0001) squanders the one moment of peak attention, while a solid launch compounds into momentum. this raises the stakes on finishing well (prod-0006), on testing under real conditions before release (qa-0004), and on the onboarding experience specifically (ux-0001), because the first hour is what most players judge on. "we'll patch it later" underestimates how much the first impression persists. any release to a real audience — launch especially, but also major updates, betas, and demos that create first impressions. early-access and live-service models deliberately launch unfinished — but they set the expectation explicitly and still must nail the first impression for what they claim to be (a rough early-access launch that oversells itself still burns trust). and no launch is bug-free; the bar is "good enough that the first impression is positive," not "perfect." small or niche launches carry lower stakes but the same logic. define launch-readiness criteria (stability, performance on target hardware — qa-0004, a strong first hour — ux-0001) and hold the release to them; if you can't hit them, cut scope or delay rather than launch broken (prod-0001/0006). prioritize the first-hour experience and common-case stability. prepare day-one support (ship-0004). set honest expectations for what the launch is (especially for early access). ship-when-ready/delay-for-quality (protect the first impression — but cost of delay, missed windows) vs. ship-on-date-and-patch (hit the market/marketing window — but risk a bad first impression that patches can't fully undo). live-service blurs this. the stakes of the first impression push toward readiness, weighed against real business timing. the launch-stakes principle of ship; raises the bar on finishing (prod-0006), real-conditions testing (qa-0004), and onboarding (ux-0001). confidence 4.


For live and ongoing games, launch is the start of the game's life, not the finish line. Plan for post-launch — updates, content, balance, events, support, and the systems that enable them — from the beginning. A game meant to live for years must be built to be maintained and extended, not just shipped once.

---
id: GDC-L1-SHIP-0002
title: For live games, launch is a beginning — plan post-launch from the start
layer: L1
domain: SHIP
subdomain: post-launch
type: contextual
confidence: 4
status: canonical
tags:
  - shipping
  - live-service
  - post-launch
  - planning
related:
  - GDC-L1-SHIP-0003
  - GDC-L1-ARCH-0006
  - GDC-L1-PROD-0004
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-scope-production
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> For live and ongoing games, launch is the *start* of the game's life, not the finish line. Plan
> for post-launch — updates, content, balance, events, support, and the systems that enable them —
> from the beginning. A game meant to live for years must be *built* to be maintained and extended,
> not just shipped once.

## Rationale
A live game spends most of its life *after* launch, and the decisions that determine whether that
life is sustainable are made *before* it: an architecture that supports live updates and
data-driven content (ARCH-0001/0006), the tooling to produce content at cadence (CONTENT-0001), the
telemetry to understand players (SHIP-0004), and the team and schedule to sustain it (PROD-0004)
all have to exist by launch [S-scope-production]. Teams that treat launch as the end and bolt on
live operations afterward struggle — the game wasn't built to be fed. Planning post-launch from the
start means designing for extension (the "build the seam" logic again), budgeting the ongoing team,
and sequencing content beyond day one. Even non-live games benefit from planning the inevitable
launch patches; for live games it's existential.

## Applies when
Any live-service, ongoing, or long-tail game — and to a lesser degree any game expecting
post-launch patches and support (i.e. almost all).

## Does not apply / Exceptions
A finite, premium, one-and-done game genuinely can treat launch as (nearly) the end — it still
plans launch patches (SHIP-0001), but not perpetual operations. Building heavy live-ops
infrastructure into a game that won't use it is over-engineering. The principle scales with how
"live" the game is meant to be — match the post-launch investment to the model (MON-0001).

## Implementation (kept separate from the principle)
Decide the live/finite model early (MON-0001) and build accordingly: architecture for live updates
and data-driven content (ARCH-0001/0006), pipelines to produce content at cadence (CONTENT-0001),
telemetry for post-launch understanding (SHIP-0004), and a staffed, budgeted post-launch plan
(PROD-0004). Sequence content beyond launch. Even for finite games, plan the day-one/first-weeks
patch support.

## Disagreement
Live-service/GaaS (ongoing revenue and evolving experience — but perpetual cost, commitment, and
the temptation toward extractive live monetization, MON-0003) vs. finite/premium (a complete,
authored experience that ends — but no ongoing revenue). A fundamental business-model and design
choice (MON-0001), not a quality question.

## Notes
The post-launch-planning principle of SHIP; depends on extensible architecture (ARCH-0001/0006),
content pipelines (CONTENT-0001), telemetry (SHIP-0004), and sustained planning (PROD-0004).
Confidence 4.

gdc-l1-ship-0002 for live games, launch is a beginning — plan post-launch from the start shipping live-service post-launch planning > for live and ongoing games, launch is the start of the game's life, not the finish line. plan for post-launch — updates, content, balance, events, support, and the systems that enable them — from the beginning. a game meant to live for years must be built to be maintained and extended, not just shipped once. a live game spends most of its life after launch, and the decisions that determine whether that life is sustainable are made before it: an architecture that supports live updates and data-driven content (arch-0001/0006), the tooling to produce content at cadence (content-0001), the telemetry to understand players (ship-0004), and the team and schedule to sustain it (prod-0004) all have to exist by launch [s-scope-production]. teams that treat launch as the end and bolt on live operations afterward struggle — the game wasn't built to be fed. planning post-launch from the start means designing for extension (the "build the seam" logic again), budgeting the ongoing team, and sequencing content beyond day one. even non-live games benefit from planning the inevitable launch patches; for live games it's existential. any live-service, ongoing, or long-tail game — and to a lesser degree any game expecting post-launch patches and support (i.e. almost all). a finite, premium, one-and-done game genuinely can treat launch as (nearly) the end — it still plans launch patches (ship-0001), but not perpetual operations. building heavy live-ops infrastructure into a game that won't use it is over-engineering. the principle scales with how "live" the game is meant to be — match the post-launch investment to the model (mon-0001). decide the live/finite model early (mon-0001) and build accordingly: architecture for live updates and data-driven content (arch-0001/0006), pipelines to produce content at cadence (content-0001), telemetry for post-launch understanding (ship-0004), and a staffed, budgeted post-launch plan (prod-0004). sequence content beyond launch. even for finite games, plan the day-one/first-weeks patch support. live-service/gaas (ongoing revenue and evolving experience — but perpetual cost, commitment, and the temptation toward extractive live monetization, mon-0003) vs. finite/premium (a complete, authored experience that ends — but no ongoing revenue). a fundamental business-model and design choice (mon-0001), not a quality question. the post-launch-planning principle of ship; depends on extensible architecture (arch-0001/0006), content pipelines (content-0001), telemetry (ship-0004), and sustained planning (prod-0004). confidence 4.


A live game is a service: keeping it healthy takes a sustained cadence of content, ongoing balance, events, and honest communication with the community. Players stay for a game that keeps giving them reasons to return and visibly cares; they leave a game that stalls or goes silent.

---
id: GDC-L1-SHIP-0003
title: Run live ops as a service — sustain content, balance, and communication
layer: L1
domain: SHIP
subdomain: live-ops
type: contextual
confidence: 3
status: canonical
tags:
  - shipping
  - live-ops
  - content-cadence
  - balance
  - community
related:
  - GDC-L1-SHIP-0002
  - GDC-L1-SHIP-0004
  - GDC-L1-BAL-0005
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-scope-production
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> A live game is a *service*: keeping it healthy takes a sustained cadence of content, ongoing
> balance, events, and honest communication with the community. Players stay for a game that keeps
> giving them reasons to return and visibly cares; they leave a game that stalls or goes silent.

## Rationale
Live games retain players through a rhythm of fresh reasons to play — new content, seasonal events,
balance updates that keep the meta alive (BAL), responsive fixes — and through a relationship with
the community maintained by communication [S-scope-production]. A live game that ships and then goes
quiet decays: the content gets exhausted, the balance staleness or exploits accumulate (BAL-0002,
BAL-0006), and players drift to games that are still evolving. Running live ops well means treating
the post-launch game as an ongoing production with its own cadence, informed by what players
actually do (telemetry and feedback, SHIP-0004). It's demanding — a real, sustained team cost — but
for a live game it's not optional; the service *is* the product after launch.

## Applies when
Live-service, seasonal, and ongoing multiplayer games — anything designed to be played and updated
for a long time.

## Does not apply / Exceptions
Finite/premium games don't run live ops (SHIP-0002) — they ship, patch, and are done, and forcing
live-ops cadence onto them wastes effort. Live ops also has a dark side to avoid: cadence and events
driven by *extraction* (FOMO, manufactured urgency) rather than genuine value cross into dark
patterns (MON-0003). Healthy live ops gives players real reasons to return, not manufactured
compulsion. Small live games run lighter cadences scaled to their team.

## Implementation (kept separate from the principle)
Plan an achievable, sustainable content/event cadence (don't over-promise — a burnt-out live team
serves no one, PROD-0005). Keep balance fresh and exploit-free (BAL-0002/0006), informed by
telemetry and feedback (SHIP-0004, BAL-0005). Communicate honestly and regularly with the community.
Ensure cadence delivers genuine value, not manufactured urgency (MON-0003). Staff and budget it as
ongoing production (SHIP-0002).

## Disagreement
Heavy live-ops cadence (retention, evolving game, revenue — but high sustained cost and burnout/
extraction risk) vs. lighter-touch or finite (lower ongoing cost, but decay without updates). And
value-driven vs. extraction-driven live ops (MON-0003). The right cadence scales with the model and
team; the ethics line is real reasons-to-return over manufactured compulsion.

## Notes
The live-operations principle of SHIP; depends on post-launch planning (SHIP-0002), telemetry-driven
iteration (SHIP-0004, BAL-0005), and honest (non-extractive, MON-0003) engagement. Confidence 3 —
live-ops practice is model-dependent and fast-evolving.

gdc-l1-ship-0003 run live ops as a service — sustain content, balance, and communication shipping live-ops content-cadence balance community > a live game is a service: keeping it healthy takes a sustained cadence of content, ongoing balance, events, and honest communication with the community. players stay for a game that keeps giving them reasons to return and visibly cares; they leave a game that stalls or goes silent. live games retain players through a rhythm of fresh reasons to play — new content, seasonal events, balance updates that keep the meta alive (bal), responsive fixes — and through a relationship with the community maintained by communication [s-scope-production]. a live game that ships and then goes quiet decays: the content gets exhausted, the balance staleness or exploits accumulate (bal-0002, bal-0006), and players drift to games that are still evolving. running live ops well means treating the post-launch game as an ongoing production with its own cadence, informed by what players actually do (telemetry and feedback, ship-0004). it's demanding — a real, sustained team cost — but for a live game it's not optional; the service is the product after launch. live-service, seasonal, and ongoing multiplayer games — anything designed to be played and updated for a long time. finite/premium games don't run live ops (ship-0002) — they ship, patch, and are done, and forcing live-ops cadence onto them wastes effort. live ops also has a dark side to avoid: cadence and events driven by extraction (fomo, manufactured urgency) rather than genuine value cross into dark patterns (mon-0003). healthy live ops gives players real reasons to return, not manufactured compulsion. small live games run lighter cadences scaled to their team. plan an achievable, sustainable content/event cadence (don't over-promise — a burnt-out live team serves no one, prod-0005). keep balance fresh and exploit-free (bal-0002/0006), informed by telemetry and feedback (ship-0004, bal-0005). communicate honestly and regularly with the community. ensure cadence delivers genuine value, not manufactured urgency (mon-0003). staff and budget it as ongoing production (ship-0002). heavy live-ops cadence (retention, evolving game, revenue — but high sustained cost and burnout/ extraction risk) vs. lighter-touch or finite (lower ongoing cost, but decay without updates). and value-driven vs. extraction-driven live ops (mon-0003). the right cadence scales with the model and team; the ethics line is real reasons-to-return over manufactured compulsion. the live-operations principle of ship; depends on post-launch planning (ship-0002), telemetry-driven iteration (ship-0004, bal-0005), and honest (non-extractive, mon-0003) engagement. confidence 3 — live-ops practice is model-dependent and fast-evolving.


After launch, keep the iteration loop running: gather what players do (telemetry) and what they say (community feedback), and turn it into responsive fixes and improvements. Launch multiplies your player base — and thus your data — enormously; a responsive post-launch loop turns a rough launch into a recovery and a good one into a great one.

---
id: GDC-L1-SHIP-0004
title: Close the loop after launch — telemetry and community feedback into responsive patching
layer: L1
domain: SHIP
subdomain: post-launch
type: contextual
confidence: 4
status: canonical
tags:
  - shipping
  - telemetry
  - feedback
  - patching
  - community
related:
  - GDC-L1-PLAYTEST-0005
  - GDC-L1-PLAYTEST-0004
  - GDC-L1-SHIP-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-scope-production
  - S-games-user-research
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> After launch, keep the iteration loop running: gather what players *do* (telemetry) and what they
> *say* (community feedback), and turn it into responsive fixes and improvements. Launch multiplies
> your player base — and thus your data — enormously; a responsive post-launch loop turns a rough
> launch into a recovery and a good one into a great one.

## Rationale
Launch is the biggest playtest the game will ever get (PLAYTEST-0005): millions of real players in
real conditions surface the balance problems, exploits, pain points, and crashes that no internal
test found. A team that watches this — telemetry for the *what* (where players quit, what they use,
where they crash) plus community feedback for the *why* — and patches responsively can fix a shaky
launch and keep a strong one improving [S-scope-production] [S-games-user-research]. This is the
post-launch continuation of the whole iteration ethos (PROTO-0006) and the playtest principles:
watch behavior over opinion (PLAYTEST-0001/0005), and listen to the problem while distrusting the
prescribed fix (PLAYTEST-0004). A responsive, visible post-launch loop also signals to the community
that the game is cared for (SHIP-0003), which retains players through the rocky early weeks.

## Applies when
The post-launch period of any game, and continuously for live games. Most critical in the first days
and weeks when the largest audience and the most data arrive at once.

## Does not apply / Exceptions
Finite games close the loop for a limited support window rather than forever. And responsiveness has
limits: not every loud complaint warrants a change (PLAYTEST-0004 — distrust the prescribed fix),
and knee-jerk patching can destabilize a game or chase a vocal minority. The loop should be
*responsive and judged*, not reflexive. Telemetry can also mislead if optimized for the wrong metric
(PROG-0004's caution).

## Implementation (kept separate from the principle)
Instrument the game for post-launch telemetry (crashes, drop-off, usage, balance data — build it in
before launch, SHIP-0002). Monitor community channels for the *why*. Combine both (PLAYTEST-0005),
and patch responsively — prioritizing crashes, exploits, and the worst pain points. Listen to the
problem, own the fix (PLAYTEST-0004). Communicate what you're doing (SHIP-0003). Avoid
metric-chasing at the experience's expense (PROG-0004).

## Disagreement
Highly responsive patching (recover launches, retain players, show care — but risk instability,
chasing vocal minorities, and over-reacting) vs. measured/deliberate updates (stability, considered
changes — but slower to fix real problems). The synthesis: fast on crashes/exploits, deliberate on
design changes, always judging feedback (PLAYTEST-0004) rather than obeying it.

## Notes
The post-launch iteration principle of SHIP; the launch-scale continuation of playtesting
(PLAYTEST-0001/0004/0005) and the iteration loop (PROTO-0006), feeding live ops (SHIP-0003).
Confidence 4.

gdc-l1-ship-0004 close the loop after launch — telemetry and community feedback into responsive patching shipping telemetry feedback patching community > after launch, keep the iteration loop running: gather what players do (telemetry) and what they say (community feedback), and turn it into responsive fixes and improvements. launch multiplies your player base — and thus your data — enormously; a responsive post-launch loop turns a rough launch into a recovery and a good one into a great one. launch is the biggest playtest the game will ever get (playtest-0005): millions of real players in real conditions surface the balance problems, exploits, pain points, and crashes that no internal test found. a team that watches this — telemetry for the what (where players quit, what they use, where they crash) plus community feedback for the why — and patches responsively can fix a shaky launch and keep a strong one improving [s-scope-production] [s-games-user-research]. this is the post-launch continuation of the whole iteration ethos (proto-0006) and the playtest principles: watch behavior over opinion (playtest-0001/0005), and listen to the problem while distrusting the prescribed fix (playtest-0004). a responsive, visible post-launch loop also signals to the community that the game is cared for (ship-0003), which retains players through the rocky early weeks. the post-launch period of any game, and continuously for live games. most critical in the first days and weeks when the largest audience and the most data arrive at once. finite games close the loop for a limited support window rather than forever. and responsiveness has limits: not every loud complaint warrants a change (playtest-0004 — distrust the prescribed fix), and knee-jerk patching can destabilize a game or chase a vocal minority. the loop should be responsive and judged, not reflexive. telemetry can also mislead if optimized for the wrong metric (prog-0004's caution). instrument the game for post-launch telemetry (crashes, drop-off, usage, balance data — build it in before launch, ship-0002). monitor community channels for the why. combine both (playtest-0005), and patch responsively — prioritizing crashes, exploits, and the worst pain points. listen to the problem, own the fix (playtest-0004). communicate what you're doing (ship-0003). avoid metric-chasing at the experience's expense (prog-0004). highly responsive patching (recover launches, retain players, show care — but risk instability, chasing vocal minorities, and over-reacting) vs. measured/deliberate updates (stability, considered changes — but slower to fix real problems). the synthesis: fast on crashes/exploits, deliberate on design changes, always judging feedback (playtest-0004) rather than obeying it. the post-launch iteration principle of ship; the launch-scale continuation of playtesting (playtest-0001/0004/0005) and the iteration loop (proto-0006), feeding live ops (ship-0003). confidence 4.


Every live game ends. Plan the end of life with respect: give honest, early communication, honor what players spent (money and time), and where feasible preserve access — an offline mode, extended notice, or archival — rather than switching the servers off and erasing what people paid for and cared about.

---
id: GDC-L1-SHIP-0005
title: Sunset with respect — plan the end of life
layer: L1
domain: SHIP
subdomain: sunsetting
type: stylistic
confidence: 3
status: canonical
tags:
  - shipping
  - sunset
  - end-of-life
  - preservation
  - player-respect
related:
  - GDC-L1-SHIP-0002
  - GDC-L1-MON-0002
  - GDC-L1-PLAYTEST-0004
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-scope-production
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Every live game ends. Plan the end of life with respect: give honest, early communication, honor
> what players spent (money and time), and where feasible preserve access — an offline mode,
> extended notice, or archival — rather than switching the servers off and erasing what people
> paid for and cared about.

## Rationale
Live games depend on servers and services that won't run forever, and how a studio handles the end
is a real test of the respect it claims for its players (MON-0002) — a game that vanishes overnight,
taking players' purchases and progress with it and with little warning, breaks the trust the whole
relationship was built on [S-scope-production]. Players invest money *and* years of time and
attachment; treating that investment as disposable at sunset is the opposite of the value exchange
and player respect the constitution argues for. A respectful sunset — ample notice, honoring
spends, and preserving what can be preserved (offline continuation, private servers, archival) —
protects the studio's reputation, respects the community, and contributes to the medium's
preservation. It's also increasingly a consumer-rights and regulatory concern.

## Applies when
The end of life of any live/server-dependent game or service — and the *planning* for it should
begin when the live model is chosen (SHIP-0002), not scrambled at shutdown.

## Does not apply / Exceptions
Finite/offline games don't sunset in this sense — they simply remain playable (their preservation
concern is compatibility over time, not server shutdown). Genuine constraints exist: some games are
technically or legally hard to preserve (licensed content, deep server dependencies), and a studio
may lack resources to maintain an offline mode. The principle is "sunset with as much respect and
preservation as feasible," not "keep every game alive forever."

## Implementation (kept separate from the principle)
Plan for end-of-life when adopting a live model (SHIP-0002): consider an eventual offline/private-
server path, and design to make graceful shutdown possible. At sunset, give early, honest notice;
honor recent purchases (refunds/consideration); preserve access where feasible. Communicate with the
community as you would at launch (SHIP-0003/0004) — the end deserves the same care as the beginning.

## Disagreement
Preservation/respect-first sunsetting (honor players' investment, protect reputation and the medium
— but real cost and technical/legal barriers) vs. clean-shutdown pragmatism (lower cost, simpler —
but breaks trust and erases what players paid for). A values-and-feasibility split (hence stylistic);
this constitution leans toward respect and preservation within what's feasible, echoing MON-0002.

## Notes
The end-of-life principle of SHIP; the sunset application of player respect (MON-0002) and the
bookend to launch (SHIP-0001) — begin and end the game's life with equal care. Confidence 3 —
clearly the respectful ideal, but genuinely constrained by cost and technical/legal reality.

gdc-l1-ship-0005 sunset with respect — plan the end of life shipping sunset end-of-life preservation player-respect > every live game ends. plan the end of life with respect: give honest, early communication, honor what players spent (money and time), and where feasible preserve access — an offline mode, extended notice, or archival — rather than switching the servers off and erasing what people paid for and cared about. live games depend on servers and services that won't run forever, and how a studio handles the end is a real test of the respect it claims for its players (mon-0002) — a game that vanishes overnight, taking players' purchases and progress with it and with little warning, breaks the trust the whole relationship was built on [s-scope-production]. players invest money and years of time and attachment; treating that investment as disposable at sunset is the opposite of the value exchange and player respect the constitution argues for. a respectful sunset — ample notice, honoring spends, and preserving what can be preserved (offline continuation, private servers, archival) — protects the studio's reputation, respects the community, and contributes to the medium's preservation. it's also increasingly a consumer-rights and regulatory concern. the end of life of any live/server-dependent game or service — and the planning for it should begin when the live model is chosen (ship-0002), not scrambled at shutdown. finite/offline games don't sunset in this sense — they simply remain playable (their preservation concern is compatibility over time, not server shutdown). genuine constraints exist: some games are technically or legally hard to preserve (licensed content, deep server dependencies), and a studio may lack resources to maintain an offline mode. the principle is "sunset with as much respect and preservation as feasible," not "keep every game alive forever." plan for end-of-life when adopting a live model (ship-0002): consider an eventual offline/private- server path, and design to make graceful shutdown possible. at sunset, give early, honest notice; honor recent purchases (refunds/consideration); preserve access where feasible. communicate with the community as you would at launch (ship-0003/0004) — the end deserves the same care as the beginning. preservation/respect-first sunsetting (honor players' investment, protect reputation and the medium — but real cost and technical/legal barriers) vs. clean-shutdown pragmatism (lower cost, simpler — but breaks trust and erases what players paid for). a values-and-feasibility split (hence stylistic); this constitution leans toward respect and preservation within what's feasible, echoing mon-0002. the end-of-life principle of ship; the sunset application of player respect (mon-0002) and the bookend to launch (ship-0001) — begin and end the game's life with equal care. confidence 3 — clearly the respectful ideal, but genuinely constrained by cost and technical/legal reality.