Documentation and GDD

Why do great game ideas fail in execution? Often: the team wasn't aligned. Documentation isn't bureaucracy - it's shared understanding. GDD, pitch, wiki - tools for making sure everyone builds the same game.

• **Hades pitch** - 'roguelike + our narrative' - clear hook secured funding quickly
• **Riot's spec culture** - every feature documented, updated continuously. Scales to thousands of employees
• **Indie wiki approach** - Notion/wiki replaces old 500-page GDDs. Living documents > static tomes

GDD Structure

**Game Design Document (GDD)** - central reference for a game's design. Not a novel - a working document. Describes what the game IS, not how to build it. Lives and evolves with the project.

**GDD evolution.** Old school: 500-page bibles, read once, ignored. Modern: wiki/Notion, constantly updated, searchable. Living document > static tome. A GDD should be USED, not archived.

**GDD principles:** - Write for the reader, not yourself - Update constantly (outdated GDD = useless) - Include visuals (mockups, diagrams) - Version control (what changed when)

Pitch Document

**Pitch document** - a short, exciting sell of your game. Not a GDD - the pitch is marketing to stakeholders (publisher, investors, team). Goal: make them WANT to know more. Hook first, details later.

**Hades' pitch success.** Supergiant pitched: 'roguelike + our narrative strength.' Combined a proven genre with the studio's unique skill. Clear hook: 'our storytelling in a roguelike.' Funded quickly.

**Pitch tips:** - Lead with hook, not features - One page is often enough - Visuals are crucial (concept art > words) - Know your audience (publisher vs investor)

Team Communication

**Team communication** - how design reaches everyone who needs it. Documentation is only half: the other half is meetings, conversations, shared understanding. The best docs fail if the team doesn't read them.

**'5-minute rule.'** If an explanation takes >5 minutes, write it down. If a question is asked twice, document the answer. Team time is precious - don't repeat yourself, create a reference.

**Communication practices:** - Single source of truth (one place for each topic) - Announce changes actively (don't assume people check) - Visual > text when possible - Regular syncs (alignment meetings)

Living Documentation

**Living documentation** - docs that evolve with the project. Not written once, forgotten - continuously updated. Wiki-style, version-controlled, linked. If the doc doesn't match the game, the doc is wrong.

**Riot's 'spec' culture.** Every feature has a spec document. Updated as implementation happens. Spec ≠ reality = spec must change. Documentation is a conversation with future team members.

**Living doc tips:** - Small updates frequently > big updates rarely - Date everything (when was this true?) - Archive, don't delete (history matters) - Celebrate doc contributions (culture thing)

Summary

• **GDD** = a working reference, not a novel. Update constantly or it becomes misinformation
• **Pitch** = hook first, details later. One exciting idea > twenty bullet points
• **Living documentation** - right amount, right place, always current. If the team doesn't use it, it doesn't exist

Related Topics

Documentation supports the full development process:

• Prototyping — Documents what prototypes teach
• Iteration — Documents design changes

Вопросы для размышления

• How would you pitch YOUR game idea in one sentence?
• What's worse: no documentation or outdated documentation?
• Do you prefer reading docs or asking people? Why?

Связанные уроки

• st-01-feedback-loops