• Introduction
• Unified Modeling Language
• Code style
• Target hardware
• Performance budget
• Branching policy
• Version list
• External libraries
• Build delivery method

Welcome to the Tech Design Document of Tankerfield. The language we use for this project is C++.

In this UML you can see the main structure will have the code. However, this may evolve during the development process.

Welcome to the code style section of the Technical Design Document.

Any piece of code should be written in the English language. It is forbidden not to follow any of the rules exposed in this section. Needless to say, this applies to any person who writes code in this project.

• The indent size is one TAB.

int MyFunction()
{
    return 0;
}

• All case labels must be aligned with its switch statement. Same applies to default.

switch(var)
{
case 1:
    break;
default:
    break;
}

• In boolean expressions which size is three or more, put the operator at the starting of the line. Check out this example with the logical OR operator.

if(expression == 1 || expression == 2)
{

}

if(expression == 1
   || expression == 2
   || expression == 3)
{

}

We use braces in separate lines in these cases:

• Loops: for, while do while.
• Classes, enumerations, functions, structs.

In terms of initializing variables, we can put the first brace on the same line where we initialize or declare the variable, with a single space between the variable or operator. If the variable needs more than 4 parameters to be initialized, place every parameter in one line. Otherwise, put the parameters all in the same line of code. Notice the spacing with the braces.

void MyFunction()
{

}

class MyClass
{

}

Foo var { bar1, bar2 };

Foo var = { bar1, bar2, bar3, bar4 };

Foo var = {
    bar1,
    bar2,
    bar3,
    bar4,
    bar5
};

• For unary operators, no space is needed.

i++;

++i;

• For binary operators, two spaces are required, one to the left and one to the right of the operator.

sum = a + b;
sub = a - b;
mult = a * b;
div = a / b;
mod = a % b;

• For ternary operators, two spaces are also required, in the same way as binary operators.

a > b ? true : false;

• Spacing in the colon operator, for example, used in classes or range-based loops, works the same way as binary and ternary operators.

class DerClass : public BaseClass
{

};

for(auto& var : vars)
{

}

• Whenever declaring, defining or calling a function, place one space to the right of the coma.

void MyFunction(int a, int b);

• In terms of pointers and references, the spacing is also very relevant. When declaring or using, in general, a pointer or a reference, the representation icon (* or &) goes just at the right of its type, without a space. Then, add a space between the representation icon and the name of the pointer or reference.

int* pointer = nullptr;
int& reference = NULL;
int MyFunction(int* par1);
int MyFunction(int& par1);

• Whenever passing a memory address in a function call, no spacing is needed, like so:

Function(&ref);

• In the last place, when using pragma comments there needs to be a space after the first parenthesis and another space before the last parenthesis, like so:

#pragma comment ( lib, "Library" )

It is important to keep the code as clean as possible. Therefore, it is important to make use of NULL and nullptr. Whenever declaring a variable, always initialize it to NULL whenever is possible. Of course, if it is a counter or a variable with a special use, then NULL is not necessary, but the variable always needs to be initialized.

int var = NULL;
int counter = 1;

In terms of pointers, always initialize it with nullptr. This way, we may avoid possible errors.

int* pointer = nullptr;

We use a naming standard to organize and structure the code. -In the first place, the variables are written in lowercase. If the variable contains more than one word, an underscore is required to separate the two words. It is crucial that the variable is named appropriately, containing just the most basic information to understand it.

int variable = NULL;
int compound_variable = NULL;

In terms of functions, they need to start with a capital letter. Also, if the name is compound, the starting letter of the next word needs to be capital too. The remaining letters need to be lowercase. This way of writing is also known as PascalCase. Note that underscores are not allowed.

void SampleFunction()
{

}

Classes and structs are written the same way as functions, like this:

class SampleClass
{

};
struct SampleStruct
{

};

In classes, it is mandatory to follow a specific structure. In the first place, the constructor and destructor must be wirtten first and as a block (with no blank line between the two of them). In the second place, the next block will be the functions (they are actually methods, as they are inside a class), subdividing this block into other ones, depending if the members are public, protected or private. The order is important, and a blank line must be there if the user is changing from public to protected members and protected to private members. In the third and last place referring to the structure of classes, the final block will be the variables, which need to follow the same structure described above. Example:

class ExampleClass
{
public:
    ExampleClass();
    ~ExampleClass();

public:
    void Function1();
    void Function2();

protected:
    void Function3();
    void Function4();

private:
    void Function5();
    void Function6();

public:
    int var_1;
    int var_2;

protected:
    int var_3;
    int var_4;

private:
    int var_5;
    int var_6;
};

All enumerations must be written uppercase. If the word is compound, an underscore must be used to separate the two words. Furthermore, the elements inside an enum must be written the same way as the enumeration. In addition, it is forbidden to use plain enumerations; instead, use 'enum class'. For example:

enum class SAMPLE_ENUMERATION
{
    EXAMPLE_1,
    EXAMPLE_2
};

The header files also need to follow a specific rule. The words need to define the header file need to be uppercase, without spaces, if the file is not defined. And also they need to start and finish with two underscores. Before, the last two underscores, there needs to be another underscore with a capaital 'h'. Note that #pragma once is not allowed. Finish the '#endif' with a comment like the following example. See the example to understand better this paragraph.

#ifndef __SAMPLEHEADER_H__
#define __SAMPLEHEADER_H__

#endif /* __SAMPLEHEADER_H__ */

Any file created in the project must be written in PascalCase. Also, if the file created is a module, the word 'Module' needs to be added at the starting place of the file name, e.g. 'ModuleRender.h'. It is obligatory that a .cpp file must have the same name to the correspondent .h file.

The team needs to write comments whenever the person considers it absolutely necessary. If the code is not so clear, there should be a comment explaining how, why and what is for the code written.

There are many types of comments in C++. Firstly, the use of '/* */' will be for commenting the end of a header file (see subsection 6). Secondly, to comment a line of code, the comment needs to be the line before the line of code that is going to be commented. The comment needs to by of the type '//'. Examples:

// This is a comment, referring to the next variable
int variable = NULL;

// This is another comment, referring to the next function
void MyFunction();

Thirdly, it is important also to make use of '/* */' in order to comment a block of lines of code, apart from the header files explained above. The spacing is important. See the example below:

/* This comment refers to the next block of code */
int variable = NULL;
void MyFunction();

Lastly, note that there is no blank line of code between the comment and the code.

Referring to line breaking, it is totally forbidden to write two statements on the same line of code. In the next example we can see how it should be done (note that it would be wrong the two statements were written on the same line).

int x = NULL;
int y = NULL;

The same applies to conditionals, for example:

if (true)
    return example;

In the example above, it would be wrong if the return was written right after the condition on the same line.

In an if-else statement, the 'else' keyword cannot have any braces next to it, both in the left or right. See the next example of how an if-else statement should be written.

if (condition)
{

}
else
{

}

It is fundamental to follow a defined hierarchy or order when using libraries or headers in the project files. The order is as follows:

• Internal C++ libraries.
• External libraries.
• Pragma comments.
• Custom headers.

Note that between any of the previous types there needs to be a blank line. For instance:

#include <iostream>

#include "ExternalLibrary.h"

#pragma comment ( lib, "ExternalLibrary")

#include "CustomHeader1.h"
#include "CustomHeader2.h"

Our main platform will be computers. Our goal is that almost all kind of computers could run our game to reach more potential gamers. But as the game will be presented in UPC CITM Computers, we will give priority to this hardware. Internet conection isn't required, cause the multiplayer mode is local.

The video game runs at 60 frames per second. Furthermore, it allows the user to use v-sync. Each frame's time will be divided in the next percentages, although these values might change

Our project has three main branches, which are called master, development and bug fixes.

In the first place, the master branch will only have releases of the videogame, and therefore production-ready code.

In the second place, the development branch will have sub-branches. These sub-branches are features implemented to the videogame. By developing these features in a parallel way and different branches, the organization is clearer and effective.

In the third and last place, the bug fixes branch is specifically for the bugs found in the program, whatever it is the grade of the bug.

It is also important to mention how the pushes, merges and pulls work in this case. The master branch only has a relationship with the development branch, so the development branch will push to the master branch. The feature branches do push and merge from the development branch, and push to the development branch. The bug fixes branch are pulled from the development branch and pushed to the development branch.

• Code base(All modules and systems)
• Save/Load

• Tank/Unit control (movement & shooting)
• Static enemies, you can shoot at them and they die
• Camera
• Gamepad controller
• Isometric testing map

• Enemies moving (pathfinding)
• UI in game
• Map
• Enemy spawn, waves & rounds

• Enemies attack
• First IA
• 2 enemies (weak and strong)
• Splitscreen & cooperative

• 4 Skills
• 4 Bonus
• Progressive difficulty
• First Boss
• All menus

• All previous requirements
• Balance and testing
• Tutorial
• Leaderboard

• Adjust the mechanics with the feedback we’ve received from our first playable demo
• Finish all Skills
• Finish all bonuses

• Add 2 vehicle
• Add 1 map
• Finish all enemies

• Add 1 vehicle
• Initial skippable cinematic

• test cooperative with all tanks

• Testing

• Testing & add details

We use as the main external library the Simple DirectMedia Layer (SDL). We will also use Brofiler to measure how much time takes every process. Another external library that will be necessary is Pugixml, to read and write .xml files.

It is important to mention the Standard Template Library (STL), even though is not an external library.

A build will be released every week via Appveyor on the GitHub release section.

The release consists of a .ZIP file with the necessary files to run the program and an executable .EXE to play the videogame.