IntroA lot of people don't design their games first in any written form, they keep it all in their head or just make the game up as they go along. That's fine, but some games are too large for that, and some games take so long that you begin to forget some of the stuff in your head. If you have a team, a design document helps everyone as a reference source.
Some people feel that writing things down is restrictive, but I don't think so myself, I find it makes me more creative to have all the ideas written down in front of me, rather than trying to come up with things as I need them. And it's not as if you design the game once and then make it without editing the design at all, the design usually changes as the game goes through development.
MediaThe format doesn't really matter, but I find a Wiki to be the most useful, because it can be edited quite easily as needed, and because it can be shared with others on the team online.
The best two I've come across are
MediaWiki (which Wikipedia uses) and
DocuWiki. DocuWiki has the advantage that it doesn't require a MySQL database, it runs entirely on text files, so it can be run on free servers without any MySQL benefits. There are also wiki's which can be set up on your hard drive, but I find them less useful because I usually work with others online on games.
FormatI'd recommend using the design document primarily for "lists" -- the type of list varies with the type of game, but often it includes a list of enemies, a list of playable characters, a list of areas or levels, a list of the music the game will need, and so on. Typically my design documents are around 80% lists, and around 20% description of the game in general.
Each item in a list, for example an enemy list, wouldn't just list the names and that's it, it'd also describe it to some degree: what the enemy does, how it moves, strategies the player might use against it, places where the enemy appears, etc., typically a paragraph or two is enough.
It's also important to think about the overall idea of the game, what it's trying to accomplish as a whole, and include a few sections on that.
LengthThe length of the design document varies by the complexity of the game; I've written design documents which were only a few pages long, and others which were hundreds of pages. Try to include enough information about something that when you get to coding something or drawing something you have a good idea about what you're trying to do, but not so detailed as to include too much unnecessary information.
Also, it's a good idea to make the game and the design document at about the same time: don't spend a few months making the design document and then a few months making the game, because that just leads to laziness, it's better to start the game prototype first, work on it every day, and occasionally add to the design document during the process of creation. I find that it's easy to fall into the trap of all design no actual work, so try to avoid that.
ExamplesHere's the
design document of the game I'm working on now as an example; it's incomplete and contains spoilers so if you do check it out skip the characters and story section. Although the game of course will change in the future, so don't take the design there to be a good representation of how the game will ultimately end up. But reading that can give you a good idea of the format I use and what a design doc looks like.
Here are two good examples of design documents I've come across:
-
Planescape Torment's design document-
Metal Gear Solid 2's design documentI'm sure there are more (feel free to add them) but those two are the most interesting I've read so far.
UseThe main use of design documents is as a primer for working on parts of your game. For instance, when working on a new enemy, you can go and look at what you wanted that enemy to do, even if you wrote that part 20 months ago, and then have an idea about how to proceed, rather than having no starting point. It's not meant to be something restrictive, don't feel as if you have to translate the document directly, it should work more the way an outline to a novel works.
Also, don't use it as a substitute for a to-do list: you'd still probably need a separate to-do list for all the tasks you want to do next for the game, to list bugs you need to fix, and so on.
Another great use of a design document is to share it with others on the team, get their input, and then change parts of it after discussing the game, to give the team a shared vision of what they want the game to be like. That's more difficult if there's nothing written down, because often team members have completely different ideas of what the game will be like if they don't have a shared reference.
Most likely the design document will be more ambitious than the game itself, if you want to get the game done at all. It's easy to list 100 enemies and all the ideas you have for each, but it's harder to code them all in, so generally parts of the design document probably won't make it into the game. That's true of the MGS2 and Torment documents above, and it's probably true of most design documents, so don't be afraid to "over-design" with the intention of only including the best parts of the design in the actual game. I.e. don't be afraid to write up descriptions for 100 enemies, and then just use the 40 or 20 best ideas in the game. Don't feel that a game is only complete if it contains everything in the design document, it can be complete even if it only includes half of the stuff in there.
Community
