The technical design document describes the internal structure of your code at the class level, and gives an overview of how the code behaves at runtime. This is accomplished by creating UML class diagrams to represent the static structure of the code, andUML sequence diagrams to represent important aspects of its dynamic behavior. These diagrams represent the detailed technical design of your project.
One aspect of software design is the use of software design patterns, where they are appropriate. Computer games often make use of the Strategy (implementation examples), Chain of Responsibility, and Composite design patterns.
A complete technical design document will contain a static structural description and a dynamic description, detailed below.
Static structural description. In one or more UML class diagrams, represent all of the classes and interfaces that your team will develop in your project. Where you create subclasses of existing game framework classes from a library you're using, you should also indicate these classes as well on the UML diagram, though not to the same level of detail. Each class should describe the class variables, and all of the methods in the class. Ideally you will also provide method parameter lists, though this is not strictly necessary. Diagrams should represent all inheritance and containment relationships among classes.
For game engines, the class diagram typically needs to describe the following game elements:
Your game may also include other elements above and beyond this list.
Dynamic description. In a series of UML sequence diagrams, describe the most important code sequences in your game.
For game engines, modeled sequences should include at least the following:
Common pitfalls. A common error is lack of consistency between UML class and sequence diagrams. For example, if a method is given in a sequence diagram, it should also be defined on a class in a UML class diagram. This error often occurs when class diagrams are created by one team member, sequence diagrams by another, without having a meeting to make them consistent. It is also common for the UML sequence diagrams to omit some of the relationships among classes. Other common errors include not including audio handling, or having inconsistent handling of input between class and sequence diagrams. Another common source of error is inconsistency between the game design document and the technical design document. Are the game aspects described in the game design document also present in the technical design document?