The Anatomy of a Design Document, Part 2: Documentation Guidelines for the Functional and Technical Specifications by Tim Ryan [Game Design, Production]
Did
you ever look at one of those huge design documents that barely fit
into a four-inch thick, three-ring binder? You assume that by its page
count that it must be good. Well, having read some of those design volumes
from cover to cover, I can tell you that size does not matter.
They are often so full of ambiguous andvague fluff that it was
difficult finding the pertinent information. So why does this happen?
Because the authors didn’t follow guidelines.
This article
is part two of a two part series that provides guidelines that when
followed will ensure that your design documents will be pertinent and
to the point. Unlike the authors of those prodigious design volumes,
I believe in breaking up the design document into the portions appropriate
to the various steps in the development process – from concept and proposal
to design and implementation. I covered the first two steps in part
one of the article, providing guidelines for the game concept and game
proposal. This part will provide guidelines for the two heaviest undertakings
– the functional specification and technical specification, as well
as some guidelines for the paper portion of level design.
Functional
vs Technical Specifications
Traditionally
in the game industry, there was only one spec. How technical it was
depended on who wrote it. Any documentation the programmers wrote afterwards
to really plan how they were going to implement it was informal and
often remained on white-boards or notepads. Yet in order to ensure the
project would proceed without hazard and on time and on budget, the
documentation needed to be more technical. Such detailed technical specifications
took time – time wasted if the goals and function of the product should
change or fail to gain approval.
This problem
was tackled as more and more seasoned programmers and managers of business
software development moved into games. They brought with them new standards
for documentation that helped ensure more accurate plans and less technical
problems. They introduced a division in the design document between
goals and method and between function and technique. They separated
the design document into the functional specification and technical
specification. This way, the clients, users or principal designers of
the product could review the functional specification and approve the
goals and functions of the proposed software – leaving the determination
and documentation of the methods and technique up to the technical staff
of programmers.
Therefore,
the technical staff waited until the functional specification was approved
and signed-off before starting on the technical specification. They
worked from the functional specification alone, ignoring any design
changes that occurred after sign-off unless the spec was updated and
a new schedule agreed to. Thus the division saved time for the programmers
and gave them more control of the schedule, while still ensuring they
had a complete plan for the methods and technique for implementation.
Many companies
still refer to the functional specification as the "design document"
and yet also produce a technical specification. The term "functional"
is a clearer term adapted by businesses and these guidelines to clarify
what is expected in the document. Here is a link to a formal definition:
In short,
what goes into the game and what it does is documented
in the functional specification. This is often written from the perspective
of the user. How it is implemented and how it performs
the function is documented in the technical specification. This is often
written from the system perspective. Both form important deliverable
milestones in the design stage of the game development process.
Printer-Friendly Version
