Skip to content

Creating a Game Design Document

November 30, 2008

This is the third post in a long-promised series. The first two are The Core of a Game and Feature Set from a Core.

Creating a Design Document (DD)

Almost every game that’s on the market had some form of design document. It may have been written prior to the game’s development and edited as it entered production, or it may have been written as sections of the game were developed and deemed good (i.e. “fun”). Some games have no document at all.

So, how does one write a game design document? Truthfully, there must be a dozen different ways. In almost every case, the overall format of the document was different. Most times, the publisher or developer for which the designer was writing had a format they preferred. Other times, the author was asked to create a format for the project and other junior designers to follow. For this, I’ll work from one of my standard process templates. It is a misnomer to think you can follow a generic outline and arrive at a specific game. Rather, you’ll do better if you figure out the process by which docs are developed and develop yours similarly.

While there is no set way to write a design document, all design docs have one thing in common – they tell a programmer or an artist everything they need to know to create your game.

Considering Your Audience

Before you start writing, consider is your audience. Many new designers write documents as if they’re being written for gamers instead of a programmer who’s tired, annoyed and up at 3 a.m. coding your combat system. The latter is your audience. Statements like, “Cannons allow you to blast your enemies to pieces!” shouldn’t be in design documents. Save that for the back of the box. Try something like this instead: “Each cannon has four shots before it must be reloaded. Cannons are reloaded automatically, provided there is ammo available and a pirate is available to reload it. If no ammo is available…”

One of the key jobs of a game designer is to anticipate issues for the programmer and leave no ambiguity. So, for instance, if in saving the game it automatically returns you to game play, you need to anticipate issues for the programmer. What if it puts the player right back on the trigger that goes into the save screen? This could result in a needless compile of the programmer doesn’t think of it (and she may not at 3 am). So, put stuff like that in there. Granted, 85% of the time, they’ll think of it, but your 15% will be more than worth their annoyance.

Never be vague. Saying things like, “The player may…” implies an ambiguity. They may if what? Other typical ambiguities include:

  • “The player has several options.” You don’t actually list them
  • “A number of…”. What number?
  • “Affects damage…”. By how much?

Also, remember that your audience is very unique – it’s people in the game industry. Generally, we’re not into marketing-speak or superfluous prose that doesn’t get to the point.  Write in an average, everyday voice, just like I’ve written this.

Creating a Core Statement

Before even putting typing a word, a designer or design team needs to identify the core of the game and create a core statement. What is the one thing your game is about? The great game designer Shigeru Miyamoto advises revisiting (not revising) this statement often, particularly when new features are added or features are cut, to make sure that you’re still on track. Mind you, it’s possible for the core of a game to change midway through development, and it’s definitely happened. When it does happen, however, the designers must revisit the rest of the game’s design to make sure that every feature in the game strengthens the new core.

Core statements can be created in two different ways – directly or from a genre. To create a direct core statement, consider the following core statement samples:

  • This game is about being a/an…
  • This game simulates…
  • This game lets you play…

Our previous discussed pirate game fits neatly into any of these statements.

A core statement can also be created from a genre. If you’re already locked into a genre, you know your statement.

  • RPGs are about character development
  • RTS are about resource capture
  • Simulations are about building
  • FPSs are about survival
  • Racing games are about being the first to the finish line

The core of a given genre can be refocused to create innovative gameplay. The previously mentioned Forza: Motorsports Racing developed a unique core for its racing game. By combining a simulation and a racing game, they created a game about building the ultimate racecar. Of course, the ultimate racecar would win races, but it would also add many features to facilitate owner pride and automotive pampering.

When creating a core statement for a game, sometimes game developers take themselves too seriously. They try to sound too important or profound. Some think that their statement doesn’t sound fun at all. Some may even go so far as to think that their statement sounds silly, and some cores actually do! However, they make for fabulous games. Katamari Damacy’s statement is this: Katamari Damacy is about rolling over things, picking them up and collecting them. Never underestimate the potential of any core, particularly yours.

Creating a Feature Set

Once your core is established, it’s time to create a feature set for your game. Feature sets consist of 5 to 15 things (tho that 15 is a super long shot) that will make up your game, each one making the core stronger. Remember, if it doesn’t make your core stronger directly, it should be revised or cut.

Going back to that original pirate game, originally, I’d just thrown out some ideas that could possibly work:

  • A pirate ship
  • An ocean we could explore
  • Other ships that we could plunder (and steal, perhaps)
  • Seaport towns that we could plunder
  • A combat system that allowed us to attack people
  • A place to sell our stolen goods or people to sell them to
  • Cannons
  • Some indication of the power we have and fear we generate as a pirate
  • Fellow pirates

A feature set turns these ideas into concrete, verb statements.

  • Command and customize your own pirate ship
  • Seize other ships and grow your pirate armada
  • Explore the distant seas and stake claims over your territory
  • Raid, plunder and attack seaport towns and islands
  • Wield dozens of weapons including daggers, swords, and scimitars
  • Sell your loot to grow your pirate empire
  • Recruit others to join your crew

The feature list above is smaller than the original list, but contains all the initial ideas that were laid out. This list will be the basis for a design doc. It’s critical to understand the overall direction of a game before starting to document how to create it. While this sounds completely obvious, you might be surprised how many people start documenting without a clear idea of where they’re going.

Feature lists usually take a ridiculous amount of time to develop and refine, usually a week or more for a first pass (unless you have to have it finished quicker, and that is sometimes the case). The list above, if subjected to a group of fellow designers, would likely be revised numerous times. By yourself, an initial list may take you an hour or two. To see feature sets for other games, check out the back of any game box you happen to have. Though these lists will usually be written in “marketing speak”, the desire of the designers is clear.

After you finish your feature list, talk it over with a couple people you respect to see what they think. Enter these conversations knowing that your list is not as good as it could possibly be. Odds are, it’s not. Experienced game designers live by that principle. By getting feedback and receiving it well, you will become a better designer, and your game will likely be stronger because of it. Designers often fall prey to “lead’s blindness” – the inability to be objective about their own work due to what can only be described as a love of their ideas. You want others to subject your ideas to scrutiny. Learning how to receive criticism well is the hallmark of good designers.

Creating a Table of Contents

Once you have a solid idea for a game, create the table of contents for the design document. The table of contents needs to cover every single thing in the game except for the story. That is typically contained in a separate document or documents written by the game’s narrative designer. Much as novice designers want to get their story out on paper, it has no place in the design document except in summary form. While I’m on a roll here, in many games, a writer would have been brought in early to work with the game designer on the game’s story and integration into the mechanics of the world. The two can and should be integral to one another. Regrettably, sometimes stories are an afterthought or aren’t given the attention they should be.

Think of the design document as an architect’s blueprint. The programmers are the construction team. The artists are the interior designers. Eventually, someone will move into that house and create a story there, but first, the house needs to be built. The table of contents is our first effort to imagine the house we’re building.

If you’ve never created anything like this before, take a look at a game manual and see how it breaks up the game. These manuals are often written from the design doc, and I say this having written a good number of both. Go grab a manual from a game that’s similar in style to the one you hope to create. Another way to think about what you’ll need is to turn on a game and consider that every screen, every option and every button press (correct and incorrect) was covered in a design document.

Begin by identifying the functional areas of the game. For our pirate game, it might look something like this:

Table of Contents

Main Menu
Character Creation
Main Gameplay Screen
Ships
Crew
Exploration
Raiding
NPCs
Inventory
Game Options

Once your functional areas are identified, it’s time to flesh them out. Remember that a design document needs to cover every single thing in a game. If you see it on the screen or if it happens in the game, it needs to be documented.

For our pirate game, and as an example, let’s flesh out the “Game Options” section. It might look like this:

Game Options

  • Save Game
  • Save Game Screen
  • Writing Saved Games
  • Deleting Saved Games
  • Load Game
  • Load Game Screen
  • Loading Saved Games
  • Quit Game
  • Music Volume
  • Dialogue Volume
  • Language Selection
  • Subtitle Toggle
  • Vibration Toggle

Each section needs to be similarly fleshed out. For the typical design document, the table of contents may be two or more pages long. When faced with this amount of writing, some would-be designers consider a career path change. However, it’s not as daunting as it looks. In fact, it’s actually fun (of course, I think item lists in Excel are fun, too). The great bulk of a designer’s time is spent thinking of games, playing games and designing features that make the core of their current game stronger. Once you get the hang of the level of detail that’s necessary, it’s pretty simple since all the detail is in your head.

Disclaimer: Everything I’ve said here may be a lie, depending on who you ask. There are sometimes multiple ways to do something right in the game industry.

Next Up… All Menus Must Die

About these ads
20 Comments leave one →
  1. November 30, 2008 5:26 pm

    Ordinarily I strive for quality comments and discussions on other people’s blogs, but I’m afraid I haven’t much to say other than an extended and heartfelt “thank you” in this instance, Mrs. Brathwaite. Your articles are informative to the point of inspiration a lot of the time anyway, but in this particular case you just made my break from laying out a document’s table of contents all the more productive.

    I may never be sure if it was genuine obstacles or my looking in the wrong places, but it has been really rather difficult to try and see just what a fully-fledged document might look like. While I was taking a shot at writing my first, I was fortunate enough to see scans of the abandoned “Sonic Mars” project script from 1995. Although the SEGA 32X technology and the growth of the industry since then have likely aged it, at the time it was an inspiring wake-up call.

    G.D.D.s are, of course, quite logical beasts once you have the right thought process in mind, but getting there in the first instance is a scary prospect. Such simple suggestions as having a core statement in there are sure to make an incredible difference. Here’s to spreading that insight.

  2. November 30, 2008 8:25 pm

    So basically more technical than casual, it make sense, I’m a programmer myself as well so I know what you mean

  3. December 3, 2008 11:27 pm

    Thanks, Murray. Much appreciated. That’s kind of you to say that.

  4. December 4, 2008 8:55 pm

    Anticipating the issues the programmer will run into… This is why game design students should know at least something about code.

    It gives you a great sense of exactly what issues you need to consider, and just what level of detail the programmer will want to know.

    • January 9, 2012 6:53 pm

      My game design program at Full Sail University includes 2 programming classes. I plan to learn both design and programming. I too agree that basic understanding of code is essential. I want to begin reading about programming, does anyone have any suggestions for beginning this endeavor?

  5. December 7, 2008 10:01 am

    To springboard off Brian’s comment, I think the biggest problem for designer’s in anticipating a programmer’s difficulties down the road is determinism.

    When we play a game, generally we use very non-deterministic logic. A computer is incapable of this, and must use totally deterministic logic at all times. It’s this leap between the way the designer thinks about the game and the way the computer needs the game explained to it that produces difficulty.

  6. December 7, 2008 2:35 pm

    @Michael: I disagree. Non-digital board game rules have to be just as deterministic. Otherwise the players get to a certain point where they’re not sure how to proceed, and have to invent or creatively interpret a rule on the fly. And yes, as humans we can do that far better than a computer, but every time a group of humans has to do this it’s still a definite failure on the part of the designer.

  7. nail permalink
    February 18, 2010 10:03 pm

    This is awesome!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

  8. May 26, 2010 1:32 pm

    Because I’m working at an engineering company that deals with lots of documents, including design documents, I was wondering…

    If there are design documents for games, what about requirements? Is there such thing as game requirement document? Are there any requirements relevant to games? If there isn’t, the only reason i could think of is because they all share same requirements: “be fun”, “marketable”, and so on…

    Just curious.

    Oh, and I loved your Train talk. It completely changed how I look at gaming… and also made me not enjoy any video games that I currently have (probably the ones I will buy in future as well).

    • June 19, 2010 1:18 am

      The TDD (technical design doc). It contains all the tech specs for the game. The TRC and TCR docs put out by first party stipulate the requirements that video games must have to get on particular systems, and all evolving systems (like Facebook) have similar documents.

  9. Jared permalink
    December 11, 2010 7:07 pm

    Please please PLEASE get rid of the “snow”!

    Are you trying to distract your viewers from your content? This isn’t the 90’s ;)

  10. terry meijia permalink
    December 28, 2010 9:07 pm

    This is a great primer on composing game design docs. I work in game design, and I plan to use this to teach new interns at our company!

  11. James permalink
    September 3, 2011 9:45 am

    Spot on! Well thought out and great start for people that are not in the know. I have created a few GDDs in my time and you can always learn from others as I just did here. Thanks for your insight.

Trackbacks

  1. Como Criar um Documento de Design « Maracatu Studios
  2. Some game design articles | No Name Games
  3. Rational Game Design » Blog Archive » Microsoft’s Word – Let’s bury the dead! – 20 Reasons why you should write your GDD in a Wiki.
  4. The Game Design Document « How To Make a Video Game
  5. Atividade da Semana – Elaborar o Documento do Jogo « Projetos de Jogos I – 2010/1
  6. Getting creative with LÖVE « Christopher Colston

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 399 other followers

%d bloggers like this: