Make a game design document for your game! In the make a game how-to we cover the steps and the game design document is one of the biggest. Here is some great information by Tim Ryan (used with permission). Here is the full article.
The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal
The purpose of design documentation is to express the vision for the game, describe the contents, and present a plan for implementation. A design document is a bible from which the producer preaches the goal, through which the designers champion their ideas, and from which the artists and programmers get their instructions and express their expertise. Unfortunately, design documents are sometimes ignored or fall short of their purpose, failing the producers, designers, artists, or programmers in one way or another. This article will help you make sure that your design document meets the needs of the project and the team. It presents guidelines for creating the various parts of a design document. These guidelines will also serve to instill procedures in your development project for ensuring the timely completion of a quality game.
The intended audience is persons charged with writing or reviewing design documentation who are not new to game development but may be writing documents for the first time or are looking to improve them.
Design documents come in stages that follow the steps in the development process. In this first of a two-part series of articles, I’ll describe the purpose of documentation and the benefits of guidelines and provide documentation guidelines for the first two steps in the process – writing a concept document and submitting a game proposal. In the next part, I’ll provide guidelines for the functional specification, technical specification and level designs.
The Purpose of Documentation
In broad terms, the purpose of documentation is to communicate the vision in sufficient detail to implement it. It removes the awkwardness of programmers, designers and artists coming to the producers and designers and asking what they should be doing. It keeps them from programming or animating in a box, with no knowledge of how or if their work is applicable or integrates with the work of others. Thus it reduces wasted efforts and confusion.
Documentation means different things to different members of the team. To a producer, it’s a bible from which he should preach. If the producer doesn’t bless the design documents or make his team read them, then they are next to worthless. To a designer they are a way of fleshing out the producer’s vision and providing specific details on how the game will function. The lead designer is the principle author of all the documentation with the exception of the technical specification, which is written by the senior programmer or technical director. To a programmer and artist, they are instructions for implementation; yet also a way to express their expertise in formalizing the design and list of art and coding tasks. Design documentation should be a team effort, because almost everyone on the team plays games and can make great contributions to the design.
Documentation does not remove the need for design meetings or electronic discussions. Getting people into a room or similarly getting everyone’s opinion on an idea or a plan before it’s fully documented is often a faster way of reaching a consensus on what’s right for the game. Design documents merely express the consensus, flesh out the ideas, and eliminate the vagueness. They themselves are discussion pieces. Though they strive to cement ideas and plans, they are not carved in stone. By commenting on them and editing them, people can exchange ideas more clearly.
Continue to the Full Article.
