6. Tech Design Document
Fantasy Brawl
Checkthedog
10/03/2019
TDD v1.0
- 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 Fantasy Brawl. 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.
Disclaimer: this document can be updated during the development of the game.
- 4 players multiplayer
- 4 camera split-screen
- Free movemnt
- Projectile attacks mechanic
- Storm/Circle mechanic
The Target Hardware is the CITM computer were all game deliveries will be played for evaluation.
| Element | Requirements |
|---|---|
| OS | Windows 10 Pro |
| RAM | 8192 MB |
| CPU | Intel Core i7 3.40Ghz |
| GPU | Nvidia Quadro 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 through other branches (Only non-code related commits can be done directly to develop) |
| 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 (with any specification required) | Feature branches (as there can be many) are for big & important feature implementations (mainly described in the version list) which may require some time. |
Use this chart to make sure you follow the branching rules for branching off and merging branches.
| Branch | Branching-off | Merges into |
|---|---|---|
| master | ||
| hotfix | master | develop, master |
| develop | master | |
| release | develop | develop, master |
| feature | develop | develop |
We branch off develop from master, in develop we will be implementing features and fixes from other branches, only non-code related commits can be done here. This will be our main branch.
Whenever a new feature or small bugfixes must be implemented, we will crete a feature branch branched off from develop. Whenever we finish our feature, code department or the assignees assigned by code department members will review the code and allow the merge back to develop. Feature branches are not expected to have a long lifetime, they should always be finished and merged back to develop ASAP or less than a week.
Whenever we need to make a release, a release branch will be created (branched off from development), were we will draft and fix the errors the release may have. When we're happy with the release, the branch will be merged into master and into develop.
The master branch will only contain commits of production ready code tagged along each version (merged into master by the latest release branch).
Hotfix branches will only be created in case that the code in master has a big problem or issue that must be fixed ASAP. They will be merged into develop and master.
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.
This is a small overview so that if you've already read the document you can have a reminder of the most critical things to remember regarding naming.
| 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;
- Bool variables must have
isas prefix
bool is_visible;
bool is_alive;
- 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 loaded from an 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.
-
Forloops should be used as default loop, try to avoid using while loops (if possible of course), they are more useful for specific situations but most times they can be substituted byforloops
// 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" />
This is a basic UML for the main classes of our game, this UML is updated to follow the changes that have appeared throught the development process.
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
Player movement Map collisions
Gamepad input
All player animations
Player aim system
UI with basic menus
First map Player particle system
4 cameras & 4 players Character selection screen
Champion abilities (attack, super and shield) In-game core loop
v0.5 Vertical Slice
Music & FX
Storm mechanic Player scores In-game UI
All champions implemented Auto-aim & new gamepad input New shield animation
Random music each game Added volume & FX in options screen
New in-game UI art
New map
New champion selection screen UI movement with gamepad
v0.9 Alpha
Particle hitbox marker
Bug fixs More improvements
Polish
Final Bug fixing