FireStorm Engine

FireStorm is my own experimental C++ game engine, inspired by Unreal Engine. Source codes are not yet available.

It is currently in an early stage with only a few functional modules. It is absolutely not intended to be ready for production, other engines are more advanced and more efficient (like Unreal).

FireStorm is designed around 3 concepts: Ease of use, Optimization and Modularity.

Ease of use

Build System

FireStorm is written in C++ and use CMake as build system. CMake very good tool for C++ programmers, despite obvious drawbacks (Weird syntax !!!). Meson is a good alternative, with a really good syntax but without the possibility to create its own functions (Meson developers explain that this would make the language "Turing-complete").

Handling dependencies

FireStorm Engine use Conan to manage dependencies. Conan is a C++ dependency manager written in Python. It is a good tool because it is "project-centric" (each project has is own dependency list) unlike VCPKG which is "system-centric". Conan allows the user to avoid installing dependencies himself. It also allows the user to have an excellent integration with CMake and to be able to create his own packages (the main defect of Hunter and VCPKG). It also has an huge list of officially supported libraries.

Code generation and metadata

FireStorm use C++ reflection. Since C++ lacks such a feature, I had to create a code generator to easily complete classes with reflection. This kind of process is widely used, for example by Unreal Engine or Qt. It works similarly to Unreal Header Tool. It permits to choose the elements able to use reflection with generate useless code. It uses macro like UHT: FIRECLASS, FIRESTRUCT, FIREENUM, FIREPARAM, FIREPROPERTY et FIREFUNCTION.

Here is an example of use to make a reflective class :

namespace firestorm
    FIRECLASS(Abstract, DisplayName = "Actor")
    class AActor : public FFireObject

        FIREPROPERTY(EditAnywhere, Help = "Actor velocity")
        float Speed = 10.0f;

        FIREFUNCTION(Getter = "Speed")
        void SetSpeed(float InSpeed);


Reflection macros use a DSL close to that of Unreal Engine. However, the FireStorm's DSL is strict, case-sensitive and extensible. For example, With Unreal, UCLASS(DisplayName = "Actor") and UCLASS(DisplayName = Actor) are same. With FireStorm, absence of quotation marks (SECLASS(DisplayName = Actor)) is considered as a syntax error by design.

FHT (FireStorm Header Tool) implementation use Clang libraries for parsing C++ code.It permits to use more C++ features than UHT like namespaces. This tool retrieves classes, structures, enumerations, attributes, methods and parameters marked with C++ annotations (cad [[annotate("...")]]) and parses the annotation string with a lexer/parser build with Flex and Bison.

FireStorm Header Tool is extensible. Each engine and game module can add specifiers and generate code. For example, an RPC module can add RpcClient, RpcClient et RpcBoth specifiers.

Manage assets

FireStorm Engine has two terms for designing assets.

The asset import process is very similar to Unity import process. The user must place the assets in the Content folder. He must then import them manually (via a tool in the interface). The engine will then associate a meta file to each asset. The meta file allows the engine to transform an asset into a resource. This meta file contains the ID of the resource and various import parameters (these parameters vary depending on the type of asset being imported). Each time an imported asset is modified, the engine automatically converts the asset into a resource.

Asset & data management follows those rules:


Scene compilation

During compilation, the scenes initially structured in XML format are transformed into C++ code. This will then be compiled into a shared library. This method should allow a faster loading of the scenes. However, the performance of this method is purely theoretical.

File system

FireStorm uses CFS. For more information about CFS, see here.


Module architecture

FireStorm is split in several parts:

Most of the modules use delayed loading. The engine is responsible for loading module dependencies.