Game Design 101: The Design Doc
June 20, 2006
by Ralph Edwards
In the early days of game development when teams were based on only a few individuals, there really wasn’t any need for what’s commonly referred to today as a design document. With only a few people working on the development of the game, the need for creating a document that defined in an easy-to-read and detailed fashion wasn’t all that important because the individuals working on the game were always communicating and often already had their hands in every single stage of development, including coming up with the concept and design of the game.
Nowadays with teams working on the development of games in the hundreds, the need of creating a design document that helps communicate the vision and direction of the game to every single member of the team, such as the programmers, producers, artists, musicians, marketers, and testers, has grown exponentially. Although, while the need to have such a document has become immensely important over the years, there still remains to be a universally-defined and accepted standard for how a design document should be written. In fact, if you’ve had the chance to work at different companies within the gaming industry, you will likely have already found that the expectations of how one should be written can vary greatly company-to-company, and in some cases, within a single company.
Nevertheless, here’s a good basic rundown of the items that should be included in a basic design document. And please keep in mind that this is just at sample of topics and what each of the topics should include and should in no way be meant to be followed as a bible. The importance of each item and how critical of a role that it plays in a game will vary greatly based on the game’s genre. What you see below should get you a good start on putting tighter one of your ideas as you shop it around to developers while looking for employment.
It’s simple but the revision history is an extremely important part of any design document, particular when dealing with larger companies and when changes are made on a consistent bases. The revision history should list any changes that have been made to the document so that a programmer, artist, producer or marketer can quickly look at the new document and know if any of the new changes directly affect what they may be working on.
Table of Contents
It seems obvious but adding a simple table of contents is often overlooked. It’s important because it lets people know exactly what sections are included in the design document and where to find them quickly. In addition to a simple table of contents, it’s wise to add tabs to the documents that separate each section so information is easy to find for whoever needs to find something. It can be a huge waste of time trying to get to page 100 for the section on the story if it’s not well marked off.
The vision statement is where the designer will want to describe what kind of game it is. Is it a first-person shooter? A 3D platformer in the vein of Mario? A card game based on Magic the Gathering or whatever is the latest fad? This is where you’ll let everyone know what the game is, how it’s unique from others in the genre, how it plays and how exactly will it look and feel – dark and very realistic, a simulation of real life, animated in a fantasy world, or whatever.
While this section may be primarily for the marketing team, it also is important to all that are working on the game because it’s key that everyone on the team knows what’s the demographic of the game that’s being made. If it’s for young children, you’ll know to keep the violence and sexuality down some. And if it’s aimed at just men or women, you’ll need to keep that in mind in every single aspect of the game from the gameplay, to the art style, and to the music.
In this section, the designer will also want to make mention of the platform it’s being designed for, why it’s the correct platform for the game, and also list the top performers in the genre being tackled, who the potential competition for the game will be, how this game’s features stacks up against those games and even take an educated guess at potential sales based on market research of games being sold in the genre.
For some games, you can just skip this section entirely. However, if the title needs a license for its story, characters, likenesses, voiceovers, music, of anything of the like, then here’s where the designer will need to list things out.
Here the designer needs to go into details about all the characters in the game, starting with the main protagonist or protagonists. It should include concepts or descriptions of who the characters look like, their age, their weight, the personality, the backgrounds and everything about them to let the person reading this get to know the character or characters that the game will be based on.
In addition to the game’s main characters, the same needs to be done with all of the NPC (non-player characters) monsters, friends, and enemies that will be encountered throughout the entire game. Not as much details will be needed for those with small roles, but major enemies will need a similar effort to the game’s main stars.
The title says it all, this section of the design document is where the designer needs to write out and overview and outline of the story as it unfolds as the player goes through the game in a linear fashion. It should include details on how the story is told – through text, voiceovers, cutscenes, or a combination of these elements – and it should also detail any back story or subplots that may not go along with the game’s main storyline but plays along with it.
This section of the document should give the reader an overview of what exactly the world in the game is all about. It should include maps of the world, the main cities or locations, the interactive and non-interactive objects in it, an idea of the general mood and look of each area, the type of people that inhabit it, just how big everything is inside the world and within each section of the world and how exactly the user travels through it.
The largest and most important section of a designer’s design document is the one that details the gameplay. It should start out with an overview of the core game play and the play mechanics that the game’s user will be using to progress throughout the game. The precise controls needed to be completely mapped out for each different section of the game, the interface needs to be explained in great detail, the conditions for winning and losing on both a small and overall scale needs to be set in stone, and details such as AI behavioral patterns, weapons or ability upgrades and any Easter eggs or hidden secrets should also all be detailed. Basically, this should explain every single thing that happens with the character in control by the user and how the AI-controlled NPC characters will respond to them.
Furthermore, this section needs to explain each of the levels in the game, a general flowchart of how you get from level to level, and what the team and challenges of each level will be presented to the person playing the game.
Beyond just the gameplay elements for playing the base game, this section should also be used to discuss the various different modes of play, what each of these modes are, and how exactly the interface and design will be for these modes will be and how they will play along with the main game.
Much like the table of contents, the appendix is pretty much a summary of all the details in the game and how you can quickly find them. It’s just a like the table of contents, except that it appears at the end of the document and has things laid out in an alphabetical and more detailed fashion. (source:IGN)