This article was last updated on January 28, 2026

A game design document (GDD) is the source of truth for your game. It explains what you’re building and why. It also sets scope, rules, and guardrails.

GDDs matter most when you’re collaborating. But they also help solo developers stay consistent. A good game design doc lets you make faster decisions later.

What is a game design document (GDD)?

A game design document, often called a GDD, is a detailed internal document that describes a video game’s design. It captures the game’s vision, core loop, systems, and content. It also defines constraints like scope, pillars, and non-goals.

If you only remember one thing, remember this:

A GDD turns a game idea into an actionable plan the whole team can follow.

It’s important to remember that lots of people from many different disciplines may refer to a GDD — from artists and level designers, to engineers, composers and even the marketing team. So creating a document that’s easy for everyone to understand is really important.

Of course, not every game has a huge development team — some titles are created entirely by solo developers. But even a solo developer may find a GDD useful, as a later reference point for decisions they took early in the process, or in case they bring in a second developer to help share the work.

What is in a game design document?

GDDs can include any relevant material for the game. That includes text, concept art, videos, musical references, photos, and prototypes. There are no strict rules, so optimize for what your team will use.

It’s also important to add more than just details for the design and development teams. A GDD should include information about the intended audience, gameplay, characters, story, user interface, and more. Remember that anyone — from artists to marketers — may refer to this when working on the game. So giving them the context to do their work is essential.

Modern GDDs

In the early days of video games, GDDs would typically be huge physical documents, often hundreds of pages long and covered in scribbled notes from producers, developers and designers. As technology evolved, and bigger-budget games meant larger teams and agile work environments, video game design documents have become more flexible.

Today, most GDDs are living documents that change as you learn. They work best when they’re easy to search and easy to update.

We often say that the best documentation is findable and up to date. That’s also the best definition of a “modern GDD”.

GDD vs pitch deck vs technical design document (TDD)

People often mix these up — but they aren’t the same document. Here are key differences:

• Pitch deck/pitch doc: Sells the game’s concept — it’s short and visual.

• Game design document (GDD): Defines gameplay, systems, content, and rules.

• Technical design document (TDD): Explains implementation details and architecture.

You can start with a pitch doc, then expand it into a GDD. Your engineering team can then derive TDDs from those two documents.

When should you write a GDD?

The best time to start a lightweight GDD is in pre-production. But make sure you keep it small and directional — don’t let it get bloated with detail.

Then grow it as you prototype. If a decision affects multiple disciplines, capture it. If it only affects one feature, keep it in the feature doc.

How to write a game design document

There is no single, agreed-upon way to make a video game design document — because no two games are the same. Each GDD needs to serve the requirements of the game it represents, so there’s no single template that will fit the needs of every game.

That said, most good GDDs follow the same flow: start broad, then get specific.

1. Define the vision (in one paragraph)

Write the game’s elevator pitch, then add your “design pillars” and non-goals.

This is the opening section of your document and should explain what makes the game fun.

2. Describe the core gameplay loop

Explain the gameplay loop as a short list. For example: explore → fight → loot → upgrade → repeat.

Nailing this early will help you keep every later decision grounded in the player experience.

3. Document the systems (rules, numbers, constraints)

Capture mechanics, progression, economy, combat, AI, or anything “systemic”.

And make sure you add edge cases — designers and engineers will both need them.

4. Define content: levels, story beats, characters, items

Explain what you need to build — and be comprehensive and explicit about volume.

This is where scope creep starts, so write carefully.

5. Add UX and UI notes

Include wireframes, UI flows, HUD requirements, and accessibility.

This keeps UI from turning into a last-minute scramble.

6. Include production and go-to-market details (if you have them)

Add milestones, risks, target platforms, business model, and ratings goals.

This helps marketing and production plan early for your eventual launch. If you don’t have all the answers at the start, give some rough estimates and make sure you come back to update them as they evolve.

What should be in your GDD template?

While every project is different, you should consider including these things in your game design document:

• Your overall project goals

• Characters — ideally including concept art

• Story and game world — again, including concept art

• Level designsMechanics and gameplay

• User interface (UI)

• Music and audio

• Any working or playable prototypes

• Information about accessibility

• Details around marketing and commercialization

Copy/paste GDD template (outline)

Use this as a simple game design document template. It’s designed to be copy/paste friendly.

Video game design document examples

GDDs are internal documents, and are generally kept that way — closely guarded secrets of the development team. But over the years, some developers have released their documents for some big-name titles. Take a look at the real-world GDD examples below for inspiration in creating your own!

• Deus Ex design document – This annotated document came from the early days of development on the first Deus Ex title and shows the original scope of the game — including competitive multiplayer and a space station-based third act, neither of which made it to production.

• The original GTA design document – Before it was GTA, it was Race ‘n’ Chase. This GDD explains the concept of the top-down title, and details gameplay, the development team, timelines and more. It’s well worth a read.

• Grim Fandango design document – This cult classic title has an equally excellent design doc, featuring handwritten notes, concept art, flow charts, and some genuinely funny descriptions of characters and more.

• The Doom bible – This document from 1992 contains all kinds of interesting information about the original Doom, from characters and weapons to sounds. How do you know this was used in development? It has opening hours and phone numbers of local takeaway places at the back.

• BioShock pitch document – This isn’t technically a game design document, but pitch documents can often form the beginnings of a GDD, evolving into that once the game moves into production. You’ll find plenty of early details from the games initial concept, and some cool artwork.

• Diablo pitch document – Another pitch document, but this one is too cool not to include. It shows the initial ideas for Diablo, and details gameplay, timelines, and marketing ideas for the first title in this best-selling series.

GDD best practices

• Keep it clear and concise – Nobody wants to read three paragraphs when a single sentence would do the job — and in game design, people don’t have the time. Keep the information in your GDD detailed but concise.

• Make things easy to find – The most important thing is that people can find what they need in your document. Structure your content well, with clear sections and headings. A search function can help a lot, and AI-powered search can be even better.

• Collaborate across the team – It’s rare that a single person will know everything about a game. Ask the whole team to contribute to your document so you bring in expertise from different disciplines. It’ll make your GDD useful to everyone.

• Update your document constantly – A GDD is never really finished. It’ll evolve alongside your game during the development process, so it’s important you revisit and update it regularly to keep it up to date.

• Include useful images, videos and links – A good GDD contains plenty of reference materials. It might be concept art or pre-vis video, prototypes, or links to other related content. Remember: this is your go-to document for everything related to your game

• Track decisions and changes – Add a lightweight changelog. Link out to deeper docs when needed. This stops repeated debates.

• Write for scanning – Many readers will skim. Use short sections, lists, and clear headings.

Creating a game design document with GitBook

While many of the older GDDs above were printed and kept as hard copies, modern docs are typically hosted online using a dedicated knowledge-sharing platform, like GitBook. You can also use other online tools, such as Google Docs, to create documents and share them with the rest of the team, although permission controls and search options are more limited.

Here are a few of the benefits to using a tool like GitBook for your GDD:

Benefits of using GitBook for your GDD

1. Organization – With GitBook, you can create a dedicated space for your GDD, and that space can contain multiple pages and subpages, each dedicated to a specific topic. Plus, each page has a table of contents, so you can quickly find the page and section you need.

2. Smarter search – A powerful search tool makes it easy to jump to a specific section or topic. Plus with GitBook AI, you can simply ask a question about your content, such as “What’s the current deadline for the first build?” and GitBook will give you an answer in seconds.

3. Permissions – Collaboration is essential in a GDD, but not everyone needs edit permissions! With GitBook, you can choose who has view and edit rights for your content, so you can bring in the right people to add their expertise.

4. Authenticated access – Publish your GDD but keep access limited to just those in your team with authenticated access. Published docs benefit from the built-in AI Assistant, so anyone on your team can ask complex questions about the GDD and get instant answers.

5. Change requests – Keep track of edits in GitBook with change requests — which work a lot like GitHub’s pull requests. Plus, you get a full history of your document, so you can always roll back if something has gone wrong.

6. Add all kinds of content blocks – Whether you want to embed the latest UI designs from Figma or just throw in an image, video or link, GitBook’s block based editor makes it easy to add and edit content.

7. Public docs – Need public documentation for your game or game engine? With GitBook, you can publish a space to the web so your community can find what they need. Take a look at Ready Player Me and AnyRPG’s docs to see some great examples!

Game design document FAQ

How long should a game design document be?

As long as it needs to be to prevent confusion. Many teams start with a one-page GDD, then add detail as the game proves itself in prototypes.

Do indie games need a GDD?

Not always. But even a small game benefits from a lightweight game design doc. It keeps scope under control and protects “future you” from forgetting decisions.

What’s the difference between a game design document and a game bible?

Teams use “game bible” in different ways. In practice, it’s usually either a narrative bible (which includes lore, characters, tone) or a broader umbrella that includes the GDD as well as art and brand guidelines.

→ Sign up to GitBook for free

→ How to write great technical documentation

→ Learn more about creating internal documentation bases in GitBook