doriax exports your game as a CMake project with the engine source inside

An engine you compile from source rather than a runtime you ship

The project describes itself as a lightweight C++ engine for 2D and 3D games, with a visual editor and scripting in Lua or C++, and the README is unusually explicit about what that means in practice. Your game can be exported as a standalone CMake project that includes the engine source, so you can build it yourself for Windows, Linux, macOS, Android, iOS or the web, and change anything you like.

That export model is the decision to evaluate the project on. Nothing is hidden inside a shipped binary that you cannot inspect or patch. The engine directory is part of your project, `CMakeLists.txt` is at the top of the tree, and the CI workflows build the engine for desktop, Android, Emscripten and Xcode targets. The cost of that openness is that your build time includes the engine, and that upgrading the engine means merging upstream changes into a tree you own.

The repository layout supports this reading. The top-level entries split into `engine/` and `editor/`, with `libs/` for bundled third-party code, a `shadercompiler/` directory, a `misc/` directory, and several generator scripts such as `generate_api_suggestions.py`, `generate_gamepad_mappings.py` and `generate_shaders.cmake`, plus `flake.nix` and `flake.lock` for a Nix based development environment. There is also a `copy_headers.cmake`, which is the kind of build plumbing that exists because the engine is a source dependency in consumer projects.

The licence is MIT, so the engine source inside your game carries no obligations beyond attribution.

The editor and the runtime are separate pieces

The engine and the editor live in different directories, and the README treats them as separate artifacts. The `engine/` directory is the runtime that ships in your game, and `editor/` is the desktop tool you use to build scenes, with a hierarchy, an inspector, a resource browser and a play mode.

The editor is a desktop application, and the CI matrix has a separate build workflow for it apart from the engine workflows. That separation is a normal design for a modern engine, and it has a practical effect: the editor is where you author, and the exported CMake project is where you ship, so the editor itself is not a runtime dependency of the player.

The screenshots in the README show what the editor actually contains, and the alt text is more informative than a marketing line would be. One shows a rainforest scene, another an animated character with its bones shown in the editor, another a code editor with Lua API completion, and another the AI assistant creating entities. The bones view and the live code editor with completion are the two that say the most about the workflow, since both imply the editor knows about your game's data at edit time rather than only at runtime.

The example games are ordinary Doriax projects, which is a useful detail for anyone assessing the project. The README says each one can be cloned and opened in the editor, so the examples double as importable samples rather than as separate binaries. The list covers a 3D platformer, a 2D platformer, an endless flyer and a 3D tower defence, and each has a playable build in the browser and a public source repository.

One ECS runtime serving both 2D and 3D

The project description calls out the entity component system, and the feature list puts it in one line.

- ECS runtime shared by 2D and 3D
- Lua and C++ scripting on the same engine API, with completion in the built-in code editor

Sharing the runtime between 2D and 3D is the meaningful part of that. It means a project that mixes a 2D user interface with a 3D scene does not need two worlds, two component sets and two script bindings, and it means the same entity model carries through from the editor hierarchy into the exported game.

The data-oriented design in the project description is the other half. An ECS with data-oriented storage implies that the hot data for a system is laid out contiguously rather than scattered behind pointers, which is the usual reason to reach for the pattern. The README does not document the memory model, the chunk layout or the system scheduling order, so those are properties you would have to read in `engine/` rather than take from the description.

For a project evaluating whether the engine can carry a real game, that gap matters more than it would for a more mature engine. The documented surface is the editor, the export flow and the feature list. The runtime internals are there to read.

Scripting in Lua or C++ against the same API

Two scripting languages on one engine API is an unusual combination, and it is the flexibility the README advertises when it says you can script in Lua, in C++, or mix the two.

The practical case for mixing is performance and tooling. Lua is fast to iterate on and easy to attach to the editor, while C++ gives you direct access to the engine when a hot path needs it. Because both sit on the same API, a project can move a system from one to the other without rewriting the interface it exposes to the rest of the game.

The editor has a built-in code editor with Lua API completion, which means the completion list comes from the engine itself rather than from a static file. The `generate_api_suggestions.py` script at the top of the repository is presumably part of producing that list, since its name says what it does, though the README does not describe the pipeline in detail.

The alternative worth naming is a single-language engine. If your team already has strong Lua skills, a Lua-only engine removes the second toolchain. If your team is a C++ shop, a C++-only engine removes the need to learn a scripting language and keeps everything in one build. Doriax's position is that you do not have to choose, which is a strength when the team is mixed and a complication when it is not.

The feature list is broad, and physics comes from two engines

The features section covers a lot of ground, and reading it as a list of specific commitments rather than as a general claim is the useful exercise.

Content and rendering cover sprites, tilemaps and polygons with 2D lights, normal maps and shadows; glTF, OBJ and FBX models with skeletal animation, morph targets, instancing and LOD; PBR rendering with cascaded shadows, image-based lighting, SSAO, SSR, fog, water, mirrors and reflection probes; built-in shaders you can fork and edit, with custom post-processing passes recompiled live in the viewport; a terrain system you can sculpt and paint, rendered with clipmap LOD; UI widgets with anchors and layout containers; and an animation timeline with keyframes and bone editing, plus sprite-sheet animation, tweened actions and blending.

Two entries stand out for a different reason. Physics is described as Box2D and Jolt, which means the 2D and 3D sides come from separate upstream projects, and a project will live with two different physics behaviours and two different debugging workflows. Multithreaded resource loading is the other, since it implies a streaming design that has to be tuned per platform rather than a simple load everything at startup model.

There is also a shipping concern in the list: AdMob ads and in-app purchases. That is a sign the engine targets mobile releases as a first class case, alongside the Android and iOS build workflows, and it also means monetisation code is part of the engine surface you inherit.

Six target platforms and a CI matrix that shows which ones work

Platform support is stated in two places, and the second is the more reliable.

The README says a game can be built for Windows, Linux, macOS, Android, iOS or the web. The build badges in the README are the operational detail, because they are attached to distinct workflows: a CMake workflow for the editor desktop build, an engine CMake workflow for the engine desktop build, an Android workflow, an Emscripten workflow for the web, and an Xcode workflow labelled for iOS and macOS. Emscripten for the web target and Xcode for the Apple targets are named build systems rather than vague platform labels, which is the level of detail that tells you whether a target is real.

The repository topics add the graphics and platform picture, listing cross-platform, data-oriented-design, directx, metalapi, opengl and opengl-es alongside the game development and ECS tags. So the rendering layer spans the Direct3D, Metal, OpenGL and OpenGL ES families, and the two OpenGL entries together with the Apple and DirectX ones indicate a coverage of both desktop and mobile graphics APIs.

What is not mentioned anywhere is console support, and there is no build workflow for it in the badge list. A project targeting a console is out of scope here, and one targeting a platform without a badge should assume untested.

Version 0.8 is recent and still moving

The release history is short and recent. v0.7.1 was published on 2026-08-29, v0.8 on 2026-10-10, and v0.8.1 on 2026-10-14. The last push was on 2026-10-22, so work continued after the 0.8.1 tag, and the repository is not archived.

The 0.x numbering is the thing to plan around. A project on a 0.x version carries no compatibility promise in the usual sense, and given that three releases landed in seven weeks, the API surface is likely to move. The good news is that the export model gives you some control over this, since the engine source is in your tree and you can see exactly what changed when you pull a new tag, and the CHANGELOG is not needed to know that the diff is right there in the merge.

The README also points to a download page on the project website, a documentation site, a Discord server and an examples section, so prebuilt editor binaries are distributed separately from the source repository, and the documentation lives outside the repo at `docs.doriax.org`.

The editor screenshots also show an AI assistant inside the editor, described as creating entities. That is a notable inclusion for a 0.x engine, and it is the kind of feature whose behaviour and cost are worth evaluating on your own project rather than taking from a screenshot.

Editorial conclusion

doriax fits a solo developer or small team that wants a full engine with an editor, an ECS runtime and dual Lua and C++ scripting without a per-seat licence or a closed runtime. Skip it if you need a proven production track record, if your build pipeline cannot absorb compiling the engine source on every target, or if you need console platform support, since none is mentioned. Verify first that your target platform has a working build path in the CI matrix, and that the 0.x API surface is stable enough for your schedule, since the release numbering is still in the 0.8 line.

Frequently asked questions

Official sources

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