The Writing Style

Before we delve into which sections your design document should contain and what areas it should cover, it is worth discussing the style you should employ when writing your document. The design document is meant to be a reference tool and, as such, you want to make it as easy for people to search and refer to as possible. A big part of this will be maintaining a good Table of Contents, as we will discuss in a moment. In writing the text of your document, you will want to break it up with lots of titles, headings, subheadings , and so forth. This will make it easier for readers to skim over the document and zoom in on the information they are seeking. Breaking your information into lists, either numbered or bulleted, wherever possible will further allow readers to easily realize what different attributes a given part of the game will need to include. Some find it more difficult to write in a bullet-point style, as it requires you to constantly shift indentations around and bold-face titles instead of just including all your ideas in a single narrative paragraph. You may find it easiest to write out your document first, and then go back and format it properly. That way you get all the content down, and when you go back to edit the document, you can simultaneously properly format it. Other designers actually prefer writing in a bullet-point style from the start to keep their ideas straight. Though writing in a bullet-point style may involve more hassle for you, the end result is a more useful document for the members of your team. Furthermore, the managers and executives will appreciate it, since it makes the document that much easier to skim.

Some designers use special writing tools for composing their document. These might be applications better suited to writing text with lots of headings, subheadings, bulleted lists, and so forth. These various applications may allow for the autoformatting and indenting of text, which could save you a lot of the time you would spend in a regular word processor dragging around indentation markers and tab stops. That said, I have never used such a tool, nor have I ever worked with someone who did. The primary problem with these tools is that once your document is done, you will need to pass it around electronically for everyone to read. Chances are slim everyone will have this unique formatting tool. Instead they will have a regular word processor. The document will be read by everyone from the other members of your development team to the people in management to the executives at your publisher. You cannot expect all of these people to have installed whatever eclectic design document authoring tool you have chosen . If the tool you use provides an exporter to a standard word processor file format such as Rich Text Format (.rtf), that will usually solve this problem, but make sure the exporter actually exports a document that matches the one you have composed . Still, I have always been quite content using standard word processors for my own needs, and have not felt the need for a more capable tool.

Though there is a great temptation to do whatever is necessary to bulk up your document in order to make it seem more thorough and complete, you want to avoid repeating information as much as possible. This is challenging as you talk about an element of gameplay that directly relies on another system you discussed ten pages back. Instead of redescribing the system, refer your reader to the system s original definition. This is important since, as you find yourself updating the document over the course of the project s development, you will need to change data in only one place instead of several. Often, if the same gameplay mechanism is described in detail in more than one place, when it comes time to make a change, only one of the descriptions will get updated. This leaves the other description out of date, thus resulting in an internally inconsistent document. Nothing is more frustrating to the reader than to find contradictory information in the design document. Inconsistent information in a specification can also throw up a red flag for producers , who will begin to question your competency to develop a game when you cannot seem to keep your facts straight.

Many people like to read design documents on their computer, as it allows them to search for words and navigate the document more easily than with a large heap of paper on their desk. For these people, it makes sense to include hyperlinks wherever appropriate. Most modern word processors make it easy to create links from one part of your document to another, allowing the reader to quickly navigate to another relevant section. This can be quite helpful as you try to avoid repeating any more of your design than is absolutely necessary. Instead of repeating, include a hyperlink to the pertinent location so that the reader can jump there if she needs to remember how a specific system functions. AWiki hypertext system can be great for allowing you to easily link from one part of a document to another, or, more often, to break your big document into smaller chunks that can all be interlinked easily. Wiki also allows you to easily link to other content that does not belong in the design document, such as the technical design document for a given feature or the art bible that shows what a particular character looks like.

As you write your document, you want to write as well as you possibly can, but keep in mind that the design document is supposed to be a reference document for the creation of an entertaining game, not an entertaining document in and of itself. You want your writing to communicate the information necessary in as concise and succinct a manner possible. Do not spend a lot of time worrying about making the document stimulating reading. No one is looking for excitement when reading the bulk of a design document; they are looking for information. I usually try to make the Introduction and Story Overview the most readable sections of the document, where someone could actually sit down and read through those sections and be interested while doing so. But for the rest of the document, you will be successful if you simply manage to include all of the information necessary. Spending a lot of time dressing it up with fancy verbiage will do nothing to improve your game. Similarly, though you should try to write as correctly as possible, do not spend too much time worrying about editing the document for grammatical mistakes. If the members of your team ” your document s audience ” are able to read it and get the information they need, they will be happy. They really will not care if you used a gerund correctly or not. That said, if your document is so dry or badly written that no one can stand reading it, people will be less likely to turn to it for the information they need. Furthermore, if you are writing your design document as a really large pitch document that you hope will convince people to fund your project, you may need to be a little more refined and sales-oriented with your writing, while still keeping the document useful and relevant for the development team.

As you write your document, it will be awfully tempting to compare elements of your design to other games , certainly ones the readers are likely to have played . Though in Chapter 5 I discouraged you from using such comparisons in your focus, in the design document comparisons can actually be useful, but with a caveat: you must fully explain your system, even if it is just like the mechanic found in Super Mario 64 . A comparison to a popular game can provide the reader with a starting point to understanding a complex game system you are describing. If she can remember that game, she will instantly have some idea of what you are talking about. Of course, to prevent any confusion, you must still include a thorough description of that aspect of your design. Comparisons are rarely useful enough to replace a thorough explanation of how a system is supposed to work. Therefore, do not rely on a comparison as a crutch to save you the trouble of documenting some gameplay. Nonetheless, having started with the comparison, your readers will have a better chance of understanding exactly what you are driving at when you go on to fully describe and document the system.

Though comparisons to existing games, such as the oft-cited Super Mario 64 , may be appropriate in the design document, the designer should be careful to fully explain what she means by the comparison.