New in GitBook: Revamped Documentation

New in GitBook: Revamped Documentation

How to write a game design document — with examples and template

How to write a game design document — with examples and template

Tutorials & tips

Tutorials & tips

Tutorials & tips

Author

Author

Author

A graphic showing levellines and dots on a black and yellow gradient background
A graphic showing levellines and dots on a black and yellow gradient background
A graphic showing levellines and dots on a black and yellow gradient background

​​A game design document is a crucial part of game development — especially when you have lots of people working on different aspects of a game. Making sure everyone understands the bigger picture is key to success, and a good game design document will explain this clearly, with important details that help team members and other stakeholders get up to speed on development fast.

What is a game design document (GDD)?

A game design document, often referred to as a GDD, is a detailed internal document that covers a number of aspects of a video game’s design and development. The primary goal is to explain the core vision of the project, as well as setting the scope and laying out guidelines that the team can refer back to throughout development.

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 contain any kind of relevant material for the game — including text, concept art, videos, musical references, photos, and even working prototypes or demos. There’s no rules about what you can or can’t include, so focus on things that will be useful and relevant to people throughout the development process.

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, GDDs are agile, living documents. We often say that the best documentation is that which is findable and up to date, and this is certainly true for GDDs. It’s really important to organize your docs, and regularly update them so everyone can find what they need.

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, there are a few recommendations that most game designers would include when creating a GDD template.

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

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

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. 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.

  5. 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.

  6. 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!

→ Sign up to GitBook for free

→ How to write great technical documentation

→ Discover why change requests are so powerful in GitBook

​​A game design document is a crucial part of game development — especially when you have lots of people working on different aspects of a game. Making sure everyone understands the bigger picture is key to success, and a good game design document will explain this clearly, with important details that help team members and other stakeholders get up to speed on development fast.

What is a game design document (GDD)?

A game design document, often referred to as a GDD, is a detailed internal document that covers a number of aspects of a video game’s design and development. The primary goal is to explain the core vision of the project, as well as setting the scope and laying out guidelines that the team can refer back to throughout development.

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 contain any kind of relevant material for the game — including text, concept art, videos, musical references, photos, and even working prototypes or demos. There’s no rules about what you can or can’t include, so focus on things that will be useful and relevant to people throughout the development process.

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, GDDs are agile, living documents. We often say that the best documentation is that which is findable and up to date, and this is certainly true for GDDs. It’s really important to organize your docs, and regularly update them so everyone can find what they need.

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, there are a few recommendations that most game designers would include when creating a GDD template.

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

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

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. 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.

  5. 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.

  6. 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!

→ Sign up to GitBook for free

→ How to write great technical documentation

→ Discover why change requests are so powerful in GitBook

​​A game design document is a crucial part of game development — especially when you have lots of people working on different aspects of a game. Making sure everyone understands the bigger picture is key to success, and a good game design document will explain this clearly, with important details that help team members and other stakeholders get up to speed on development fast.

What is a game design document (GDD)?

A game design document, often referred to as a GDD, is a detailed internal document that covers a number of aspects of a video game’s design and development. The primary goal is to explain the core vision of the project, as well as setting the scope and laying out guidelines that the team can refer back to throughout development.

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 contain any kind of relevant material for the game — including text, concept art, videos, musical references, photos, and even working prototypes or demos. There’s no rules about what you can or can’t include, so focus on things that will be useful and relevant to people throughout the development process.

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, GDDs are agile, living documents. We often say that the best documentation is that which is findable and up to date, and this is certainly true for GDDs. It’s really important to organize your docs, and regularly update them so everyone can find what they need.

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, there are a few recommendations that most game designers would include when creating a GDD template.

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

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

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. 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.

  5. 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.

  6. 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!

→ Sign up to GitBook for free

→ How to write great technical documentation

→ Discover why change requests are so powerful in GitBook

Get the GitBook newsletter

Get the latest product news, useful resources and more in your inbox. 130k+ people read it every month.

Email

Similar posts

Get started for free

Play around with GitBook and set up your docs for free. Add your team and pay when you’re ready.

Get started for free

Play around with GitBook and set up your docs for free. Add your team and pay when you’re ready.

New in GitBook: Revamped Documentation

New in GitBook: Revamped Documentation