Creating a Game Design Document

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