Throughout game and software development, documenting the process and specifics of the product is essential. Every facet of your product needs to be recorded and explained in as comprehensive a detail as possible. In a situation where one of your technical team-members disappears, you need a record of their work so you don’t need to dig through it to understand how their systems work and what they do. The best way to mitigate risk is to keep a Technical Design Document (TDD). A Technical Design Document is a comprehensive explanation of your code, its purpose and implementation. It’s not always possible for every programmer on your team to know how their systems work, and so by documenting everyone’s work, you can avoid losing time if one leaves or someone takes over.
Anatomy of a TDD
Summarise this system – what does it do? How does this benefit the deliverables of the product?
What will this document tell the user? How will this document help them to better their understanding and implementation of this system?
The requirements of this product, what desire does this deliverable fulfil? For example,
The time, budget and technical constraints of the product
Touch on the major aspects of your system; how it works and achieves the deliverables in as simple an explanation as possible
Here, you want to delve into the specific of the execution of the product.
Give a detailed overview of the specific implementation of your product, how it works, and what it is designed to do. You should also provide diagrams to explain the layout and flow of the systems within the product. Explain your systems elaborately, making sure to break everything down into as much detail as possible.
How will you break down the development process to achieve your deliverable? Will your product’s development need to be broken into stages to ensure its developmental efficiency?
Give a very detailed breakdown of your various systems. Include diagrams for every component of your systems, and their relations. This section should be incredibly long and detailed, explaining very nook that your system contains.
This section will be useful for the testing/QA team. You want very specific succession and fail states for your systems for your QA team to recognise, since you likely aren’t testing the system yourself. You should highlight effective testing practices and processes to extract the best feedback from your testers.