-
Notifications
You must be signed in to change notification settings - Fork 0
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
- Introduction
- Technical goals
- Target hardware
- Performance budgets
- Branching policy
- Build delivery method
- Code style
- UML
- External libraries & Tools
- Version list
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.
- 4 players multiplayer
- 4 camera split-screen
- Multiple characters selection
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 |
The game must run at 60 fps at least on the described target hardware.
To ensure a good repository workflow we will follow the GitFlow branching policy
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 |
We will be using AppVeyor to make the releases of the game. For each feature planned in each version we will create a release.
Language: all code and comments must be written in English.
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. |
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)
- 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.
- 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.
- 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.
- 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
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.
- Bool variables must be 0 or 1
- Elements that have no children should always be written in this form
<life value="350" />
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.
Base Code
Map Implementation
4 Gamepad Multiplayer Input
Players movement
1st Character animations
Player colliders
4 player splitscreen cameras
Camera movement
1st Character attack
1st Character Special Ability
Basic in-Game UI
Basic sounds implemented
Menus
Polish
Bug Fixing
Final polish
Final Bug fixing
Copyright Disclaimer, allowance is made for "fair use" for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use." All content is owned by its respective creators, no copyright infringement is intended, its use is solely and strictly educational.