Skip to content

3. Tech Design Document

Jump to bottom
Eweer edited this page Mar 13, 2023 · 19 revisions
Table of contents
  1. Development hardware and software
  2. Main releases and Build delivery method
  3. Coding style
  4. File Organization

Development hardware and software

Hardware

Recommended requirements we are aiming for are:

  • CPU: Intel Core i5 4460 or similiar
  • Memory: 8GB DDR3
  • GPU: Nvidia Geforce GTX 750 or similiar

User be able to change the following options that impact the game performance: * Game resolution will be 1280x720 at 60 fps, with the possibility to play either in windowed mode or fullscreen. * User will be able to turn VSync on and off. It will require a game restart.

Regarding the hardware used for production, we'll use the ones stated in the production plan. If it's not possible or any inconvenience happens, we'll use our own personal computers.

Software

Game will be programmed in C++20, with the following software being used:

Code

  • GitHub Desktop
  • Visual Studio 2019/2022

Assets

  • Adobe Photoshop
  • Aseprite
  • SmearFX
  • Tiled

External libraries

  • SDL
  • PugiXML

Main releases and Build delivery method

Game will have three main releases that will be available in Github, they will be:

  • v0.5 (Vertical slice)
  • v0.8 (Alpha)
  • v1.0 (Gold)

All of these builds will be created on the profile "Release" that Visual Studio 2019 offers. In "Debug" mode will be done most of the code and we will pass it to "Release" in order to create the corresponding builds.

Coding Style

Branching policy

Everyone should work on their own branch (develop branch), and every time we finish a functionality and QA tested, then push towards the release branch (main).

The #define guard

  • All defines and macros should be in all caps separated by underscores if there are multiple words.
  • All header files should have #define guards to prevent multiple inclusion.

#ifndef FOO_H_

#define FOO_H_

...

#endif FOO_H_

Variable naming

  • Variables should be in camelCase.
  • Variable names should specify what they do:
    • If a variable is used instantly and never used again in an obvious usage (e.g iterator in a while), it's fine with it being a single letter (e.g.: i).
    • If a variable is used in multiple parts of the code, be as long as necessary (e.g.: tilesFromPlayerToEnemy).
  • Do not deny boolean variables (e.g.: "notDead"), use: "isFalling", "isAlive" instead.

Enumerations

  • Always use enum class.
  • Enums should be in TitleCase.
  • Members should be in all caps with underscores if multiple words.

Class and Structs

  • Always in TitleCase.
  • Do not mix public and private members.

Miscellaneous

  • Brackets after functions should go on a new line.
  • Use TABS instead of 4 spaces.
  • Usage of constexpr is highly advised instead of the C-style macros.
  • Use nullptr instead of NULL.

File Organization

File formats encode information so that it can be accessed by the same or similar software programmes in the future and accessed from any computer and some mobile devices. Selection of file format is often determined from the software and hardware that we initially use to encode the information. With that being said, here we have the format files we will be using for the project:

Art

  • Art assets should be in *.png.
  • Sprites with few (2-) or no animations:
    • Should be encapsulated in a folder.
    • Should be named as: Identifier of item + image variation number + "_" + name of animation + frame number. Example:
    • Items
      • arrow0_shine000.png
      • arrow0_shine001.png
      • arrow0_static000.png
      • arrow1_shine000.png
      • coin0_rotation000.png
      • ...
  • Sprites with a large (3+) animations
    • Should have their own folder per animation.
    • If the images are part of a longer animation, they should be named: name of the animation followed by the frame number.
    • Example:
    • Characters
      • Player
        • Idle
          • idle1.png
          • idle2.png
        • Attack
          • ...
        • Run
          • ...
      • Enemies

Audio

  • File format has to be either *.ogg or *.wav.

  • It has to be stored in the corresponding SFX or music folder.

  • In case there are multiple sounds related to each other (e.g.: enemy sounds on battle) they should be inside a folder. Example:

  • Example:

    • Audio
      • SFX
        • Battle
          • Enemies
            • Slime
              • slime0_hit.ogg
              • slime0_death.ogg
              • slime0_attack.ogg
          • Player
            • ...
        • Overworld
          • ...
        • Example3
          • ...
      • Music
        • ...

Map assets

  • Tiled format file should be *.tmx.
  • Maps in tiled should NOT have tileset data embedded on them. It should be in their own *.tsx file.
  • The *.tsx file should be stored in the same folder as the *.png.

Data saving

  • Configuration files and databases should be on .xml format.
Clone this wiki locally