The short version: Let the prototype prove behavior and the living GDD explain intent, ownership, constraints, and open questions; keep both tied to the same revision.

“The game is the design document” sounds refreshingly anti-bureaucratic. It is also what teams say shortly before asking why a system exists, which version was approved, or whether changing one variable breaks three others.

A build answers what happens now. It does not reliably answer why, who decided, what remains unresolved, or what must not change.

The prototype’s job

Use a prototype to test risky behavior:

  • Is the core interaction understandable?
  • Does the loop create the intended decision?
  • Can the technology support the mechanic?
  • Does the pace survive contact with a player?

Code is excellent evidence for behavior. It is a poor meeting record and a terrible place to hide business rules from non-programmers.

The living document’s job

Keep the document small and operational. For each important system, record:

  • player purpose;
  • current rule and owner;
  • dependencies and tunable values;
  • state: proposed, testing, accepted, or cut;
  • decision date and build/revision tested;
  • evidence and unresolved risks.

The document should link to the build, data, mockup, or task that proves the current state. It should not duplicate every implementation detail.

Versioning matters

Epic’s Unreal documentation describes source control as the mechanism for managing changes over time and coordinating developers. The same principle applies to design decisions. A screenshot from last month and a build from today are not one source of truth unless the relationship is explicit.

Tag playtest notes and design decisions to a build identifier or source revision. When a rule changes, record what evidence changed the decision.

The spicy middle ground

The alternative to a 200-page frozen GDD is not zero documentation. It is a decision system: one-page vision, current loop, system contracts, content tables, open questions, and dated decisions.

Delete prose nobody uses. Preserve the information that prevents re-litigation and accidental breakage.

Sources and limits

The right documentation depth varies by team and risk. This article is production guidance, not a claim that one template fits every studio.

Key takeaway

The prototype proves behavior. The living GDD preserves the decision around it. Keep both lean, versioned, and connected.

game prototypeGDDdesign documentationdecision log