Summary
Game development produces a range of documents at different stages for different audiences. Documentation is not bureaucracy. It has concrete purposes: crystallising ideas, aligning teams, communicating vision to stakeholders and recording decisions so they can be revisited. A long, detailed, undirected GDD that nobody reads is worse than no document at all. It gives a false sense that the design is settled while obscuring what matters.
Purpose of documentation
Every game document should be written with its specific purpose clear:
| Purpose | Questions to answer before writing |
|---|---|
| Working out the idea | What do we not yet know? What needs to be resolved before we can build? |
| Pitching the concept | Who is reading this? What decision do they need to make? What must excite them? |
| Explaining to the team | Who are the main points of contact? What level of detail do they need? How will this be kept up to date? |
Warning signs of bad documentation:
- Too long: nobody reads it, so key information is buried.
- Undirected: no clear audience or purpose.
- Out of date: the game has changed, so the document now misleads the team.
Pre-production documents
These are created before or during the earliest stages of development to establish vision and direction.
The Blue Sky phase
Before any document exists, there is an ideation phase. Kristjan (We Deserve Better Villains) calls this Blue Sky, the period when “nothing is off the table” and ideas are born without constraints:
“Look up at the sky on a beautiful day and realise that it’s limitless in scope, just like your imagination should be for any game.” — Kristjan, Ch. 2
Blue Sky (also called the concept phase or high concept phase) exists to produce the elevator pitch. This is the game idea compressed into a sentence or paragraph that sells the soul of the game to anyone who hears it. The elevator pitch is a core professional skill for game designers:
“Any designer should be able to present the soul of the game in a phrase, sentence, or paragraph in the time it takes to travel to a destination in an elevator… The greatest designer in the room is the person who can tell a story better than anyone else in that room.” — Kristjan, Ch. 2
A good elevator pitch:
- States specifically what is spectacular about the product
- Is concise enough to let the listener fill in their own mental picture
- Provokes the response “I want to play that game”
- Survives being pitched to a complete stranger who knows nothing about games
The HCD and pitch document are the written artefacts that follow from a successful Blue Sky phase.
(Kristjan, We Deserve Better Villains, see source-we-deserve-better-villains)
High Concept Document (HCD)
One page or less. The elevator pitch in written form.
- What the game is in 2–3 sentences
- What makes it unique (the Unique Selling Points / USPs)
- Target platform and audience
- The “hook”: why would a player want this?
Use when: Starting a new project or circulating the idea internally before committing resources.
Pitch Document
2–10 pages. Written for an external audience.
- Expands on the HCD: genre, gameplay pillars, art direction, comparable titles
- Target market and commercial case
- Team overview and relevant experience
- Development timeline and budget estimate
Use when: Presenting to publishers, investors, or funding bodies.
Pitch Presentation
Slides version of the pitch document. Typically 10–15 slides.
- Visual-first format where images and diagrams carry the argument
- Designed to be read in a meeting, not in detail after the fact
Use when: Live presentations to stakeholders or trade show pitches.
Pillar Posters
One poster per game pillar (core design principle).
- Concise visual statements of the game’s foundational goals (e.g. “Exploration is Always Rewarded”, “Every Fight Has Multiple Solutions”)
- Hung in the studio space as persistent design touchstones
- Helps teams make consistent decisions without consulting a document
Use when: Establishing shared design language or onboarding new team members.
Mood Board
Visual reference collection establishing art direction and tone.
- Images, colour palettes, textures, film references, concept art
- Communicated visually rather than described in words
- Establishes the emotional register the game should inhabit
Use when: Starting art direction, briefing external artists or communicating tone to non-artistic stakeholders.
Design documents
Game Design Document (GDD)
The central living design reference for the development team.
A modern GDD is not a complete specification written before development begins. The Agile approach (see agile-design) treats the GDD as a living document updated continuously as design decisions are made, tested, and revised. Attempting to specify everything upfront produces a document that is outdated before development starts.
What a GDD typically contains:
- Game overview and vision statement
- Core mechanics and systems descriptions
- Level design structure and goals
- Character and enemy design
- Interface and UX guidelines
- Economy and progression systems
- Win/loss conditions and difficulty model
Who it serves: The entire development team. Programmers, designers, level designers and QA testers all reference it.
GDD pitfall: A GDD written once and never updated becomes a liability. Design decisions made in-engine that contradict the GDD will confuse new team members who read the document and then encounter the actual game.
Feature/Scene Map
Visual diagram showing all features or scenes and how they connect.
- Useful for understanding dependencies and scope at a glance
- Can highlight gaps (features promised but not yet designed) and bloat (features that don’t serve core pillars)
Feature Specification Document
Detailed description of a single feature or system.
- Who owns this feature, what it does, how it connects to other systems and what acceptance criteria apply
- Useful for complex systems (economy, AI, dialogue) that need more detail than the GDD can hold
Art and audio documents
Art Reference Board
Visual compilation of specific art references for individual assets or areas.
- More focused than a mood board and may include annotated notes
- Used by artists when creating specific assets
Art Bible
Comprehensive visual style guide for the entire game.
- Character design rules, environment design language, colour palette constraints and UI style guidelines
- Ensures visual consistency across a large team
- New artists or external contractors consult the art bible to match the established style
Story Bible
The master reference for all narrative content.
- World history, lore, and backstory
- Character backstories, motivations, and relationships
- Tone and dialogue guidelines (how do characters speak? what vocabulary is used or avoided?)
- Timeline of events within the game’s fiction
Use when: Any game with significant narrative content, especially when multiple writers are contributing.
Storyboard / Flipbook
Sequential visual script for cutscenes or key narrative moments.
- Drawn panel-by-panel to communicate camera angles, character positions and action
- Used by animators and cinematic directors
Post-production and handoff
Technical Design Document
Specifies the technical implementation of game systems.
- Written by or with programmers
- Covers data structures, system architecture, API design, and technical constraints
- Bridges the design intent (GDD) with the implementation reality
Content Document
Tracks all game content: levels, items, NPCs, dialogue lines, audio assets, etc.
- Used by production to track completeness and ownership
- Often implemented as a spreadsheet or project management system entry
Hotlist / Feature Priorities List
Ordered list of features by priority.
- What must be in the game (must-haves)
- What should be in if time allows (should-haves)
- What would be nice but is cut if necessary (could-haves)
- Connects to the product backlog in agile workflows
Post-Project Overview Document
Written after ship. Captures what went well, what went wrong and what to do differently.
- The game development equivalent of a retrospective (see sprints)
- Invaluable for team development and future project planning
Documentation in context
Documentation exists within a larger production pipeline. See the game design pipeline (from CRE133 Wk8):
Pre-production → Production → Post-production
Roles involved:
Producers | Game Designers | Level Designers | Programmers (AI/Gameplay/Engine/Tools/Network/3D)
Technical Artists | Concept Artists | 3D Artists | 3D Animators | VFX Artists | Sound Designers
Narrative Designers | UI Artists | Game Testers
Different documents are the primary responsibility of different roles. Game designers own the GDD, the art director owns the Art Bible and lead programmers own the Technical Design Doc. The whole team still needs visibility.
In the expanded wiki pipeline, these documents now connect directly to preproduction-and-concept-validation (for hook, audience, and risk framing), vertical-slice (for proving the pitch in playable form), publishing-and-funding (for external-facing pitch and milestone context), and legal-and-business-basics (for ownership, credit, and obligation questions that documents often imply but do not themselves resolve).
Pitch artefact exercise
Use this exercise when a team has one game concept and needs to choose the right document for the right reader.
Scenario:
You are making a two-hour cosy puzzle game about repairing abandoned machines in a floating town. The playable prototype contains one repair puzzle, one character interaction, placeholder art and no save system. You need to communicate the project to four different audiences:
| Audience | Best artefact | What it should prove |
|---|---|---|
| Student team joining next week | High Concept Document | The core fantasy, hook, target platform and why the concept is worth building |
| Internal production meeting | Game Design Document extract | The current loop, known design decisions, unresolved questions and feature priorities |
| Publisher or grant body | Pitch document | Audience, comparable titles, production plan, budget, risks and evidence that the team can execute |
| Live assessment panel | Pitch presentation | The argument in visual form, supported by prototype footage and clear next steps |
The common mistake is to reuse the same document everywhere. A GDD can be too detailed for a funder. A pitch deck can be too thin for a programmer. A High Concept Document can align a team, but it cannot replace a budget, milestone plan or Business Model Canvas.
Practice
Take your current project and write four one-sentence document goals:
- HCD goal: what should a new reader understand in one minute?
- GDD goal: what should a teammate be able to build or test after reading?
- Pitch document goal: what decision should an external supporter be able to make?
- Pitch deck goal: what should an audience remember after the room has moved on?
Then choose one missing piece of evidence for each artefact. Examples include a comparable title, a prototype clip, a budget line, a player-test quote or a risk table.
Answers
- A good HCD goal names the game, player fantasy, platform, audience and hook without explaining every system.
- A good GDD goal helps the team make the same design decision twice. It should reduce ambiguity during production.
- A good pitch document goal supports a funding, signing or approval decision. It must include evidence about audience, feasibility and risk.
- A good pitch deck goal makes the project memorable and discussable. It should not ask slides to carry detail that belongs in the written document.
- If the same sentence works for all four artefacts, the team has probably written a slogan rather than a document goal.
(Della Rocca and McAloon, Four Tips for Pitching Your Game, see source-game-pitching-to-publishers. Osterwalder and Pigneur, Business Model Canvas, see source-business-model-canvas)
Three levels of complexity (Good/Bad/Ugly)
A practical framework for writing designs that can survive scope changes. Kristjan’s approach: every design feature should be specified in three tiers of implementation, not one.
| Tier | Description | Use |
|---|---|---|
| Good | The full, best-case implementation with everything you want | The design target |
| Bad | Stripped-down core version with the essential intent intact | The fallback if time or resources constrain |
| Ugly | Bare-bones minimum, enough to avoid harming the game | The absolute floor. Cut no further |
Why it matters: Production schedules change. Features get cut. When a feature must be cut or reduced, a three-tiered design already has its fallback positions defined. The designer does not need to redesign under pressure, and every group can estimate time for each tier in advance.
Bonus: When schedules extend or production has spare time, higher-tier versions of existing designs can be pulled from the pre-written design and implemented without additional design work.
“Adding this philosophy to your design allows for a lot of leeway down the line in the production of the game.” — Kristjan, Ch. 3
This connects to the product-backlog concept of prioritisation: the Good tier is the full feature, the Bad tier is the MVP version, and the Ugly tier is the minimum that clears the Definition of Done. Having all three written in advance is the design equivalent of a sprint buffer.
(Kristjan, We Deserve Better Villains, see source-we-deserve-better-villains)
Related
- agile-design: agile development’s attitude to documentation: prefer playable games over documents
- overview-full-game-development-pipeline: where these artefacts sit from concept through launch and post-launch
- preproduction-and-concept-validation: the hook, audience, comparable-title and risk work that happens before full production
- product-backlog: the agile alternative to a fixed feature list
- prototyping: prototypes often generate the understanding that feeds back into documentation
- vertical-slice: the vertical slice is the playable validation of what the documentation promises
- minimum-viable-game: scope management: what must be in the documentation at launch
- publishing-and-funding: pitch materials, milestone logic and external commercial audiences
- investment-pitches-for-games: how pitch artefacts change for publishers, investors, grants and crowdfunding
- business-model-canvas-for-games: compact business model thinking before pitch documents
- legal-and-business-basics: ownership, crediting and public obligations that sit behind production documents
- sprints: sprint planning uses documentation artifacts (feature specs, backlogs)
- source-cre133-lectures
- source-we-deserve-better-villains