The Technical Design Document is a scheme for all the technical aspects of the features which are defined in the Game Design document. It is an architectural description of the game from the developer’s point of view.

• Working guidelines
  • Performance budgets
  • Technical goals
  • Technical risks
  • Code style guidelines
    • Naming
    • Variables
    • Loops
    • Conditionals
    • Classes and structs
    • XML files
  • Code organization overview
  • Branching policy
• Builds and files
  • Version list
  • Build delivery method
  • External libraries
  • Data layout
• Delivery platform
  • Target hardware
  • Target software

We will use Visual Studio Community 2017 v15.9.7 to develop our game and Tiled to create all the maps of the levels. Besides, we will use Brofiler to check the performance of each code section of our game.

Our game will run at 60 frames per second.

• Dungeon exploration.
• Movement in eight directions.
• Possibility to choose between four totally different characters.
• Four unique boss combats.
• Fast and fluid combat.

Since the game we are aiming to make does not use a lot of heavy features we do not expect a lot of technical risks to appear. Nevertheless, there are a few of them we must take into account:

• The game may not be able to run at 60 frames per second.
• The combat may be slow, and as a consequence, boring.

In order to avoid those risks, we will try to optimize the code the best we can.

In order to have an organized and homogeneous code, we will follow these guidelines when we are coding our game.

• All the code must be in English.

• After a semicolon (;) we will continue in the next line.

• The list of includes must start with the ones from C/C++ libraries, then from external libraries and then from game files. There must be a blank line between each #includeblock:

    #include <iostream>
  
    #include "SDL\include\SDL_rect.h"
  
    #include “App.h”
    #include “EntityManager.h”
    #include “Gui.h”
  

• Defines must be in uppercase: #define GRAVITY 9.81f.

• Use the comments (//) as titles that explain what each function or code block does. If a function has several code lines use the comments to explain what each part of the function does:

    // Limit X camera position
    if (App->render->camera.x > 0)
      App->render->camera.x = 0;
  

• If the code file is very extensive we will divide it into visible sections with uppercase big titles. In order to differentiate those from the comments titles they will be written as the following:

    // ----------------------------------------------------------------------
    // CONTROL OF THE CAMERA
    // ----------------------------------------------------------------------
  
    // Limit X camera position
    if (App->render->camera.x > 0)
      App->render->camera.x = 0;
  

• Use the comments (/**/) to comment a whole function. That will mean that section is not being used at the moment but that it might be in the future:

    /*if (App->render->camera.x > 0)
    App->render->camera.x = 0;*/
  

• Function names will be compound and as most self explanatory and short as possible. The first letter of each word will be a capital letter:

    moveThePositionOfThePlayer()       <-- Bad function name
    UpdatePlayerPosition()             <-- Good function name
  

• Temporary variables must have very short names: int temp.

• The other variables must be self explanatory. In the case they have compound names they will follow the same uppercase and lowercase rule as the functions: float playerSpeed.

• In the case there are two variables with almost the same name it will be used underscore _ to highlight the difference between them:

    int playerPosition_Y
    int playerPosition_X
  

• The name of an enum and the elements inside it must be in uppercase. Besides, each element of the enum must go in a different line:

    enum DIRECTIONS {
    UP,
    DOWN,
    RIGHT,
    LEFT 
    };
  

• Every time an enum variable is created it must be called as the enum itself (with slight variations if there are more than one): DIRECTIONS directions.

• There will be used whitespaces between operators, outside parentheses and brackets and between names, signs, and initialization of variables: return (a + b) * c is a lot better than return(a+b)*c.

• The star (*) of the pointers must be near the variable type instead of near the name: float* var rather than float *var.

• Every time a class or a struct is created their name must start with capital letter: class Enemy.

• We want no magic numbers in our code: something like int life = 300 is not allowed.
• Pointers must be initialized to nullptr: Collider* playerCollider = nullptr.
• Floats must be initialized to 0.0f: float speed = 0.0f.
• Integers must be initialized to 0: int = 0.
• Bools must be initialized to trueor false: bool isAlive = true.
• When we declare various variables of the same type they will be declared in the same line: int time, resistance.
• When making operations, it is preferred to use the short version of the operation: y += x rather than y = y + x.
• Any variable that is going to be always constant must have the keyword const: const int damage.
• If a variable has to keep a value which is already in memory, it must be a pointer.

• We will not use do-while loops.

• If we are using implementing a typical for that uses numbers, the iterator variable will be called i. If there are nested loops they will be called j and k:

    for(int i = 0; i < MAX_1; ++i){
        for(int j = 0; j < MAX_2; ++j){
            for(int j = 0; j < MAX_3; ++j){
  
                // Code
  
            }
        }
    }
  

• We will not use condition ? true : false conditionals.

• Avoid operators in the conditions: if(condition){} rather than if(condition == true){}.

• Avoid the scopes {} when they are not necessary:

    if(condition)                                       if(condition) {
        function1();                                        function1();
    else                      is preferred to           }
        function2();                                    else {    
                                                            function2();
                                                        }
  

• The conditional and the code inside it will be in different lines unless it is a very simple function:

    if(condition) doSomething();      <-- Not easy to read
    
    if(condition)
        doSomething();                <-- Easy to read
  

• If there are a lot conditions inside a conditional they will be divided in different lines by intuitive blocks that facilitate their readability:

    if ((x >= 0 && x <= MAX_X) ||
    (y >= 0 && y <= MAX_Y))
  

• If it is going to contain a few variables and just a couple of functions we will make a struct. In any other case, it will be a class.
• Data in classes will follow this order: a public section will contain the public functions of the class, then a private one will contain the private functions of the class, then another public section again will contain the public variables and to end another private one will contain the private variables.

• Booleans must be either true or false instead of using 1 and 0.

• Animations will follow this hierarchy:

    <idle loop="true" speed="15.0f">
      <animation x="2" y="184" w="22" h="25"/>
      <animation x="33" y="184" w="24" h="25"/>
      <animation x="65" y="184" w="24" h="25"/>
      <animation x="97" y="184" w="24" h="25"/>
      <animation x="130" y="184" w="22" h="25"/>
      <animation x="163" y="184" w="21" h="25"/>
    </idle>
  

This diagram shows the structure our code will have. As you can see in the picture, all the modules are managed by App.h and they all inherit from Module.h. Besides, both entities and UIElements inherit from a specific class. This will be used as a guide to see the whole picture. Nevertheless, as the project evolves this UML will change and be enlarged as the new modules appear.

We will use the GitFlow strategy. GitFlow relies on two permanent branches: master and development. The state of master branch should always be clean: it reflects the last stable version of the project. On the other hand, the development branch will be most of the time potentially unstable. This will be the main work branch, the one which handles all the -you will forgive the repetition- development of the game. This development happens with the use of the other branches: feature, release and hotfix.

• Feature branches are the ones developers create to work on new features. They should always branch off develop. After the feature is complete, the developer should merge the feature back to master. They must have a descriptive name and will be erased once the feature is implemented to development branch.

• Release branches will provide the preparation of a new release. Since this work is being done in a separate branch, the development branch is free to receive new other features. When the release branch gets stable enough to become a release, it should be merged into master and that commit tagged with the correct version numbers, so it can be easily accessed in the future.

• Hotfix branches are also meant to prepare for a release in production when a critical bug in production must be dealt quickly. With that, the team can continue working on new features as usual at the same time someone is preparing the fix for the problem. Hotfix branches should be created from master since it reflects the last "good" state of the game. When the bug is fixed, the release branch should be merged to master. Besides, it must also be merged to develop since the feature releases will require those corrections too.

Example of a project using GitFlow.

The following list is what we have planned to have for each game release. It will serve us as a guideline to follow and to keep us on track in which phase of the development are we.

    Version v0.1                           Version v0.2 
    ------------                           ------------
    Level 1 scenery                        Black Mage 
    Camera movement                        Dragoon Knight
    Collision system                       2 Enemies      

    Version v0.3                           Version v0.4 (Vertical Slice)
    ------------                           ------------
    HUD                                    Minimap
    Enemy drops                            Level 1 Boss
    Judge                                  Main menu

    Version v0.5                           Version v0.6 
    ------------                           ------------
    Level 2 scenery                        Level 2 Boss
    Tank                                   Level 3 scenery
    Rogue                                  Rest of the enemies

    Version v0.7                           Version v0.8 (Alpha)
    ------------                           ------------
    Level 3 Boss                           Final Boss
    Level 4 scenery                        Shop
    Overworld (inter-level stage)          In-game menu

    Version v0.9                           Version v1.0 (Gold)
    ------------                           ------------
    Secondary quests                       Final game polishing
    Polish the UI                          Bug fixing
    Polish the overworld and the shop      Animated logo

To deliver the builds we will use AppVeyor. AppVeyor is an application which drafts a new release every time a member of the time makes a commit. Linking this app with the Development branch we are going to have a new release every time a feature is implemented.

As it is specified in the Production Plan document, we are going to make a release each week on Saturdays. This release will be delivered by our member in charge of the QA, Òscar Faura.

To develop our project we will use the SDL and STL libraries.

We will have all the files inside the game repository. In it, we will have the Visual Studio solution and two files. One of them will be the Game folder. It will contain the .dll of the libraries, the XML files and all the assets for our game: fonts, GUI, maps, textures, and audio, with music and audio Fx. The other folder inside de repository will be the Motor 2D file, that will contain all the libraries of our game and the .cpp and .h files.

All textures will be .png, the audio Fx will be .wav, music .ogg, maps .tmx and the fonts .tff. The names will be of two words -separated by an underscore- at maximum and the most self-explanatory as possible: player_jump.wav.

The platforms for which the game will be delivered will be the computers of the UPC's CITM Campus.