Game Documentation
An essential part of any game production is game documentation. Good game documentation is ensuring that everyone working on the game production is on the same page and working towards the same goals. These documents serve two purposes:
- Memory aid
- Communication tool
Game Design Document (GDD)
The most crucial game document is the Game Design Document or GDD. The GDD is comprised of several documents that are revised during each phase of the development process and includes the following information:
- The core idea of the game
- Team tasks and timeline
- The game atmosphere (mood & tone)
- The goal of the game
- Plan for implementation
Throughout the stages of the game production, the GDD evolves into a variety of different types of documents these include:
| Document | Purpose | When It Appears in the Pipeline | Production Phase |
|---|---|---|---|
| Initial Concept Document | Captures the raw idea from brainstorming, outlining the core concept, theme, and basic mechanics. | First stage, immediately after brainstorming. | Concept |
| Pitch Document | A refined, high-level proposal that sells the game idea, focusing on feasibility, market potential, and unique selling points. | Early stage, used to secure approval from stakeholders, investors, or internal leads. | Concept |
| Project Charter | Formalizes the approved project's scope, team structure, objectives, risks, and constraints. | After the Pitch Document, to officially initiate the development process. | Pre-Production |
| Project Proposal | Combines the Pitch and Project Charter into a single document, detailing the creative concept, project scope, objectives, team structure, risks, constraints, and market feasibility. | After the Project Charter, used as the formal document to secure final approval and resources. | Pre-Production |
| Game Design Brief | Expands on gameplay mechanics, objectives, and structure, serving as a bridge between the concept and full design documentation. | Early development, after the project is approved but before full documentation. | Pre-Production |
| Art & Audio Briefs | Define the game's visual style, assets, animations, music, and sound effects to maintain consistency. | After the Game Design Brief, to guide artists and composers. | Pre-Production |
| Game Design Document (GDD) | A comprehensive blueprint detailing gameplay, mechanics, levels, UI, player experience, and design philosophy. | Early to mid-development, evolving as the game progresses. | Pre-Production to Production |
| Style Guide | Specifies design strategies and standards for all assets, code, and version control systems to maintain consistency in visual and audio elements. | Created alongside the GDD, acts as a reference for design, art, and development teams. | Pre-Production to Production |
| Technical Design Document (TDD) | Outlines the game's technical aspects, including the engine, networking, physics, AI, and performance considerations. | As needed, usually created alongside or after the GDD when technical feasibility is being addressed. | Pre-Production to Production |
Other GDD Docs
Other documents that are typically developed in a game production include:
| Document | Purpose | When It Appears in the Pipeline | Production Phase |
|---|---|---|---|
| Story Overview | Provides an outline of the game's narrative, key characters, and story structure. | Early Pre-Production, to ensure alignment with the game's theme and vision. | Pre-Production |
| Puzzle/Quest Document | Describes puzzles, quests, and player challenges, including objectives, solutions, and mechanics. | After the Game Design Brief, used to plan gameplay challenges and player tasks. | Pre-Production |
| Pipeline Overview | Outlines the processes, tools, and workflows for asset creation, integration, and iteration. | Early Pre-Production, to align teams on asset workflows and technical pipelines. | Pre-Production |
| System Limitations | Defines technical constraints, platform limitations, and hardware specs affecting gameplay. | Early Pre-Production, ensures design aligns with platform capabilities. | Pre-Production |
| Game Budget | A detailed breakdown of financial resources required, including development costs, team salaries, marketing, and other expenses. | Early Pre-Production, defines financial scope and resource allocation. | Pre-Production |
| Project Schedule | A timeline with milestones, deadlines, and task assignments. | Early Pre-Production, updated throughout Production and into Post-Production for tracking. | Pre-Production to Production |
| UX Design Standards | Specifies standards for user experience, including interface flow, accessibility, and interaction design. | After Game Design Document, guides UI/UX design for consistency and player engagement. | Pre-Production to Production |
| Story Guide | Expands on the story overview, providing detailed character backstories, world-building, and dialogue. | After Story Overview, often used during scriptwriting and character development. | Pre-Production to Production |
| Level Walkthrough | Detailed guide for each level, including objectives, obstacles, and enemy placements. | After Game Design Document, detailed breakdown of levels to guide design and asset creation. | Production |
| Script | The full game script, including dialogues, monologues, cutscene instructions, and other narrative elements. | Mid Production, as the narrative and interactions are finalized and recorded. | Production |
| Game Tutorials | Detailed design for any in-game tutorials, including mechanics, instructions, and player guidance. | Mid Production, created to introduce players to new mechanics and systems. | Production |
| Quality Assurance (QA) Documentation | Documents testing plans, bug tracking, and fixes for quality control. | Late Production to Post-Production, essential for bug testing and refining the game. | Post-Production |
| Patch Notes | Lists updates, bug fixes, and changes made to the game after release. | Post-Production, used to communicate updates and fixes to the community. | Post-Production |
| Player Feedback Documentation | Documents player feedback, suggestions, and reactions to the game. | After release, as part of ongoing content improvement and updates. | Post-Production |
Rules for Good GDD
When writing a good GDD it is important to follow these rules:
- Know your target: who are you writing this version of the document for? Your development might need more technical details provided while the publishing team is less concerned about the actual development, but more so on costs and gains.
- Keep it short: Nobody has time to read a ton of pages, keeping the documents short and well organized will help everyone stay abreast of the details and easily find the information they need to get their task done.
- Prioritize the design: focus on the overall design of the game. Development details will change over time.
- Illustrate: Pictures are worth more than words. Whenever possible use images, even reference art to illustrate what you are aiming for.
- Do not micromanage: while it is important to stay time on task, things change, and the development/design team needs to be able to release their creativity on the project.
- Use user stories: get feedback from playtesters to help illustrate how and why the game will succeed.
- Separate code from content: going back to knowing your audience, keep the technical information separate from the overall content of the game.
- Invest in a good format: Use a format that works for everyone on your team.
- Use clear terminology: To ensure everyone is referring to the same thing, use clear and consistent terminology for documentation. For example, does the game use gold or cash, these could both be in the game, so you will have to set guidelines as to when and where each term should be used.
- Kill redundancy: do not keep repeating the same information in different documents, keep things short, clear, and precise.
- Avoid weak language: show your drive to succeed, but use language such as "we will" instead of "we hope".
- Capture your reasoning: provide an explanation for choices and direction
Writing GDD
Traditionally GDDs were written as rigid Word documents, attempting to needlessly explain every detail of the game only to never be updated or read by anyone, and have since been made obsolete.
Game Designers today create GDDs as living documents that are updated throughout the project and have been adapted to support the creative, iterative, and collaborative process of game development
GDD Wikis
Many GDDs are writing using a wiki platform. A wiki is a collaborative tool that allows users to contribute and modify one or more pages of related materials. Wikis offer bite-size pieces of information; each Wiki page is a topic, and it can easily be linked to other topics, grouped into sections, and labeled for searching. In short, Wiki makes GDDs more accessible.
Triple AAA game companies often host their own server for the GDD wiki, and while that is not always an option for smaller independent game studios, there are free alternatives. One of the best options is to make use of the Project Wiki that is included in each GitHub Repository.
A GitHub repository can be taught as a single development project. Inside the repository, are all of the project files. GitHub is primarily used for version control and this is made possible by storing project files' revision history. At any point in the development collaborates can revert to previous versions of a project in the repository.