TDD Template

Translation: Technical Design Document Template

This is the Game Design Document’s nerdy cousin. I’ve never had to write one of these thank goodness, this is usually written and maintained by the lead programmer. Fortunately programmers have really good habits about documenting what they’re doing, so this doc tends to fare better than the GDD.

Why do publishers want all this info? This is all part of risk mitigation. The grim reality is that if it turns out the developers have dropped the ball and aren’t going to be able to finish the game then the publisher hopes that they can take the completed assets and code along with the TDD and GDD and hand it to some Ukranian developer to finish.

Of course I don’t know of any case in the history of the world where this has actually resulted in a shipped game (alright, I’m sure a game has shipped after this happening, but it probably got terrible reviews and poor sales).

Again, the following outline is taken out of the Spark/Activision contract which entered the public domain thanks to a kind LA judge.


A TDD is a document that must set up the parameters, identify the potential hurdles, and establish the strategies, choices and options for the development and production of the Product. The TDD shall include, but not be limited to, the following information:

1   Product overview from a technical standpoint

1.1   a description of the finished product
1.2   minimum and ideal requirements of the target system and the manner in which the Product will perform in each instance under each such requirements;
1.3   general technical design strategy;
1.4   potentially difficult technical issues or techniques anticipated in the production of the Product;
1.5   asset conversion processes;
1.6   art, interface and marketing concerns; and
1.7   description of all tests performed during the development process that determines the technical viability of the Product.

2   Code design

2.1 List and description of major/critical software routines and algorithms used in the development and production of the Product. (This includes any tools/utilities used in or developed specifically for the Product).
2.2   Description of significant data structures to be employed in the Product (modules organization, etc.).
2.3   Indication of what parts of computer code created for the Product will be changed in order to accommodate a new platform.
2.4   Memory map of both the hard drive usage and the RAM memory usage.
2.5   Description of memory management codes.
2.6   Delivery of a medium map.

3   List of all proposed participants on the Product

3.1 This section should include a brief biography of each person engaged by Developer in the production of the Product together with a list of the specific responsibilities/tasks attached to each of them.

4   Description of the hardware/software environment in which the Product will be developed

4.1 This section should describe in detail the development system hardware configuration (which should include the language/compiler. to be used). It also should provide a list of all software toots and the stages (Le., alpha, beta, final) that these tools are to be used by the programmers, artists, and sound and music professionals involved in the production of the Product. This section also should include an assessment of the hardware versus manpower.

5   Backup plans

5.1   This section should include a description of potential alternative production scenarios if the assessed risks associated with the proposed production plan make such plan unfeasible.