How to write a game design document (with examples)

When you’re making your game there’s a good chance that, at some point, you’re going to need to write down how it works.

This might be because you’ve got plans and ideas for your project that you don’t want to forget.

Or it might be because other people are going to work on your game with you, and you need a way to show them what the game should or should not be like.

Or maybe you need to pitch your project in some way, to a publisher, as a part of a crowdfunding campaign, or as an early access project, and you need a way to show others what the game is going to be like when it’s finished.

So how can you do that?

One solution is to write a Game Design Document, which is typically a detailed guide that describes what your game is and how it will work.

However, while the general idea of a game design document is fairly straightforward, actually writing one can be tricky and time-consuming.

How long should a game design document be?

What should you put in it?

And does anyone even read them anyway?

Whether you even need a game design document or not can be a surprisingly divisive issue.

Some people love them, while others insist that they are obsolete and have been for some time.

However, while long written documents, that describe every detail of your game, may be considered old-fashioned, at some point, you are going need to communicate your game’s details and ideas to another person.

To a publisher or an investor,

To developers or artists working on your game,

Or even just to your future self, so that you can keep track of what it is you’re making.

So, what’s the best way to make a game design document?

Should it be one page long, or 100 pages?

And is a game design document the right option for you?

In this article, you’ll learn what a game design document is, what it can be used for and how you can write one of your own, so that you can decide if a game design document, or something like it, is the right design tool for your project.

Here’s what you’ll learn on this page:

• What is a game design document?
• How to write a game design document
• Game design document formats
• How to make a one-page game design document

Let’s get started.

What is a game design document?

A Game Design Document, or GDD for short, is typically a detailed guide that can be used to keep track of the core themes, styles, features, mechanics and ideas of your game project.

The main purpose of a game design document is to communicate the details of your project to either yourself, as you work on your game over time, or to other people, such as team members, publishers, stakeholders or people who will be playing your game, as part of a crowdfunding campaign or early access product.

Put simply, it’s the tool that you’ll use to manage and develop the concept of what your game is, how it’s supposed to work and how it will be built.

Meaning that it can be an extremely important part of your game’s development.

However, there’s no set standard for what a game design document should be, what it should look like or what it should actually do.

So why should you even use one?

Should you use a game design document?

Generally speaking, the decision to use a game design document or not depends on how you like to work.

However, if your project is large, complex or involves multiple people, then you should probably consider some kind of design document that can help you to communicate core ideas and information to other people involved with your game.

Even if it’s just you, a GDD can act as a place where the main concepts, ideas, features and the specific mechanics of your project are written out in detail.

Which can be extremely useful, as the process of writing down and describing part of your game can force you to decide exactly how it’s going to work. 

Put simply, the process of documenting your design can be an important part of the design process itself.

But, how do you write one?

How to write a game design document

So, how do you write a game design document?

How do you decide what should be in it?

And what type of format or structure should you use?

How to decide what should be in your game design document

When you write your game design document, it can help to think about why you actually need one in the first place.

Otherwise, it can be extremely difficult to know what should be in it, how detailed it should be or what it should even look like.

For example, do you want a simple overview page that you can use to keep track of your game’s high-level concepts, or do you want a marketing focussed summary that you can give to publishers or investors?

Do you want to be able to keep track of your game’s story, lore or items?

Or do you want to be able to show a developer exactly how a feature works or what a level should look like?

Your design document might do one of these things or it might do all of them but, what’s important is that you understand what information your design document is supposed to provide and who it’s going to provide it to.

Knowing that will help you to decide what needs to be included.

For example, a basic one-page game design document can help you to keep track of high-level concepts and the broad details of your game.

For example…

What to include in a basic game design document

An example structure of a basic game design document might include the core concept of the game, which is typically a high-level description of what the player will do, and the game’s design pillars, which are the design goals that every other decision you make about the game will be compared against.

It might also include a couple of the game’s main mechanics or controls, so that someone could easily understand what the game is going to be like to play. 

You might add any early ideas you have for the game’s visual style, what it might sound like, or what kind of music might end up being used.

Or, if the narrative of the game is important, this is where you might outline the basic story.

Or, you could add a rough timeline with some milestones that you’re hoping to hit during development.

A basic game design document might include:

• Core concept
• Design pillars
• Main features & mechanics
• Target platform & target audience
• Interface & controls
• Basic story
• Visual style
• Music & sound
• Similar games & genres
• Development timeline & major milestones

Which might look something like this:

The point of a basic game design document like this is that it’s simple and easy to use. As a result, you would typically try to keep it to a single page.

To do that, you may not be able to include all of the above points.

Instead, it can help to focus on the most important elements of the game that you want to get across without worrying too much about the detail.

The idea is that a basic one-sheet game design document can be used to quickly communicate what your game is about in a concise way, and it’s typically what you’d give to anyone involved in the early stages of your project.

However, while providing a general idea about what the game will be like is, usually, always useful, if your design document has a more specific purpose, such as for marketing or as a part of a project pitch, then you may need to also include marketing-specific information in your GDD.

Marketing & pitch document example structure

A game design document that’s marketing focussed might include information that a potential investor or publisher might want to know before considering your project for investment.

Exactly how you secure an agreement with a publisher is beyond the scope of this article and I’m not going to pretend that it’s as simple as only writing a marketing focussed game design document.

However, while the process of building a relationship with a publisher or with an investor may take more than a simple pitch document, you can still use your GDD to present the information that someone who’s funding your game may want to know.

• MCV – What publishers want from developers

Typically, someone who’s willing to consider funding part of your game’s development will probably want to be able to understand how much of a risk investing in that project will be.

As a result, you may want to use your GDD to explain who the product will be for, how it will make money, how well other games you’ve made have done and importantly, what level of social interest this project is already getting.

A project that already has a degree of interest from potential customers is likely to be a more attractive proposition than an untested concept and your GDD can be used to show that.

For example, you could include:

• Target platform & target audience
• Monetisation & price point
• Social engagement & wishlist adds
• Competition and how the game will compare
• Unique selling points
• New experiences & technologies
• Previous games and their performance
• Cost breakdown, salaries, assets, tools etc. (what will the game cost to make)
• Future opportunities for the game
• Market analysis

In this scenario, it can help to think of your GDD as more of a project pitch or business proposal, as that’s pretty much what it’d be. For that reason, it’s generally a good idea to focus on what you know you can deliver, based on your experience, your skills and what you’ve managed to do in the past.

However, while the details of your game’s production are going to be important in a business-focussed proposal, if you’re trying to communicate something much less tangible, such as the feel of a game, what it looks like and sounds like, using your GDD as a style guide can help you to do that as well.

Design & style focussed design document example

You might choose to use your game design document as the place to refine and share the story and the style of your game.

For example, if you need to keep track of the game’s narrative, keeping a reference to your game’s characters and how the story will unfold can be useful as you develop it.

Or, if your game has multiple endings or paths that the player can follow, having a place to keep track of them can help to avoid confusion later.

Or maybe you want to use the GDD as a kind of concept document, where the general style and feel of each level is set out, but isn’t specifically described.

A style-focussed game design document might include:

• Characters
• Story
• Lore
• World & areas
• Graphics & visuals
• Audio & music
• Sound effects
• Dialogue

Or, for a more practical approach, your design document might explain exactly how each of the systems, mechanics and features of your game are supposed to work.

Game mechanics & feature design document example

Writing down the details of how something is supposed to work can be extremely useful, as it gets the idea out of your head and forces you to describe exactly how it’s supposed to function.

Which, when you’re working with other people, and you want them to build part of your game in the way you imagined it would be, can be important.

Typically, a game design document that is this detailed would act as a point of reference for how everything works in the game, what each level should look like and which controls the player will use to actually play it.

A mechanics-focussed GDD might include:

• The core gameplay loop
• Controls
• The player
• Enemies
• Weapons
• Items
• Systems
• AI
• Controls
• UI & HUD

A large game design document might include all of the above.

Which can be useful, as it allows you to keep every detail of your game in a single location.

However, it’s up to you to decide how long your game design document should be.

How long should a game design document be?

A long, in-depth design document can be useful.

If you’re working on a detailed project and you need a place to keep track of all of your ideas for new mechanics items and features then writing them down in a single document seems like a good idea and, if it’s how you like to work, then go for it.

However, this approach can also work against you.

Trying to get started with such a detailed overview of your project is, in most cases, going to be extremely difficult.

Untested ideas, unless you really know that they’re going to work in the way that you expect, will often change as soon as you start to build them or as soon as people try them for the first time.

Which means that writing a long and overly-specific document upfront, before testing and validating your ideas, can be difficult, restrictive or, at the very least, a waste of time, as much of what you write now may end up changing later.

Instead, it can sometimes be better to use different length design documents at different stages of your project.

For example, in the early stages of your project, you probably won’t know exactly how each mechanic is going to work or what everything will look like or what the name of the level 2 shopkeeper’s dog will be.

And that’s fine…

However, you will probably have a working title, you’ll know what the gameplay or the story might involve and you’ll know what your design pillars, the cornerstones of how your game feels to play, will be.

For that reason it can often help to start with a simple one-page document and build on it as your project grows:

1. Start with a one-page design document that focuses on high-level concepts
2. Next, write a ten-page design document as the game starts to take shape, that includes core mechanics & story beats
3. Lastly, write a full game design document that includes all of the game’s content & detail

Staging your design document to match the phases of your game’s development can make writing your GDD more efficient.

However, even when it’s split up like this, a long written document can be difficult to organise, difficult to manage and difficult to use.

Which is why the format of your design document can make a huge difference to how helpful it is.

When thinking of a game design document, you might picture a giant 100-page word file, neatly organised into sections with links to chapters on marketing, mechanics, characters and the game’s story.

And there are many games that were designed exactly in that way.

However, there are more ways than one to manage the design of your game, and you may find that some methods work better for you and your project than others.

Game design document formats

There are many different ways to design something and one method isn’t necessarily better than another.

However, a design document will usually have a specific purpose, such as to communicate information, to explain how something is supposed to work or to act as a design tool itself, where an idea is developed at the time it’s written down.

In which case, the best format for your design document will depend on what you’re doing with it.

So what are your options?

Written game design documents

When you picture a game design document, you might imagine a written file, such as a word document or a Google doc, that sets out all of your game’s design details in one, or more, pages.

And while large written design guides have, reportedly, fallen out of fashion in recent years, there’s a lot to be said for having all of your game’s information organised and stored in a single place.

However…

While writing down your game’s design can be useful, a written document can only really be understood in one way, word after word, chapter after chapter.

If your design document is small, this might not be a problem for you,

But, if your GDD includes multiple sections and information, organising it in a single file can be tricky and, even with linked section headings, can be difficult to navigate.

As a result, if you need to manage a large amount of content that’s split across many different subjects, such as item descriptions, enemy stats, weapon profiles or level maps, for example, it can sometimes make sense to use a design wiki instead.

Using a game design wiki

A wiki is an online database of information that can be managed and edited by multiple users.

Compared to a written design document, a wiki is useful in that it’s easy to access, easy to update and provides information in smaller, bite-sized chunks.

Which can be helpful if you want to build a database of information about items, weapons, pickups and locations in your game.

However, while a design wiki can be useful for managing a large database of information, separating data into categories and entries can hide the relationships between the different parts of your game.

In the same way that reading a dictionary is different to learning a language, separating the different parts of your game’s design can make it difficult to understand how it’s supposed to work as a whole.

Which is why, while written guides and wiki databases can be useful for documenting data, they’re not always the best option for explaining an idea.

And while you might assume that all you need to do to communicate the design of your game is to write it all down in one place, the reality is that most people, yourself included, probably won’t read it.

So what’s the answer?

Instead of thinking of your design document as a database, it can be better to think of it as a communication tool.

A way for you to translate the ideas you have about your game for someone else in the best way possible.

The one-page game design document

The one-page design document approach is a method of creating engaging design documents by focussing on how well they communicate a particular idea.

This particular method was described by Stone Librande in his one-page design GDC talk and typically involves using illustrations, charts or maps along with callout information to describe how a feature, a mechanic or a level of your game is going to actually work in a visual way, and limited to a single page.

As a result, the one-page method can be significantly more effective at working through ideas than a written text document or wiki.

For example, imagine trying to describe to a builder what you want your house to be like using a word document.

Even if your description of where every wall window and door should go was perfectly described and incredibly detailed, it still wouldn’t be as effective as a blueprint drawing, which shows the builder where everything should go, to scale, along with all of the more detailed pieces of information that they might need in callouts and information boxes.

A blueprint works because it’s easy to understand, easy to modify and troubleshoot and is the most appropriate method of communication for that type of information.

The one-page design methodology explained

At this point, you might be thinking that the one-page approach simply involves using images and diagrams to communicate ideas because they usually work better than written text.

And while that’s true, it’s not the whole story.

While the one-page method does encourage you to present information in the most appropriate way, this is often a beneficial side effect of limiting your design to a single page.

Why only one page?

Using only a single page to communicate your design can work well for a few reasons.

1. One page is often as much as anyone is willing to read of your design (yourself included)
2. It forces you to think of the most effective way to explain what you mean, without relying on other pages or resources
3. It keeps your design concise, saving you time upfront

As a result, using one-page designs can help you to communicate your ideas more easily, in a better way and, when you do, people are much more likely to actually read them.

Even if you’re working on your game on your own, the one-page approach can be an extremely useful design tool.

This is because trying to teach someone else how your design works, even if it’s just you that will read it, can often be the fastest way to find out what’s not going to work, what’s missing and what doesn’t make sense.

So while one-page documents are helpful because of their often visual focus, their one-page limit generally encourages a more useful and more efficient design process as well.

So how do you make a one-page game design document and what should go in it?

How to make a one-page game design document

Generally speaking, there are two steps to making a one-page game design document.

1. Decide what the document is supposed to do
2. Choose the most effective format to explain the design

First, decide what your one-page design document is supposed to do

One of the most important parts of writing any kind of design document is making a decision about what its purpose is.

If you don’t know know what your design document is supposed to explain, it can be extremely difficult to make anything that’s actually useful.

So, to give your design document an objective, decide what it’s for and give it a descriptive title before you do anything else.

While this may sound simple, it can be surprisingly tricky.

For example, let’s say that you want to understand how the combat system is going to work in your game.

What do I mean by that?

Do I mean how much damage a particular move will do, or do I mean the different controls that a player might input to perform them?

Do I mean how a player’s attacks might compare to enemy attacks or do I mean the balance of weapons in the game?

Or would it actually be better if I included all of those things on one page?

Deciding exactly what it is you’re trying to design can be difficult however, to make it a little easier, try to think specifically about the problem you’re trying to solve.

It can be a specific problem or it can be a broad problem, but try to make it one thing, not several, by giving it a primary focus.

For example, if you’re trying to balance the stats of different weapons in your game then designing them all on one “weapon balance” page makes a lot of sense, as you’ll be able to see how they compare at a glance.

However, if you’re trying to choose what kinds of attacks should be available to the player and how they will trigger them then a “Combat controls” page could work for that.

Or, if you make your page bigger, there’s no reason you can’t combine multiple elements into a single design, so long as the design document still solves a single problem and has a primary focus.

One-page designs work well because, just like the builder’s blueprint, they allow you to communicate an entire idea on a single page.

However, it may not be possible to design your entire game on one page.

Instead, chances are the different parts of your design, such as the problems you want to solve, the high-level concepts that will run throughout your project or the ideas and information you want to be able to explain to other people, will be delivered using multiple one-page designs.

Which is fine…

What’s important is that each individual design doesn’t rely on other pages to do its job, which would simply be a large design guide by a different name.

Once you’ve decided what you want your design to do, you’ll need to decide the best way to demonstrate it.

Decide the best way to explain your design

There are a lot of different ways to show information and, a lot of the time, different types of data can be easier to understand and easier to work with when it’s presented in a particular way.

For example, UI design is often shown using flowcharts, as it’s a good way to demonstrate the flow of a user interface from screen to screen but also allows you to dig into the details of each panel and what it’s supposed to look like.

Whereas game levels are usually clearest when using a map, as this provides a high-level understanding of how the layout is going to work, even though it’s from a point of view that the player will probably never see.

One-page designs can also be used as an organisational tool.

For example, Gantt charts can be useful for explaining when the different stages of a project are expected to start and end, who will work on them and how long they will take.

Exactly which format you should use for your design document depends on what you’re trying to show.

But, there is a general approach that you can follow.

Typically, there are two elements that are common to many one-page designs.

1. A main illustration that explains the core idea of the design
2. Optional details that expand on the core idea for those that need to know more

The important thing is that, whatever you do choose, it should be as easy as possible to understand.

The one-page approach isn’t a challenge to fit as much information as you possibly can into one space.

Which, if you do that, can make your design harder to understand, not easier.

Instead, try to think of the one-page approach, and game design documents in general, as an exercise in communication.

If someone else can easily understand your game by reading your GDD then, even if you’re working alone, your design document will be much easier to work with and much more helpful to you as you build your project.