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.

Words on Paper

I may have a book out:

If you are an aspiring game designer and want to learn about what a Game Design Document is (and isn’t), how to use Powerpoint without murdering your audience and how to use Excel to answer game design questions, then perhaps you should check it out?

The problem with being a perfectionist is that every time I’d make a proof revision, there would be about fifty other things I wanted to change. So my enthusiasm for the final copy is a bit muted even though I worked super-hard on it. I’m actually quite proud of it and think it will be a great help to students. I fear if I waited until it was “done” that it would never come out. So I tell the perfectionist voice in my head that all those changes will come in the second version which is already taking form.

I’ll post some excerpts here on the blogitron shortly. I’d love to hear from anyone who orders it.


“Turning Depression into Inspiration” by Michael Todd.

The above link is a GDC Vault presentation about being a game designer while being depressed. I hope they never take it down. The presentation itself is okay in terms of organization and style but it is excellent in broaching a taboo topic. How do we as designers create joy for players when we cannot create joy for ourselves? We should be able to talk about this. How do we sell ourselves as artists when we hate ourselves? Interesting questions without straightforward answers.


I haven’t written a review in a while, so I thought maybe I’d give my impressions of F.3.A.R or Fathirar or what henceforth I will call Fear 3.

For a game with an aesthetic response right there in the title, it does little to evoke fear. Day 1 Studios tries hard and I want to gently pat them on the head and say “Good effort” but there seems to be a clear delineation between “scary parts” and “shooty parts”. The “scary parts” are marked by a lack of enemies and overall creepier music. But once you realize there is no danger in the “scary parts”, then it becomes like a tame theme park haunted house. You walk around and admire the workmanship and cleverness of the designers.

But good survival horror (if that’s even the genre they look to nudge into) doesn’t give you a chance to breathe and enjoy the scenery. Or if they do, it’s only to lower your guard for when they choose to shock you in a “safe” area. About three quarters of the way through the game, they seem to start to realize this and they start throwing enemies at you in a way where you can’t camp behind cover and methodically advance. I was excited by this, but the rails came off when I realized the AI of the enemies was a bit too stupid to provide for any interesting encounters–the monsters bite at your ankles mostly so you just unload shotgun round after round at them until they go away or you die. Playtesting must have revealed that they had no clue how to balance this thing as there is a difficulty slider on the respawn screen so you can nudge it to suit your own level of flow.

I probably wouldn’t have pushed myself through the entire campaign but for periodic surfacing of some truly great tactical set pieces. About once per mission there appears an encounter where you truly have to use the environment and the weapons at your disposal cleverly to progress rather than either Ramboing or playing cover tag.

If these moments happened more often, my blood would have been pumping. Regretfully, it seems like a rogues gallery of early 00s bad design and technical decisions. Enemies will pop in from nowhere. Doors lock behind you constantly to load further parts of the level (I just blew up a helicopter with this surface-to-air missile, yet I can’t open this door that just automatically closed behind me?). Invisible walls block progress where you aren’t “allowed” to go yet. Enemies clip through closed doors. Scripted events trigger too early meaning you don’t actually get to see the helicopter crash or the monster come through. Even enemies that are invincible because they are part of scripted events and can’t be killed until you walk past the line that triggers the event.

Inexplicably, these bugs and mistakes are paired next to excellent looking levels with masterful indirect control. You almost always know which way to go and it is usually because of a well-placed light or other non-obvious marker. Of course, a lot of the cool-looking things were in Half-Life 2, seven years ago but games can’t all be Half-Life 2.

You’ll get sick of the same monsters appearing over and over again by game’s end. One of the best enemies is some sort of Dr. Manhattan-esque blue guy who can create portals and walk through walls. These guys can set up some pretty good moments, but they don’t go far enough. In fights with them, you should always be vulnerable next to walls as they can just teleport behind you and grab you. This would make being out in the open the safest place, a direct reversal from the dynamics set up in the rest of the game.

The story is pretty nonsensical, but I’ll admit I didn’t play the first two iterations. For some reason, they stick with the silent protagonist (nee Gordon Freeman) but they place him in cutscenes where it would be natural for him to offer some sort of response. Even a nod or a grunt. Instead, he looks stone faced at whoever is talking to him. I guess I shouldn’t ask for much when the character doesn’t even have a real name. The game hints on a theme of mistakes and favorite sons but really doesn’t develop on either. One mechanic at the end of the game takes it into consideration as which brother you played throughout the game, but since they don’t really tell you that, you will probably have the Point Man ending.

There’s an exploitative points system that gets you to do stupid things like hiding in cover when no one is around to gain points. When you complete levels you unlock the ability to play through the game as the evil brother Fettel who can possess enemies and make them fight each other. This is much more interesting than silent commando protagonist! But since it is just an unlock option, few will play that way. Why not have made Fettel levels and Point Man levels where you can set up interesting pieces with your possession abilities? I almost wrote something about Fettel’s voice acting being almost as bad as Psycho Mantis from Metal Gear Solid, but looking at his biography it turns out he was Vulcan Raven in that series, so I understand perfectly.

The multiplayer shows signs of being compelling, eschewing the normal deathmatch/ctf types for some objectives that are a little more interesting. I didn’t dive too deep into it, but there were some mechanics I really liked in there. One mode has you possessing NPC enemy players and battling NPCs possessed by other real players. That’s clever. One mode has you running from an ever encroaching wall of badness, which strangely reminded me of a minigame from Fuzion Frenzy. Something tells me co-op would be a blast, but I’m so tired of the game after going through the single player. If the game was primarily about Fettel or provided a separate co-op campaign, you’d see it jump a few points in my book.

Overall though, it is a game about guns and little else. If you are tired of gun games like I have been lately, then this won’t do anything to change your view of the hollowness of gun games. If it was released in the crowded Christmas season, it would have been instantly forgotten. Luckily WB Games is smarter than that. There are plenty of things to like, but they are surrounded by frustrating same-y filler. Unless you are willing to forgive a lot of sins, you will be more distracted by FEAR 3 than drawn into its world.

Is this from Uncharted 2 or Fear 3 or Call of Duty 6?

Oh! I almost forgot! There is a level that takes place completely within a near future Costco!