FUNDAMENTALS OF GAME DESIGN, SECOND EDITION
Types of Design Documents
This section is a short introduction to the various types of documents a game designer might create: the high concept, game treatment, character design, world design, and story or level progression documents, as well as the flowboard and the game script. Each of these is defined in the following sections. This isn't an exhaustive list, nor does every project need all of the items on the list. Rather, these are some of the most common ones.
The high concept and game treatment documents are sales tools, designed to help communicate the game concept to a funding agency such as a publisher. They are usually written in a word processor such as Microsoft Word and distributed in paper form. The other documents used to be written in a word processor as well, but it is increasingly common in the game industry to create them as pages on an internal company website or wiki. As long as you can keep the website secure, it's a good way of documenting a game design so that all the members of the team can access it, and you can update it easily. Once the wiki software is installed on the company server, the whole team can edit the content using only a browser. Be sure you have revision control and backups so that you can revert to a previous edition if someone deletes a page by accident.
You can find samples (or pointers to samples) of design documents on the book's companion website at www. peachpit. com/fgd2.
The high concept document is not a document from which to build the game. Just as the purpose of a resume is to get you a job interview, the purpose of a high concept document is to get you a hearing from someone, a producer or publishing executive. It puts your key ideas down on paper in a bite-size chunk that he can read in a few minutes. Like a resume, it should be short—not more than two to four pages long.
It's also worthwhile to write high concept documents for yourself, to record ideas that you might want to work on in the future.
A game treatment document presents the game in a broad outline to someone who's already interested in it and wants to hear more about it. Like a high concept document, it's primarily a sales tool. The treatment is designed both to satisfy initial curiosity and to stimulate real enthusiasm for the game. When you give a presentation about your game to a potential publisher, you should hand him the game treatment at the end so he has something to take away and look at, something that floats around his office and reminds him of your game. Your goal at this point is to get funding, either to create a more thorough design or a prototype or (preferably!) to develop the entire game.
The game treatment is still a simple document—almost a brochure that sums up the basic ideas in the game. A good way of picturing what to write in a treatment is to imagine that you are making a website to help sell your game; then throw in some business and development details for good measure.
A character design document is specifically intended to record the design of one character who appears in your game, most often an avatar. Its primary purpose is to show the character's appearance and above all her moveset—a list of animations that documents how she moves, both voluntarily and involuntarily. It should include plenty of concept art of the character in different poses and with different facial expressions. In addition, it should include background information about the character that helps inform future decisions: her history, values, likes and dislikes, strengths and weaknesses, and so on. Chapter 6 discusses character design in detail.
The world design document is the basis for building all the art and audio that portray your game world. It's not a precise list of everything in the game but, rather, background information about the kinds of things the world contains. If you have a large landscape or cityscape, for example, the world design document should include a map. You need not supply every detail, just a general overview. The level designers and artists use this information to create the actual content. Be sure also to note
the sources of ambient sounds in the world so the audio designers can build them in at the appropriate locations.
The world design document should also document the "feel" of the world, its aesthetic style and emotional tone. If you want to arouse particular emotions through images and music, indicate how you will do so here.
A flowboard is, as the name suggests, a cross between a flowchart and a storyboard. Storyboards are linear documents used by filmmakers to plan a series of shots; flowcharts are used by programmers (though rarely nowadays) to document an algorithm. A flowboard combines these two ideas to document the structure of a game.
Although you can create a flowboard in an editor such as Microsoft Visio, it's actually quicker and easier to make one on several sheets of paper and stick them on a large blank wall. Use each sheet of paper to document one gameplay mode or shell menu. On each page, write the name of the mode clearly at the top. Then, in the center of the page, draw a quick sketch of the screen as it appears in the mode, showing the perspective that the camera model implements and the user interface items that appear on it. Leave plenty of space around the edges. Off to the sides of the sketch, document the menu items and inputs available to the player and what they do. You can also list the challenges that arise in that mode, although that's less important—the key thing is to indicate the player actions that are available. Then draw arrows leading to the other gameplay modes or shell menus and indicate under what circumstances the game makes a transition from the current mode to the next one. By creating one mode per page and putting them up on the wall, you allow everyone in the office to see the structure of the game. You can also easily make revisions by adding new sheets and marking up the existing ones.
STORY AND LEVEL PROGRESSION DOCUMENT
This document records the large-scale story of your game, if it has one, and the way the levels progress from one to the next. If you're making a small game with only one level (such as a board game in computerized form) or a game with no story, you need not create this document. However, if the game has more than one level, or the player experiences a distinct sense of progress throughout the game, then you need such a document. You're not trying to record everything that can happen in the game, but rather a general outline of the player's experience from beginning to end. If the game's story branches based upon the player's actions, this is the place to document it and indicate what decisions cause the game to take one path rather than another. Here also you indicate how the player experiences the story: whether it's told via cut-scenes, mission briefings, dialog, or other narrative elements.
Bear in mind that the story or level progression is not the same as the game's structure. An entire story can take place in only one gameplay mode; likewise, a game can have many different gameplay modes but no story at all. Although the game
changes from mode to mode over time, and the story also progresses over time, the two are not necessarily related.
As a good rule of thumb, the game script should enable you to play the game. That is, it should specify the rules of play in enough detail that you could, in theory, play the game without the use of a computer—maybe as a (complicated) board game or tabletop role-playing game. This doesn't mean you should actually sit down and play it as such, but it should theoretically be possible to do so, based solely on the game script document. Sitting down and playing paper versions of game ideas is a very inexpensive way of getting valuable feedback on your game design. For designers without huge teams and equally huge budgets, paper-play testing is an invaluable tool.
The game script does not include the technical design, though it may include the target machine and minimum technical specifications. It should not address how to build or implement the game software. The technical design document, if there is one, is usually based on the game script and is written by the lead programmer or technical director for the game. Technical design is beyond the scope of this book. If you want to know more about technical design, read Game Architecture and Design by Rollings and Morris (Rollings and Morris, 2003).
