-
Notifications
You must be signed in to change notification settings - Fork 0
3. Tech Design Document
-
2.1 Target Hardware
2.3 Requirements
-
5.1 General
5.2 Comment Policy
5.4 Intendation
Document TDD (Tech Design Document) is meant to analyse all the specifications of the technical profile which this project follows.
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.
The resulting game of this project is originally made for PC only. Expected peripherals needed to play the game: monitor, keyboard and mouse.
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.
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 |
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
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
The programming of the project is "strictly" ruled by the following custom set of code conventions.
- 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.
- 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.
- Words should be full so that they are more easily understood (
positionoverpos). - 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
isorhasdepending 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 classtype 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()overPlayer::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;- Curly braces
{ }should always be used, regardless of the amount of code lines theif ()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.
- Use
switchstatements overif ()and multipleelse if (). - Use
for()overwhile()loops. - Concerning increments, use
++varovervar++, as it is less resource consuming. var++ returns BEFORE being incremented while ++var returns AFTER being incremented.
- All
classandstructelements will be organized following this rule:
- First
publicthenprivate. - Order of elements is variables, then main functions for updating object, and last util functions.
- 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.
- As an XML only convention, boolean variables must be 0 as
falseor 1 astrue.
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.jpgonly allowed in necessary cases. - Audio effects and samples are of file type
.wavfor 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.
Releases are held on GitHub. Format of submiting new releases follows these steps:
- Compile project and copy outut file
.exe. - Add executable to premade folder with:
- All required
.dll. - Subfolder containing all assets and audio files.
-
README.mdandLICENSEfiles.
- All required
- Zip all items inside the folder into a
.zipcontainer. - 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 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.