# [Game title]: Game Design Document

| | |
|---|---|
| **Version** | v0.1 |
| **Owner** | |
| **Last updated** | YYYY-MM-DD |
| **Status** | Concept / Pre-production / Production / Live |
| **TDD link** | |
| **Style guide link** | |

> **How to use this template.** Keep section 0 to one screen. Delete sections your game doesn't need. One owner per section. Date every diagram. Log every change in section 15. Italic text is guidance: replace it or delete it.

*Template by Innovecs Games. Free to use and adapt. Guide: innovecsgames.com/blog/game-design-document/*

## 0. One-page overview

*The page everyone reads. Keep it to one screen so a new team member or a publisher can take in the whole game in five minutes. Update it whenever a pillar, platform or scope decision changes.*

| Field | Fill in |
|---|---|
| **One-sentence pitch** | *e.g. A co-op salvage game where every storm rewrites the map.* |
| **Genre** |  |
| **Platforms** | *e.g. PC (Steam), PS5, Xbox Series X\|S* |
| **Target audience** | *Age range, session length, platform habits, genres they already play* |
| **Design pillars (3 to 5)** | *Experiences the game must deliver. A pillar should be able to kill a feature.* |
| **Comparable titles (2 to 3)** | *And what you take from each* |
| **Business model** | *Premium / free-to-play / subscription / hybrid* |
| **Current version and owner** | *v0.0, name, date* |

## 1. Game concept

*Write the fantasy, not the feature list. Mechanics can change completely and the concept should still hold.*

| Field | Fill in |
|---|---|
| **Player fantasy** | *What does the player get to be or do that they can't elsewhere?* |
| **Player goal** | *What are they trying to achieve, in one sentence?* |
| **Unique selling points** | *Three, each provable in a trailer or a demo* |
| **What this game is NOT** | *The ideas you've already decided against, so nobody re-proposes them* |

## 2. Core gameplay loop

*Draw it before you describe it. A diagram of the loop lands faster than three paragraphs.*

> [ Insert loop diagram here. Date it. ]

| Loop | Duration | Player actions | Reward |
|---|---|---|---|
| *Moment-to-moment* | *Seconds* |   |   |
| *Session* | *Minutes* |   |   |
| *Meta / progression* | *Days to weeks* |   |   |

## 3. Mechanics and systems

*One block per system. Duplicate the table below for each mechanic. Keep tuning values in one linked table, not scattered across pages.*

| Field | Fill in |
|---|---|
| **System name** |  |
| **Objective** | *What the player is trying to achieve and why it's worth doing* |
| **Rules and inputs** | *What the player can do, on which controls, with which limits* |
| **Feedback** | *Sound, animation, numbers, camera: how the game says it worked* |
| **Failure and recovery** | *What happens on a loss, what's kept, how the player gets back in* |
| **Tuning values** | *Link to the tuning table* |
| **Done criteria** | *What QA checks to accept this system* |
| **Engineering needs** | *One or two sentences, plus a link to the TDD page* |
| **Owner** |  |

## 4. Progression and economy

*Every currency needs sources and sinks. If a currency has no sink, it will inflate.*

| Currency | Sources | Sinks | Cap | Purchasable? |
|---|---|---|---|---|
|   |   |   |   |   |
|   |   |   |   |   |
|   |   |   |   |   |

| Field | Fill in |
|---|---|
| **Unlock order** | *What opens when, and why in that order* |
| **Difficulty curve** | *[ Insert curve chart ]* |

## 5. Feature priority and cut list

*Decide now what goes first if budget or schedule slips. Deciding in a crisis costs far more.*

| Feature | Priority | Rough cost | Cut order | Owner |
|---|---|---|---|---|
|   | *Must / Should / Nice* |   |   |   |
|   |   |   |   |   |
|   |   |   |   |   |
|   |   |   |   |   |

## 6. Characters and narrative

*Keep the story tied to play. Match the depth of this section to how much the story drives the game.*

| Character | Role | Wants | Arc | First appears |
|---|---|---|---|---|
|   | *Protagonist* |   |   |   |
|   | *Antagonist* |   |   |   |
|   |   |   |   |   |

| Story beat | What it unlocks | Level / region |
|---|---|---|
|   |   |   |
|   |   |   |
|   |   |   |

| Field | Fill in |
|---|---|
| **Dialogue approach** | *Full VO / barks / text only* |

## 7. Level and world design

*List every level or area with the one job it does for the player.*

| Level / area | Purpose | New mechanic introduced | Target length | Status |
|---|---|---|---|---|
|   |   |   |   |   |
|   |   |   |   |   |
|   |   |   |   |   |

> [ Pacing chart ]    [ One annotated sample level ]

## 8. Art and visual direction

*Show the style, don't just name it. "Stylized" means nothing until there's a mood board next to it.*

> [ Mood board ]

| Field | Fill in |
|---|---|
| **Color palette** |  |
| **Shape language** | *Characters, environments, props* |
| **UI style** |  |
| **Camera** |  |
| **This style is NOT** | *The looks you're ruling out* |
| **Style guide link** | *For internal artists and external vendors* |

## 9. Audio direction

*Sound is half of how a hit feels. Set a loudness target early to save a painful final mix.*

| Field | Fill in |
|---|---|
| **Music** | *Style, reference tracks, linear or adaptive* |
| **Sound effects priorities** | *Hits, pickups, UI: what must read over music* |
| **Voice** | *Rough line count, languages, full VO / barks / text* |
| **Middleware** | *FMOD / Wwise / engine-native; memory limits on mobile* |
| **Loudness target** | *e.g. ASWG-R001: -24 LUFS (±2) home consoles, -18 LUFS portable* |

## 10. UI/UX and controls

*Map every action on every input you ship. Features designed around one input scheme are the usual porting surprise.*

> [ Screen flow diagram ]

| Action | Gamepad | Keyboard and mouse | Touch |
|---|---|---|---|
|   |   |   |   |
|   |   |   |   |
|   |   |   |   |

| Field | Fill in |
|---|---|
| **HUD elements** |  |
| **Accessibility options** | *Remapping, subtitles, colorblind modes, difficulty* |

## 11. Technical summary

*Keep it short and link to the TDD. Agree performance budgets with the tech director before features are designed in detail.*

| Field | Fill in |
|---|---|
| **Engine** | *Unity / Unreal Engine / proprietary* |
| **Minimum device or spec** | *Name the actual device, e.g. a specific mid-range Android phone* |
| **Online requirements** |  |
| **Save system** |  |
| **Third-party services** | *Analytics, backend, anti-cheat* |
| **TDD link** |  |

| System | Frame time (ms) | Memory (MB) | Draw calls | Agreed with |
|---|---|---|---|---|
|   |   |   |   |   |
|   |   |   |   |   |
|   |   |   |   |   |

## 12. Monetization and LiveOps

*Write the never-for-sale list first. It's the shortest part of this section and the one players judge you by.*

| Field | Fill in |
|---|---|
| **Business model** |  |
| **Never for sale** |  |
| **Season / event plan** | *Cadence you can actually sustain* |

| Store item | Type | Price | Where it appears |
|---|---|---|---|
|   | *Cosmetic / convenience / pass* |   |   |
|   |   |   |   |

| Event one-pager field | Fill in per event |
|---|---|
| *Goal* |   |
| *Player segment* |   |
| *Rewards* |   |
| *Economy impact* |   |
| *Art and content needs* |   |
| *A/B test and result* |   |

## 13. Localization

*Plan text space and region changes before UI and art are final.*

| Field | Fill in |
|---|---|
| **Languages at launch** |  |
| **Languages later** |  |
| **Text expansion allowance in UI** | *e.g. +30% for German* |
| **Fonts and character sets** |  |
| **Region-specific content or art** |  |

## 14. Platforms and release

*Each platform adds its own input scheme, performance targets and certification work. Treat certification as scope.*

| Platform | Launch | Certification | Cross-play / progression |
|---|---|---|---|
|   |   | *Sony TRC / Xbox Requirements / Nintendo Lotcheck* |   |
|   |   |   |   |
|   |   |   |   |

| Milestone | Date | What 'done' means |
|---|---|---|
| *Vertical slice* |   |   |
| *Alpha* |   |   |
| *Beta* |   |   |
| *Launch* |   |   |

| Field | Fill in |
|---|---|
| **Marketing beats** | *Demo (e.g. Steam Next Fest), closed beta, store page date, trailer capture* |

## 15. Open questions and change log

*The two lists that keep a GDD honest. If the last change log entry is older than the last playtest, the document has stopped working.*

| Open question | Owner | Decide by | Status |
|---|---|---|---|
|   |   |   |   |
|   |   |   |   |
|   |   |   |   |

| Date | Section | Change | Why | Who |
|---|---|---|---|---|
|   |   |   |   |   |
|   |   |   |   |   |
|   |   |   |   |   |

## A. Appendix: partner brief

*One page per external partner: co-development, art vendor, porting or QA. Partners work from the same live pages as your team, with access limited to what they need.*

| Field | Fill in |
|---|---|
| **Partner and scope** | *Which features, levels or asset sets are theirs* |
| **Boundaries** | *Interfaces with your team's work they must respect* |
| **Sections they work from** | *Link each one* |
| **Done criteria per deliverable** | *Testable, e.g. "hit reactions play within two frames of impact"* |
| **Access level** |  |
| **Change approver** | *Who signs off changes that cross a partner boundary* |