Gamasutra: The Art & Business of Making Gamesspacer
The Anatomy of a Design Document, Part 2: Documentation Guidelines for the Functional and Technical Specifications
View All     RSS
June 23, 2017
arrowPress Releases
June 23, 2017
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

The Anatomy of a Design Document, Part 2: Documentation Guidelines for the Functional and Technical Specifications

December 17, 1999 Article Start Previous Page 6 of 6

Documentation Milestones and the Development Schedule

Below is a list of the typical milestones in a schedule and where the documents described in this series serve as deliverable items. Following each milestone would be a review of that milestone, which would require approval to go on to the next. As the production schedule isn’t due until after the bulk of the documentation, then there shouldn’t be an impact on the schedule if time needs to be spent going back to the drawing board and creating specifications that everyone can agree with. It’s a recipe for disaster to race into production with iffy design documents just because of the urgency to meet an arbitrary ship date. In the end, it usually doesn’t save you any time, and in fact often leads to wasted efforts and significant delays.

Conceptual Phase

  • Document: Game Concept
  • Document: Game Proposal

Design Phase

  • Document: Functional Specification
  • Document: Technical Specification
  • Documents: Tool Specifications (if applicable)

Production Phase (sometimes called Implementation Phase)

  • Production Schedule
  • Technology and Art Demo
  • First Playable Level
  • Documents: Paper Level Designs (not always a deliverable)
  • Alpha - Functionally Complete

Testing Phase (Quality Assurance)

  • Beta - First Potential Code Release
  • Gold Master - Code Release

There could be more milestones, as it’s often necessary for publishers to have some means of determining and ensuring that progress is being made. Sometimes there are arbitrary monthly milestones for particular art, code, and design. The ones suggested here are the most common and have the greatest significance.

Dealing with Change

It can be a beautiful thing to witness a project run smoothly following these guidelines, but what typically happens is some change to the vision due to inspiration or market trends. It’s very easy to slip into design-on-the-fly mode to try to adapt to the new vision without impacting the schedule. Of course it inevitably does anyway, because design-on-the-fly has its dangers. In these cases, the only way to make sure this doesn’t happen is to be adamant about the guidelines and the procedures they promote. This is easier if it’s spelled out in the contract. Don’t make any changes to the game without it going through the documentation. A change to the functional specification potentially invalidates the technical specification and subsequent schedule. It’s certainly grounds for reassessing the schedule. It should be very clear to the principle designers who may want these changes that when they sign-off on the functional specification and deliver it, they do so with no expectations on being able to make changes. Then, if they really want the change, the impact can be lessened with a period of updating the documentation and a reassessment of the schedule. The threat of being stuck with what you got or being late is certainly compunction enough to put as much forethought as possible into the design and produce the best possible documentation. The guidelines presented in this series of articles should help you do just that.

For more details on how to deal with change, I encourage you to read my article "Controlling Chaos in the Development Process" published here.

This concludes part 2 of a 2 part series of articles on the anatomy of a design document.

Tim Ryan is a freelance game developer and software consultant. He has produced and designed computer games since 1992. His recent work can be seen in the PC game MechCommander: The First MechWarrior Game of Tactical Command. Please send your feedback, questions and business inquiries to

Article Start Previous Page 6 of 6

Related Jobs

Pixelberry Studios
Pixelberry Studios — MOUNTAIN VIEW, California, United States

Junior Game Writer
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan

Experienced Game Developer
Visual Concepts
Visual Concepts — Novato, California, United States

UBM Tech
UBM Tech — San Francisco, California, United States

General Manager, Game Developers Conference

Loading Comments

loader image