What is a game design document?

A game design document, or GDD, describes what a game is, how it plays and what must be built: the core loop, mechanics, progression, content, art direction, technology and the scope of the first release.

How long should a game design document be?

As short as possible while still being buildable. Many good GDDs are 10 to 30 pages plus a balance spreadsheet and diagrams, topped by a one-page summary. Small games need less.

What should a game design document include?

A one-page summary, the core loop, mechanics and controls, progression and economy, a content list, art and audio direction, UI flow, a technical plan, MVP scope with a cut list, milestones and risks.

Do I need a GDD before hiring a studio?

It helps a lot. A GDD with a content list and MVP scope lets a studio give an accurate fixed price. If you only have an idea, a good studio can help you turn it into a document first.

Can AI write a game design document?

AI can turn notes into a first draft and point out missing sections, but the design decisions, numbers and scope cuts must come from the people making the game.

How to Write a Game Design Document (2026 Template)

The short answer

A game design document (GDD) explains what the game is, how it plays and what has to be built, clearly enough that a team can build it and a studio can give you a fixed price. In 2026 the best GDDs are short and living: a one-page summary on top, then focused sections on the core loop, mechanics, progression, content, art direction, technology and, most importantly, what the first version will and will not include.

Start with a one-page summary

If someone reads only one page, it should tell them:

The pitch in one or two sentences.
Genre and platforms: for example, a casual puzzle game for iOS and Android, later Steam.
Audience: who plays it, how often, for how long.
The hook: the one thing that makes it different.
Comparable games: two or three titles players would recognise, and how yours differs.
Business model: premium, ads, in-app purchases or a mix. Our ads vs in-app purchases guide helps here.

The sections that matter

Core loop

What the player does every 30 seconds, every session and every week. Draw it as a cycle: play a level, earn coins, upgrade, unlock harder levels. If you cannot draw the loop, the design is not ready.

Mechanics and controls

Each mechanic with its rules, and how it is controlled on every platform: touch, mouse and keyboard, controller. Include edge cases: what happens when the player does something unexpected.

Progression and economy

How difficulty rises, what players unlock and when, which currencies exist, how they are earned and spent. Put the numbers in a spreadsheet and link it; prose hides balance problems.

Content list

Every level, character, item, enemy, map and mode in the first release, as a countable list. This is what turns a description into an estimate.

Art and audio direction

Mood boards, reference images and a few words on style, camera and colour. Note the technical constraints: the art style must run on your weakest target device.

UI and screen flow

A diagram of every screen from launch to gameplay to store to settings, with rough wireframes for the important ones.

Technical plan

Engine, platforms, online features (accounts, multiplayer, leaderboards), backend, analytics, ads and purchase providers, and any third-party services. For a Unity project, note the render pipeline; new projects should start on URP, as our Unity 6 upgrade guide explains.

MVP scope and cut list

The most valuable page in the document. Write what the first playable release includes, and just as clearly, what it does not. "Multiplayer: not in MVP" saves more money than any other sentence you will write.

Milestones and risks

The order of work, from prototype to launch, and the three or four things most likely to go wrong, with a plan for each.

A copyable outline

One-page summary: pitch, genre, platforms, audience, hook, comparable games, business model
Core loop diagram (moment, session, long term)
Mechanics and rules, with controls per platform
Progression, difficulty and economy (link the balance spreadsheet)
Content list for the first release
Art direction: references, style, camera, technical limits
Audio direction
UI flow diagram and key wireframes
Technical plan: engine, platforms, backend, analytics, monetisation providers
MVP scope and explicit cut list
Milestones
Risks and mitigations
Open questions and decisions log

Mistakes that make GDDs useless

Writing a novel. Long lore and no rules. Keep story to what affects gameplay.
Wishes instead of decisions. "Maybe multiplayer later" is not a decision. Decide, or put it in open questions.
No numbers. "Upgrades get more expensive" cannot be built or tested. Give the curve.
Freezing it. A GDD that is never updated after the prototype becomes fiction. Keep a decisions log.
Skipping the cut list. Every feature looks essential until you price it.

Tools

Any shared document tool works. Most teams use a document for the text, a spreadsheet for the numbers and a whiteboard tool for loops and screen flow. AI assistants are useful for turning notes into a first draft and spotting gaps, but the design decisions have to be yours; our look at AI game generators explains where AI helps.

From document to quote

A GDD with a content list and an MVP cut list is exactly what a studio needs to give you an accurate fixed price instead of a guess. Send yours to us and you'll get a detailed scope, milestone plan and fixed price within 48 hours. If you only have an idea, we can help turn it into a document first; read our guide to choosing a game development studio before you send it anywhere.

How to write a game design document