Game Development Reference
In-Depth Information
about the projects upon which they lavish their money. If a large part of the
development budget is earmarked for technical innovation, it is important
that the publisher understands what that money will be spent on and what
will be delivered at the end of development.
The technical design review (TDR) is a collection of documents that
outline all the technology - hardware and software - that will go into
making the game the best ever. It should cover, where appropriate, the player
interface, the use of simulated physics, the audio system specifications,
graphics rendering techniques, the use and incorporation of middleware,
outlines of the various target platform differences and how they will be
resolved and many other details specific to the project.
Because a lot of time, thought and expertise goes into developing the ideas
and systems involved, the documentation can run into hundreds of pages -
something that will take the technical lead a great deal of time to pull
together. A writer with the right background and understanding will be able
to help take much of this burden, using notes, conversations and reference to
pull it together.
The TDR serves two purposes. Internally, it serves as a description of all
the technical tasks that will be required during the development of the game
and gives the technical team, and others, the vision of what the game should
deliver. Externally, when combined with the other game documents, it is a
sales brochure designed to convince a publisher to invest in the project.
To have a chance of persuading the publisher that the technical team is
competent, the TDR must be written in clearly, explaining every aspect of
the game's technical development. If there is even the slightest chance that an
explanation or detail may be misunderstood, then it must be resolved so there
is no ambiguity.
It is very easy to fall into the trap of assuming that the reader of the TDR
will have the same specific knowledge as the technical team on the project.
This might well be the case, but with the rapidity of software and hardware
advances it is always worth explaining the concepts behind the technology,
perhaps as a side bar, so that the publisher understands that the tech team
knows what it is doing.This is particularly important where the technology
is pushing at the boundaries in some way or that the software being
developed is proprietary.
Often the technical development is not just about creating logic engines,
rendering engines and the like, but also about developing the tools that
enable the implementation team to put the game together through the use
