RaZ is a C++20 ECS engine written to be read, with a demo for every subsystem

An engine whose stated purpose is learning

RaZ is a modern and multiplatform 3D game engine in C++20, and the README is unusually open about its motivation. Written in modern C++ with an entity component system, it is primarily developed for learning purposes. The stated design goal is that it be very intuitive and easy to use and tinker with, while trying to stay as optimized and modular as possible.

That combination of ambitions is what makes the project interesting to read. A teaching engine that throws away performance is not teaching what production code does, and an engine that hides its internals teaches little. The ECS design, the modular layout and the demo-per-subsystem structure all follow from that goal.

The name comes from the author's username, Razakhel, and doubles as a pun on the French RàZ for remise à zéro, a reset. The author says he had no particular intent behind the double meaning, other than maybe hoping the engine would reset your mind.

The scope is a full 3D engine rather than a toy: the topics attached to the repository cover rendering, a render graph, visual effects, audio, physics, scripting, OpenGL, CMake, WebAssembly, and cross platform builds in general.

The CI table tells you exactly what is verified

The README opens with a status table, and it is the most operationally useful part of the document because it is specific about gaps.

The compilation row shows a build badge for all four targets: Linux, Windows, macOS and WebAssembly, all pointing at the same RaZ.yml workflow on the master branch. So the engine is compiled on every platform it claims to support.

The unit tests row is where the honesty matters. Linux has a badge, Windows says No CI yet, macOS says No CI yet, and WebAssembly says N/A. Unit tests therefore run on Linux only, and the other platforms are covered by compilation alone.

For anyone planning to depend on RaZ, that distinction decides a lot. A change that compiles on Windows and macOS is known to build there, but a test failure on those platforms would not be caught by the project's own pipeline, so the risk sits with whoever merges the change.

Two code quality services are wired in as well, with a Codacy status badge and a Coveralls coverage badge, so static analysis and coverage reporting happen outside the CI workflow rather than being described in prose.

The examples directory is the closest thing to a feature list

The examples directory is where the engine's capabilities are actually visible, because each file is a small application that exercises one subsystem. The list is unusually broad for a learning engine.

There is minDemo.cpp and fullDemo.cpp, which read as the minimal and the maximal configurations, and showcaseDemo.cpp, which is the general showpiece. Then the subsystem specific ones: audioDemo.cpp, bloomDemo.cpp, computeDemo.cpp, deferredDemo.cpp, networkDemo.cpp, physicsDemo.cpp, scriptDemo.cpp, ssrDemo.cpp for screen space reflections, tessellationDemo.cpp and xrDemo.cpp for extended reality.

The demos directory has its own CMakeLists.txt and shared helper files, DemoUtils.cpp and DemoUtils.hpp, and an EmscriptenAssets.cmake file, which is how the WebAssembly build knows which assets to embed.

The two demos that tell you the most about the engine's shape are the compute and the deferred rendering ones. ComputeDemo implies programmable work on the GPU beyond the standard pipeline, and deferredDemo implies a deferred rendering path, which is a different frame graph from a forward one.

The rendering vocabulary in the repository topics fits: a render graph, visual effects, and OpenGL as the graphics API.

Lua for scripting, RaZor for the interface

The engine is designed to be driven from scripts. RaZ can be used with Lua, described in the README as a scripting language that is very simple to both learn and use, with a dedicated wiki page for it, and the scriptDemo.cpp example is there to show it working.

The design argument is a separation of concerns that is common in engines: C++ for the heavy lifting and the parts that need to be fast, Lua for the parts that change often and should not require a recompile. scriptDemo.cpp and the presence of a script/ directory in the repository layout are the visible end of that.

The graphical side is a separate project rather than a mode of this one. RaZor is an editor, also multiplatform, available to manipulate the engine through a graphical interface. That is a meaningful design choice. An engine that includes its own editor has to keep the editor, the engine and the data format in step, whereas a separate tool can lag or lead. The cost is that using RaZ means building two things.

The community sits on a Discord server dedicated to RaZ and RaZor, and the documentation is split between a wiki for getting started and a generated doc/ site for reference.

extern/, shaders/ and src/ in the repository root

The repository layout tells you where the engine's pieces live. The root holds CMakeLists.txt, a cmake/ directory of build modules, include/ and src/ for the engine itself, shaders/ for the graphics side, extern/ for third party code, assets/ for resources, doc/ for the generated documentation, examples/, tests/, scripts/ and a debug/ directory.

Two of those are the ones to look at first if you want to understand the engine.

The extern/ directory implies that dependencies are vendored rather than resolved through a package manager, which is common for engines that need a specific version of a maths library or an image loader. The cmake/ directory alongside it means the build is driven by CMake modules rather than a single generated script, and the whole project is CMake based, which is listed as a topic.

The shaders/ directory is a reminder that a modern engine is not only C++. A shader directory at the top level means the render graph consumes compiled shader programs, and that pipeline is part of the build rather than something you drop in as assets at runtime.

The scripts/ directory and the .gdbinit file at the root point to a developer workflow built around debugging and helper commands, and the presence of a separate tests/ directory alongside the demos means the engine is tested apart from the applications that use it.

One nightly tag, an MIT licence, and a small project family

The release record is thin in a way that tells you how the project is versioned. There is a single release, tagged nightly, dated 2025-10-25. There is no numbered version series in the tags.

A nightly tag is a rolling marker. It points at a commit rather than at a curated release, which means the tag is a snapshot of the development branch at a moment in time, and what it contains changes with every push. The last push to the master branch was on 2026-08-09, so the code has moved on since that tag by a wide margin.

For learning purposes, tracking master is usually the right choice, since the point is to read the current code. For anything you build on, pinning to a commit is the safer choice, and the README points you to the wiki and the generated documentation for getting started.

The licence is MIT, with the LICENSE file at the repository root, which is permissive enough to build on commercially.

Around RaZ there is a small family of projects by the same author, listed in the README as projects using RaZ. Atmos is an atmospheric simulation, Midgard is terrain procedural generation, and Yggdrasil is tree and foliage procedural generation. A graphics engine with the rendering done for it is exactly the foundation those generators need, and their existence is a reasonable signal about what the engine is good at.

Editorial conclusion

RaZ fits a developer who wants to read a complete 3D engine in modern C++ and follow how its subsystems fit together, and it fits a project that needs a WebAssembly build of a 3D scene without licensing a heavyweight engine. It is the wrong choice for a commercial game on a schedule, since the project states it is developed primarily for learning purposes and ships only a nightly tag, and it is the wrong choice if you need continuous integration coverage on Windows or macOS, since the README's own status table says no CI yet for those platforms. Verify first that the nightly build you pull corresponds to the commit you are reading, that the WASM target builds with the Emscripten version you have, and that the subsystem you need is covered by one of the example applications rather than only by a demo of the main window.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. Razakhel/RaZ on GitHub
4. README
5. Releases