I am Enric-G. Durán, student of the UPC Bachelor’s Degree in Video Game Development at CITM. This content corresponds to the second year’s subject Project 2, under the supervision of lecturer Ramón Santamaría
The need for a Tech Design Document is one of structure and organization so that the members of the team know the circumstances the project is surrounded by. It also goes into detail explaining in which way the mechanics and the feel the GDD conceptualizes are going to be implemented in code.
A TDD basically works like a blueprint for the programmers or engineers in the team to implement their code properly, just like an architect would do with a building so that the construction workers follow the conventions.
Apart from coders, the rest of the team also benefits from knowing the TDD as it specifies every piece of hardware or software to use in the process and lets them know the limits of what they can make or design. Without a TDD, a project is almost undoubtedly going to suffer from lacking information about its limitations, scope and procedures to stick to when it comes to coding.
Once we understand the importance of making a TDD for our project, we should search for references from other teams that have similar needs to ours in order to find a proper structure and really understand what this document is about.
For software creation in general, TDDs are very related to research and the functionality of the code itself: the questions and the answers the program wants to provide. However, in essence, the template for any TDD follows the same logical order that goes from what we want to do to what platform do we do it for, how we do it, where we do it and how we deliver it.
(for more examples go to Bibliography)
In game creation TDDs is where we can find examples similar to what our document should be like. We can see different structures depending on what the focus is, however, most examples you can find will follow the same important bullet points. One important thing to take into account, though, is that our project's scope is very different from big productions and there are technical differences between genres, platforms, artstyles...
(for more examples go to Bibliography)
Finally, we need to know that we are not the only ones that have done this project and we can look back to see what TDD proposals other students came up with in past years for a situation nearer to the scope of our own project. The point of this is NOT copying, but learning from them and improving their proposals.
(for more examples go to Bibliography)
After my research through different structures proposed online, I arrived to the following TDD template:
Includes the name of the game, the team members, a brief description (genre, main mechanics, feel...), the code language and the licensing. It keeps the goal and the basics of the project in the mind of the engineers.
Includes the chosen platform for the project and its technical specifications. But most importantly, it includes the performance budgets, which are the resources the game can afford to use and are mesured in many ways: fps, quantity of textures, waiting time.... These are affected by the genre, mechanics, style and platform, but moreover, the resources of the team. The performance budgets should be made considering the target platform and vice-versa as an incongruence between them could cause the game to be too powerful for a platform or not use the resources the platform offers.
More about Performance Budgets...
Similar to the case of the Target Platform, here we should find the minimum requirements for the pieces of hardware we plan on using for the making of the game: Computers( Minimum OS version, speed at which programs should run...), Screens, Art Tools (graphic tablets, more powerful computers for rendering, cameras...), etc.
Specification of the software and pre-existing code that will be used during the project as well as what the software is going to be used for. This englobes any piece of software that the developers of the game haven't made and need to know how to use to implement in the project.
GitHub Branching: GitHub, which is a platform used to share the work environment of the project, allows developers to work in different branches. This is called branching and while useful, this establishes a following of rules and conventions that must be followed every commit. It is important that the branches are explained in the TDD so that this advantage doesn't become a setback for the project.
Here each of the parts of the game that need to be implemented in the code are explained.
Technical Requirements: A list of every important feature that the team needs to develop and implement into the game and what the plan to do it is (i.e. Entity System, Split Screen, Random Map Generation...)
Game Architecture: A diagram or a written explanation of the game loop and how data is managed (saved and loaded) trhoughout the game.
Graphics and Audio: Specifications for graphics (screen resolution, tile dimensions, ...) and audio (format, channels, ...) accompanied by a short explanation of their implementation.
Artificial Intelligence: Explanation of the AI's behaviour and role in the gameplay as well as which entities are controlled by it.
Logic: Diagram or written explanation of the Entity System and Game Object hierarchy.
Physics and Collisions: Analysis of the functionality of collisions and physics of the game (Are they realistic? To which objects are they applied?)
Network: Only needed in the case that the game has online features.
Every project should follow a homogeneous set of rules for all the code that is implemented by the different programmers so that the project has better intelligibility for any interested people who might see it and also for the participants. Having a homogeneous code style is a very easy way to avoid losing time of debugging and fixing errors. The strictness of the code style guidelines is different in every team, but some examples of conventions would be:
- Naming Rules: These explain rules like the code language, how variables act and are created, signs like parenthesis or claudators and the perspective on comments. For example:
Every variable should start with a lower case letter
uint life 100
- Variables: How to manage, declare and initialize variables and whether to declare them inside
public,protectedorprivatepart when using classes or structs. For example:
Every time a pointer is created must be initialized as null:
int* test = nullptr;
-
Loops: Names the loop expressions preferred inside the code (
while,do-while,for,...) and when to use thebreakandcontinuekeywords. -
Conditionals: Describes conditionals use, the rules of separation of lines using
if, where to use scopes{}or if conditionals with operators are preferred. For example:
We prefer a conditional like if(something == true) {}
rather than one like if(something) {}
-
Classes & Structs: Rules about how to choose between classes or structs and how to write elements inside them.
-
XML: States how to write variables in XML files for the game and how to use their nodes and attributes. For example:
If a node has more than one attribute we'll declare them in different lines:
<house>
<colour="red"/>
<walls=4/>
</house>
This list of elements has been made taking DLorenzoLaguno’s TDD as a reference.
Main UML of the Code Organization Overview. An UML diagram of all the code in the project that shows every class, the inheritance between them and the variables and functions allocated inside. This diagram is supposed to change throughout the time of development, increasing its size and complexity.
Image of DevCrumb’s general UML for their game Warcraft II: The Stolen Artifacts.
Diagram or explanation of how the folders of the project are distributed and a brief explanation stating the logic behind it.
Here we can find a calendar or graph (trello style) with every feature to include in the game, the person in charge of it and its delivery date. It should as well include all the vertical slices, builds and sprints allocated during the project. This schedule is a form of orientation and is most definitely going to change.
In addition, there will also be a list of every version planned from the start of the project as a guideline for the order of the features implemented and such.
This section allocates an explanation of how every build will be created in the project.
For more information, check out this video on GitHub Actions (Minutes 7:30 to 12 shown in class)
In the case that there is time left, the students will be asked to form their project II groups, choose a game and decide what the main points of the TDD could have been like for its development.