Документация и GDD

Почему отличные game ideas fail in execution? Often: team wasn't aligned. Documentation isn't bureaucracy - it's shared understanding. GDD, pitch, wiki - tools для 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 game's design. Not novel - working document. Describes what game IS, не how to build it. Lives and evolves with project.

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

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

Pitch Document

**Pitch document** - short, exciting sell of your game. Not GDD - 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 proven genre с studio's unique skill. Clear hook: 'our storytelling in a roguelike.' Funded quickly.

**Pitch tips:** - Lead with hook, не features - One page is often enough - Visuals 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: other half is meetings, conversations, shared understanding. Best docs fail if team doesn't read them.

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

**Communication practices:** - Single source of truth (one place для 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 project. Not written once, forgotten - continuously updated. Wiki-style, version-controlled, linked. If doc doesn't match game, doc is wrong.

**Riot's 'spec' culture.** Every feature has spec document. Updated as implementation happens. Spec ≠ reality = spec must change. Documentation is conversation с 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)

Итоги

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

Связанные темы

Documentation supports full development process:

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

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

• Как бы ты pitched YOUR game idea в one sentence?
• What's worse: no documentation или outdated documentation?
• Ты prefer reading docs или asking people? Why?

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

• st-01-feedback-loops