Game Design Documents

This is an excerpt from my new book Practical Tools for Game Design Students. If you are at all familiar with Damion Schubert’s popular game design documents talk from recent GDCs, you will find a lot this is familiar and I give him a lot of credit in my classes and in the book. This is the introduction of the concept of Game Design Documentation. In later sections and chapters, the book goes into different kinds of documentation like Feature Overviews and Pitch Documents and also how you can use some of Word’s advanced features to ease their creation.

Oh, the Game Design Document! It is one of the most useful tools in a designer’s toolbox for communication, but also one of the most misunderstood. Nearly every professional designer deals with game design documents (or GDDs). But what are they? Why are they so ubiquitous?

When a game development team is only three people (say a designer, artist and programmer), the team only has three channels of communication they need to keep open: designer-artist, designer-programmer and artist-programmer.

Figure 4.1 – Three Members and Three Communication Channels

But add just one more programmer and the number of lines of communication jumps from four to six:


Figure 4.2 – Add One Member and Communication Lines Double

Professional game development can be a mammoth undertaking with team sizes that can top well over one hundred people. If everyone on a team of one hundred had to connect with every other team member, it would require four thousand, nine hundred and fifty connections. World of Warcraft is estimated to have over a hundred and forty people on the team.[1] If this is true, there are 9,730 connections between the team members that would need to be maintained if every team member needed to directly talk with each other.[2]

This is too unwieldy. Real-world teams are not structured where every team member needs access to every other team member. Instead, larger teams are subdivided into groups by either discipline or project area. For instance, the artists may all talk to each other but route their communication with other disciplines through a producer. Or all of the team members working on the multiplayer portion work together while the single player teammates only communicate with their own.

This causes another problem: instead of team members being able to directly communicate with each other freely, communication has to be routed through gatekeepers such as producers or leads. If you ever played the childhood game Telephone, you know how multiple rebroadcasts can add noise to a channel:

Figure 4.3 – The Telephone Game

A fluid and, at times, highly vague concept like a game design can’t be faithfully communicated in such a manner. Teams devise artifacts that can be digitally replicated to eliminate the signal loss of the “telephone” method above. The game design document (or documents) is a tool to solve this problem.

A game design document is any method of documentation that gives instructions for building a game or feature. It is important to note that from team to team and studio to studio, game design documents can take wildly different forms and be constructed from wildly different methods. There are also common misconceptions about the form and purpose of a game design document.


Common Misconception #1: The Game Design Document is a repository of all information about a game or feature.

Game design documents are there to serve a primary purpose: to inform team members as to what they are to build. To this end, there are a number of stakeholders:

  • Programmers. Because they need to build the thing.
  • Artists. Because they need context to know what they are creating.
  • Producers. Because they need to be able to gauge how long a feature will take.
  • QA. Because they need to know what a feature looks like when it is working.
  • Other designers. Because their systems need to work with the feature.
  • Licensors. Because they need to ok use of their intellectual property.

To look like they are producing a lot of content, many designers fill a GDD with explanations of all of influences behind a system, backstory, design discussions or other ephemera. Here’s the rule of thumb: Unless it directly instructs a programmer or artist what exactly to make, leave it out of the GDD proper. You may relegate it to an appendix (see below) or to another document.

In some cases, it is necessary to keep a second pseudo-GDD. In cases where you have external licensors or overly involved executives, they will want to get their hands in what the team is making. In these cases, the GDD will likely be too technical for what they need. For these situations, “Design Overviews” or “Executive Summaries” are sometimes useful and are covered at the end of Part Four.

Common Misconception #2: The word in the GDD is law.

Aspiring designers who are just entering the field often hold this misconception. Game design is an iterative process: it requires experimentation and often-copious trial-and-error. Yet many game design documents are written and attitudes are hardened as if the game design document will never change. In the worst-case scenarios, programmers will print out the GDDs and build from a static conception of what the feature is.

The GDD is the formulation of an idea at a given time. The GDD’s function is to foster communication throughout a team, not to be a dictate.

Often I have heard from programmers that they don’t read game design documents. We will get into the cardinal sins that cause this attitude below but one of the reasons for this attitude is that GDDs are not kept up-to-date. If a programmer reads a GDD and then is told to make something contrary to what he or she read, she will wait to be told in the future instead of trusting that what the GDDs say. It is the designer’s job to keep documents as up-to-date as possible, no matter how tedious a job that may be.

Remember the purpose of the GDD: Unless you personally want to communicate a change in design to every member of the team, you must keep the GDD aligned to the most current design.

Common Misconception #3: There is a template to how studios create design documentation.

Often students will ask to see sample design documentation. I will show some made-up examples later in this book. Why I am hesitant to show anything at all is that every studio has its own documentation processes. The purpose of a student asking me for a sample is to copy formatting. The formatting is the least important part!

The design documentation is written specific to a particular audience. Blizzard’s design documentation for MMOs on hundred person teams is going to look quite different from Quantic Dream’s narrative-heavy design process. Who are your programmers? What do they know implicitly[3]? You are going to write your documentation for a particular audience.

Some studios do, in fact, have massive templates for game design documentation. This can be a useful practice if there are needed sections that are commonly left out. The danger with templates, however, is that they are not updated as the team and the project change and are thus prone to overloading documentation with wasteful, empty categories. Empty sections that have to be scrolled through make it more difficult for programmers and other stakeholders to find the information they need. That is anathema to having formal game design documentation at all. Given all the other things you have to deal with when writing your design document, keep clarity as the most important goal.


GDD Creation Process

Now we will go through an example together of creating a short, concise design document. Assume we are on a small team putting together a Fantasy RPG for Facebook. The lead designer comes to you and says you need to design a crafting system for the game. How would you go about creating the documentation?

Step One – Determine Purpose, Desired Scope, Locate Connected Systems

Designers usually have lead designers or creative directors above them. From one of these folks, you must clearly determine the goals of the designs. You must find out: the purpose of the design, the scope of the design and the systems that will necessarily connect with the design.

The purpose of the design: Without knowing the purpose of the system, all you can do is copy a similar crafting system from another game. Your lead designer says: “We need a system to use the items that players receive via gifts from other players. We want it to encourage creativity and social connections.” That is a start. Interview. Ask probing questions. Really understand the motivations behind the assignment before you begin writing or prototyping.

The scope of the design: Designers have an awful tendency to over-design. What this means is that given an assignment, designers will come up with nuanced, complex systems. In isolation this is not a problem. But in aggregate, no project can sustain complexity in every system and still expect to ship on time and be understood by users. Great designers know which systems benefit from complexity and which benefit from simplicity. By identifying the scope of the feature, designers get an idea as to the depth of the system to create.

Possible Scope Levels of a Design:

(Level 4)
The design is as bare bones as it can be while still satisfying the purpose of the design. Example:
Driving in Alan Wake
(Level 3)
The design is at the level that is expected from other titles in the market. Example:
Multiplayer Ranking in Uncharted 2
(Level 2)
The design is at the level of the top example of other titles of the market. Example:
Cover in Gears of War
(Level 1)
The design is beyond the level of other titles in the market and is something that has never been tried before. Example:
Creature Creator in Spore

In our example, the lead designer says: “We have a lot of art time for this, so you can make it broad, but the entire game is pretty casual so keep the complexity low.” In this instance, I would probably choose to go with the “Market Standard” complexity. We will deal with the implications of this choice below.

The systems that will connect: Clearly, from the original proposal, this system will be interacting with the gifting system. In addition there may be an inventory system. Perhaps you will make salable items? What designer is in charge of the economy so you don’t flood your game’s market with free goods? Who do you need to contact?

Assure that none of these statements are contradictory. For instance, if the purpose of the design is to have a fully customizable character generator while the scope of the design is to be simple, then you will need to meet with your lead designer to find out what must give.

Step Two: Research

The scope level you come to in the previous step will help you to decide how much and what type of research you need to do. Having a wide breadth of exposure to other titles in the industry helps here. I remember working in a studio that only produced one genre of game. Many of the designers there never played games from other genres! How will you know about features that may eventually creep into your genre without exposure? What is going on in matchmaking for leagues in sports games may become relevant for real-time-strategy games.

I have often said that the best examples for growth in being a designer is to play bad games and endeavor to understand why they are bad. By identifying features that were unsuccessful, you can design around the pitfalls and mistakes of your industry brethren.

Of course, your research is not just limited to games.

Research Techniques Based On Scope

(Level 4)
Play games that implement similar features and try to find what is common between all of them. Can anything else be taken away while still preserving the purpose of the feature? This requires design by subtraction.
(Level 3)
Play games that implement similar features. Which are the worst implementations? What can we do to avoid their pitfalls?
(Level 2)
Play games that implement similar features. Which are the best implementations? Why are they the best? How can we adapt their system to our game’s requirements?
(Level 1)
Since, by definition, you are attempting to create something that has never been done before, you cannot take features from other games and apply them to yours. However, you do still need to know the best practices for that feature to determine whether yours exceeds the quality of the market leader.This step requires influences from beyond the world of games. You do read outside your design work, correct? From what fiction and nonfiction can you pull inspiration? From what non-game interactive systems (ATMs, Toys, Events) can you draw inspiration? Be thorough.

Step Three: Brainstorm

We are going to discuss brainstorming and its uses in a later chapter in depth. A brainstorm is a creative meeting where an individual or a group tries to create a quantity of solutions to a problem. Based on the research you completed in Step Two, you should be well equipped to envision a number of possible solutions. See the Idea Generation chapter for the how-to of using this technique.

Step Four: Reduction

You will have a lot of possible directions to pursue after your brainstorming. It is best to sleep on them to have adequate time to think them over. When this is done, come back to the list of possible ideas. In Brainstorming, you don’t discriminate against ideas. In the Reduction step, discrimination is all you do.

Eliminate ideas that are:

  • Not in line with the chosen scope
  • Impossible to create
  • Not effective in researched titles
  • Don’t meet the purpose of the design
  • Conflicts with another design in the project

Step Five: Write the Best Method Down

Now fire up a word processor and get this idea down on (digital) paper. You’ve been exposed to a large amount of research in Step Two and a large amount of ideas in Step Three. It would be easy to put your voluminous knowledge down to paper. Stop!

Remember your audience.

If you are writing for programmers (and it is likely that you are), remember that programmers will change your words into logical code. The closer the form your document is to how they think, the easier it will be for them to translate it into code that works for their system. Generally, they will like hierarchically formatted lists like:

  • Player chooses a race (See RaceList.doc).

⁃          If player chooses elf, +2 speed.
⁃          If player chooses dwarf, + 2 strength.
⁃          If player chooses cow, +2 mooing.

  • Player then chooses a class (See ClassList.doc).

⁃          If player chooses priest, starting skill is heal (see Skills.doc)
⁃          If player chooses paladin, starting skill is smite. If player chooses paladin, he/she cannot choose evil alignment later.
⁃          If player chooses critic, starting skill is annoy. If player chooses critic, he/she cannot choose good alignment later.

This, of course, is a generalization. There are many types of programmers and each like different styles, but I have found it to be helpful. When in doubt, ask the programmers what they like to see. They are just as afraid of you as you are of them. Generally they will tell you, “Something short and easy to read.” No one has ever said “Something thirty pages long with lots of details.”

Err on the side of brevity. Remember how I have told you that it is your duty to keep the design documents up-to-date? Which do you think is easier to update: short hierarchical bulleted-lists or vast walls of text? Always ask yourself: what can I do to make this document clearer and shorter?


Did you see the “See RaceList.doc” mentions in the above example? Those are references and are the most helpful technique to keep your document size small. If you find yourself copy and pasting information into multiple designs, consider separating that information out into a reference and add a hyperlink. In the above example, I could have spelled out all the races, their designs, attributes and locations in the character creation design, but is it relevant?


What if there is some background information that is necessary or helpful to include? We don’t just throw that out, right? Absolutely not. Jesse Schell points out in The Art of Game Design that game documentation is a cure for the frailty of human knowledge. But since the programmers won’t be using that background information in scheming up how to create the feature, we don’t want it cluttering up the design document proper. Therefore, all the “bonus” material should be put at the end of the document in a footnote section or in a linked “FAQ” document. Here you have little restrictions on brevity. Anything that needs to be remembered (design battles, reasoning for certain choices, sketches that aren’t particularly informative, etc.) can be added to the appendix section/document. If you find it painful to be brief in the design document, you can let loose in this section.

Step Six: Edit and Find Edge Cases

You’ve written down the most salient feature idea and condensed that idea down to a logical list form. Great! Now there are two things you must do and it helps to do them simultaneously. Send the design out to your fellow designers and folks implementing the feature. Ask them: is this clear? Are there mistakes? Where does it break down?

An edge case is a problem that occurs only under extreme conditions. While others are reviewing your documentation, try to find edge cases in your own design. Test the extremes to see if it breaks down.

For instance, here’s a simple design:

“The player’s jumping height is equal to his strength divided by the weight of items in his/her backpack.”

Sounds reasonable. What if the weight of items in his/her backpack is zero? 18/0 means the player can jump an undefined height!

Here’s another:

“Players can put items in the “bag” item, which has twenty storage slots.”

Neat. What happens if a player puts a bag in a bag? What happens when a player tries to put a 21st item in a bag? What happens to the in-bag items when the player tries to sell the bag itself? These are all questions that will need to be answered. Since the bag-in-a-bag question is a little awkward, it would be an edge case. The others should have been thought out in the draft.

It is difficult to identify edge cases sometimes, at least more difficult than my simple examples above. The easiest way to check for edge cases is to make extreme examples of your players. What if a player has zero of something? What if he has everything? What if the maximum number of players all tried to stand on the same spot? What if a player did this action 20,000 times? What is the most illogical way the player could access the features in this design?

[1] From the horse’s mouth:

[2] If you are interested in the math behind this, see “On the Shortest Route Through a Network” by GB Dantzig (1960).

[3] For instance, designers at EA Tiburon (who are responsible for the American Football franchise Madden) don’t need to spell out what a “first down” is every time they make a new yearly iteration. That knowledge is implicit to the team.


  1. Hi Zack! Great post! I just ordered your book.

    Have you seen the game design log stuff that Dan C. has been talking about? I find it very interesting and useful.

  2. Hi Jesse!

    Yeah, I read Danc’s article and I love the idea, but since I haven’t actually used it yet I didn’t feel comfortable including it in my book.

    I’d love to hear your comments. I wish I could have spent more time on it, but I guess that is true of any project. I had to get it out in a reasonable time so my students would have something to work from. On a related note, one of my students told me he is starting as a remote tester for Schell Games next month.

Leave a Reply

Your email address will not be published.


Human? * Time limit is exhausted. Please reload the CAPTCHA.

© 2016 Zack Hiwiller

Theme by Anders NorénUp ↑