In multiplayer games the product is human interaction, not just synchronized state. Design the social experience — how players meet, cooperate, compete, communicate, and relate — deliberately. The other players are the content; the netcode only delivers them.

---
id: GDC-L1-MP-0001
title: Design the social experience, not just the netcode
layer: L1
domain: MP
subdomain: social-dynamics
type: contextual
confidence: 4
status: canonical
tags:
  - multiplayer
  - social
  - community
  - human-interaction
related:
  - GDC-L1-MP-0002
  - GDC-L1-DESIGN-0001
  - GDC-L1-MP-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-multiplayer-design
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> In multiplayer games the product is **human interaction**, not just synchronized state. Design
> the social experience — how players meet, cooperate, compete, communicate, and relate —
> deliberately. The other players are the content; the netcode only delivers them.

## Rationale
What players remember about multiplayer games is the *people* — the clutch teammate, the rival,
the friend made in a raid, the stranger who was kind or cruel — and those experiences are
produced by the game's social systems, not incidentally [S-multiplayer-design]. Treating
multiplayer as "single-player plus networking" misses that the design object is the *interaction*:
whether the game fosters cooperation or hostility, connection or isolation, is a design outcome
(DESIGN-0001, the experience produced). Matchmaking, communication tools, team structures,
incentives, and social features all shape what kind of human experience the game creates. The
netcode (MP-0004) is necessary infrastructure, but the social design is the actual game.

## Applies when
Any multiplayer game — cooperative, competitive, social, or massively-multiplayer. The more
central other players are to the experience, the more social design dominates.

## Does not apply / Exceptions
Primarily single-player games with thin multiplayer (a leaderboard, an async ghost) have little
social experience to design. And some multiplayer is deliberately anonymous or minimal-contact
(a background-population feel) — a valid choice, but still a *social* design decision (how much
contact), not the absence of one.

## Implementation (kept separate from the principle)
Decide what social experience you want (cooperation? rivalry? community? fleeting encounters?)
and build the systems that produce it: matchmaking (MP-0003), communication affordances and
limits (MP-0002), team and role structures, and incentives that reward the interactions you want.
Design against the toxic dynamics your systems could produce (MP-0002). Treat "how does it feel to
play *with people*" as the core question.

## Disagreement
Rich social design (deep interaction, community, relationships — but heavier design and moderation
cost) vs. minimal/anonymous multiplayer (lower friction and moderation burden, but thinner human
experience). The right amount depends on the game; the point is that it's a *design* choice, made
on purpose.

## Notes
The framing principle of the MP domain; an application of DESIGN-0001 to human interaction, and the
context for behavior design (MP-0002) and matchmaking (MP-0003). Confidence 4.

gdc-l1-mp-0001 design the social experience, not just the netcode multiplayer social community human-interaction > in multiplayer games the product is human interaction, not just synchronized state. design the social experience — how players meet, cooperate, compete, communicate, and relate — deliberately. the other players are the content; the netcode only delivers them. what players remember about multiplayer games is the people — the clutch teammate, the rival, the friend made in a raid, the stranger who was kind or cruel — and those experiences are produced by the game's social systems, not incidentally [s-multiplayer-design]. treating multiplayer as "single-player plus networking" misses that the design object is the interaction: whether the game fosters cooperation or hostility, connection or isolation, is a design outcome (design-0001, the experience produced). matchmaking, communication tools, team structures, incentives, and social features all shape what kind of human experience the game creates. the netcode (mp-0004) is necessary infrastructure, but the social design is the actual game. any multiplayer game — cooperative, competitive, social, or massively-multiplayer. the more central other players are to the experience, the more social design dominates. primarily single-player games with thin multiplayer (a leaderboard, an async ghost) have little social experience to design. and some multiplayer is deliberately anonymous or minimal-contact (a background-population feel) — a valid choice, but still a social design decision (how much contact), not the absence of one. decide what social experience you want (cooperation? rivalry? community? fleeting encounters?) and build the systems that produce it: matchmaking (mp-0003), communication affordances and limits (mp-0002), team and role structures, and incentives that reward the interactions you want. design against the toxic dynamics your systems could produce (mp-0002). treat "how does it feel to play with people" as the core question. rich social design (deep interaction, community, relationships — but heavier design and moderation cost) vs. minimal/anonymous multiplayer (lower friction and moderation burden, but thinner human experience). the right amount depends on the game; the point is that it's a design choice, made on purpose. the framing principle of the mp domain; an application of design-0001 to human interaction, and the context for behavior design (mp-0002) and matchmaking (mp-0003). confidence 4.


Player behavior is partly a design outcome: systems shape whether a community is toxic or welcoming. Design for good behavior — matchmaking, communication affordances and limits, reporting, penalties, and positive incentives — rather than treating toxicity as an inevitable externality to be mopped up after the fact.

---
id: GDC-L1-MP-0002
title: Behavior is designed — shape the community with systems, don't just moderate it
layer: L1
domain: MP
subdomain: fairness-and-anti-toxicity
type: contextual
confidence: 4
status: canonical
tags:
  - multiplayer
  - toxicity
  - community
  - incentives
  - moderation
related:
  - GDC-L1-MP-0001
  - GDC-L1-SYS-0007
  - GDC-L1-TEAM-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-multiplayer-design
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Player behavior is partly a *design outcome*: systems shape whether a community is toxic or
> welcoming. Design for good behavior — matchmaking, communication affordances and limits,
> reporting, penalties, and positive incentives — rather than treating toxicity as an inevitable
> externality to be mopped up after the fact.

## Rationale
Toxicity isn't purely a property of "bad players"; it's strongly influenced by what the game
incentivizes, permits, and punishes [S-multiplayer-design]. Anonymous, consequence-free
interaction with frustrated, mismatched opponents *produces* hostility; systems that add
accountability (reporting, reputation), reduce frustration (good matchmaking, MP-0003), shape
communication (mute/limit options, positive comms), and penalize harm (e.g. leaving penalties —
"a 4v5 is no fun for anybody") measurably shift behavior. This is the multiplayer form of a
systemic truth already in the constitution: players respond to incentives (SYS-0007), so the
community you get is partly the community you *designed for*. Moderation is necessary, but
designing the conditions that reduce toxicity in the first place is more effective than
punishing it after.

## Applies when
Any multiplayer game with real player-to-player interaction, especially competitive and
communication-heavy games where toxicity thrives.

## Does not apply / Exceptions
Systems can't eliminate all bad behavior — some moderation and human judgment is always needed,
and over-restricting communication to prevent toxicity can also strip out the positive social
contact that makes multiplayer worthwhile (MP-0001). The balance between open interaction and
safety is real. And behavior design must avoid punishing false positives that alienate good
players.

## Implementation (kept separate from the principle)
Reduce the *causes* of toxicity (frustration, mismatch) via matchmaking (MP-0003) and fair play
(anti-cheat, MP-0004). Add accountability (reporting, reputation, escalating penalties) and
positive incentives (honor/commend systems). Give players tools to shape their own experience
(mute, block, communication options). Penalize genuinely harmful acts (quitting, abuse)
proportionately. Moderate *and* design — don't rely on moderation alone.

## Disagreement
Open communication and freedom (richer social experience, but more toxicity to manage) vs.
restricted/managed interaction (safer, but thinner contact). And behavior-shaping via systems vs.
reactive moderation. Most healthy communities use both design and moderation; the debate is the
mix and how much to constrain interaction.

## Notes
The community-health principle of MP; the multiplayer application of incentive design (SYS-0007)
and a social parallel to psychological safety (TEAM-0001) — safe spaces produce better behavior,
in teams and in player communities alike. Confidence 4.

gdc-l1-mp-0002 behavior is designed — shape the community with systems, don't just moderate it multiplayer toxicity community incentives moderation > player behavior is partly a design outcome: systems shape whether a community is toxic or welcoming. design for good behavior — matchmaking, communication affordances and limits, reporting, penalties, and positive incentives — rather than treating toxicity as an inevitable externality to be mopped up after the fact. toxicity isn't purely a property of "bad players"; it's strongly influenced by what the game incentivizes, permits, and punishes [s-multiplayer-design]. anonymous, consequence-free interaction with frustrated, mismatched opponents produces hostility; systems that add accountability (reporting, reputation), reduce frustration (good matchmaking, mp-0003), shape communication (mute/limit options, positive comms), and penalize harm (e.g. leaving penalties — "a 4v5 is no fun for anybody") measurably shift behavior. this is the multiplayer form of a systemic truth already in the constitution: players respond to incentives (sys-0007), so the community you get is partly the community you designed for. moderation is necessary, but designing the conditions that reduce toxicity in the first place is more effective than punishing it after. any multiplayer game with real player-to-player interaction, especially competitive and communication-heavy games where toxicity thrives. systems can't eliminate all bad behavior — some moderation and human judgment is always needed, and over-restricting communication to prevent toxicity can also strip out the positive social contact that makes multiplayer worthwhile (mp-0001). the balance between open interaction and safety is real. and behavior design must avoid punishing false positives that alienate good players. reduce the causes of toxicity (frustration, mismatch) via matchmaking (mp-0003) and fair play (anti-cheat, mp-0004). add accountability (reporting, reputation, escalating penalties) and positive incentives (honor/commend systems). give players tools to shape their own experience (mute, block, communication options). penalize genuinely harmful acts (quitting, abuse) proportionately. moderate and design — don't rely on moderation alone. open communication and freedom (richer social experience, but more toxicity to manage) vs. restricted/managed interaction (safer, but thinner contact). and behavior-shaping via systems vs. reactive moderation. most healthy communities use both design and moderation; the debate is the mix and how much to constrain interaction. the community-health principle of mp; the multiplayer application of incentive design (sys-0007) and a social parallel to psychological safety (team-0001) — safe spaces produce better behavior, in teams and in player communities alike. confidence 4.


Matchmaking is game design, not plumbing: who a player is matched with largely determines whether a match is fun. Match players by skill (for balanced, engaging contests) and by connection quality (for a fair, playable match). A great game with bad matchmaking delivers bad games.

---
id: GDC-L1-MP-0003
title: Fair matchmaking is core design — match by skill and connection
layer: L1
domain: MP
subdomain: matchmaking-design
type: contextual
confidence: 4
status: canonical
tags:
  - multiplayer
  - matchmaking
  - fairness
  - skill
  - flow
related:
  - GDC-L1-MP-0002
  - GDC-L1-DESIGN-0004
  - GDC-L1-BAL-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-multiplayer-design
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Matchmaking *is* game design, not plumbing: who a player is matched with largely determines
> whether a match is fun. Match players by skill (for balanced, engaging contests) and by
> connection quality (for a fair, playable match). A great game with bad matchmaking delivers
> bad games.

## Rationale
For competitive and many cooperative games, the moment-to-moment experience is produced by the
match, and the match is produced by matchmaking — so a mismatch (a stomp in either direction, a
laggy opponent, a broken team) ruins an otherwise-great game [S-multiplayer-design]. Skill-based
matching keeps players in the flow channel (DESIGN-0004): fights that are neither trivial nor
hopeless. Connection-based matching keeps them *fair* (a player shouldn't lose to latency,
MP-0004). And matchmaking shapes behavior — repeated stomps breed frustration and toxicity
(MP-0002). Because it so directly governs the experience, matchmaking deserves first-class design
attention and iteration (informed by player feedback and telemetry), not a set-and-forget
formula.

## Applies when
Any multiplayer game that pairs or groups players — competitive matches, co-op sessions, ranked
ladders. Most critical in competitive games where fairness and balance are the point.

## Does not apply / Exceptions
Small-population games face a real tension: strict skill/connection matching can mean *no* match
(long queues), so they must trade match quality against wait time. Social/party play often
*wants* mismatched skill (friends playing together). And some designs deliberately avoid tight
matchmaking (open-world PvP, casual playlists). The principle is strongest for competitive
integrity; it bends for population and social goals.

## Implementation (kept separate from the principle)
Match on skill (a rating system) and connection (latency/region), balancing match quality against
queue time for your population. Avoid repeated stomps (they breed toxicity, MP-0002). Iterate the
system on player feedback and telemetry (PLAYTEST-0005) — matchmaking is never "done." Handle
parties and social play as a deliberate exception, not a bug.

## Disagreement
Tight skill/connection matching (fair, balanced matches — but longer queues, harder on small
populations) vs. loose/fast matching (short queues, but stomps and unfair matches). Also
skill-based matchmaking itself is debated in casual contexts (some players want to "pubstomp").
The balance depends on population size and whether the mode is competitive or casual.

## Notes
The matchmaking principle of MP; connects to flow (DESIGN-0004), fairness/balance (BAL-0002), and
community health (MP-0002 — good matches reduce toxicity). Confidence 4.

gdc-l1-mp-0003 fair matchmaking is core design — match by skill and connection multiplayer matchmaking fairness skill flow > matchmaking is game design, not plumbing: who a player is matched with largely determines whether a match is fun. match players by skill (for balanced, engaging contests) and by connection quality (for a fair, playable match). a great game with bad matchmaking delivers bad games. for competitive and many cooperative games, the moment-to-moment experience is produced by the match, and the match is produced by matchmaking — so a mismatch (a stomp in either direction, a laggy opponent, a broken team) ruins an otherwise-great game [s-multiplayer-design]. skill-based matching keeps players in the flow channel (design-0004): fights that are neither trivial nor hopeless. connection-based matching keeps them fair (a player shouldn't lose to latency, mp-0004). and matchmaking shapes behavior — repeated stomps breed frustration and toxicity (mp-0002). because it so directly governs the experience, matchmaking deserves first-class design attention and iteration (informed by player feedback and telemetry), not a set-and-forget formula. any multiplayer game that pairs or groups players — competitive matches, co-op sessions, ranked ladders. most critical in competitive games where fairness and balance are the point. small-population games face a real tension: strict skill/connection matching can mean no match (long queues), so they must trade match quality against wait time. social/party play often wants mismatched skill (friends playing together). and some designs deliberately avoid tight matchmaking (open-world pvp, casual playlists). the principle is strongest for competitive integrity; it bends for population and social goals. match on skill (a rating system) and connection (latency/region), balancing match quality against queue time for your population. avoid repeated stomps (they breed toxicity, mp-0002). iterate the system on player feedback and telemetry (playtest-0005) — matchmaking is never "done." handle parties and social play as a deliberate exception, not a bug. tight skill/connection matching (fair, balanced matches — but longer queues, harder on small populations) vs. loose/fast matching (short queues, but stomps and unfair matches). also skill-based matchmaking itself is debated in casual contexts (some players want to "pubstomp"). the balance depends on population size and whether the mode is competitive or casual. the matchmaking principle of mp; connects to flow (design-0004), fairness/balance (bal-0002), and community health (mp-0002 — good matches reduce toxicity). confidence 4.


In networked multiplayer, treat the client as untrusted and the network as hostile. Make the server authoritative over game state, never trust a client's claims, and use lag compensation to keep play fair and responsive despite latency. Fairness and security are designed in, not bolted on.

---
id: GDC-L1-MP-0004
title: Trust the server, not the client — assume the network is hostile
layer: L1
domain: MP
subdomain: competitive
type: contextual
confidence: 4
status: canonical
tags:
  - multiplayer
  - netcode
  - authoritative-server
  - anti-cheat
  - lag-compensation
related:
  - GDC-L1-MP-0003
  - GDC-L1-ARCH-0006
  - GDC-L1-FEEL-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-multiplayer-design
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> In networked multiplayer, treat the client as untrusted and the network as hostile. Make the
> **server authoritative** over game state, **never trust a client's claims**, and use lag
> compensation to keep play fair and responsive despite latency. Fairness and security are
> designed in, not bolted on.

## Rationale
A client runs on a machine the player controls, so anything the client asserts (I hit, I moved
there, I have this item) can be forged — which is why a server-authoritative model, where the
server validates and owns the truth, is the foundation of fair networked play
[S-multiplayer-design]. "Never trust the client" limits the cheats possible and protects the
competition (MP-0003's fairness). At the same time, latency is unavoidable, so responsiveness
(FEEL-0002) must be preserved through techniques like client prediction and server-side lag
compensation (rewinding to validate a shot against what the shooter saw) — balancing "fair to
the shooter" against "fair to the target." These are architectural commitments (authoritative
state, ARCH-0006) that shape the whole game and are extremely costly to retrofit.

## Applies when
Any real-time networked multiplayer, especially competitive games where cheating and latency
directly affect outcomes.

## Does not apply / Exceptions
Purely cooperative or low-stakes multiplayer may tolerate more client trust for simplicity
(peer-to-peer, host-authoritative) — the security bar scales with how much cheating would hurt.
Turn-based and asynchronous games have weaker real-time constraints. And there are genuine
tradeoffs in lag compensation (favoring shooter vs. target) with no perfect answer. Full
server-authority also has cost (server infrastructure) that small/co-op games may forgo.

## Implementation (kept separate from the principle)
Make the server authoritative over outcomes; validate, don't trust, client input. Use client
prediction + reconciliation for responsiveness (FEEL-0002) and lag compensation for fairness
across latencies. Decide the netcode model (authoritative state, ARCH-0006) *early* — it's
foundational. Layer anti-cheat, but rely first on the server-authority architecture. Test under
real latency, packet loss, and adversarial clients (QA).

## Disagreement
Server-authoritative (secure, fair, but infrastructure cost and latency-handling complexity) vs.
client-trusting/peer-to-peer (cheaper, simpler, but exploitable) — the security bar follows the
stakes. And within lag compensation, favor-the-shooter vs. favor-the-target is a genuine,
unresolved fairness tradeoff. Competitive games lean fully authoritative; casual co-op may not.

## Notes
The networking-reality principle of MP; an architectural commitment (authoritative state,
ARCH-0006) that also serves fairness (MP-0003) and responsiveness (FEEL-0002). Confidence 4.

gdc-l1-mp-0004 trust the server, not the client — assume the network is hostile multiplayer netcode authoritative-server anti-cheat lag-compensation > in networked multiplayer, treat the client as untrusted and the network as hostile. make the server authoritative over game state, never trust a client's claims, and use lag compensation to keep play fair and responsive despite latency. fairness and security are designed in, not bolted on. a client runs on a machine the player controls, so anything the client asserts (i hit, i moved there, i have this item) can be forged — which is why a server-authoritative model, where the server validates and owns the truth, is the foundation of fair networked play [s-multiplayer-design]. "never trust the client" limits the cheats possible and protects the competition (mp-0003's fairness). at the same time, latency is unavoidable, so responsiveness (feel-0002) must be preserved through techniques like client prediction and server-side lag compensation (rewinding to validate a shot against what the shooter saw) — balancing "fair to the shooter" against "fair to the target." these are architectural commitments (authoritative state, arch-0006) that shape the whole game and are extremely costly to retrofit. any real-time networked multiplayer, especially competitive games where cheating and latency directly affect outcomes. purely cooperative or low-stakes multiplayer may tolerate more client trust for simplicity (peer-to-peer, host-authoritative) — the security bar scales with how much cheating would hurt. turn-based and asynchronous games have weaker real-time constraints. and there are genuine tradeoffs in lag compensation (favoring shooter vs. target) with no perfect answer. full server-authority also has cost (server infrastructure) that small/co-op games may forgo. make the server authoritative over outcomes; validate, don't trust, client input. use client prediction + reconciliation for responsiveness (feel-0002) and lag compensation for fairness across latencies. decide the netcode model (authoritative state, arch-0006) early — it's foundational. layer anti-cheat, but rely first on the server-authority architecture. test under real latency, packet loss, and adversarial clients (qa). server-authoritative (secure, fair, but infrastructure cost and latency-handling complexity) vs. client-trusting/peer-to-peer (cheaper, simpler, but exploitable) — the security bar follows the stakes. and within lag compensation, favor-the-shooter vs. favor-the-target is a genuine, unresolved fairness tradeoff. competitive games lean fully authoritative; casual co-op may not. the networking-reality principle of mp; an architectural commitment (authoritative state, arch-0006) that also serves fairness (mp-0003) and responsiveness (feel-0002). confidence 4.


Design multiplayer for the real population, not an idealized one: uneven skill and numbers, off-peak hours, disconnects, AFKers, griefers, and a community with its own culture. The game must stay good when the lobby isn't perfect — because it rarely will be.

---
id: GDC-L1-MP-0005
title: Design for the players who actually show up
layer: L1
domain: MP
subdomain: community
type: contextual
confidence: 3
status: canonical
tags:
  - multiplayer
  - community
  - population
  - resilience
  - griefers
related:
  - GDC-L1-MP-0001
  - GDC-L1-MP-0002
  - GDC-L1-SYS-0007
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-multiplayer-design
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Design multiplayer for the *real* population, not an idealized one: uneven skill and numbers,
> off-peak hours, disconnects, AFKers, griefers, and a community with its own culture. The game
> must stay good when the lobby isn't perfect — because it rarely will be.

## Rationale
Multiplayer designs quietly assume full, balanced, well-behaved lobbies, and then reality
delivers a 4v5 after a disconnect, a lopsided skill spread at 3am, a griefer, or a dwindling
off-hours population [S-multiplayer-design]. Systems that only work under ideal conditions fail
constantly in practice. Robust multiplayer plans for the imperfect case: backfill and surrender
options for abandoned matches, bots or scaling for thin populations, penalties and safeguards for
griefing and quitting (MP-0002), and graceful handling of disconnects. Players also form a
*community* with emergent norms and their own optimization pressure (SYS-0007) — anticipate that
they'll find the exploits and the antisocial edges, and design so the common, messy reality still
produces good games.

## Applies when
Any multiplayer game, especially those depending on healthy populations and fair lobbies —
competitive, session-based, and community-driven games.

## Does not apply / Exceptions
Games with guaranteed full, curated lobbies (private matches, esports, tightly-managed sessions)
face less of this. Very large, always-populated games have more slack. But even they hit off-peak
and adversarial conditions eventually. The principle scales with how much the game depends on
other players cooperating.

## Implementation (kept separate from the principle)
Plan for imperfect lobbies: backfill, surrender/forfeit, disconnect handling, bot or scaling
support for thin populations, and anti-griefing/quitting safeguards (MP-0002). Watch the real
community's behavior and norms, and design against the antisocial edges players will find
(SYS-0007). Test with realistic, adversarial, and under-populated conditions, not just ideal
ones.

## Disagreement
Robustness-for-the-real-population (resilient, but more systems to build) vs. design-for-the-happy
-path (simpler, but brittle in practice). Also how much to spend accommodating small/off-peak
populations vs. focusing on peak. The right investment tracks how central healthy lobbies are to
the experience.

## Notes
The resilience/community principle of MP; extends behavior design (MP-0002) and optimization
pressure (SYS-0007) to the messy reality of live populations. Confidence 3 — clearly wise, but
how much to invest is highly game- and population-dependent.

gdc-l1-mp-0005 design for the players who actually show up multiplayer community population resilience griefers > design multiplayer for the real population, not an idealized one: uneven skill and numbers, off-peak hours, disconnects, afkers, griefers, and a community with its own culture. the game must stay good when the lobby isn't perfect — because it rarely will be. multiplayer designs quietly assume full, balanced, well-behaved lobbies, and then reality delivers a 4v5 after a disconnect, a lopsided skill spread at 3am, a griefer, or a dwindling off-hours population [s-multiplayer-design]. systems that only work under ideal conditions fail constantly in practice. robust multiplayer plans for the imperfect case: backfill and surrender options for abandoned matches, bots or scaling for thin populations, penalties and safeguards for griefing and quitting (mp-0002), and graceful handling of disconnects. players also form a community with emergent norms and their own optimization pressure (sys-0007) — anticipate that they'll find the exploits and the antisocial edges, and design so the common, messy reality still produces good games. any multiplayer game, especially those depending on healthy populations and fair lobbies — competitive, session-based, and community-driven games. games with guaranteed full, curated lobbies (private matches, esports, tightly-managed sessions) face less of this. very large, always-populated games have more slack. but even they hit off-peak and adversarial conditions eventually. the principle scales with how much the game depends on other players cooperating. plan for imperfect lobbies: backfill, surrender/forfeit, disconnect handling, bot or scaling support for thin populations, and anti-griefing/quitting safeguards (mp-0002). watch the real community's behavior and norms, and design against the antisocial edges players will find (sys-0007). test with realistic, adversarial, and under-populated conditions, not just ideal ones. robustness-for-the-real-population (resilient, but more systems to build) vs. design-for-the-happy -path (simpler, but brittle in practice). also how much to spend accommodating small/off-peak populations vs. focusing on peak. the right investment tracks how central healthy lobbies are to the experience. the resilience/community principle of mp; extends behavior design (mp-0002) and optimization pressure (sys-0007) to the messy reality of live populations. confidence 3 — clearly wise, but how much to invest is highly game- and population-dependent.


Pick a monetization model — premium, free-to-play, subscription, expansions, cosmetics — that fits the game's design and audience, and be honest with the player about the deal they're getting. The model is a design decision with ethical weight, not a bolt-on afterthought.

---
id: GDC-L1-MON-0001
title: Choose a monetization model that fits the game and is honest about the deal
layer: L1
domain: MON
subdomain: models
type: contextual
confidence: 4
status: canonical
tags:
  - monetization
  - business-model
  - ethics
  - honesty
related:
  - GDC-L1-MON-0002
  - GDC-L1-DESIGN-0001
  - GDC-L1-PROG-0004
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-monetization-ethics
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Pick a monetization model — premium, free-to-play, subscription, expansions, cosmetics —
> that fits the game's design and audience, and be honest with the player about the deal
> they're getting. The model is a design decision with ethical weight, not a bolt-on
> afterthought.

## Rationale
Monetization shapes design: a free-to-play game's economy, pacing, and retention loops are
built around its business model, so choosing the model *after* the design tends to graft
extractive mechanics onto a game that wasn't built for them [S-monetization-ethics]. Different
models fit different games — premium suits a finite, authored experience; F2P suits broad-reach
live games; subscription suits ongoing services — and forcing a mismatched model distorts the
design (DESIGN-0001: the model becomes part of the experience produced). The honesty clause is
the ethical core: players should understand what's free, what costs money, and what they're
buying, up front. A model chosen to fit the game and communicated plainly earns trust; one
chosen to maximize extraction and obscured erodes it.

## Applies when
Any commercial game — the model should be considered early, alongside the design, not tacked on
near launch.

## Does not apply / Exceptions
Non-commercial, free, or art games may have no monetization to design. And the "right" model is
genuinely game-dependent — there's no universally superior choice (premium vs. F2P is a real
strategic decision, not a moral hierarchy). The invariant is *fit and honesty*, not a particular
model.

## Implementation (kept separate from the principle)
Decide the model early and design the game and its economy (ECON) coherently around it. State
the deal plainly (what's free, what's paid, whether there's randomness — MON-0005). Prefer models
where the player's interests and the revenue align (MON-0002) over models that pit them against
each other. Revisit if the design and model drift apart.

## Disagreement
Premium (one honest purchase, aligned incentives, smaller reach) vs. free-to-play (broad reach,
ongoing revenue, but strong temptation toward extractive mechanics) vs. subscription — a genuine
strategic choice with different ethical hazards. This constitution takes no position on *which*
model, only that it fit the game and be honest.

## Notes
The framing principle of the MON domain; ties to ECON (the model shapes the economy), DESIGN-0001
(the model is part of the experience), and the ethics thread (PROG-0004, MON-0002/0003).
Confidence 4.

gdc-l1-mon-0001 choose a monetization model that fits the game and is honest about the deal monetization business-model ethics honesty > pick a monetization model — premium, free-to-play, subscription, expansions, cosmetics — that fits the game's design and audience, and be honest with the player about the deal they're getting. the model is a design decision with ethical weight, not a bolt-on afterthought. monetization shapes design: a free-to-play game's economy, pacing, and retention loops are built around its business model, so choosing the model after the design tends to graft extractive mechanics onto a game that wasn't built for them [s-monetization-ethics]. different models fit different games — premium suits a finite, authored experience; f2p suits broad-reach live games; subscription suits ongoing services — and forcing a mismatched model distorts the design (design-0001: the model becomes part of the experience produced). the honesty clause is the ethical core: players should understand what's free, what costs money, and what they're buying, up front. a model chosen to fit the game and communicated plainly earns trust; one chosen to maximize extraction and obscured erodes it. any commercial game — the model should be considered early, alongside the design, not tacked on near launch. non-commercial, free, or art games may have no monetization to design. and the "right" model is genuinely game-dependent — there's no universally superior choice (premium vs. f2p is a real strategic decision, not a moral hierarchy). the invariant is fit and honesty, not a particular model. decide the model early and design the game and its economy (econ) coherently around it. state the deal plainly (what's free, what's paid, whether there's randomness — mon-0005). prefer models where the player's interests and the revenue align (mon-0002) over models that pit them against each other. revisit if the design and model drift apart. premium (one honest purchase, aligned incentives, smaller reach) vs. free-to-play (broad reach, ongoing revenue, but strong temptation toward extractive mechanics) vs. subscription — a genuine strategic choice with different ethical hazards. this constitution takes no position on which model, only that it fit the game and be honest. the framing principle of the mon domain; ties to econ (the model shapes the economy), design-0001 (the model is part of the experience), and the ethics thread (prog-0004, mon-0002/0003). confidence 4.


Monetization should give the player something they genuinely value in fair exchange for money — content, cosmetics, convenience, expression. It should add value, not manufacture a problem (artificial grind, imposed friction, withheld fun) in order to sell the relief.

---
id: GDC-L1-MON-0002
title: Trade fair value — monetization should add value, not manufacture problems to sell relief
layer: L1
domain: MON
subdomain: value-exchange
type: contextual
confidence: 4
status: canonical
tags:
  - monetization
  - value-exchange
  - ethics
  - player-respect
related:
  - GDC-L1-MON-0003
  - GDC-L1-PROG-0004
  - GDC-L1-UX-0007
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-monetization-ethics
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Monetization should give the player something they genuinely value in fair exchange for
> money — content, cosmetics, convenience, expression. It should *add* value, not manufacture
> a problem (artificial grind, imposed friction, withheld fun) in order to sell the relief.

## Rationale
There are two fundamentally different ways to make money from a game: sell things that make the
experience *better* (new content, cosmetics, quality-of-life), or degrade the experience and
sell the fix (padding the grind so players pay to skip it, adding friction so players pay to
remove it) [S-monetization-ethics]. The first is a fair value exchange that aligns the
studio's and player's interests; the second pits them against each other and treats the player
as a mark. The difference is felt: players reward games that respect them and resent games that
hold fun hostage. This is the monetization face of respecting the player (PROG-0004) and
minimizing manufactured friction (UX-0007) — the friction here is imposed *specifically* to be
sold back.

## Applies when
Any paid content or transaction — DLC, cosmetics, battle passes, convenience purchases, currency.

## Does not apply / Exceptions
Some friction is legitimate design, not a manufactured paywall (a grind that's fun on its own,
a time-cost that creates meaning); the line is whether the friction exists *to be sold*.
Convenience purchases (skip the grind) can be fair when the grind is optional and the game is
fun without paying — the abuse is *building* the grind to force the sale. Genuinely generous
free experiences with optional paid extras are the healthy end of this.

## Implementation (kept separate from the principle)
Audit each monetization hook: does it add value, or does it create a problem the purchase
solves? Keep the free/base experience genuinely good on its own (so paying is a bonus, not a
ransom — echoes PROG-0004). Sell content, expression, and true convenience; don't engineer
tedium or friction to monetize its removal. Ask whether players would feel *respected* or
*exploited* on reflection.

## Disagreement
Value-add monetization (aligned incentives, sustainable goodwill) vs. friction/relief
monetization (higher short-term revenue, player resentment). The engagement/revenue-maximization
case is that these techniques demonstrably work and players opt in; the player-respect case
(this constitution's lean) is that manufacturing problems to sell relief exploits rather than
serves. A real, ongoing industry values split.

## Notes
The value-exchange ethic of MON; the monetization form of PROG-0004 (intrinsic-over-treadmill)
and UX-0007 (don't manufacture friction). Confidence 4.

gdc-l1-mon-0002 trade fair value — monetization should add value, not manufacture problems to sell relief monetization value-exchange ethics player-respect > monetization should give the player something they genuinely value in fair exchange for money — content, cosmetics, convenience, expression. it should add value, not manufacture a problem (artificial grind, imposed friction, withheld fun) in order to sell the relief. there are two fundamentally different ways to make money from a game: sell things that make the experience better (new content, cosmetics, quality-of-life), or degrade the experience and sell the fix (padding the grind so players pay to skip it, adding friction so players pay to remove it) [s-monetization-ethics]. the first is a fair value exchange that aligns the studio's and player's interests; the second pits them against each other and treats the player as a mark. the difference is felt: players reward games that respect them and resent games that hold fun hostage. this is the monetization face of respecting the player (prog-0004) and minimizing manufactured friction (ux-0007) — the friction here is imposed specifically to be sold back. any paid content or transaction — dlc, cosmetics, battle passes, convenience purchases, currency. some friction is legitimate design, not a manufactured paywall (a grind that's fun on its own, a time-cost that creates meaning); the line is whether the friction exists to be sold. convenience purchases (skip the grind) can be fair when the grind is optional and the game is fun without paying — the abuse is building the grind to force the sale. genuinely generous free experiences with optional paid extras are the healthy end of this. audit each monetization hook: does it add value, or does it create a problem the purchase solves? keep the free/base experience genuinely good on its own (so paying is a bonus, not a ransom — echoes prog-0004). sell content, expression, and true convenience; don't engineer tedium or friction to monetize its removal. ask whether players would feel respected or exploited on reflection. value-add monetization (aligned incentives, sustainable goodwill) vs. friction/relief monetization (higher short-term revenue, player resentment). the engagement/revenue-maximization case is that these techniques demonstrably work and players opt in; the player-respect case (this constitution's lean) is that manufacturing problems to sell relief exploits rather than serves. a real, ongoing industry values split. the value-exchange ethic of mon; the monetization form of prog-0004 (intrinsic-over-treadmill) and ux-0007 (don't manufacture friction). confidence 4.


Do not use dark patterns — manipulative designs that exploit cognitive biases to get players to spend in ways they wouldn't on reflection. Artificial urgency (FOMO timers), sunk-cost and loss-aversion traps, obscured real costs (opaque currencies, layered conversions), and reward-anticipation loops belong on a refuse-list, not a design doc.

---
id: GDC-L1-MON-0003
title: Refuse dark patterns — don't exploit cognitive biases to extract spending
layer: L1
domain: MON
subdomain: dark-patterns-to-avoid
type: contextual
confidence: 4
status: canonical
tags:
  - monetization
  - dark-patterns
  - ethics
  - wellbeing
  - manipulation
related:
  - GDC-L1-MON-0002
  - GDC-L1-PROG-0004
  - GDC-L1-UX-0006
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-monetization-ethics
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Do not use dark patterns — manipulative designs that exploit cognitive biases to get players
> to spend in ways they wouldn't on reflection. Artificial urgency (FOMO timers), sunk-cost and
> loss-aversion traps, obscured real costs (opaque currencies, layered conversions), and
> reward-anticipation loops belong on a refuse-list, not a design doc.

## Rationale
Dark patterns work by *overriding* the player's judgment rather than earning their choice: they
weaponize well-documented biases — loss aversion, the sunk-cost fallacy, reward anticipation,
social pressure — and obscure information (the true cost to obtain a reward) so the player can't
decide rationally [S-monetization-ethics]. This is exploitation, not persuasion, and it is most
harmful to those least able to resist it — younger players and people vulnerable to compulsion.
It is the monetization extreme of everything the constitution warns against: manufactured
compulsion (PROG-0004), imposed friction (UX-0007), and the opposite of clear, honest
communication (UX-0003, MON-0005). Beyond the ethics, it is increasingly a *legal* risk —
regulators have fined publishers for undisclosed odds and disguised paywalls.

## Applies when
Any monetization surface — stores, currencies, offers, loot mechanics, timers, bundles.

## Does not apply / Exceptions
Not every persuasive technique is a dark pattern — a genuinely limited-time cosmetic, a clearly-
priced bundle, or an honestly-communicated sale is legitimate marketing. The line is
*manipulation and concealment*: exploiting bias and hiding true cost is the abuse; clear,
honest offers are fine. Intent and transparency separate persuasion from a dark pattern.

## Implementation (kept separate from the principle)
Keep a refuse-list: no fake scarcity/urgency, no obscured real-money cost, no currency mazes
designed to hide value, no compulsion loops (loss-aversion streaks), no predatory targeting of
spenders or minors. Show true costs and odds plainly (MON-0005). Design offers you'd be
comfortable explaining to the player's face. Take extra care where minors may play (UX-0006's
duty-of-care spirit extends here).

## Disagreement
Engagement/revenue-optimization argues these techniques are effective, widely used, and that
adults opt in freely; the player-respect/wellbeing position (this constitution's, and
increasingly regulators') is that exploiting cognitive bias and concealing cost is manipulation
that harms players, especially the vulnerable. This is a genuine, live industry and legal
dispute — but the manipulation-and-concealment core is what this principle refuses.

## Notes
The sharpest ethics principle in the MON domain, with legal as well as moral stakes; the extreme
case of PROG-0004 (compulsion) and the opposite of honest communication (MON-0005, UX-0003).
Confidence 4.

gdc-l1-mon-0003 refuse dark patterns — don't exploit cognitive biases to extract spending monetization dark-patterns ethics wellbeing manipulation > do not use dark patterns — manipulative designs that exploit cognitive biases to get players to spend in ways they wouldn't on reflection. artificial urgency (fomo timers), sunk-cost and loss-aversion traps, obscured real costs (opaque currencies, layered conversions), and reward-anticipation loops belong on a refuse-list, not a design doc. dark patterns work by overriding the player's judgment rather than earning their choice: they weaponize well-documented biases — loss aversion, the sunk-cost fallacy, reward anticipation, social pressure — and obscure information (the true cost to obtain a reward) so the player can't decide rationally [s-monetization-ethics]. this is exploitation, not persuasion, and it is most harmful to those least able to resist it — younger players and people vulnerable to compulsion. it is the monetization extreme of everything the constitution warns against: manufactured compulsion (prog-0004), imposed friction (ux-0007), and the opposite of clear, honest communication (ux-0003, mon-0005). beyond the ethics, it is increasingly a legal risk — regulators have fined publishers for undisclosed odds and disguised paywalls. any monetization surface — stores, currencies, offers, loot mechanics, timers, bundles. not every persuasive technique is a dark pattern — a genuinely limited-time cosmetic, a clearly- priced bundle, or an honestly-communicated sale is legitimate marketing. the line is manipulation and concealment: exploiting bias and hiding true cost is the abuse; clear, honest offers are fine. intent and transparency separate persuasion from a dark pattern. keep a refuse-list: no fake scarcity/urgency, no obscured real-money cost, no currency mazes designed to hide value, no compulsion loops (loss-aversion streaks), no predatory targeting of spenders or minors. show true costs and odds plainly (mon-0005). design offers you'd be comfortable explaining to the player's face. take extra care where minors may play (ux-0006's duty-of-care spirit extends here). engagement/revenue-optimization argues these techniques are effective, widely used, and that adults opt in freely; the player-respect/wellbeing position (this constitution's, and increasingly regulators') is that exploiting cognitive bias and concealing cost is manipulation that harms players, especially the vulnerable. this is a genuine, live industry and legal dispute — but the manipulation-and-concealment core is what this principle refuses. the sharpest ethics principle in the mon domain, with legal as well as moral stakes; the extreme case of prog-0004 (compulsion) and the opposite of honest communication (mon-0005, ux-0003). confidence 4.


In games where players compete or share a world, prefer selling cosmetics, expression, and (optional) convenience over selling competitive power. "Pay-to-win" — where money buys a gameplay advantage others must match with cash or grind — corrodes fairness and the trust the competition depends on.

---
id: GDC-L1-MON-0004
title: Keep pay out of "win" — sell expression and convenience, not competitive power
layer: L1
domain: MON
subdomain: models
type: stylistic
confidence: 3
status: canonical
tags:
  - monetization
  - pay-to-win
  - fairness
  - cosmetics
  - competitive
related:
  - GDC-L1-MON-0002
  - GDC-L1-BAL-0001
  - GDC-L1-MP-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-monetization-ethics
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> In games where players compete or share a world, prefer selling **cosmetics, expression, and
> (optional) convenience** over selling **competitive power**. "Pay-to-win" — where money buys a
> gameplay advantage others must match with cash or grind — corrodes fairness and the trust the
> competition depends on.

## Rationale
There is a meaningful ethical and design line between cosmetic purchases and purchases that
affect gameplay outcomes in a shared or competitive game [S-monetization-ethics]. When money
buys power, the contest is no longer decided by skill or investment but by wallet, which breaks
the fairness that makes competition meaningful (BAL, MP-0003) and tells free or lower-spending
players their effort is worth less than someone's credit card. Cosmetics and expression, by
contrast, let players spend to *personalize* without distorting outcomes — a fair value exchange
(MON-0002). Convenience (skipping optional grind) sits in between and can be acceptable when it
doesn't create a competitive gap. The healthiest competitive monetization keeps the playing field
level and sells everything *around* it.

## Applies when
Competitive and shared-world multiplayer, and any game where one player's purchases affect
another's experience. Less pressing in purely single-player games.

## Does not apply / Exceptions
This is genuinely contested (hence stylistic). Single-player games have no fairness stake in
power purchases (buying an advantage in a solo game harms no one — arguably it's just a
difficulty option). Some entire genres and markets (many mobile RPGs, gacha games) are built on
power monetization and their audiences accept it. And the cosmetic/convenience/power line blurs
(is a time-saver in a co-op game pay-to-win?). The principle is strongest for *competitive
integrity*; it weakens as the shared/competitive stakes fall.

## Implementation (kept separate from the principle)
In competitive/shared games, keep purchasable items cosmetic or expressive; keep power earnable
through play, equally available to all. If selling convenience, ensure it doesn't create a
competitive advantage. Communicate clearly what purchases do (MON-0005). Where the design is
single-player, treat "power for money" as a difficulty/accessibility option, not a fairness
issue.

## Disagreement
Cosmetic-only/fair-play monetization (protects competitive integrity and goodwill) vs.
power/progression monetization (higher revenue, accepted in some genres/markets, harmless in
single-player). A real, market-dependent split — competitive and community-focused games lean
cosmetic-only; many mobile and gacha economies are built on the opposite. Typed stylistic
because it's a genuine values-and-market choice, sharpest where competition is real.

## Notes
The fairness-in-monetization principle; connects MON to balance (BAL-0001) and multiplayer
fairness (MP-0003). Confidence 3 — the competitive case is strong, but the single-player and
genre exceptions make it a contextual/values call.

gdc-l1-mon-0004 keep pay out of "win" — sell expression and convenience, not competitive power monetization pay-to-win fairness cosmetics competitive > in games where players compete or share a world, prefer selling cosmetics, expression, and (optional) convenience over selling competitive power. "pay-to-win" — where money buys a gameplay advantage others must match with cash or grind — corrodes fairness and the trust the competition depends on. there is a meaningful ethical and design line between cosmetic purchases and purchases that affect gameplay outcomes in a shared or competitive game [s-monetization-ethics]. when money buys power, the contest is no longer decided by skill or investment but by wallet, which breaks the fairness that makes competition meaningful (bal, mp-0003) and tells free or lower-spending players their effort is worth less than someone's credit card. cosmetics and expression, by contrast, let players spend to personalize without distorting outcomes — a fair value exchange (mon-0002). convenience (skipping optional grind) sits in between and can be acceptable when it doesn't create a competitive gap. the healthiest competitive monetization keeps the playing field level and sells everything around it. competitive and shared-world multiplayer, and any game where one player's purchases affect another's experience. less pressing in purely single-player games. this is genuinely contested (hence stylistic). single-player games have no fairness stake in power purchases (buying an advantage in a solo game harms no one — arguably it's just a difficulty option). some entire genres and markets (many mobile rpgs, gacha games) are built on power monetization and their audiences accept it. and the cosmetic/convenience/power line blurs (is a time-saver in a co-op game pay-to-win?). the principle is strongest for competitive integrity; it weakens as the shared/competitive stakes fall. in competitive/shared games, keep purchasable items cosmetic or expressive; keep power earnable through play, equally available to all. if selling convenience, ensure it doesn't create a competitive advantage. communicate clearly what purchases do (mon-0005). where the design is single-player, treat "power for money" as a difficulty/accessibility option, not a fairness issue. cosmetic-only/fair-play monetization (protects competitive integrity and goodwill) vs. power/progression monetization (higher revenue, accepted in some genres/markets, harmless in single-player). a real, market-dependent split — competitive and community-focused games lean cosmetic-only; many mobile and gacha economies are built on the opposite. typed stylistic because it's a genuine values-and-market choice, sharpest where competition is real. the fairness-in-monetization principle; connects mon to balance (bal-0001) and multiplayer fairness (mp-0003). confidence 3 — the competitive case is strong, but the single-player and genre exceptions make it a contextual/values call.


Tell players the truth about what they're buying: disclose the real cost in money and the odds of any randomized reward, in plain terms, before purchase. Informed consent requires that material information — true price, drop rates, what the item does — be visible, not buried.

---
id: GDC-L1-MON-0005
title: Be transparent — disclose odds and true costs; enable informed consent
layer: L1
domain: MON
subdomain: ethics
type: contextual
confidence: 4
status: canonical
tags:
  - monetization
  - transparency
  - disclosure
  - odds
  - informed-consent
related:
  - GDC-L1-MON-0003
  - GDC-L1-UX-0003
  - GDC-L1-MON-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-monetization-ethics
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Tell players the truth about what they're buying: disclose the **real cost** in money and the
> **odds** of any randomized reward, in plain terms, before purchase. Informed consent requires
> that material information — true price, drop rates, what the item does — be visible, not buried.

## Rationale
A purchase decision is only fair if the player has the information to make it, and randomized or
currency-obscured monetization routinely hides exactly what the player needs: the real-money cost
to obtain a specific reward, and the probability of getting it [S-monetization-ethics].
Concealing this — through opaque premium currencies, layered conversions, or undisclosed loot-box
odds — is what makes such systems a dark pattern (MON-0003) and, increasingly, illegal.
Transparency is the antidote: publish odds, show true costs, and make the terms legible
(UX-0003). It's also simply respectful — a studio confident its offers are fair has no reason to
hide them. Disclosure lets players who *want* to spend do so knowingly, and lets others opt out.

## Applies when
Any paid transaction, and especially any randomized reward (loot boxes, gacha) or
multi-currency store.

## Does not apply / Exceptions
Straightforward fixed-price purchases (a $10 expansion, a named cosmetic) already carry their
information and need little extra disclosure. Some surprise/reveal in *earned* (non-paid) rewards
is fine — the transparency duty attaches to *money*. Platform and regional regulations set
minimums; meeting them is a floor, not a ceiling.

## Implementation (kept separate from the principle)
Publish drop rates/odds for randomized paid rewards. Show the real-money cost, not just an opaque
currency amount. State what an item does before purchase. Make prices and terms legible (UX-0003),
not buried in menus. Where minors may play, err further toward clarity and restraint (MON-0003).
Treat legal minimums as the floor.

## Disagreement
Little serious dissent that transparency is *right*; the industry tension is how much disclosure
hurts revenue (obscurity sells) versus builds trust. Regulators and player-respect ethics push
toward full disclosure; some business practice resists it. This principle sides with disclosure.

## Notes
The informed-consent principle of MON; the honest counterpart to dark patterns (MON-0003) and an
application of clear communication (UX-0003) to money. Confidence 4.

gdc-l1-mon-0005 be transparent — disclose odds and true costs; enable informed consent monetization transparency disclosure odds informed-consent > tell players the truth about what they're buying: disclose the real cost in money and the odds of any randomized reward, in plain terms, before purchase. informed consent requires that material information — true price, drop rates, what the item does — be visible, not buried. a purchase decision is only fair if the player has the information to make it, and randomized or currency-obscured monetization routinely hides exactly what the player needs: the real-money cost to obtain a specific reward, and the probability of getting it [s-monetization-ethics]. concealing this — through opaque premium currencies, layered conversions, or undisclosed loot-box odds — is what makes such systems a dark pattern (mon-0003) and, increasingly, illegal. transparency is the antidote: publish odds, show true costs, and make the terms legible (ux-0003). it's also simply respectful — a studio confident its offers are fair has no reason to hide them. disclosure lets players who want to spend do so knowingly, and lets others opt out. any paid transaction, and especially any randomized reward (loot boxes, gacha) or multi-currency store. straightforward fixed-price purchases (a $10 expansion, a named cosmetic) already carry their information and need little extra disclosure. some surprise/reveal in earned (non-paid) rewards is fine — the transparency duty attaches to money. platform and regional regulations set minimums; meeting them is a floor, not a ceiling. publish drop rates/odds for randomized paid rewards. show the real-money cost, not just an opaque currency amount. state what an item does before purchase. make prices and terms legible (ux-0003), not buried in menus. where minors may play, err further toward clarity and restraint (mon-0003). treat legal minimums as the floor. little serious dissent that transparency is right; the industry tension is how much disclosure hurts revenue (obscurity sells) versus builds trust. regulators and player-respect ethics push toward full disclosure; some business practice resists it. this principle sides with disclosure. the informed-consent principle of mon; the honest counterpart to dark patterns (mon-0003) and an application of clear communication (ux-0003) to money. confidence 4.


Push as much game behavior, content, and tuning as practical out of compiled code and into data — assets, tables, config, DataAssets — that can be edited and reloaded without a rebuild. This separates what the game does from how the engine runs it, and lets designers and artists iterate directly instead of through a programmer.

---
id: GDC-L1-ARCH-0001
title: Make the game data-driven — push behavior and tuning out of code into editable data
layer: L1
domain: ARCH
subdomain: data-driven-design
type: contextual
confidence: 4
status: canonical
tags:
  - data-driven
  - iteration
  - tooling
  - decoupling
  - empower-creators
related:
  - GDC-L1-ARCH-0005
  - GDC-L1-SYS-0002
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-nystrom-gpp
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Push as much game behavior, content, and tuning as practical out of compiled code and
> into **data** — assets, tables, config, DataAssets — that can be edited and reloaded
> without a rebuild. This separates *what the game does* from *how the engine runs it*,
> and lets designers and artists iterate directly instead of through a programmer.

## Rationale
Games are found through iteration, and the iteration bottleneck is usually the
edit→compile→see-result loop. Moving values and behavior into data collapses that loop:
a designer changes a number or a rule in an asset and sees the result immediately, with
no code change [S-nystrom-gpp]. It also decouples systems — the code becomes a generic
engine that interprets data, so new content is new data rather than new code, and the
people closest to the design (not just programmers) can shape it. The deeper payoff is
architectural: a data-driven system is one where you "build the seam" (baseline plus
parameters) once and fill it endlessly, which is exactly what makes large, tunable
systems tractable.

## Applies when
Content- and tuning-heavy games; anything with many entities, abilities, items, or
values that will be balanced and iterated. The more content and the more iteration
expected, the stronger the case.

## Does not apply / Exceptions
Data-driving everything has real upfront cost — schema design, tooling, an interpretation
layer — and can be over-applied (YAGNI): for a tiny game, a game-jam prototype, or a
one-off system, hardcoding is faster and clearer. Over-abstraction into data can also
hurt readability and debuggability. Data-drive what will actually be iterated; hardcode
what won't.

## Implementation (kept separate from the principle)
Identify the values and behaviors that will be tuned or extended, and expose them as
data with a clear schema. Support hot-reload so edits show up live (see ARCH-0005). Give
the data good authoring tools (even a spreadsheet beats recompiling). Keep the code a
thin, generic interpreter of the data. Validate data on load so bad content fails loudly,
not silently.

## Disagreement
The tension is future-proofing vs. YAGNI. Over-engineering seams that never get used is
waste; under-building them forces painful refactors when iteration demand arrives. The
resolution most teams accept: data-drive the systems you *know* will be iterated heavily
(combat tuning, content), hardcode the rest until proven otherwise.

## Notes
Partners with SYS-0002 (second-order design — data is how you author the rules players play with) and ARCH-0005 (iteration speed). Confidence 4; typed `contextual` for the genuine small-project exception.

gdc-l1-arch-0001 make the game data-driven — push behavior and tuning out of code into editable data data-driven iteration tooling decoupling empower-creators > push as much game behavior, content, and tuning as practical out of compiled code and into data — assets, tables, config, dataassets — that can be edited and reloaded without a rebuild. this separates what the game does from how the engine runs it, and lets designers and artists iterate directly instead of through a programmer. games are found through iteration, and the iteration bottleneck is usually the edit→compile→see-result loop. moving values and behavior into data collapses that loop: a designer changes a number or a rule in an asset and sees the result immediately, with no code change [s-nystrom-gpp]. it also decouples systems — the code becomes a generic engine that interprets data, so new content is new data rather than new code, and the people closest to the design (not just programmers) can shape it. the deeper payoff is architectural: a data-driven system is one where you "build the seam" (baseline plus parameters) once and fill it endlessly, which is exactly what makes large, tunable systems tractable. content- and tuning-heavy games; anything with many entities, abilities, items, or values that will be balanced and iterated. the more content and the more iteration expected, the stronger the case. data-driving everything has real upfront cost — schema design, tooling, an interpretation layer — and can be over-applied (yagni): for a tiny game, a game-jam prototype, or a one-off system, hardcoding is faster and clearer. over-abstraction into data can also hurt readability and debuggability. data-drive what will actually be iterated; hardcode what won't. identify the values and behaviors that will be tuned or extended, and expose them as data with a clear schema. support hot-reload so edits show up live (see arch-0005). give the data good authoring tools (even a spreadsheet beats recompiling). keep the code a thin, generic interpreter of the data. validate data on load so bad content fails loudly, not silently. the tension is future-proofing vs. yagni. over-engineering seams that never get used is waste; under-building them forces painful refactors when iteration demand arrives. the resolution most teams accept: data-drive the systems you know will be iterated heavily (combat tuning, content), hardcode the rest until proven otherwise. partners with sys-0002 (second-order design — data is how you author the rules players play with) and arch-0005 (iteration speed). confidence 4; typed contextual for the genuine small-project exception.


Assemble game entities from small, reusable components rather than from deep inheritance hierarchies. Add behavior by composing parts, not by extending an ever-growing class tree. "This entity has a health component, a movement component, an inventory" scales; "this entity is a subclass of a subclass of Actor" does not.

---
id: GDC-L1-ARCH-0002
title: Favor composition over inheritance — build entities from components
layer: L1
domain: ARCH
subdomain: patterns
type: contextual
confidence: 4
status: canonical
tags:
  - composition
  - components
  - ecs
  - modularity
  - decoupling
related:
  - GDC-L1-ARCH-0003
  - GDC-L1-SYS-0005
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-nystrom-gpp
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Assemble game entities from small, reusable **components** rather than from deep
> inheritance hierarchies. Add behavior by composing parts, not by extending an
> ever-growing class tree. "This entity *has* a health component, a movement component, an
> inventory" scales; "this entity *is a* subclass of a subclass of Actor" does not.

## Rationale
Game entities need behavior in combinations that a single inheritance tree can't express
cleanly — the moment you want "a crate that's also flammable and also a mount," a rigid
hierarchy forces duplication or contortion [S-nystrom-gpp]. Composition sidesteps this:
each capability is an independent, reusable component, and an entity is whatever set of
components it holds. This keeps capabilities decoupled (each component is testable and
editable alone), avoids the duplication that deep inheritance breeds, and lets designers
build new entity types by mixing existing parts — which pairs naturally with data-driven
design (ARCH-0001).

## Applies when
Any game with many entity types that share overlapping-but-not-identical behavior — most
games with a variety of actors, items, or units.

## Does not apply / Exceptions
Composition has overhead: indirection, wiring, and (in full ECS) a real conceptual and
tooling cost that a small game may not need. Shallow, stable inheritance is perfectly
fine where the "is-a" relationship is genuine and unlikely to combine in surprising ways.
Full data-oriented ECS is a bigger commitment than "components over inheritance" and
brings its own tradeoffs (performance wins vs. complexity) — adopt the depth the game
actually needs.

## Implementation (kept separate from the principle)
Model capabilities as components with narrow responsibilities; compose entities from
them. Prefer wiring components together over subclassing. Let components communicate
through events or a shared owner rather than direct hard references (ARCH-0003). Keep each
component's job orthogonal to the others' (the code-level echo of SYS-0005).

## Disagreement
Component/ECS vs. classical OOP inheritance is a long-running debate. Inheritance is
simpler for small, stable hierarchies; composition scales far better for combinatorial
behavior. Full ECS adds performance and decoupling benefits at a real complexity cost.
The pragmatic default — "favor composition, reach for ECS only when its benefits are
needed" — is what this principle encodes.

## Notes
The code-level counterpart to systems-orthogonality (SYS-0005): distinct, non-overlapping parts, whether they're game systems or software components. Confidence 4.

gdc-l1-arch-0002 favor composition over inheritance — build entities from components composition components ecs modularity decoupling > assemble game entities from small, reusable components rather than from deep inheritance hierarchies. add behavior by composing parts, not by extending an ever-growing class tree. "this entity has a health component, a movement component, an inventory" scales; "this entity is a subclass of a subclass of actor" does not. game entities need behavior in combinations that a single inheritance tree can't express cleanly — the moment you want "a crate that's also flammable and also a mount," a rigid hierarchy forces duplication or contortion [s-nystrom-gpp]. composition sidesteps this: each capability is an independent, reusable component, and an entity is whatever set of components it holds. this keeps capabilities decoupled (each component is testable and editable alone), avoids the duplication that deep inheritance breeds, and lets designers build new entity types by mixing existing parts — which pairs naturally with data-driven design (arch-0001). any game with many entity types that share overlapping-but-not-identical behavior — most games with a variety of actors, items, or units. composition has overhead: indirection, wiring, and (in full ecs) a real conceptual and tooling cost that a small game may not need. shallow, stable inheritance is perfectly fine where the "is-a" relationship is genuine and unlikely to combine in surprising ways. full data-oriented ecs is a bigger commitment than "components over inheritance" and brings its own tradeoffs (performance wins vs. complexity) — adopt the depth the game actually needs. model capabilities as components with narrow responsibilities; compose entities from them. prefer wiring components together over subclassing. let components communicate through events or a shared owner rather than direct hard references (arch-0003). keep each component's job orthogonal to the others' (the code-level echo of sys-0005). component/ecs vs. classical oop inheritance is a long-running debate. inheritance is simpler for small, stable hierarchies; composition scales far better for combinatorial behavior. full ecs adds performance and decoupling benefits at a real complexity cost. the pragmatic default — "favor composition, reach for ecs only when its benefits are needed" — is what this principle encodes. the code-level counterpart to systems-orthogonality (sys-0005): distinct, non-overlapping parts, whether they're game systems or software components. confidence 4.


Let systems communicate by broadcasting events through a mediator, rather than holding direct references to one another. A sender announces "this happened" without knowing who listens; listeners subscribe without knowing who sent it. This keeps systems independent — new listeners can be added without touching the sender.

---
id: GDC-L1-ARCH-0003
title: Decouple systems through events, not direct references
layer: L1
domain: ARCH
subdomain: decoupling
type: contextual
confidence: 4
status: canonical
tags:
  - events
  - observer
  - event-queue
  - decoupling
  - messaging
related:
  - GDC-L1-ARCH-0002
  - GDC-L1-SYS-0006
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-nystrom-gpp
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Let systems communicate by broadcasting **events** through a mediator, rather than
> holding direct references to one another. A sender announces "this happened" without
> knowing who listens; listeners subscribe without knowing who sent it. This keeps
> systems independent — new listeners can be added without touching the sender.

## Rationale
Direct references make systems mutually dependent: the combat system calling the audio
system, the UI, the achievement tracker, and the particle system directly becomes a knot
where nothing can change in isolation [S-nystrom-gpp]. An event/observer boundary cuts
the knot — the combat system fires "enemy died" and is done; any number of systems react,
each ignorant of the others. An event *queue* goes further, decoupling *when* a message is
sent from *when* it's processed, which smooths frame spikes and ordering. This is the
architecture that lets a system like a behavior-observing skill engine watch everything
the player does without every other system having to know it exists.

## Applies when
Cross-cutting reactions to game events (audio, UI, VFX, analytics, progression), and any
system that must observe many others without coupling to them.

## Does not apply / Exceptions
Events are not free. Indirection makes control flow harder to trace, hides ordering
dependencies, and — overused — produces "event spaghetti" where no one can tell what
happens when. For tight, direct, one-to-one relationships a plain function call is
clearer and more debuggable than an event. Use events to decouple *across* system
boundaries; don't event-ify everything inside a system.

## Implementation (kept separate from the principle)
Define a clear, typed event vocabulary (a fixed set of well-named events beats ad-hoc
strings). Fire events at meaningful moments; let systems subscribe. Consider an event
queue when timing/ordering or frame-spikes matter. Guard debuggability: log/inspect the
event stream, and keep the vocabulary small and documented (this is where ARCH meets
SYS-0006, legibility — events can hurt traceability, so invest in tooling that restores
it).

## Disagreement
Event-driven decoupling vs. direct calls is a real tradeoff: decoupling and extensibility
vs. traceability and simplicity. The synthesis: use events at seams where decoupling pays
(many independent reactors, or a system that must not know its observers), and direct
calls where the relationship is tight and clarity matters more than flexibility.

## Notes
Confidence 4.

gdc-l1-arch-0003 decouple systems through events, not direct references events observer event-queue decoupling messaging > let systems communicate by broadcasting events through a mediator, rather than holding direct references to one another. a sender announces "this happened" without knowing who listens; listeners subscribe without knowing who sent it. this keeps systems independent — new listeners can be added without touching the sender. direct references make systems mutually dependent: the combat system calling the audio system, the ui, the achievement tracker, and the particle system directly becomes a knot where nothing can change in isolation [s-nystrom-gpp]. an event/observer boundary cuts the knot — the combat system fires "enemy died" and is done; any number of systems react, each ignorant of the others. an event queue goes further, decoupling when a message is sent from when it's processed, which smooths frame spikes and ordering. this is the architecture that lets a system like a behavior-observing skill engine watch everything the player does without every other system having to know it exists. cross-cutting reactions to game events (audio, ui, vfx, analytics, progression), and any system that must observe many others without coupling to them. events are not free. indirection makes control flow harder to trace, hides ordering dependencies, and — overused — produces "event spaghetti" where no one can tell what happens when. for tight, direct, one-to-one relationships a plain function call is clearer and more debuggable than an event. use events to decouple across system boundaries; don't event-ify everything inside a system. define a clear, typed event vocabulary (a fixed set of well-named events beats ad-hoc strings). fire events at meaningful moments; let systems subscribe. consider an event queue when timing/ordering or frame-spikes matter. guard debuggability: log/inspect the event stream, and keep the vocabulary small and documented (this is where arch meets sys-0006, legibility — events can hurt traceability, so invest in tooling that restores it). event-driven decoupling vs. direct calls is a real tradeoff: decoupling and extensibility vs. traceability and simplicity. the synthesis: use events at seams where decoupling pays (many independent reactors, or a system that must not know its observers), and direct calls where the relationship is tight and clarity matters more than flexibility. confidence 4.


Express game rules in terms of the game, not the engine. Isolate gameplay logic behind interfaces so it doesn't depend directly on rendering, input, platform, or engine internals. The more your rules are engine-agnostic, the more testable, portable, and durable they are.

---
id: GDC-L1-ARCH-0004
title: Keep game logic decoupled from engine and platform specifics
layer: L1
domain: ARCH
subdomain: gameplay-architecture
type: contextual
confidence: 3
status: canonical
tags:
  - separation-of-concerns
  - portability
  - testability
  - engine-agnostic
related:
  - GDC-L1-ARCH-0001
  - GDC-L1-ARCH-0003
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-gregory-game-engine-arch
  - S-nystrom-gpp
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Express game rules in terms of the game, not the engine. Isolate gameplay logic behind
> interfaces so it doesn't depend directly on rendering, input, platform, or engine
> internals. The more your rules are engine-agnostic, the more testable, portable, and
> durable they are.

## Rationale
Engine and platform details churn — APIs change, engines get upgraded, platforms come and go — while a game's core rules are comparatively stable [S-gregory-game-engine-arch]. Binding rules directly to engine specifics couples the durable to the volatile, so an engine change ripples into gameplay code, and the rules can't be unit-tested without spinning up the whole engine. A clean seam between "the game" and "the engine that runs it" contains that volatility: gameplay logic becomes testable in isolation and survives engine changes, and the engine-specific layer stays thin and replaceable.

## Applies when
Longer-lived projects, teams anticipating engine upgrades or ports, and any logic worth
unit-testing. The value grows with the project's lifespan and the cost of an engine change.

## Does not apply / Exceptions
This is the most contested ARCH principle, and honestly so. For a team fully committed to
one engine, *embracing* the engine's idioms (its component model, its ability system, its
data assets) is often more pragmatic than abstracting over them — over-abstraction to
preserve a portability you'll never use is wasted effort and can fight the engine.
Prototypes and jam games should just use the engine directly. Decouple where testability
or longevity genuinely pays; otherwise lean into the engine.

## Implementation (kept separate from the principle)
Keep core rules in engine-agnostic terms and push engine calls to a thin adapter layer.
Depend on interfaces, not concrete engine types, at the seam. Aim for gameplay logic you
can exercise in a test harness without the full runtime. But calibrate the effort to the
project — a fully committed single-engine game may draw the seam loosely.

## Disagreement
Engine-agnostic purity vs. engine-embrace is a live disagreement with no universal winner.
Purity buys testability and portability; embrace buys velocity and full use of the engine's
strengths. The deciding factors are project lifespan, port intentions, and how much of the
engine you're leaning on.

## Notes

gdc-l1-arch-0004 keep game logic decoupled from engine and platform specifics separation-of-concerns portability testability engine-agnostic > express game rules in terms of the game, not the engine. isolate gameplay logic behind interfaces so it doesn't depend directly on rendering, input, platform, or engine internals. the more your rules are engine-agnostic, the more testable, portable, and durable they are. engine and platform details churn — apis change, engines get upgraded, platforms come and go — while a game's core rules are comparatively stable [s-gregory-game-engine-arch]. binding rules directly to engine specifics couples the durable to the volatile, so an engine change ripples into gameplay code, and the rules can't be unit-tested without spinning up the whole engine. a clean seam between "the game" and "the engine that runs it" contains that volatility: gameplay logic becomes testable in isolation and survives engine changes, and the engine-specific layer stays thin and replaceable. longer-lived projects, teams anticipating engine upgrades or ports, and any logic worth unit-testing. the value grows with the project's lifespan and the cost of an engine change. this is the most contested arch principle, and honestly so. for a team fully committed to one engine, embracing the engine's idioms (its component model, its ability system, its data assets) is often more pragmatic than abstracting over them — over-abstraction to preserve a portability you'll never use is wasted effort and can fight the engine. prototypes and jam games should just use the engine directly. decouple where testability or longevity genuinely pays; otherwise lean into the engine. keep core rules in engine-agnostic terms and push engine calls to a thin adapter layer. depend on interfaces, not concrete engine types, at the seam. aim for gameplay logic you can exercise in a test harness without the full runtime. but calibrate the effort to the project — a fully committed single-engine game may draw the seam loosely. engine-agnostic purity vs. engine-embrace is a live disagreement with no universal winner. purity buys testability and portability; embrace buys velocity and full use of the engine's strengths. the deciding factors are project lifespan, port intentions, and how much of the engine you're leaning on.


Treat the length of the change-to-feedback loop as a primary architectural concern. Hot-reload, live tuning, data-driven values, fast builds, and good in-editor tools all compound: the faster a creator sees the result of a change, the more iterations they get — and iteration count, not any single decision, is what produces quality.

---
id: GDC-L1-ARCH-0005
title: Architect for iteration speed — treat the change-to-feedback loop as first-class
layer: L1
domain: ARCH
subdomain: code-that-designers-can-touch
type: objective
confidence: 4
status: canonical
tags:
  - iteration
  - hot-reload
  - tooling
  - workflow
  - empower-creators
related:
  - GDC-L1-ARCH-0001
  - GDC-L1-DESIGN-0001
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-nystrom-gpp
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Treat the length of the change-to-feedback loop as a primary architectural concern.
> Hot-reload, live tuning, data-driven values, fast builds, and good in-editor tools all
> compound: the faster a creator sees the result of a change, the more iterations they
> get — and iteration count, not any single decision, is what produces quality.

## Rationale
Good games are found, not specified — the target experience only becomes real through
repeated try-observe-adjust cycles against actual play (DESIGN-0001). That makes the
*cost of one iteration* the master variable of a project's quality ceiling: halve the
edit→see-result time and you roughly double how many refinements fit in the same schedule.
Architecture directly sets that cost — a codebase that requires a full recompile and
relaunch to test a tweak strangles iteration, while one with hot-reloadable data and live
tuning invites it [S-nystrom-gpp]. Investing in iteration speed pays back continuously,
across every future change.

## Applies when
Throughout development, for any system that will be tuned or iterated — which is most of a
game. The earlier the investment, the more cycles benefit.

## Does not apply / Exceptions
Iteration tooling has upfront cost, and there's a point of diminishing returns — building
elaborate live-tuning for a value you'll set once is waste. Tiny or one-off projects may
not recoup the investment. Spend the tooling budget where iteration will actually be heavy.

## Implementation (kept separate from the principle)
Make tunable values data-driven and hot-reloadable (ARCH-0001). Minimize build and load
times on the critical iteration path. Provide in-editor/live controls for the parameters
designers touch most. Measure the loop: if changing a combat value takes minutes, that's
an architectural bug worth fixing. Prefer play-in-editor and fast preview over
full-rebuild testing.

## Disagreement
Little on the principle; debate is only about *how much* to invest and *when*. The honest
caution is over-tooling — gold-plating iteration affordances that never get used. Target
the systems with real iteration demand.

## Notes
The architectural enabler of the whole design-by-iteration philosophy (DESIGN-0001, and
the PROTO domain to come). Tightly paired with ARCH-0001 (data-driven). Confidence 4.

gdc-l1-arch-0005 architect for iteration speed — treat the change-to-feedback loop as first-class iteration hot-reload tooling workflow empower-creators > treat the length of the change-to-feedback loop as a primary architectural concern. hot-reload, live tuning, data-driven values, fast builds, and good in-editor tools all compound: the faster a creator sees the result of a change, the more iterations they get — and iteration count, not any single decision, is what produces quality. good games are found, not specified — the target experience only becomes real through repeated try-observe-adjust cycles against actual play (design-0001). that makes the cost of one iteration the master variable of a project's quality ceiling: halve the edit→see-result time and you roughly double how many refinements fit in the same schedule. architecture directly sets that cost — a codebase that requires a full recompile and relaunch to test a tweak strangles iteration, while one with hot-reloadable data and live tuning invites it [s-nystrom-gpp]. investing in iteration speed pays back continuously, across every future change. throughout development, for any system that will be tuned or iterated — which is most of a game. the earlier the investment, the more cycles benefit. iteration tooling has upfront cost, and there's a point of diminishing returns — building elaborate live-tuning for a value you'll set once is waste. tiny or one-off projects may not recoup the investment. spend the tooling budget where iteration will actually be heavy. make tunable values data-driven and hot-reloadable (arch-0001). minimize build and load times on the critical iteration path. provide in-editor/live controls for the parameters designers touch most. measure the loop: if changing a combat value takes minutes, that's an architectural bug worth fixing. prefer play-in-editor and fast preview over full-rebuild testing. little on the principle; debate is only about how much to invest and when. the honest caution is over-tooling — gold-plating iteration affordances that never get used. target the systems with real iteration demand. the architectural enabler of the whole design-by-iteration philosophy (design-0001, and the proto domain to come). tightly paired with arch-0001 (data-driven). confidence 4.


Decide early what the game's authoritative state is and how it serializes. Save/load, networking, and determinism all depend on a clean answer to "what is the state, and how does it persist?" Retrofitting persistence onto a codebase that ignored it is painful, bug-prone, and sometimes save-breaking.

---
id: GDC-L1-ARCH-0006
title: Decide your authoritative state and how it serializes — early
layer: L1
domain: ARCH
subdomain: save-systems
type: contextual
confidence: 3
status: canonical
tags:
  - save-systems
  - serialization
  - state
  - determinism
  - networking
related:
  - GDC-L1-ARCH-0001
  - GDC-L1-ARCH-0004
depends_on: []
conflicts_with: []
supersedes: []
sources:
  - S-gregory-game-engine-arch
first_added: 2026-07-14
last_verified: 2026-07-14
---

## Statement
> Decide early what the game's **authoritative state** is and **how it serializes**.
> Save/load, networking, and determinism all depend on a clean answer to "what is the
> state, and how does it persist?" Retrofitting persistence onto a codebase that ignored
> it is painful, bug-prone, and sometimes save-breaking.

## Rationale
Persistence cuts across everything: if state is scattered, implicit, or tangled with
transient runtime objects, then saving, loading, syncing, or replaying it becomes a
minefield of special cases [S-gregory-game-engine-arch]. Deciding up front what is
canonical state (versus derived or transient), and giving it a stable serialized form,
keeps that complexity contained. It also front-loads decisions that are *expensive to
change later* — notably identifier and format stability: once a build ships, the ids and
schemas in save files are effectively permanent, because changing them breaks existing
saves. Thinking about this before shipping avoids a class of the worst late bugs.

## Applies when
Any game with saves, progression, multiplayer, or replays — anything where state must
persist or synchronize. The larger and longer-lived the state, the more this matters.

## Does not apply / Exceptions
Games with little or no persistent state (pure arcade loops, some session-only
experiences) can treat this lightly. Early prototypes may defer it deliberately — but
should *know* they're deferring it, since the cost of retrofitting rises with codebase
size.

## Implementation (kept separate from the principle)
Distinguish authoritative state from derived/transient state, and keep the authoritative
set explicit and serializable. Choose stable identifiers and a versioned save format
early; treat shipped ids and schemas as append-only/immutable. Design state so it can be
reconstructed from its serialized form. If determinism or netcode is a goal, decide that
early too — it constrains the whole architecture.

## Disagreement
Mostly about timing: persistence-first designers argue state/serialization should shape
architecture from day one; YAGNI-leaning developers defer it to avoid over-designing an
uncertain game. The reconciliation: the *decision* about what state is authoritative
should be early and conscious even if the *implementation* is deferred — deferring
knowingly is fine, ignoring it is not.

## Notes
Confidence 3; typed `contextual` for the low-persistence exception.

gdc-l1-arch-0006 decide your authoritative state and how it serializes — early save-systems serialization state determinism networking > decide early what the game's authoritative state is and how it serializes. save/load, networking, and determinism all depend on a clean answer to "what is the state, and how does it persist?" retrofitting persistence onto a codebase that ignored it is painful, bug-prone, and sometimes save-breaking. persistence cuts across everything: if state is scattered, implicit, or tangled with transient runtime objects, then saving, loading, syncing, or replaying it becomes a minefield of special cases [s-gregory-game-engine-arch]. deciding up front what is canonical state (versus derived or transient), and giving it a stable serialized form, keeps that complexity contained. it also front-loads decisions that are expensive to change later — notably identifier and format stability: once a build ships, the ids and schemas in save files are effectively permanent, because changing them breaks existing saves. thinking about this before shipping avoids a class of the worst late bugs. any game with saves, progression, multiplayer, or replays — anything where state must persist or synchronize. the larger and longer-lived the state, the more this matters. games with little or no persistent state (pure arcade loops, some session-only experiences) can treat this lightly. early prototypes may defer it deliberately — but should know they're deferring it, since the cost of retrofitting rises with codebase size. distinguish authoritative state from derived/transient state, and keep the authoritative set explicit and serializable. choose stable identifiers and a versioned save format early; treat shipped ids and schemas as append-only/immutable. design state so it can be reconstructed from its serialized form. if determinism or netcode is a goal, decide that early too — it constrains the whole architecture. mostly about timing: persistence-first designers argue state/serialization should shape architecture from day one; yagni-leaning developers defer it to avoid over-designing an uncertain game. the reconciliation: the decision about what state is authoritative should be early and conscious even if the implementation is deferred — deferring knowingly is fine, ignoring it is not. confidence 3; typed contextual for the low-persistence exception.