# Rythe-Engine and a data-oriented C++20 game engine built on Legion

> Rythe-Engine is a C++20 game engine whose core separates logic from data, with an entity component system for the data side and an async compute-minded design for the logic side, extended with rendering, physics, audio, an OpenCL compute frontend and a shader precompiler. The interesting part is the module layout, since each subsystem is an optional git submodule, and the interesting constraint is that the engine is built with premake and Clang-cl rather than a mainstream build system.

**Rythe-Interactive/Rythe-Engine** — Rythe is a data-oriented C++20 game engine built to make optimal use of modern hardware.

- Repository: https://github.com/Rythe-Interactive/Rythe-Engine
- Website: https://rythe-interactive.com
- Stars: 534 · Forks: 30
- Language: C++
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/rythe-interactive-rythe-engine

## The core idea: logic in one place, data in another

Rythe-Engine is described as a data oriented C++20 game engine built to make optimal use of modern hardware, and the sentence that explains how is the one about the core. Rythe's core is built on an async compute minded design to take care of the logic and an ECS to take care of the data. The stated result is that the engine, its other modules and the editor can utilize all the power they can find and be extremely modular.

That split is the whole architecture, and it is not a slogan. The logic side is a set of schedulers and process chains, and the data side is an entity component system with archetype support, which is the storage layout where entities of the same component combination live together in memory rather than scattered across separate arrays. That layout is what makes iteration over a large set of entities cache-friendly, and it is the reason the engine calls itself data oriented.

The topic list names the pieces the engine is assembled from: 3d-graphics, 3d-audio, async, audio, cpp20, data-oriented, ecs, legion, opengl, physics, rendering, scheduling. The presence of legion and legion-engine among them records the project's own history, since this engine grew out of the Legion ECS project and the documentation link still points at docs.legion-engine.com.

The audience is a C++ game developer, and the audience for the submodules is slightly different: the engine is a platform for other people to build modules on, and the readme's structure of optional git submodules under rythe/engine/ is the clearest statement of that.

The primary language is C++, the licence is MIT, the default branch is develop/current, and the last push was on 2026-10-01. There are no GitHub releases, and the homepage is rythe-interactive.com.

## The module system and what each subsystem covers

The engine's modules are separated into optional git submodules, with links to them in their respective folders under rythe/engine/. That single sentence explains a lot about the project. You do not get a monolithic engine binary; you get a core plus a set of subsystems you choose to bring in, each of which can be replaced without touching the others.

The feature list is organised by subsystem, and it is more specific than most engine feature lists.

Rendering has a post-processing stack, a particle system, PBR, Imgui, automatic exposure, a modular rendering pipeline, custom shader support with a shader standard library, a shader precompiler called lgnspre with its own repository, and GLTF and OBJ support.

Physics has convex quick hull generation and the Diviner physics engine, with dynamic destruction listed as a preview feature.

The ECS section is short: data oriented, thread-safe, and with archetype support. The event system has a thread-safe eventbus, unique and persistent events, and easy extensibility. Audio covers spatial and non-spatial audio, a Doppler effect, MP3 and WAV support, and stereo to mono conversion.

Compute has an OpenCL frontend with support for buffers and textures, plus high level abstractions.

The miscellaneous section is where the infrastructure lives: a virtual filesystem, serialization and scenes marked alpha, job scheduling, pipeline scheduling for multiple main threads, modular process chains, custom logging, a custom input system, an extended standard library, a modular architecture, and math extensions to GLM.

The rendering and compute lists are where the modern hardware story sits. Automatic exposure, a modular pipeline and a shader precompiler are the tools you need for a modern renderer, and the OpenCL frontend with high level abstractions is a GPU compute path that goes beyond the graphics API. Together with the async compute core, that is a coherent bet: the CPU-side logic is scheduled, the data is in archetypes, and the heavy numeric work is pushed to the GPU where the hardware allows it.

## Building it: premake, Visual Studio 2022 and Clang-cl

The build story is specific and it is where most adopters will hit friction first.

The engine is by default built using Visual Studio 17, which is 2022, with Clang-cl and C++20. For Linux there is no default IDE support, though you can still compile the engine using Clang++.

To generate the gmake, make, or Visual Studio solution, you use premake bundled in the tools folder, and for Visual Studio there is an example batch file, VisualStudio22-All.bat, which can be used. As of now, the readme says, Rythe does not support compilation to DLL. After building, you copy the include folder to your project and link the libraries you compiled.

The absence of DLL support is a meaningful constraint for an engine intended to be modular. A plugin architecture that loads shared libraries at runtime is a common way to extend an engine, and Rythe's answer is instead to compile the modules you want into the application. That is a defensible choice, since it removes a class of runtime failure and simplifies distribution, but it means the module boundary is a build-time boundary, and a downstream user cannot ship a module to a customer who already has the engine installed.

The premake workflow is the other thing to plan around. It is a small amount of setup compared with a full CMake project, and the dependency libraries are all vendored: the readme notes that all libraries can already be found in the deps folder, and lists them as OpenAL Soft, GLM, OpenGL, GLFW, OpenCL, TinyOBJ, STB image, Cereal, Spdlog, Minimp3, and the Legion shader preprocessor lgnspre.

Vendoring the dependency set is what makes the build self-contained, and it is also what makes it heavy. The repository root has build/, libraries/, modules/, applications/, tools/, docs/, the rythe-build-system directory, and an xcopyexclude file, which is a Windows batch file exclusion list, another sign of the Visual Studio-first workflow.

## Writing your first module, systems and components

The setup instructions assume you are writing a module rather than using the engine, and they are short.

Rythe already defines the C++ entry point in its own source code, so to start making a program you define RYTHE_ENTRY and include any of the module main include files:

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

Since the entry point is already defined, you need to define a different function to start working with Rythe, and that function is reportModules:

```cpp
#include "mymodule.hpp"
using namespace legion;

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

The two reportModule calls are how a module becomes visible to the engine, and the pattern is that the engine starts itself with no modules attached until you report them.

A module is a class deriving from legion::Module, and its setup function reports the component types and systems it provides:

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

And since the engine uses an ECS for all of its core functionality, a system defines its own components and its own work. The example system creates a process in setup, and the process body iterates a query:

```cpp
    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.
        }
    }
```

Two details carry the design. The query is a static local, so it is built once and reused, which is the point of an archetype layout. And the queryEntities call is explicit, so the system decides when the storage is refreshed rather than having the engine refresh it behind your back, which is what lets the work be scheduled onto an update thread.

The process model is what connects the ECS to the async core. A system creates processes, and the scheduler decides which thread they run on.

## The people behind it, and the state of the project

The authors section is unusually specific about who did what, which is a good sign for a project of this size and a useful way to judge whether the parts you care about are actively worked on.

Glyn Leine is the technical director covering core architecture, ECS, scheduling, import pipeline and renderer. Raphael Baier covers the filesystem, build pipeline, GPGPU compute, the input system and the meta layer. Raphael Priatama does physics, Jelle Vrieze does audio and 3D audio, and Rowan Ramsey does serialization.

The MIT licence applies, and the repository also carries AUTHORS.md, a code of conduct, a CONTRIBUTING.md, a .clang-format and a .clang-tidy, a .clang_complete, a .runsettings file, and a .nojekyll marker.

The project is not archived and the last push was on 2026-10-01, and there are no GitHub releases, so a consumer takes the default branch rather than a tagged version. The build and analyze workflow badges show a continuous integration setup with separate build and analyze jobs, and there is a Discord community.

For an adopter, the sensible framing is that this is an engine in development with a serious architecture and a small team behind it, where the modules you need are the ones that particular people maintain. If your interest is the ECS and the scheduling, that is the core and the technical director's area. If your interest is audio or physics, those are one person's work. That mapping is in the readme, and it is more informative than the feature list.

## Conclusion

Rythe-Engine is a good fit for a C++ developer who wants to work with a modern entity component system and an async-aware engine architecture rather than a traditional scene-graph engine, because the ECS is the organising principle for every subsystem including the editor. It is a poor fit if you want a finished engine with batteries included, since the modules are separate submodules and the build assumes Visual Studio 2022 with Clang-cl. Before adopting, read the module list under rythe/engine/ to see which subsystems you would actually pull in, and plan for the premake workflow, because generating the gmake, make or Visual Studio solution with the bundled premake is the first step and the engine does not support compiling to a DLL.

## FAQ

### What is Rythe-Engine?

It is a data oriented C++20 game engine built to make optimal use of modern hardware. The core is built on an async compute minded design for the logic and an ECS for the data, and it is extended with modules for rendering, physics, audio, compute and miscellaneous infrastructure.

### How do I build Rythe-Engine?

The default build uses Visual Studio 17, meaning 2022, with Clang-cl and C++20, and on Linux you can compile with Clang++ since no default IDE support is provided. You generate the gmake, make or Visual Studio solution with the premake bundled in the tools folder, for example with the VisualStudio22-All.bat file, and the engine does not support compilation to a DLL.

### How are the Rythe-Engine modules organised?

Each module is a separate optional git submodule, with links in the respective folders under rythe/engine/. The features span rendering, physics, the ECS, the event system, audio, an OpenCL compute frontend and miscellaneous infrastructure such as the virtual filesystem and job scheduling.

### How do I attach my own module to Rythe-Engine?

Define the entry point macro and include a module main header, then implement a reportModules function that calls engine->reportModule for each of your modules. A module is a class deriving from legion::Module whose setup function reports its component types and systems.

### What does Rythe-Engine use for its entity component system?

The ECS is data oriented, thread-safe and supports archetypes, and the project is built on the Legion ECS. Systems create processes and use queries over components, and the query is built once as a static local and refreshed explicitly with queryEntities.

### What licence does Rythe-Engine use?

The MIT Licence, with the LICENSE file at the repository root. The last push was on 2026-10-01, the default branch is develop/current, and the project publishes no GitHub releases, so consumers track the branch rather than a tag.

## Sources

- [Issues](https://github.com/Rythe-Interactive/Rythe-Engine/issues)
- [License: MIT](https://github.com/Rythe-Interactive/Rythe-Engine/blob/develop/current/LICENSE)
- [Project website](https://rythe-interactive.com)
- [README](https://github.com/Rythe-Interactive/Rythe-Engine/blob/develop/current/README.md)
- [Rythe-Interactive/Rythe-Engine on GitHub](https://github.com/Rythe-Interactive/Rythe-Engine)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rythe-interactive-rythe-engine