In the preceding pages, I have presented the format I like to use for game design documents. Let me repeat that it is by no means the industry standard format. Many great design documents have used formats wildly different from mine, both in terms of structure and in terms of how much detail they provided. But if you present a document structured as I have explained, you will not be laughed at or thought a fool. As I have stated previously, what is most important is that you communicate your vision for the game to the people reading your document. You are free to present your design information in whatever form makes the most sense to you while providing for maximum clarity and utility for your data.
Part of the reason why the design document format can vary so much from project to project is that games are not yet (nor do I think they ever will be) a standardized art form, as plays, movies, or symphonies are. Just as a writer s style guide for a cookbook and a romance novel would be extremely different, one can hardly expect the design document for a first-person shooter such as Halo to be of the same form as one for a strategy game like Rise of Nations . What the games accomplish and the experiences they provide are too radically different from each other, and hence their design documents must be different as well. Sure, within gaming there are certain genres or types of gameplay, and the design document format for a given genre , such as a first-person shooter, can be standardized. But even then, as the form of the shooter changes, as it implements new gameplay styles and mechanics, the structure of the document will need to adapt to these changes in order to communicate them effectively.