Design Docs, How to...

#1 How coincidental - I just finished off my design document last night :)

A design document is really just a formal detailed report on all of the design aspects of your game - including game philosophy, gameplay, setting, characters, rendering techniques, sounds, music, multiplayer, possible expansions, etc, etc. If you can come up with a clear format that covers all those points and more, then go with it :)

If you want a template to look at or work from, a popular one is Chris Taylor's Design Document Template (a zipped M$ Word file). The template's worth a look even if you don't plan on following it - chances are he's included something there that you've forgotten about.

Good luck :)

#2 It's just like making an outline. In fact, that's what it should be.

Just break up your game into the major parts, such as:

*Purpose
*Plot
*Combat
*Characters
*Scoring
*Controls

And so on. If you have more than one example for some of those, create subcategories for them. It's a good idea to split apart these into pages as often as possible, except when dealing with a lot of very short ones. In such a case, using the good ol' #pageplacement will do the job, if you're working in html.

#3 Nice work on the design doc

#4 I like to start by first writing a design treatment. A Design Treatment is a short document, no more than 4-5 pages that helps clear up ideas in your head. Its purpose is to find gaps in your thinking.

Once that is done, it's when the real work starts.

'Title Page
'Table of Contents
'Brief Overview of the game
'Game Philosophy
'Target Audience
'System Requirements
'Game Installation
'General Features
'Style
'~World
'~Characters
'~Main Characters
'~(any other features that you feel need a section)
'~Summary
'Look & Feel
'~Main Character
'~The World
'~Bad Guys
'~Good Guys
'~(any other features that you feel need a section)
'~Summary
'Aim
'Life & Death
'~Gaining & Losing Health
'~Death
'Story
'How it is typically played. (step by step)
'The Game Engine
'~(stuff on features that it will need)
'Appendixes
'Credits

Damn there is more but I've run out of steam (this is all I can think of right now), this should be an ok structure. This type of game design structure is less structured than the ctaylord.doc in the above link. Where as it is much more structured and is probably better if you want to find something out without reading it. If you want a document that is more flowing to read, maybe you should try going for a more organic style of writing.

-Skye

#5 I found that there a two keys to writing a design document. First: Never be done. Once you think you have written about a piece of your game, go into more detail. When you think you really have it nailed, go back to it. Genius is in the details.

Second: Justify everything. Just because it is dynamic or graphically stunning is not enough. Make sure your customer's belief in the system is complete.

Once you've covered every detail of your world like this, your format is really tertiary.

#6 Well, I am going to dissent from a few people.

First off, I think thay justifying things is a great idea but I'm not sure if it has a place in the actual design document. It is better off IMO to make that separate as an appendix or some related notes. I think justifying things is very important, but mixing that with the design text can dissuade people from actually reading the design, and make it harder for people to find the info they need. One of the annoying real-world problems you have to face is that people aren't going to read a 100 page document with a fine-toothed comb. You can be glib and say "find better workers" but that doesn't satisactorily address the issue.

Another point that I know some if not most people are going to disagree with is that at some point details become extraneous and including them does more harm than good. The more fine the details are the more likely they are going to change.

I've had this discussion with a few people on IRC, but let me repeat myself a bit. Compare these two following:

1: A zergling has weak defense and can take only small punishment. However it is fast and has a high rate of attack, in large groups they can often overwhelm enemies. Weak against splash damage.

2: Zergling has HP 100 and speed 200. Attack rate 1.3/s.

These two could very well say the same thing. However I would argue that the first *directly* addresses the Zergling, while the second indirectly addresses the Zergling, *even though* the second is more specific!

That is because in the course of a game the numbers could easily change. Maybe when I started writing the doc I thought an attack rate of 1.3 would be fast and 100 hp would be low. But then after tweaking it turned out that 1.3 really wasn't all that fast, and 100 was way *too* low.

The first snippet is immune to those sorts of changes. It describes the feel of the game and the role of the zergling. Later the numbers can be best chosen to create that feel in the game. The numbers are the implementation for the concept, not vice-versa. I could care less if attack speed is 1.3/s or 13/s, as long as it is "fast." My conception of Zergling is based on small fast critter, not a set of numbers that only have meaning in rapidly changing context.

I see a lot of people get bogged down in details that are going to change underneath them. A good example is people making giant lists of items, powering-up charts in RPGs, etc. If you truly have nothing else to describe that might be worth doing, but only as a last step. Is 30,000 xp too much to get from level 31 to level 32? You'd be lying if you said you knew.

It would be instructive to take Master of Orion 3 as an example of what I am saying. MOO3 was based on a monolithic design doc, a lot of which changed or was thrown out later. It was so complicated that they didn't get a chance to really test out the game until a few months before the ship date - and it turned out it wasn't very fun and was delayed another few quaters. Often times prototyping and testing are the only ways to arrive at meaningful numerical values, interesting map designs, etc.

A lot of projects have a big problem where different team members have a different conception of what the game is really supposed to be. However I don't think this is due to lack of details, but rather due to lack of big picture and gameplay descriptions. Knowing that the "Holy Sword of Light" does +34 against Werewolves isn't going to help people get on the same page. Better to write a little story about the adventures of a typical gamer.

"I logged on, then shouted for a teleport for 20 minutes. Then I camped a spot for 40 minutes, then killed the swamp rat and checked it for loot...then stood around waiting for it to respawn again..."

That sort of thing. People have to understand the subjective experience for the objective things like numbers to have any meaning.

That's my 10 dollars and change.

#7 On an unrelated note, Bob the "organism" sketches on your project webpage are awesome.

#8 Excellent feedback James. Well put. I think we both got to the same point but I didn't explain it very well. Those details do continue to change as the document grows, that's what I meant when I said go back to it again and again. And secondly, the justifications shouldn't be included for each thing, but the reasoning behind those components should be included in each aspect of the game.

I mean, don't just have a meteor shower on the planet because your artist (He's going to really appreciate your comment! Thanks!) can make one look cool. For instance, in Newhaven, a zirconium alloy piece of armor refracts laser damage better than titanium, which is better to defend melee attacks. We used those because of the characteristics of those materials. (zirconium is highly reflective and titanium is very strong) But we didn't include this justification in the document, just our thought process to get there.

I typed it late at night and obviously could have done a much better job.