Project Architecture

Tree

The project is composed of several directories, each with a specific purpose:

Directories

Documentation

The /docs directory contains all the documentation for the project, including the Sphinx configuration file, the index.md file, and the meta directory.

This is where the project’s documentation is written and built from. The index.md file is the main entry point for the documentation, and the meta directory contains all the Markdown files that are included in the documentation.

When adding a new feature or component to the project, make sure to write the documentation for it in the /docs directory.

Here is how the /docs directory is structured:

/docs
├── index.md
├── meta
│   ├── architecture.md
│   ├── contributing.md
│   └── requirements.md
├── cmake
│   ├── engine.md
│   ├── subsystem.md
│   ├── component.md
│   └── etc.
├── engine
│   ├── hal
│   │   ├── display
│   │   ├── input
│   │   ├── filesystem
│   │   └── etc.
│   ├── subsystem
│   │   ├── graphics
│   │   │   ├── class_a.md
│   │   │   ├── class_b.md
│   │   │   └── etc.
│   │   ├── input
│   │   │   └── etc.
│   │   └── etc.
│   ├── game
│   ├── etc.
├── rtype
│   ├── gameplay
│   │   ├── boss.md
│   │   └── etc.
│   ├── network
│   │   ├── client.md
│   │   └── etc.
│   └── etc.
└── etc.

Each feature or component should have its own directory in the /docs directory, and each class or module should have its own Markdown file, unless if it is a small or straightforward feature to document.

Tip

If a feature or component produces a Markdown file that is too long, consider splitting it into multiple sub-files.

Proof of Concepts

Proof of concepts (POCs) are used to prototype new features or components before integrating them into the project.

The /poc directory contains all the POCs for the project. Each POC should have its own directory in the /poc directory, demonstrating the feature or capability that is being prototyped.

Here is how the /poc directory is structured:

/poc
├── reflect_cpp
│   ├── main.cpp
│   ├── CMakeLists.txt, Makefile, build script or instructions
│   └── etc.
├── graphics_subsystem
│   ├── main.cpp
│   ├── CMakeLists.txt, Makefile, build script or instructions
│   └── etc.
├── etc.

When developing a new feature or component, consider creating a POC in the /poc directory to prototype the feature.

The prototype does not need to be very complex, but it should demonstrate the core behavior of the feature or component.

Include and Source Directories

All of the include/ and src/ directories contain the source code for the project.

The folder tree is mirrored in both directories, with the include/ directory containing the header files and the src/ directory containing the source files.

Here is how the /include and /src directories are structured:

/include
├── engine
│   ├── subsystem
│   │   ├── graphics
│   │   │   ├── class_a.hpp
│   │   │   ├── class_b.hpp
│   │   │   └── etc.
│   │   ├── input
│   │   │   ├── class_a.hpp
│   │   │   ├── class_b.hpp
│   │   │   └── etc.
│   │   └── etc.
│   ├── game
│   └── etc.
└── etc.
/src
├── engine
│   ├── subsystem
│   │   ├── graphics
│   │   │   ├── class_a.cpp
│   │   │   ├── class_b.cpp
│   │   │   └── etc.
│   │   ├── input
│   │   │   ├── class_a.cpp
│   │   │   ├── class_b.cpp
│   │   │   └── etc.
│   │   └── etc.
│   ├── game
│   └── etc.
└── etc.

Tests

(Work in progress, currently not implemented)

Continus Deployment and Integration

BBOC uses GitHub Actions to automate quite a few things, including:

  • Generating the static website documentation from the /docs directory

  • Mirroing the master repository to the Epitech repository

  • Building the project and running the tests

The GitHub Actions workflows are defined in the .github/workflows directory, and each workflow is defined in its own YAML file.

The tasks performed by the workflows are pretty straightforward, self-documenting and should not require any manual intervention in most situations. Should a workflow fail, the logs should provide enough information to diagnose the issue and fix it.

CMake Building System

The project uses CMake as its building system. The CMakeLists.txt file at the root of the project is the main entry point for the building system.

Each subdirectory has a CMakeLists.txt file that is included in the main CMakeLists.txt file.

You can get more information about the CMake scripting structure by browsing through the CMake Building Architecture page.