Documentation
What is a GDD and how do you keep it useful?
Programming follows a rule in the GDD; design changed it in the latest prototype. Both mean well, but they are building different games. Let's look at what the document should capture and how to stop it falling behind.
Key idea
The GDD records current decisions and open questions; it should evolve with what the team learns.
A Game Design Document, or GDD, is a working document that describes how a game should function and why particular decisions are made. It can cover mechanics, rules, progression, interface, economy, references and open questions. Its form depends on the project: there is no universal template that works for every team.
A tool for coordination
The GDD is not the manual the player receives. Its purpose is to help the different disciplines involved understand what they are building. Design may describe a rule; programming needs to know its states and conditions; art and sound need to know which actions, objects or situations they must communicate.
That is why a useful GDD combines description and context. Saying that an action deals ten points of damage is not enough: it helps to explain its role in combat, what the player should perceive and which special cases the system needs to handle.
A living document, maintained responsibly
Design is discovered through prototyping, testing and discarding options. A test may reveal that a mechanic does not produce the intended decision, that a value changes the pacing or that an interface hides essential information. The document needs to change with those findings.
Being a living document does not mean it can remain out of date. If a GDD keeps rules that have been removed or numbers that are no longer used, it stops being a reliable source and becomes noise. A useful practice is to keep decisions that affect the team's work up to date and record uncertainties that still need testing.
Documented design, not frozen design
The goal is not to write an enormous document before production begins. It is to preserve a clear reference for relevant decisions as the game evolves. Used well, a GDD ensures that lessons from development reach the whole team rather than remaining only in the memory of whoever made the decision.
Apply it to your game
- Choose a mechanic and document its purpose, current rules, required states and cases that remain unresolved.
- After a test changes that mechanic, review the affected section and record the decision and its reasoning. Do not leave the previous version looking current.
- Ask someone from another discipline to check whether they can work from that information. Add what they need to act and remove what no longer describes the game.
To check whether the document makes sense without its author, use the clarity test offered by game manuals. When a decision remains open, a prototype with a specific question can provide the missing evidence.