Skip to content

3. Tech Design Document

Ignasi Pardo Carbó edited this page Mar 14, 2021 · 7 revisions

Index:

1.Technical Goals

  1. Hardware Baseline

    2.1 Target Hardware

    2.2 Performance Budget

    2.3 Requirements

  2. Software Baseline

    3.1 Development Sofware

  3. External Libraries

  4. Code Style

    5.1 General

    5.2 Comment Policy

    5.3 Naming Conventions

    5.4 Intendation

  5. Assets

  6. Build Delivery Method and Data Layout

  7. Version List


Document TDD (Tech Design Document) is meant to analyse all the specifications of the technical profile which this project follows.

Technical Goals

All the main technical goals that have been set for this project will be stated below:

  • 2D Orthogonal World
  • RPG Turned Based Combat System
  • Resource Management of a "big" project.

Hardware Baseline

Target Hardware

The resulting game of this project is originally made for PC only. Expected peripherals needed to play the game: monitor, keyboard and mouse.

Performance Budget

The guidelines of this project state the budget and expected performance of the final result:

  • Resolution 1280x720px@60fps.
  • Support for either windowed or fullscreen mode.
  • RAM memory usage must not surpass 256 MB.

Requirements

According to the guidelines this project is meant to follow, the final result/product runs at a system with the following specs:

Minimum Requirements
OS Windows 7
CPU 2.00 GHz
GPU >1000 MHz, 2 GB, GDDR3
RAM 256 MB
HDD/SDD ???
  • Must correctly run in the university computers.

An example PC accomplishing minimum requirements would be:

Example Valid Computer
OS Windows 10
CPU Intel Core i3-5005U 2.00 GHz
GPU NVIDIA GeForce GT 1030
RAM 4 GB
HDD/SDD 500 GB

Software Baseline

Development Software

The following programs have been employed in the process of development of the project:

Programming:

  • Github
  • Visual Studio 2019

Asset:

  • Adobe Photoshop CC

Profiling:

  • //Brofiler

Map/Level edition:

  • Tiled

External Libraries

All the external libraries that will be employed during the project's development will be shown down below:

  • SDL (SDL2-2.0.14)
  • SDL_image
  • SDL_mixer
  • SDL_ttf
  • //Brofiler
  • //STL
  • //mmgr

Code Style

The programming of the project is "strictly" ruled by the following custom set of code conventions.

General

  • Code and comments must be written in English.
  • Programming language will be C++, except for those steps which require xml.
  • As a general convention, code must be as simple, readable and straightfordward as possible.

Comment Policy

  • All methods should have a brief comment on their functionality and variables if otherwise they would seem unclear at first sight. In general, the code should not need any comments to be understood.

Naming Conventions

  • Words should be full so that they are more easily understood (position over pos).
  • In general, variable names begin in lowercase, and if compound, every other word but the first has upper case first letter (likeThisExample).
  • Bool variables' names are preceeded by is or has depending on functionality.
  • Constant variables' names are in uppercase and separated by an underscore should there be a compound name (MAX_SIZE 1000).
  • Enumerations are of enum class type and both class and items follow same naming convention as constant variables.
enum class ENEMY_TYPE
{
	GROUND,
	AIR,
	BOSS
};
  • Function names follow the FunctionName() format and must be clearly descriptive of what they do.

  • The object to which the function belongs too should be taken into account when naming a function, and so not appear in its name (Player::Update() over Player::UpdatePlayer()).

  • Variable names should always start at the same column.

  • Variables should never be initialized in their origin .h file.

// Variable Declaration Examples
int 	health;
float 	speed;
bool 	is_running;
char* 	unit_name;

Indentation

  • Curly braces { } should always be used, regardless of the amount of code lines the if () statement comprises:
//bad example
if (condition)
	Function();
else if (condition) OtherFunction();

//another bad example
if (condition) {
	Function(); }

//good example
if (condition)
{
	Function();
}
  • Braces will be placed in the same column where the control statement begins, and so NO braces will be placed at end of statement.

Loops

  • Use switch statements over if () and multiple else if ().
  • Use for() over while() loops.
  • Concerning increments, use ++var over var++, as it is less resource consuming. var++ returns BEFORE being incremented while ++var returns AFTER being incremented.

Classes & Structs

  • All class and struct elements will be organized following this rule:
  1. First public then private.
  2. Order of elements is variables, then main functions for updating object, and last util functions.

Whitespacing

  • Do NOT stack variables of same type using ,.
  • Separate variables, functions and defines/includes that do not belong to the same data type or are not related at all:
#include <iostream>

#include "SDL.h"
#include "SDL_image.h"

#define GRAVITY 10.0

#define WINDOW_WIDTH 1280

int health;
int lives;

bool isAlive;
bool isJumping;

void Move();
void Jump();

bool IsMoving() const;
bool IsJumping() const;
  • Always separate function definitions
Function1()
{

};

Function2()
{

};
  • Space to separate operators and items inside statements.
//bad example
if((a>b)&&(a-b)>=0)

//good example
if ((a > b) && (a - b) >= 0)
  • Never use double enter.

Additional convention

  • As an XML only convention, boolean variables must be 0 as false or 1 as true.

Assets

Complete description of style, structure and ultimately content of assets and audio files is found on respective Art Bible and Audio Bible. As a general and temporary convention for these files:

  • Images are of file type .png, being .jpg only allowed in necessary cases.
  • Audio effects and samples are of file type .wav for better resource management.
  • Audio music files and soundtracks longer than few seconds are of file type .mp3.
  • Map files are of file type .xml.
  • Font files are of filetype .ttf.

Build Delivery Method and Data Layout

Releases are held on GitHub. Format of submiting new releases follows these steps:

  1. Compile project and copy outut file .exe.
  2. Add executable to premade folder with:
    • All required .dll.
    • Subfolder containing all assets and audio files.
    • README.md and LICENSE files.
  3. Zip all items inside the folder into a .zip container.
  4. Upload release file to GitHub and add description.

Data layout during development organizes project files as default by Visual Studio, in addition there is a certain structure for those folders which include working libraries, assets, and documenting files used.

Version List

Version list for this project will be updated every time a release is made. At the moment of delivering of this document, the project is yet at an early development stage and so this list remains blank until first release.

Clone this wiki locally