Building the Project¶

Pre-requisites¶

Make sure to take a look at the External Dependencies page first before proceeding to the building process.

The building process requires a powerful machine with a decent amount of RAM and a good CPU.

What follows is a table of different configurations that were used to build and develop on the project:

We thus recommend you the following configuration:

• 16GB of RAM

• A decent CPU with at least 4 cores

• 16GB of free storage space

• A decent integrated, discrete or dedecated GPU

  • Intel Iris Xe, NVIDIA GTX 1650 or AMD Radeon RX 5500M are good choices

It is possible to build the project on weaker systems, but be prepared for longer build times, potential issues, crashes, excessive swapping, etc.

Building the Project¶

Use the build.sh or build.ps1 script according to your build environment; these two scripts are for Linux and Windows respectively.

These scripts all achieve the same steps:

1. Create a build directory in the root of the project.

2. Generate the build files using CMake. Depending on the platform, the script will use the appropriate generator.

3. Build the project using the generated build files.

JOBS=4 ./build.sh

The build process will generate a set of binaries which can be found in build/src/game.

A game is always going to generate a server and a client binary file. For example, the rtype game will generate a rtype_server and a rtype_client binary file.

Debugging the Project¶

During development, it is possible to debug the project with a debugger and other tools to track down bugs, memory leaks, undefined behavior, etc.

On Linux¶

Use the build.sh script with the following parameters:

./build.sh -DCMAKE_BUILD_TYPE=Debug

This will produce a debug-enabled build of the project, enabling both debugging symbols and verbose logging.

Debugging with GDB¶

You can run gdb with the path to the binary you want to debug:

gdb ./build/src/game/rtype_server

Check out the GDB documentation for more information on how to use the debugger. Integration with IDEs such as Visual Studio Code, CLion, etc. is also possible – check their respective documentation for more details.

Debugging with Valgrind¶

You can run valgrind with the path to the binary you want to debug:

valgrind ./build/src/game/rtype_server

Check out the Valgrind documentation for more information.

Debugging with AddressSanitizer¶

To enable AddressSanitizer, use the following parameters with the build.sh script:

./build.sh -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS="-fsanitize=address"

This will enable AddressSanitizer in the build, which can be used to detect memory leaks, buffer overflows, etc. You can then run the binary as usual; this will output the errors in the console.

Building Options¶

Target Types¶

The project can be built in either Debug or Release mode. This can be controlled by setting the CMAKE_BUILD_TYPE option as described in the CMake documentation:

./build.sh -DCMAKE_BUILD_TYPE=Release ...

Release Mode¶

In Release mode, the project is built with most of the compiler optimizations enabled, along with the global logging level set to INFO.

Debug Mode¶

In Debug mode, the project is built with the logging level set to TRACE. This mode is required for most debugging tools to work properly.

Additional Options¶

The build.sh and build.ps1 scripts can take additional options to customize the build process. These options are passed the same way as you would with the cmake command, regardless of the platform.

BBOC_VERBOSE_LOGS¶

This option enables verbose logging in the project which basically sets the logging level to TRACE, even if the build is in Release mode:

./build.sh -DBBOC_VERBOSE_LOGS=ON ...

This can be useful to track down issues that can only be reproduced in Release mode.

Cleaning-up¶

To clean-up the build folder, just delete the build directory generated at the root of the project.