The Design Document is the designer’s entire vision spelled out in detail, which includes all of the storyline, character dialog, world maps, city views, and room specifications with sample wallpaper, artwork, and rug designs, audio content for background or ambient sounds, sound effects and character dialog (with accents and speech patterns), programming, and AI considerations. This document is often called the “Design Bible,” since it is the document written by the designer for the entire team to follow, including the programmers (game and engine, technical programmers), the artists (both scenery and character artists), audio specialists (composer, special effects, background sound engineers, ADR and Foley specialists), and game testers. The concept is “if something exists in the game, it must appear and be described in the Design Document.” It is the common point of reference that the entire team understands and follows to create the designer’s vision. It is from this document that programmers (usually the lead programmer or technical director) and the artist (usually the head artist) refer to when documenting the technical spec (or specification), which explains in detail the in-depth technical issues of all the game code, the engine code, and the artwork and audio files (describing the file’s name, size, and description).
In late May 2001 I met with Phantom EFX in Iowa to discuss a follow-up game to Reel Deal Slots. My previous “casino” games included products from Villa Crespo Software, such as video poker (Stanford Wong Video Poker and Dr. Wongs Jacks+), black jack (Dr. Thorp’s Black Jack), craps, roulette, and poker (Amarillo Slim’s Dealer’s Choice, 7 Card Stud, and Ruckus Poker). The meeting determined that the product was to be a poker game, and some basic game design issues were discussed and written down.
In June 2001 the project was underway as design, programming, and artwork progressed concurrently. The distributors wanted a Christmas product, and that meant a mid- to late-August deadline (a gold master reproduced and boxed by the end of August). That was a 12-week project life cycle. My friends in the industry laughed when I chatted with them about the project, claiming that the time needed to complete a game of this size was six to twelve months.
This case is not (I repeat not) the usual project life cycle. Several important issues had to be done to meet these critical deadlines, such as numerous daily meetings in the beginning to flesh out the game design, total control of the project by the programmer (me), and working six to seven days a week, ten to sixteen hours a day. Needless to say, the official design document was never written. The design discussed daily was written down, and artwork submitted to programming had to be documented (filename, screen positions, file format).
The project shipped on time with a few items dropped from the design document and the Internet component placed in the first patch (downloadable update). In the design document of Reel Deal Poker Challenge in this chapter, I note the design originally planned, and in brackets (“[this was dropped from the game because…]”) I discuss issues and reasons for changes, later implementations, or dropping the issue from the game.
I have often read articles and books on game design that discuss game design documents in theory. In this chapter I show you in detail what goes into a game design document. This document is provided as a tutorial so you can start with this template and create your own, much better design documents for your visions—the games of the future.