Design Document
Last Updated March 9th, 2004
A term that's often thrown about. But what should a design document actually look like?
This page will serve as a preliminary guide for those individuals who would like to know the basics of creating an effective design document.
Header or Title (May already be provided if on Wiki)
All work Copyright © 200x by Team Name or Personal Name
(Current Version. i.e. "Version 1.9")
(Last Date Updated)
Introduction
This section is a short, one to two paragraph abstract in which the basic principles, purpose, and tasks of the mod are to be laid out. The purpose of this section is not to deliver detailed information, but instead to sell people on your mod and cover only its essence in the most distillled form.
- Example: The purpose of this mod is to create a Total Conversion for Unreal Tournament 2004 in the form of a Vietnam War mod with two team distinct teams, the Democratic and Communist factions, as there is a distinct lack of representation for this combat theater within the gaming world. This mod will be focused on realism and will include a selection of ten historically accurate weapons, as well as eight different vehicles encompassing both land and air transportation. Its design will be heavily objective based, with limited points being awarded for kills and signifigant gains being rewarded for completing tasks central to the map. As an added feature, it will feature an original score composed by some of the leading members of the game music remixing community.
General Structure
This is a section where you lay out the important features of the game in each of their respective subsections. By features I mean such things as the general play mechanics or modifications for those mods which have a less widespread impact. You can cover things such as how a general round of play is meant to progress, the particular features of the Unreal Engine which your mod will affect, or similar widespread topics. For large things like Total Conversions you will probably want to break this into subsections to cover them completely, and you may want to include flowcharts for particularly complex concepts.
Game Environment
A complete description of the world in which your mod operates if it is pertinent. Cover the story setup, the major players, the reasons for whatever conflict is happening, and any interesting pieces of info which might make it into the mod. Obviously not necessary for mods without a substantial story behind them.
- Example: The setting for this mod is the Korean War, and more specifically within the central region of Korea along the Naktong region during the late summer and winter of 1950 when the fighting was at some of its fiercest. It will include four maps covering the important battle locations of the Naktong Bulge, the Retaking of Seoul Korea, the Pusan Perimeter, and the Chosin Reservoir.
Special Features
For many mods this may be one of the only sections. It will basically cover any features which will be unique to this mod or additions to game operation which this mod may make. This can be things like cheat protection, self autonomous bots, troop formations, or pretty much anything else you can imagine. If there are multiple new features, try to break them up into modular segments which can be developed independently.
Snazzy New Feature Name 1
(Add more as needed)
Description of your feature, what it does or its purpose, your basic plan for implementing it if you have one, and how it will be integrated into the play experience. This is basically a more in depth description for anything in the above summary that doesn't fall into one of the more specific subtopics below.
Characters/Classes
This section will cover the various roles which the user of your mod might take during its operation. In the case of war and other such mods these may be things like positions within an army or command roles. For single player or roleplaying type mods, these might instead be classes or sets of abilities which your character can adopt. There are many more possiblities as well.
- Class 1 - Description and details about the abilities of the first class and its overall purpose within the mod.
- Class 2 - Description and details about the abilities of the second class and its overall purpose within the mod.
- Etc...
Weapons
This section will cover all of the new weapons which you are planning to add in or change if they apply.
- Weapon 1 - Description and details about the ranges, firing method, purpose, damage, and pictures if appropriate.
- Weapon 2 - Description and details about the ranges, firing method, purpose, damage, and pictures if appropriate.
- Etc...
Vehicles
This section will cover all of the new vehicles which you are planning to add in or change if they apply.
- Vehicle 1 - Description and details about the ranges, firing method, armaments, purpose, and pictures if appropriate.
- Vehicle 2 - Description and details about the ranges, firing method, armaments, purpose, and pictures if appropriate.
- Etc...
Music and Sound
This section will cover any new sound or music that you are planning to include with this mod. Try to be as specific as possible and include links to samples of representative works if appropriate or available.
- Music or Sound Set 1 - General concept of the music or sounds that you are aiming to create.
- Example: A series of burst patterns that realistically emulate the sound of an assault rifle being fired at close range.
- Music or Sound Set 2 - General concept of the music or sounds that you are aiming to create.
- Example: A set of four ambient music pieces which set the tense and fretful tone of jungle warfare. Possible influences include things like the score of Hamburger Hill, Apocalypse Now, Full Metal Jacket, and Platoon.
- Etc...
Mapping Tasks and Game World
This section will cover any new map assets that you are planning to include with this mod.
- Map 1 - General description of the first map you wish to include. Try to be as detailed as possible and include pictures of representative regions or sketches of the concepts if possible.
- Map 2 - General description of the second map you wish to include. Try to be as detailed as possible and include pictures of representative regions or sketches of the concepts if possible.
- Etc...
Work Plan
A step by step guide for determining what objectives lie on the path to completion of the mod and the timelines for when they should be completed. This section is useful as it will allow you or your team to gage the progress of the mod, target problem areas which are slowing it down, and provide a sense of completion as each task is marked off.
- Example:
- Finish this design document
- Subtask one - Mapping ("Total section 1 due date")
- Create Seoul Korea map. ("Due date")
- Create Hamburger Hill map. ("Due date")
- Ect... ("More dates")
- Subtask two - Weapons ("Total section 2 due date")
- Create Flamethrower Model. ("Due date")
- Create AK47 Model. ("Due Date")
- Ect...
- Further Subtasks (Coding, Vehicles, Music, Features, ect...)
Appendix
Include things like technical terms that may not be immediately apparent, references to known works, and "thank you"'s to signifigant contributors.
Example Design Documents on the Wiki
How Not to Write a Design Document
Araes: Assume you mean [this] one, as it's quite abysmal. (03/08/04)
Araes: Alright, second update is a big one, as I have basically included my first draft of what I think a design document should look like. Further input is of course appreciated and clarifications of points. (03/09/04)
EntropicLqd: Apart from the due date on the task list its a pretty decent document. One thing I would say is that all Snazzy Features should be listed - even if there's no obvious way of coding them up.
Araes: Done. Implied that your imagination is the limit of what you can write instead. However, haven't changed the due dates yet as I tend to find that they are a valuable tool in my own work. Even something horribly rough, as they give people at least a target to shoot for.
EntropicLqd: Due-dates are a pretty personal thing tbh. I don't like working with them because it's like being at work again. And so much of my time gets used by things outside of my control I'm rarely even close to a due date.
RegularX: I'm not even sure I would ever combine a design doc and a schedule. The design doc seems like it should be purely a description of what goes into the game design. Apart from that, I've sometimes managed an asset list which describes the actual physical files which needs to be created to achieve what's in the design doc, and then a schedule for those assets. Course, my last mod team scattered to the four winds, so now I largely write memos to myself 
