Nazara Engine is a game framework with its own shading language

A framework for real-time applications, not only games

Nazara Engine describes itself as a cross-platform framework aimed at, but not limited to, real-time applications requiring audio, 2D and 3D real-time rendering, network and more, with video games given as the example. The supported platforms are Windows, Linux, macOS and the web, and Android and iOS are described as coming. The repository shows that the web is not an afterthought, since there is a dedicated Emscripten build workflow alongside the Windows, MSYS2, Linux and macOS ones, each with its own build status badge, which means the project is expected to compile for a browser target as a first class case rather than a port. The language is C++ with C++17 in the topic list, and the project is MIT licensed, which the README says allows use in any kind of commercial and non-commercial application without restriction.

NZSL is the piece that makes the renderer choice cheap

The rendering section is the most distinctive part of the design. Rendering is done with either Vulkan, OpenGL or OpenGL ES, depending on what is available on the target system, and the engine provides its own renderer-agnostic shader language, NZSL, which lives in its own repository. The claim is that NZSL is a single modern language that works with all of the renderer backends, and that matters more than it first appears. Writing shaders in a native shading language ties your effects to one API, so a project that wants to run on Vulkan, on OpenGL and on the web either maintains parallel shader sets or restricts itself. A shared language removes that duplication, and the separate repository is what makes the language evolvable without a full engine release. The graphics module is described as easy to customize, providing a basis for advanced techniques such as deferred shading, HDR and PBR rendering.

A frame graph sits above the renderer

Alongside the graphics module the README lists a powerful and extensible frame graph system that lets you define how your rendering works. The frame graph is the structure that decides the order and dependencies of render passes, and having it in the engine rather than in application code is what allows the deferred shading and HDR examples in the repository to exist at all. The examples directory is a good catalogue of what the engine can do, with folders for DeferredShading, PhysicallyBasedRendering, DopplerEffect, FirstScene, HardwareInfo, MeshInfos, Particles, PhysicsDemo, Physics2DDemo, PhysicsPlayground, PlayMusic, Showcase, WebServices, WidgetDemo and the tutorial series Tut00, Tut01 and Tut02, plus a shared `examples/xmake.lua` that builds them. For an engine with an MIT licence and a single named main developer, an examples directory that large is the main evidence of what the framework actually does.

Physics, audio, networking and an optional ECS

The service layers are integrations with established libraries rather than new implementations, and the README names each one. Audio playback and streaming are based on miniaudio. 2D and 3D physics integration is with Chipmunk for 2D and Jolt Physics for 3D. Networking is an ENet based reliable UDP protocol with IPv6 support and encryption, and the README points at ENet6 for the encrypted variant. Entity handling is optional, with ECS classes provided on top of entt, and the wording is that they help with entity handling, so the engine does not force an ECS architecture on you. The plugin system is the extension mechanism, and the README says support for plugins is provided, with Assimp, ImGui and FFMpeg plugins included, and the ImGui integration is described as available through an engine plugin rather than built in. Built-in retained widgets are listed as a separate feature.

Building it with xmake and checking five platforms in CI

The build instructions are not in the README, and the project says so directly. You find tutorials on installation, compilation and use on the official wiki, and the README points to `INSTALL.md` for build instructions. The repository root shows the tooling: an `xmake.lua` file alongside an `xmake/` directory, which is the xmake build system, plus `tools/`, `src/`, `include/`, `plugins/`, `tests/`, `assets/` and `documentation/`. There is also a Doxyfile, which is how the API reference is generated, and a set of licence files for the bundled third party parts, including `LICENSE-FFmpeg`, `LICENSE-Kiwi` and `License-OpenSans.txt`, which is what you would expect when a renderer and a physics library are compiled into the same project. The CI matrix is the practical guide to what is supported, with separate workflows for Windows, MSYS2 on MinGW64, Linux, macOS and Emscripten, so a change that breaks one of those platforms is caught before it lands on the main branch.

One maintainer, a wiki, and an unusual release history

Two things are worth knowing before you commit to the project. The first is that the README names a single main developer, Jérôme Leclercq, known as SirLynix, and the contact routes are a Discord server, a Bluesky profile and a forum, with the wiki as the documentation home. This is a project with one person at the centre of it, and the contribution section invites patches, wiki edits, bug reports and forks, so the community route exists, but the bus factor is what it is. The second is the release list. The tagged releases are v0.3 from February 2017, v0.4 from October 2017, and a 0.0.0-nightly build from January 2024. The last push was on 2026-10-06 and the repository is not archived, so the work continues, but the version numbers do not tell you where you are. In practice you track the main branch, and the wiki rather than a changelog is where the current instructions live.

Editorial conclusion

Adopt Nazara Engine when you are writing a C++ real-time application and want rendering, physics, audio and networking from a codebase you can actually read, and when you are willing to accept an engine whose documentation lives in a wiki. Do not adopt it expecting a stable, regularly tagged release cadence, because the listed releases are a 0.4 from 2017, a 0.3 from 2017 and a nightlies tag from 2024, so the practical version is whatever the main branch holds today. Verify first that your target platform and renderer combination is covered, since the supported set is Windows, Linux, macOS and the web with Android and iOS described as coming, and read `INSTALL.md` for the build steps.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NazaraEngine/NazaraEngine on GitHub
4. README
5. Releases