Documentation
Game manuals and GDDs: documenting with clarity
Your team has a document, yet every question comes back to you. Does it explain the game, or does it depend on you explaining it? Board game manuals offer a useful test for spotting that dependency.
Key idea
Documentation is useful when people can act on it without asking its author to interpret every decision.
A board game manual and a Game Design Document (GDD) serve different audiences, but they share one essential requirement: they must allow someone else to act confidently without depending on the person who wrote them.
The manual as a test of clarity
When someone opens a board game at home, the designer is not there to answer questions. The rules need to appear in the right order, use consistent terminology and anticipate ambiguities that could bring a game to a halt. This makes writing a manual a useful test of the design: it forces you to separate what the designer takes for granted from what the player needs to understand.
The GDD is not an internal rulebook
A GDD describes how an experience should work so that design, programming, art, sound and production can build it together. It does not have to teach people how to play, nor does it need the rigidity of a published manual. It changes as the team prototypes and makes decisions.
However, that flexibility should not become a dependence on informal conversations. A document that only makes sense to someone who has spent months on the project fails as a shared reference.
A principle for design work
Writing manuals develops a transferable discipline: asking what the reader already knows, what they need to know before making a decision and which terms could be interpreted in more than one way. Applied to a GDD, this discipline improves onboarding for new team members, reduces rework and makes unresolved decisions visible.
A good document does not replace conversation or attempt to lock down the game before testing it. It gives the team a common language so that conversations, changes and tests start from the same understanding of the system.
Apply it to your game
- Choose a rule and ask someone who did not write it to explain how they would implement or apply it. Note where they need to ask you questions.
- Review the terms they interpreted differently. Use the same name for the same concept, and add an example where a rule leaves room for doubt.
- Separate decisions from things that still need testing. The team should be able to tell a current specification from an open question.
If you are deciding what the document should cover, start with what a GDD is and how to keep it useful. For the text players will read, the next step is designing how to teach the rules.