Appendix A: Sample Design Document: Atomic Sam

Overview

The following design document is for a simple console character-action game called Atomic Sam . The game itself is far from revolutionary and, from a design standpoint, part of its appeal is its simple nature. It is part of a project I was previously involved with that was never developed into a finished game. Despite this, the reader can consider the document to be authentic , since it is written in the exact style and format I have used in design documents for projects that have made it all the way through production.

As a result of its simplicity, the design document for Atomic Sam is not very large. I have written documents five times the length of this one for other projects, and even those documents were not as big as others in the industry. Parts of this document were deliberately kept short, since it was not intended to be a complete design document, but rather to give its reader an idea of what Atomic Sam would be without fully detailing every part of the game. In particular, certain sections have deliberately been kept short. For instance, the listing of enemy robots is much smaller than it would be if the document actually described all of the enemies in the game. Similarly, a full version of this design document would include descriptions of more projectiles for Sam to throw, more devices and contraptions for him to manipulate, and more of the characters he would meet in the game-world. The game might even be expanded to include more areas than just the five described here.

In fact, more detail could be used throughout the document. The way this document is written assumes that the author is going to be involved throughout the development process, guiding the design in the correct direction. If this document were for a project that the author did not expect to be actively working on, it would make sense to add more detail throughout in order to be completely clear about the direction the project should take.

For example, the section about level design could be significantly more detailed. Indeed, readers may find it interesting to compare the level of detail in this document with The Suffering design document included in Appendix B, as that document is significantly more detailed in its level flow. However, if one has a team of level designers who understand the gameplay and can be trusted with the responsibilities of designing a fun level, the descriptions contained in the Atomic Sam document could be a sufficient starting point for level design. From this document, the level designers are given a great deal of freedom in terms of how to build their levels, a system that works well if the level designers are up to the challenge. Certainly, if you will be designing many of the levels yourself, you do not need to plan everything out in minute detail in advance. Many successful games have been made this way, including a number of the projects I have worked on. For instance, Centipede 3D had only a general notion of the AI, mushroom types, and power-ups designed before the level construction process began , and it was a system that ended up working quite well.

Of course, before writing a design document, the designer should have a good idea of the focus of the gameplay, as I have discussed elsewhere in this book. Here, for example, is the focus statement I had in mind when I started working on the design document for Atomic Sam .

Atomic Sam: Focus

Atomic Sam is a non-violent, fast-paced action game whose gameplay centers on defeating various villainous robots in creative and inventive ways, using a variety of projectiles and environmental devices. The story is one of a young boy separated from his parents for the first time who learns about the world through mentors, friends , and new experiences. Atomic Sam takes place in a unique retro-future with whimsical, nonsensical devices providing a unique backdrop to the unfolding of the story and action.

Armed with the direction provided by the focus, the game design grew organically from there into the design you will read below. As I have stated before, there is no set-in-stone format for design documents. It is the designer s responsibility to present the design in as much detail as is necessary, in a manner that clearly communicates the design to all the members of the team.