Rythe-Engine is an MIT-licensed, data-oriented C++20 game engine built to make optimal use of modern hardware, aimed at C++ engine and gameplay programmers who want an async-compute core and an ECS without assembling those pieces themselves.

What it is

Rythe-Engine is a data-oriented C++20 game engine whose core is built on an async-compute-minded design to handle logic, with an ECS handling the data. That split lets the engine, its other modules, and the editor use all the compute power they can find, and is what makes the architecture extremely modular: the engine's modules are separated into optional git submodules, with links in their respective folders under rythe/engine/. The code identifies itself with a legion prefix (legion::Module, legion::System, LEGION_ENTRY), and the project builds by default with Visual Studio 17 (2022) using Clang-cl and C++20, or with Clang++ on Linux.

The concrete problem it solves is the plumbing a C++ team otherwise writes and maintains by hand: entity storage, job scheduling, pipeline scheduling across multiple main threads, a thread-safe eventbus, virtual filesystem, input, logging, audio, and a rendering pipeline. Rythe already defines the C++ entry point in its own source code, so a project does not write main; instead it defines reportModules to attach modules, then declares its own systems and components. Rythe does not support compilation to a DLL, so consumers copy the include folder into their project and link the libraries they compiled.

Key capabilities

• A data-oriented, thread-safe ECS with "archetype" support for entity storage.
• An async-compute core with job scheduling, pipeline scheduling for multiple main threads, and modular process chains.
• Rendering with PBR, a post-processing stack, a particle system, automatic exposure, a modular rendering pipeline, custom shader support and a shader standard library, plus the lgnspre shader precompiler and GLTF and OBJ import.
• Physics with convex quick-hull generation and the Diviner physics engine, with dynamic destruction marked as a preview feature.
• Audio with spatial and non-spatial playback, the Doppler effect, MP3 and WAV support, and stereo-to-mono conversion.
• An OpenCL compute frontend with support for buffers and textures and high-level abstractions.
• Supporting systems: a thread-safe eventbus with unique and persistent events, a virtual filesystem, serialization and scenes (Alpha), a custom input system, custom logging support, and math extensions to GLM.

Who uses it and how

• Windows teams building with Visual Studio 2022, Clang-cl and C++20, generating a solution through the premake scripts in the tools folder.
• Linux teams compiling with Clang++, accepting that no default IDE support is provided for that platform.
• Engine programmers extending the engine by subclassing legion::Module and reporting content from setup() via reportComponentType and reportSystem.
• Projects consuming Rythe as source: copy the include folder and link the compiled libraries, since DLL builds are not supported.
• Gameplay teams that want ECS, scheduling, rendering and audio already present and add only their own components and legion::System classes.

Getting started

Generate the gmake, make, or Visual Studio files with the premake bundled in the tools folder — for example VisualStudio22-All.bat — then compile and link the libraries. In your program, define the entry macro (the README body says RYTHE_ENTRY while its code example uses LEGION_ENTRY) and implement reportModules(Engine* engine).

How it compares

No list of paid products this project replaces is provided in the facts, and no comparable engines are named either; the only related identifier, legion, is Rythe's own code prefix, not a rival tool. On the evidence given, it stands alone in this registry.

When to use it — and when not to

A self-hoster must operate a full C++ toolchain — premake plus Clang-cl on Windows or Clang++ on Linux, with their own IDE configuration on Linux — and must build from source, since no DLL or hosted option is documented. Do not pick it if you need a drop-in library with your own main() entry point, a dynamically linked build, or a stable released API: serialization and scenes are marked Alpha and dynamic destruction is only a preview feature. The README is also thin on deployment guidance, so teams without C++ build experience should expect to invest time in the toolchain.

#define LEGION_ENTRY
#include <core/core.hpp>

#include "mymodule.hpp"
using namespace legion;

void LEGION_CCONV reportModules(Engine* engine)
{
    engine->reportModule<MyModule>();
    engine->reportModule<app::ApplicationModule>();
}

#include <core/core.hpp>
#include "mysystem.hpp"

class TestModule : public legion::Module
{
public:
    virtual void setup() override
    {
        reportComponentType<my_component>(); // Report a component type
        reportSystem<MySystem>(); // Report a system
    }
};

#include <core/core.hpp>

struct my_component { int myVal; };

class MySystem final : public legion::System<MySystem>
{
    virtual void setup()
    {
        createProcess<&MySystem::update>("Update");
    }
    
    void update(legion::time::span deltaTime)
    {
        // Do stuff every frame on the update thread
        static auto myQuery = createQuery<my_component, position>();
        mQuery.queryEntities();
        for(auto entity : myQuery)
        {
            // Runs for every entity that has both my_component and a position component.
        }
    }
};