As I’ve written previously, Technical Design Documents are essential pieces of documentation for any team creating a technically-driven product. You will need a TDD to establish the rules and processes for creating the technical components of your product. The example I provided was designed for a Security Camera
The example I provided in my previous blog was designed for a Security Camera system, and doesn’t necessarily apply to games in a number of ways. Based on a work-in-progress TDD by one of my classmates, I have a far stronger idea on what a TDD should entail for a video game project:
A broader view of the product’s technology
Game Concepts
Your reader should know in general terms what your game is about, and what the end product will feel like.
Technical Goals
What are the basic requirements for your systems? In the example, a game may require 2D graphics & gameplay, simplistic particles, and glanceable UI.
Technical Requirements
What kind of system is your game built for? For a complex 3D game using a lot of assets and visual effects, you will require a high-end setup with a high-end graphics solution. This system will be the end-goal of your product. Don’t forget to be specific about the Operating System, Graphics Card spec and control system requirements. Lay out the exact minimum and desired hardware setups, so you can develop for the least-able system, and provide a much smoother/beautiful experience for the desired setup
It’s also worth describing the potential technical bottlenecks of this system, as your first port-of-call when your performance isn’t as-desired later on in development, or you encounter bugs or project woes.
Third-Party Tools
What tools will you use to aid producing your project? You may use Photoshop to create art, Audition for editing audio, GitHub for Version Control, Visual Studio for scripting, etc. Make sure you lay these out so your teammates know what’s expected of them
System Breakdown
This is the meat of the project (and where my example was largely accurate), where you need to lay out every system within your project. In the example provided, the project requires the following examples:
Physics
What physics solution will you use? Will you create your own?
Scene Structure
What is the basic makeup of a level? Are there any particular functions/actions thatg take place relating to the level? For example, does the player die if they fall out of a level? Does there need to be more than one camera? What objects will be in the level? (characters, props, physics objects, abilities?)
Player Actions
When in control, what does the player do? Lay out everything effect that the player object has on the world around it. For example, a player can move, jump, shoot and collide with objects around it, among others. Clearly define these for the script & function breakdowns
Victory Conditions
What does it take to “complete” a game, and what happens when you do?
Scripts & Functions
This is where you break down each and every function and lay out every script for your project. For example, a Player character will have a PlayerController Script, and that script will house many functions that relate to the player’s abilities and actions. Include detailed and comprehensive descriptions of each function and how it works and interacts with its related components.
For example: What would the Scripts and Functions section look like for the players, enemies and objects in Mario’s World 1-1?
We can break down the various components of a Mario level into four distinct components: Player, NPC, Collectible and Interactive Block
Player
In every Mario game, the player has a few distinct actions:
- Jump (hold for longer jump)
- Move (walking or springing)
- Take Damage (losing health or dying)
- Launch Projectile (depending on power-up)
- Collide (with another object)
Further, the Player has a particular number of functions relating to them:
- Power state (small, big, or power-up)
- Movement Speed
- Score
- Coins Collected
- Jump gradient
- Collider
Combining these with the interactions between them, we get:
Jump:
The player will press ‘A’ to jump. Jump height is determined by the jump gradient. Holding ‘A’ for longer will increase the jump gradient. The player’s movement speed will affect the directionality of the jump, allowing the player to jump a distance, or guide their fall in the air.
Move:
The player can move left and right along the screen by pressing Left and Right, and by holding down the sprint button can sprint at an increased movement speed.
Collide:
When a collision occurs between two objects, both of them must execute functions on the other. When the player collides with an enemy from the enemy’s left and right side, the player will execute the TakeDamage function. If Mario collides with an enemy from the top, the enemy will execute TakeDamage.
Take Damage
The Take Damage script will manage the player’s health. If the player has a power-up, they will fall to Big Mario. If the player is Big Mario, they will fall to Small Mario. Otherwise, they will die and respawn.
Launch Projectile
When the player presses ‘B’, as long as they have an appropriate power-up active, they will launch a projectile. The exact type of projectile and its behaviour is determined by the Power-Up itself. The Launch Projectile script will handle the input and direction of the projectile.
Enemy
Enemies need a few variables for their actions:
- Projectile Interval
- Projectile Type
- Health States
- Collision box
- Movement Speed
Enemies have a few distinct actions:
Move
Enemies in Mario move at a set speed left from the right of the screen. Depending on their health states, Koopas will retract into their shells and slide faster across the screen.
Launch Projectile
If applicable, the enemy will launch a projectile towards the player after a set interval. The exact specifications and physics of the projectile is determined by the projectile’s class.
Collide
If an enemy collides with the player, the player will move down a health state. If the player jumps on or otherwise defeats an enemy, the enemy will move down a health state. If a walking enemy collides with a chunk of the world, it will switch direction. If a Koopa reaches the end of a platform, it will switch direction.
Enemies will usually have bespoke behaviours based on whether or not they are a boss, and occasionally will have different movement or attack patterns than regular enemies.
Collectable
Collectables are simple yet essential objects. While their behaviour is limited, they execute a variety of functions on the player when they are collided with:
Collide
If the player collides with a collectable, it will execute its functionality onto the player. A power-up will apply a new health state to the player (including a suit), a coin will increase the player’s score, a one-up will increase the player’s health, etc. If a moving power-up collides with a wall, it will switch direction
Move
Some power-ups will move to the right of the screen (instead of remaining stationary). These power ups will switch direction if they collide with a wall
Interactive Block
Interactive blocks are largely stationary but provide some bespoke functionality that differs them from general collectables:
Collide
If a player jumps into or body-slams an interactive box, it will execute functionality onto itself or the player. For example, a box containing a coin will immediately give its coin to the player, but a power-up will spawn on the side opposite the player. After which it will remain stationary or be destroyed
World Functions
The world itself will execute functionality on the objects within it for menu and game continuity functionality:
Start
The game starts, and every interactive or mobile object in the world is set active and ready to spawn
Spawn Enemy
When the camera is close to the spawn point of an enemy, the enemy will spawn. When an enemy leaves the range of the camera, it will despawn.
Game Paused
When a game is paused, all objects are frozen except for menu elements until the game is unpaused
