Chapter 19: The Design Document

Overview

It wasn t until Ultima IV: Quest of the Avatar , that Ultimas really started having compelling, purposeful stories, and it was the first game in the series to have a social commentary subtext. Not only did I want to build worlds that were large, epic, and meaningful, I also wanted to add a subtext to each game which might not necessarily be obvious in the actions your characters took in the game, but one which ultimately would give the game a more lasting meaning. So in Ultima IV you had to prove yourself to be a good person, one who could be an example to the people of Britannia. The game acted like a ˜Big Brother, requiring gamers to behave in a ˜heroic fashion in order to win the game. I thought that design was pretty cool, since gamers were accustomed to pretending to be the hero yet they would beat up all the townsfolk in order to become powerful enough to beat up the character who was supposed to be the big bad guy, even though he generally didn t do anything bad in the game.
” Richard Garriott

For some years , while I was still an aspiring professional designer, I wanted someone to tell me what the official format for a design document was. I knew that Hollywood screenplays had a very precise format, and I figured there must be something comparably rigorous for design documents. What sort of information is it supposed to include? How should it be laid out? What format should it use? Only recently, after numerous years as a professional, did I figure out the big secret, and it is one that I am happy to pass on to you in this book. Yes, here my years of experience in the gaming industry will impart on you this precious information.

There is no format! Everyone who writes a game design document just makes up their own format! Have you ever heard of anything so incredible? Whenever I have asked people what format I should be using for a particular document, they invariably answer, Well, you know, the standard format. No one really knows what this mythical standard format is, yet all refer to it. In the end, as long as it communicates the nature of the game effectively and in sufficient detail, whatever you hand over to the people who will review your document will be regarded as the standard format. There is definitely a certain type and quantity of information that belongs in a design document and which must be included for it to be useful, but there is no standardized form you must use in documenting that data.

Certainly within some companies, especially large ones, there may be an agreed-upon format that all of the in-house designers must use for their documents. Your design document will end up standing out if it diverges too much from other design documents in the industry. It makes sense for you to get your hands on every official design document you can, just as you might seek out practice exams before taking major standardized tests. Optimally, you will be able to obtain some documents that were used for games that were actually published. Or, at least, you will want to review documents written by designers who have completed and shipped games . This is hard to do, since gaming companies are fanatical about protecting their intellectual property and do not want to reveal how chaotic their internal development may be, but see what you can find. The Atomic Sam and The Suffering design documents included at the end of this book are good ones with which to start.

A design document is all about communicating a vision for a game, for mapping out as much information as possible about how that game will function, what players will experience, and how players will interact with the game-world. Organizing and structuring all of this information into appropriate sections is one of the key challenges in writing a good design document. Again, many companies may prefer their documents in a format different from what I describe here, and you should certainly organize your data in the form desired by the people for whom you are writing. If the development team is familiar with navigating design documents written in a specific format, you should mold your data to fit that format. Remember, the design document is not the end result of your efforts; the game is. As such, the format of the design document is relatively unimportant. As long as the format allows for the effective communication of the pertinent information, the design document will be a success.