Tech Design Document
- Target hardware
- Performance budget
- UML
- Code Style
- Branching policy
- Version list
- External libraries and tools used
- Build delivery method
| Component | Requirements |
|---|---|
| CPU | Intel Core i7-9700 3.00 GHz |
| GPU | Nvidia GeForce GTX 1050 Ti |
| RAM | 16 GB |
| Memory disk | 220 MB |
| OS | Windows 10 |
| Component | Requirements |
|---|---|
| CPU | Intel Core i7-2720QM 2.20 GHz |
| GPU | Integrated |
| RAM | 8 GB |
| Memory disk | 220 MB |
| OS | Windows 10 |
- The game must run at 60 FPS in order to get a fluid gameplay.
- Update method shouldn't exceed a third of the memory processing.
To create the game entities we will be following this structure though it is subject to change through development.
This rules will be applied during the development of this game:
- Useful to make code readable as possible.
- Short and descriptive names.
- Mustn't use no meaning names.
Ex. int gp - Variables will be written always without capital letters.
Ex. int AMMO | int ammo - Variable with more than 1 word must be spaced with ‘_’.
Ex. int player_life
- Try to think in a verb that will describe the action that it's going to do that function.
Ex. EatFood() - Unlike variables, functions doesn't have space between words.
Ex. Read_Book() | ReadBook() - Use of capital letters must be done in first letter of each word.
Ex. walkaway() | WalkAway()
- Try always to simplify arithmetic operations syntax.
Ex. life = life + 100 | life += 100 - To optimize computer calculation times, try to multiply instead of divide.
Ex. 100/2 | 100 * 0.5
- Identation style when using braces after conditions or loops. First brace will be right on the same line as condition or loop.
Ex. if(condition){
stuff
}else{
stuff
}
- If conditions using just one line must be written in the same line, without braces {}.
Ex: if(life <= 0) Lose(); | 1 Line
Ex.2: if(life <= 0) { Lose(); } | 4 Lines: 1 for condition, 2 each brace , 1 for content.
PROS: Readable code and less lines for same stuff. 1 line vs 4 lines.
- Important block codes that aren't part of any function will be titled with:
/**/ - Try to comment whenever you can. Think about if need to be commented or not
- Always make a brief description about each function in header files, these will be supported by function names.
- When naming a file it must be named the same way a function would, with capital letters for the first letter of each word. Ex.
entitymanager.h | EntityManager.h
When declaring variables or using them in code if a big set of variables is put together they must be grouped and separated with an intro in order to difference them more easily. It shouldn't be:
- int life;
- iPoint position;
- bool is_grounded;
- iPoint last_position;
- int damage;
It should be:
- int life;
- int damage;
- iPoint position;
- iPoint last_position;
- bool is_grounded;
During the development of the game we will be using three branches:
- Master: for fully working versions and releases.
- Programming: to implement new features.
- UI: for UI implementation.
Normally all changes made in programming will be merged into master once it has been tested that these new features all work properly and there are no bugs. When a release date is close this will be made from the master branch. The UI branch should mainly interact with the programming one, but in the case that the differences between the two branches are very few and a release must be done, UI can directly be merged into master.
In the production plan it is explained in which sprint we are going to implement each feature, here we will determine in which version it will be included.
- All art included into the project.
- Basic entity system.
- Basic movement implemented.
- Zoom.
- All faction entities working.
- The player can create multiple entities.
- Group movement.
- Buildings basic functionality.
- Map fully designed and created.
- Random map functionality implemented.
- Resource management.
- Event system.
- Buildings fully implemented.
- Pause menu.
- Fog of War.
- Wild animals.
- Particles systems implemented.
- Minimap.
- Loading screen.
- Buildings can be upgraded.
- Main menu.
- Intro video.
- Units can be upgraded.
- Fully functional UI.
- Alpha installer.
- Deathclaws.
- Polished game.
- No bugs left.
To automatically make builds when we upload code and content to the master branch we will be combining cmake with GitHub actions. This won't only let us automatize the building method it will also let us test our code automatically giving us extra time for development or finding errors we wouldn't have found in any other way.