6. Tech Design Document

TDD (Tech Design Document): UML, code style, target hardware, performance budgets, branching policy, version list, external libraries and build delivery method.

Fantasy Brawl

Checkthedog

07/03/2019

TDD v0.5

TDD Index

• Introduction
• Technical goals
• Target hardware
• Performance budgets
• Branching policy
• Build delivery method
• Code style
  • 1. Naming Conventions
  • 2. Variables
  • 3. Conditionals
  • 4. Loops
  • 5. Classes & Structs
  • 6. XML Conventions
• UML
• External libraries & Tools
• Version list

Introduction

This page of the wiki is dedicated to the Tech Design Document (TDD) of Game Name TBD. In it you will find all information related to code guidelines that we will be following throughout the development of the game.

We will be using C++ and SDL to create the game.

Technical goals

1. 4 players multiplayer
2. 4 camera split-screen
3. Multiple characters selection

Target hardware

The Target Hardware is the CITM computer were all game deliveries will be played.

Element	Requirements
OS	Windows 10 Pro
RAM	8192 MB
CPU	Intel Core i7 3.40Ghz
GPU	Nvidia Cuadro 600
Free Disk Space:	200 Mb

Performance budgets

The game must run at 60 fps at least on the described target hardware.

Branching policy

To ensure a good repository workflow we will follow the GitFlow branching policy

Gitflow:

Branch uses.

Branch	Usage
master	Tracking released code only. Reduced number of commits (tagged for versions) consisting of merges from release and hotfix branches.
hotfix	Branches used for emergency fixes.
develop	Main branch where features and fixes will be implemented (what we've been doing on master all the time we've been learning).
release	Release branches to prepare releases and fix the errors they may contain until the release is ready to be published at github releases.
feature (/followed by what feture it is)	Feature branches (as there can be many) are for big & important feature implementations (mainly described in the version list) which may require some time.

Gitflow branching off and merge rules.

Branch	Branching-off	Merges into
master
hotfix	master	develop, master
develop	master
release	develop	develop, master
feature	develop	develop

Build delivery method

We will be using AppVeyor to make the releases of the game. For each feature planned in each version we will create a release.

Code style

Language: all code and comments must be written in English.

Naming Conventions Overview

Element	Naming case	Naming Golden rule
Variables	snake_case	Vars must have unique meaning & concept.
Enums	SCREAMING_SNAKE_CASE	Descriptive about the concept they are related to.
Enum items	SCREAMING_SNAKE_CASE	Start with the keyword of the enum. Always have a ERROR / UNKNOWN / NONE enum item in the enumeration.
Constants	SCREAMING_SNAKE_CASE
Functions & methods	CamelCase	Descriptive about what the function does. start with Get or Set functions that are there to respect encapsulation.

Naming Conventions

Variables must be written in snake_case. *Variables must have a unique meaning, avoid namig variables with concepts that may be too similar. In snake_case words are always written in lower case and with underscores between words in the case of compound names.

• Single name: position

• Compound name: last_direction

Avoid using long names of variables for temporal variables such as those used inside loops, or eliminated once we get out of scope, since length will give use a first sight hint of the importance and use on code of the variable.

Examples:

//Temporary var bad example, this would be a Long Term variable
int map_index;

//Correct temporary example, the variable is descriptive enough in the context
int m;

• Enumerations: must be written in SCREAMING_SNAKE_CASE.

BUTTON_STATE

• Enums items must be also written in SCREAMING_SNAKE_CASE, and they must start with the keyword of the enum.

BUTTON_PRESSED
BUTTON_RELEASED

If an enum item were to be over 4 words, it should be shortened when possible.

Original Item:
STATE_MACHINE_ALERT_IDLE

Shortened version:
ST_ALERT_IDLE

• Constants have to be written in SCREAMING_SNAKE_CASE

MAX_FPS BASE_DAMAGE

• Functions and methods names must be written in CamelCase and must be descriptive of what the function or method does.

ResetFogOfWar()
GetTileProperties()
ApplyDamage()

• Remember the object the function or methods belongs to, so taht you avoid repeating the name inside the function.

//Bad
     player.GetPlayerState()

//Good
     player.GetState()

Input variables for functions and methods should have the same or a similar name than it's type.

CameraFollow(Player* player)

Variables

• Don't use magic numbers, vars should not have hardcoded values, they should have either values from the xml or other vars or const vars.
• Remember to initialize all variables that will have their value assigned later on in the following way

// int
int example = 0;

// uint
uint example = 0;

// float
float example = 0.0f;

// pointers
char* example = nullptr;

• Bools can be initialized with either true or false but remember they must always be initialized!
• Classes critical variables should be private or protected and have acces functions to follow the encapsulation concept.

Conditionals

• With conditions use operators only under the condition. Use operators only if more than one line of code is required

3 Examples:

//Bad, only use operators if more than 1 line is required
     if (is_finishing) {Close()}

//Instead we do this
     if (is_finishing)
            Close()

// Good use of operators
     if (is_finishing)
       {
          Close()
          PrepareNext()
       }

• With booleans in conditions, place the positive condition in the if statement

if (is_finishing)  // The process is finishing
       Close()
else               // The process is not finishing
       KeepDoingIt()

• If possible, avoid sequnces of if () else if() statements, and use switches instead specially when enums are involved.

Loops

• For loops should bbe used as default loop, try to avoid using while loops, they are for very specific situations and most times can be substituted by for loops

// Remember we can still do this

int i = 0;

for (; i < some_num; ++i)
        DoSomething();

Remember the difference between ++var and var++.

var++ returns value of variable BEFORE incrementing
++var returns value of variable AFTER incrementing

Try to always use ++var, specially while iterating on loops.

Classes & Structs

• Write all class elements in the following order

class ExampleClass{

public:
       constructor
       ~destructor
       public functions and methods

private:
       private functions and methods

public:
       public variables

private:
       private variables
};

• Write struct elements in the following order

struct example_struct{
     
     variables

     functions
};

If a struct is not essentially a data structure it must be adapted into a class

Indentation

For the brace indentation we will be following Allman style.

• Braces are on the same column where the control statement starts

//Allman Indentation example

for (int i = 0; i < target;++i)
{
     if (is_true)
     {
         DoIt();
     }
}

Whitespacing: Leave some space between chunks of logic/data that are different

uint layers;
uint maps;

string example_str1;
string example_str2;
string example_str3;

void ManageLayers();
void DrawMap();

Commenting: comment code regularly, at least there should always be a comment of what the function does in the header of the class where it belongs.

XML Conventions

• Bool variables must be 0 or 1
• Elements that have no children should always be written in this form

<life value="350" />

UML

External libraries & Tools

STL (Standard Template Library), will be used for template classes such as lists, strings and dynamic arrays.

Profiling Tools: Brofiler to check how the game performs and what must/could be optimized.

Map related tools: Tiled will be used for map editing and all its related metadata.

Version list

v0.1 Base Code Map Implementation 4 Gamepad Multiplayer Input

v0.2 Players movement 1st Character animations

v0.3 4 player splitscreen cameras Colliders

v0.4

v0.5

v0.6

v0.7

v0.8

v0.9

v0.95

v1.0

< Previous | Next >