Design Doc Rant

Anne Chilldon — 2007-08-06T15:35:05+00:00

Ok, so seeing as I'm still somewhat new to this community I have been putting off this rant for as long as I can, but after reading the forums for awhile, I think it is necessary. Before I go any further though, I think I should point out that this is not directed to anyone in specific but just a general rant.

It appears to me that a lot of people view the documentation process of making a game as just writing down all the game ideas and organizing them into categories. Being someone who loves and thrives off of this particular process, I view this somewhat as blasphemy, though I will admit that most have the basic sections down: overall story, levels, characters (NPCs & enemies), items and weapons. Yes, these categories are necessary and information must be placed in each of them but what kind of information seems to be what confused from one tutorial to the next. Those categories should be used by the designers to figure out everything. Whoever is in charge of documentation should constantly ask the questions: who, what, where, why and how? If any of those questions are not answered, the designers must go back and figure out a way to answer them. The best example of this I can think of is J.K. Rowling who, on several occasions, has stated that she has storage units filled with notes on every single character, building, animals, etc. in the Harry Potter series. This is what needs to be done with a game's documentation but on a smaller scale.

For each genre of game the documentation changes, if you are doing a puzzle game, you do not need as much documentation on characters as you would for an RPG. If you are trying to go for a game that emotionally involves the player you are going to need a lot more documentation for the back stories. You want to make the player see that you know a lot more than what you are letting on.

Documentation is used by everyone in your team so needs to be readable by everyone, and not everyone likes to read pages of back story to find out why someone has a scar on their right cheek. To make it easier to read, it is suggested to use the "newspaper technique." Highlight everything that really needs to be known in the first paragraph. In the following three paragraphs, give a slightly more detailed version of the information given in first paragraph. After that feel free to write a whole novel on something but always keep in mind that there is a possibility that no one but you will read it.

It doesn't stop there though! Each previous category should include the stats for each person/item in said category. The documentation also should include descriptions of how things look and/or sound, detailed enough to give concept artists and musicians. Said concept art should also make its way into the documentation. There also should be a place to hold algorithms, and in the case of games using combos, the sequence to create such combo. Specifications on the hardware that will be used to play the game, for PCs it is a good idea to the basic and optimal performance specs, and the audience you are trying to target with your game should also have their own very special spot.

Most importantly, the game document should grow with the game. Stats change through testing and should be changed in the document. Many things change while making a game and those changes should be reflected in the document. It is a living thing and should be treated with respect instead of just being thrown to the side once you start coding.

Many people in the industry consider those of us that like to do documentation a little odd, I have been called a sadist on more than one occasion. Yes, it can be a tedious job but it is an extremely rewarding job also. Even though I haven't even started scratching the surface of what goes into a document, hopefully this will help those that are asking questions about how to document and make others realize that it isn't just compiling notes into separate categories.

Blog for Anne Chilldon at GarageGames.com

Design Doc Rant