What’s a Game Design Document & Why Would You Use One?

So many times I’ve been part way through a project and realised that I’ve totally lost my way. If only there was some way to keep me on track, some kind of plan…

Well, it turns out that there is! And it’s called a game design document (or GDD for short). But, what is a game design document?

A game design document is the blueprint for the game that outlines everything that needs to be created, how everything should work, and how each part of the game interacts. It is a vital document that will be referred to by everyone involved in the development of the game.

There are many different forms that a game design document can take and they can vary drastically in length, often stretching to over 300 pages! It’s important that it covers everything in enough detail for everyone to be able to stick to the plan, while avoiding being hard to read or understand.

Game design documents are usually completed before development begins. I’ve written a guide on the difference between design and development here, if you’re unsure of the distinction.

For smaller games and smaller teams, there may be alternatives that are a better fit, and some development processes won’t work with a traditional GDD at all.

For example, games that are developed through Early Access on Steam (or similar models) are more likely to have a more organic and reactive development, having a more skeletal design document so the design is able to react to the feedback from the community.

Let’s take a closer look at what actually goes into a game design document, why you might need one, why you might not, and what other things you can use instead.

What’s covered in a game design document?

A game design document usually covers everything that will be included in the game, as well as why they’re a part of the game and how they should be implemented. Where more than one part of the game interacts with another, the intended outcome of these interactions is also detailed.

For example, when the players sword hits an enemy in the face, how will the game react?

The game designer who is creating the GDD will often also detail any edge cases and what should happen in those instances. Expanding on the example above, what happens if the enemy hits you at the same time that you hit them? This would be answered in the GDD.

The following aspects of the game will commonly take up a section of the GDD:

The story overview
A gameplay overview and game flow
The main character (if there is one)
The controls for that character
Other characters that the player will meet
Gameplay – what the player will actually be doing in the game
The world of the game (what kind of environments will the player visit)
Game modes (if there are multiple modes)
Intended experience (the mood and feel of the game)
Mechanics (what can the player do, what elements can be interacted with and how)
Enemies and bosses (if the game has any)
Camera implementation
Cutscene implementation (where, when and how are cutscenes used)
Any key set pieces in the game
Progression systems (do you level up, do you unlock new areas etc)
User interface designs
Concept art (how the game is intended to look)
Sound and music design (how the game is intended to sound)

Remember that this is a reference for everyone that will be developing the game. So, if there are any questions that come up during development, those questions should be answered by the GDD.

In addition to the above, GDDs will often also include something known as a ‘beat chart’. Beat charts are awesome and are basically a map of the structure of the game. For each level or part of the game, you would detail things such as:

The part of the story that the level takes place in and the story elements within that level
What the player will learn during that level and how the game progresses
What enemies and mechanics are introduced during the level
New abilities unlocked
Any secrets hidden in the level
Anything else that is relevant to the structure of the game

As a solo developer, I rely on beat charts extensively, as they can really help you to keep on track and make sure that the game has a really satisfying progression to it (rather than thinking “oh it’d be cool if I add this in here” and ruining the flow of the game.)

For an excellent guide on how to use beat charts, I’d recommend the book Level Up by Scott Rogers. It often mixes up design and development, whereas I try to keep those things as separate as possible, and some of the terminology is used in a slightly outdated way. But the way that the book covers how to document the design of your game is without comparison, and it’s worth it for that alone. You can get it on Amazon in paperback or on Kindle (this link will open in another tab by the way).

How long is a game design document?

The length of a game design document can vary wildly, as some games just have more stuff that needs to be created for it to be a finished game. For example, the GDD for Red Dead Redemption 2 is going to be orders of magnitude bigger than the GDD for something like Candy Crush Saga (although, don’t underestimate how much design goes into casual and puzzle games!)

The golden rule is: a GDD should be as long as it needs to be to cover everything in enough detail to avoid any ambiguity on how anything should work.

If a GDD is too short and not detailed or clear enough, then parts of the game risk straying away from the original design and undermining every other aspect of the game.

If a GDD is too long it can lose clarity, or be too overwhelming for a developer to actually take in what it’s trying to communicate.

Why would you use a game design document?

For larger studios, having a comprehensive game design document is absolutely vital to ensuring that the finished product even vaguely resembles what you originally set out to make. Consider that Red Dead Redemption 2 had over 3000 people working on it, which is roughly the same number of people who built the Titanic!

You’d be naive to undertake any huge project without a plan in place, and game development is no different.

For any game studio that has more than a handful of people working on a game, starting development without a GDD is a recipe for disaster. No matter how skilled the developers are, there’s still the risk that you’ll end up with a mess of a game made up of ideas that don’t work.

Without a clear plan, each part of the game could be fantastic in isolation but not work well with any other aspect, leading to a disjointed experience.

As an extreme example, the artist may create world class environment art for a sci-fi epic, while the writer has written an emotional story set during WW1 and the gameplay programmer has added in a bunch of fantasy style sword fights.

I mean, thinking about it, I actually like the sound of that game…

Do you have to use a game design document?

Not everyone uses a game design document, and there are some situations where a complete GDD can actually hinder development.

Once example is when a game is in Early Access, which is when it has been released before it is complete and development continues and takes in feedback from its community of players.

A good example of this is Dead Cells, whose developers weren’t afraid to make fundamental changes to the design if players didn’t like one feature or another. You can read more about their experience with Early Access in this interview with Gamasutra.

Solo developers and small teams also often forgo using GDDs, although personally I’ve found that this can lead to project falling off the rails and so I’ll always create some kind of documentation before developing the game to make sure I know what I’m going to make and what’s actually required for it.

The risk is that you can add features that don’t make the game better, perhaps something cool that you’ve seen in a game you’ve recently played. If you haven’t defined the scope of a game, then it can also grow, with the game and development time growing along with it (potentially forever in the case of some games).

It can be tempting to get straight into development, particularly if you have a really exciting prototype or have had really awesome feedback from something you’ve made for a game jam. But it’s always worth taking that step and making sure you know exactly what you’re setting out to create.

You can always update your design if something isn’t working as intended. In fact, most GDDs are considered fluid documents and are changed and updated through a game’s development.

Do all game design documents follow the same format?

Not all game design documents follow the same format. Some are longer and some are shorter, some are led by images and designs, some are basically notated prototypes and some may be a collaborate wiki.

No matter how a GDD is put together, it always has the same goal of making sure the design of the game is clearly defined so that the completed game is what it was intended to be.

GDDs may include some, all or none of the below:

A set of storyboards
Prototypes of systems or gameplay
Diagrams and flow charts
Animation
A beat chart (see above)
A wiki
Concept art

Again, a GDD should include whatever is needed to clearly describe whatever needs to be understood by the developer. If that means a comic strip of the main narrative beats or a diagram of the resource tree, then that’s what goes in the GDD!

Examples of game design documents

There are plenty of examples available online, for games of all sizes.

For a solo developer or small team, the concise design document for Monaco is a great resource.

For those with a sense of history, the original design document for Deus Ex, along with Warren Spectors scribbled notes, is available here.

For something a bit different, be sure to check out the original pitch document for BioShock. Although not strictly a design document, it makes for interesting reading and does a good job of defining what the game was intended to be.