This section of technical design analyzes the game design thoroughly and figures out the sections where technology plays a major role. Game play logic development is not a part of this section. However, when game logic requires hardware dependency, then this section is also considered in technical design.

Many developers and organizations have a habit of making a technical design document after creating the game design and before starting the actual development process. This helps define the timeline and predict upcoming challenges, with possible solutions.

This section designs the class diagram and hierarchy for the game. The game flowchart and server-client architecture (if required) are also defined here.

This section of game technical design gives a clear picture of upcoming development for a developer. Each and every part of game modules, program structure, call hierarchy, third-party tool integration, database connectivity, and server-call management should be clearly declared in this part of the technical design document.

The visual display of such a diagram, showing the flowcharts, is always a headstart for any development process.

The technical specification specifies the development platform, target device set, and target operating system. It may also mention what hardware system and software is required to develop the project.

This identification is essential before starting the actual development. For any software to run, it requires a hardware platform that is well capable of supporting the software. Developers must know the target devices and must be provided with these devices to carry out unit testing. Any additional requirement is also identified in this section of technical design.

So, basically, there are two different sections in this specification. First is to specify the target system on which the game is designated to run. Second is to identify the system required to create the game according to the design.

This section in technical design refers to the additional tools and system requirements. In many cases, this section is included in the technical specification. However, this part serves a different purpose.

This may create the requirement to develop a new tool for the actual game development. Therefore, tool programmers are referred to this section. Android game development is not out of scope for this section. Although most of the tools are readily available for Android development, a few scenarios may demand a game-specific tool as well. In this case, the tool design and separate technical design, and the use of the tool is mentioned in this section.

Resource analysis is a report on staff dependency, staff skill level, technical dependency, and other resource dependencies. This helps estimate project cost and decide the development timeline.

This is another important part of technical design. Testing is an integral part of a game development process. Technical design should define the testing procedure along with the defined test cases.

The development head of the game identifies the stages of testing and its requirements. Testing tools may be declared in this section. We have already mentioned testing tools in the previous chapter. In some cases, a customized tool may be required.

Testing requirements have four main sections:

Every game has a predefined limited scope. Especially in Android devices, where the variety is maximum, a scope definition is required. Running a game with the same design on all Android platforms is next to impossible.

This section of technical design indicates the probable scope of the game. This may identify the minimum required configuration, recommended configuration, and target configuration to run the game at its maximum performance.

The game scope defines the minimum and maximum range of the hardware platform. Most developers like to minimize the game design scope to target maximum hardware devices. A technical design document is a good reference for developers to get an idea of the performance of the game within the scope.

A technical design document is made before the production is started, so there are many fields that have to be assumed beforehand. This obviously increases the risk of the project. However, having a clear idea of the risk always helps developers get the solution when the actual problem occurs.

This is the reason risk analysis is mandatory for any technical design standard. The risk may be analyzed in different fields.

While developing a game, the technical requirements or game design may change. So, risk should be calculated to accommodate these changes without affecting the main project pipeline.

Technology is evolving quickly. So, in the risk analysis section, change of technology should also be addressed. In a common scenario in game development, technology may change during development to increase the game quality.

A change log is the list containing all the changes in technical document from the first draft and according to the date and version number. This helps in keeping track of the evolution of the game.