| | 1 | = Final Design Document = |
| | 2 | [[TracNav(TracNav/TOCCP)]] |
| | 3 | |
| | 4 | Discussions on the preliminary design may lead you to drop some features, scale back others, and introduce new ones. Once everyone agrees on the functionality the game is going to implement, the design document is ready to go Final. |
| | 5 | |
| | 6 | A good final design document goes into as much detail as possible. If you are in doubt as to whether a certain bit of information should be in there, then it should. EVERYTHING that you can put in is relevant, because it forces you to think your design through before production begins, and nothing helps smooth a two-year development cycle as much as a design which leaves no (or few) crucial decisions to make midway. |
| | 7 | |
| | 8 | There can be a certain amount of overlap between the contents of a final design and those of a product specification. If the designer happens to be a senior programmer, for example, he should write down the algorithms for some of the unique software features he wants in the game; after all, he thought of them, and no one else knows what behaviour he wants the software to exhibit more than he does. Something that definitely should be in the FDD (although I have rarely seen it) is a list of priorities: what features the game can not live without, what would be really great to have, and what will be added at the last minute if there is time to spare (or delayed until the sequel if there is not). It is a fact of life that some productions go wrong; the game industry is not very strong on software engineering techniques, and even highly organized studios can get in trouble if key people leave at the wrong time. A lot of trouble can be avoided if you know in advance what should be cut if you risk not being able to deliver in time for Christmas; besides, such "risky" stuff can be scheduled for later, so that if it needs to be taken out, it won't have wasted your team's time and effort. |
| | 9 | |
| | 10 | By the time the Final design document is deposed, the lead designer can have spent 150 to 400 hours on his product, or even more. Final design documents can range in size between 75 pages (for simple action games, when most of the level design is written down in a Graphic Bible or handled informally) and 200 pages or more. My personal record is around 160. Interactive movies have screenplays that occupy 300-500 pages by themselves! |
| | 11 | |
| | 12 | All the Final design documents I have ever written are either subject to non-disclosure agreements from former employers and clients, or lost in the dawn of time. Therefore, I can not post any here. However, just to give you an idea of how much detail you should put in, here is a partial table of contents for a typical play-by-mail multi-player sports simulations: |
| | 13 | |
| | 14 | * The length and timing of seasons (how many per year, when do new leagues open their doors, etc.) |
| | 15 | * The hierarchy of leagues necessary to support thousands of teams, with promotions/demotions between leagues of different levels for strong/weak teams. |
| | 16 | * The procedure to create a new team: standard and custom team colors, creation of new players, stadium building, expansion draft. |
| | 17 | * The database of fantasy player attributes and statistics: over 40 attributes covering talent (current and potential), health, luck and personality; a list of every statistic which will be compiled by the system and of the record books which will be maintained. |
| | 18 | * Scouting process: what is visible to the players (and how clearly), and what remains hidden in the database. |
| | 19 | * The reports which will be sent to players: contents, layouts, frequency. |
| | 20 | * Detailed description of the data-entry application's interface, including a list of menus and dialog boxes. |
| | 21 | * Franchise management: hiring and firing players, recruiting minor leaguers, training, trades and trade adjudication mechanism (to prevent one-sided trades from boosting a team unduly), scouting, ticket prices, salary cap, contract offers, how to generate revenue from TV and from press releases, etc. |
| | 22 | * Game management options: what orders the player will be able to send, and how mistakes in player commands will be handled. |
| | 23 | * The manual which will be sent to players at registration.. |
| | 24 | * The game's simulator algorithms, in great detail (including the effects of weather, fatigue, injuries, etc.) |
| | 25 | * Random events: accidents, "real-life" problems influencing fantasy player performance, grudges, etc. |
| | 26 | * Game Definition Language: allows to store games in compact form and to enerate play-by-play text (or audio) files automatically. |
| | 27 | * A discussion of game pricing, marketing strategy, and prizes. |
