TDD (Tech Design Document)

In this document all the technical specifications related with the project will be laid out. This project will be developed in C++.

Purpose

The main purpose of our video game is to entertain people and for us, the developers, to learn.

Background

This is a project asked to be made by the UPC for Project 2 subject. Our team was asked to make a 2D RPG game with turn-based combat system during a period time of a semester.

Requirements

By now this is just a guess, it will be updated during the development. The game will be launched for PC only.

Hardware	Minimum Requirements
Operating System	Windows 7/8/10
Processor	1.2 GHz processor
RAM	200 MB
Graphics Card	DirectX 8 - integrated compatible graphics card with at least 32MB of video memory
Storage	500 MB

Detailed design

Software used

Code

• Visual Studio 2019
• Github Desktop

External libraries

• SDL2
• Pugi XML
• OpTick Profiler

Assets creation/editing

• Adobe Photoshop 2023 (Art)
• Aseprite (Art)
• Krita (Art)
• Ableton Live (Music and Sound)

Profiling

• OpTick Profiler

Map Creation

• Tiled

Files and directories

• Directories will be written in TitleCase.
• Files names in snake_case.
• Without special characters or spaces.

Code style

General conventions

• Code will be written in C++, comments and commits will be written all in English.
• Use of Get/Set no synonyms

 //Use
 GetAttackRange();
 SetItem();

• Indentation:

if(isAlive)
{
   //Here do everything needed
}

• Includes order:

#include "Module.h" //1. Engine files
#include "Optick/include/optick.h" //2. Third party files
#include <iostream> //3. Std files

Variables

• Usage of understandable and simple words:

 int health; //for single name variables
 int attackRange; //for compound name variables

Functions

• Funcitons will be named with PascalCase:

CreateEntity();
GetPosition();

Enumerators

• Enumerators will also be named in PascalCase.
• Enumerator variables will be named with UpperCase and SnakeCase.

enum PlayerType {
  SOLDIER = 0;
  VEHICLE_TANK = 1;
};

Classes & Structs

• All class elements will be organized following the below example:

class Entity
{
public:
	constructor/destructor
	public app functions (order updates)
	public utility functions (Jump(), LoadMap()...)
private:
	private functions

public:
	public variables (order by types, then alphabetically)
private:
	private variables (order by type, then alphabetically)
};

• All struct elements will be organized following the below example:

struct Example
{
	variables
	
	functions
	
	constructor/destructor
};

Conditionals

• Avoid the use of operators:

if(isAlive)
{
   
}
//We will try to avoid
if(isAlive == true)
{

}

Comments

• Comments will be simple and understandable.
• Always trying to go directly to the point and give the best explanation possible in a few words.

Temporal variables

• We will be using i, j, k for the temporal variables inside of loops.

White spacing

• Separate variables that are not from the same data type:

int health;
int attackRange;

bool isAlive;
bool inCombat;

XML conventions

• The structure example shown down below must be followed:

<config>
	<window>
		<resolution width="1280" height="720" scale="1"/>
		<fullscreen value="true"/>
		<borderless value="false"/>
		<resizable value="false"/>
		<fullscreen_window value="false"/>
	</window>
</config>

UML

• The UML will be added and updated once we start developing all the modules needed.

Branching policy

There will be three branches:

• Master: Where the releases versions with big updates will be uploaded.
• Development: Where the features will be updating continuously, making sure it works well before pushing it into the master branch.
• Bugs: Where bugs and errors will be fixed and then pushed to the development branch.

Implementation plan

Feature List

Inventory system

The player has to be able to pick up items, for him to use through the game or in combats. Example: health potions, coins, weapons, armor, etc.

Turn-based combat system

A combat system where there will be some characters in the field and each one will take their turn to make an action, such as using an ability or consumable. When all the characters have had their turn, it completes a combat turn.

Path-finding

A system that will calculate a path between two points in a grid based map, useful for the enemy's movement AI.

Dialogue system

A system to make the game more interactive, also letting the player give certain answers. This could lead the player to know more about the story, lore, or to receive items and consumables.

Animations

Sprite animations to make the game more interesting and appealing.

Enemy AI

Artificial intelligence for the enemies so it’s a little bit more difficult for the player to win and a changing experience every time a combat is played.

GUI System

The game user interface that will have buttons, images, sliders, check-boxes, etc.

HUD

The game head-up display shows the current game status, such as coins gathered, current level, mini-map, etc.

Collision system

All the collision calculations between the entities, so the player can collide with the terrain, enemies, or objects.

Audio system

All the music and sound effects that will be executed in the game to grant a more immersive experience.

Performance budgets

• The game will be able to run in 1280x720 resolution at 60 fps or with Vertical Syncronization activated (frame rate variable depending on screen refresh rate in Hz). Moreover Fullscreen mode, as well as Windowed mode, must be supported.

• Sprites, textures, particles and images will use .png format.

• Sounds Effects will use .wav format and Background Music .ogg format at 44100 Hz.

• Data files will use .xml format.

Performance will be tested by doing benchmarks using Brofiler library to check in each milestone the performance impact that our game has and if it accomplish our investor's requirements.

Build delivery method

The build will be delivered following our investor's given method as shown in the image below.

---

< Previous page > < Next page >