Wicked Engine: a C++ 3D engine with DirectX 12, Vulkan and Metal backends

Who Wicked Engine is aimed at, and who it is not

The README states the intended use directly: "Use this as a C++ framework for your graphics projects, a standalone 3D editor, LUA scripting or just for learning." That is four different audiences, and they do not have the same experience. The C++ framework path assumes you already know how to link a static library and set search directories. The editor path assumes you want to author scenes rather than write an application. The Lua path assumes you want to drive an existing build without recompiling. The learning path assumes you are reading the engine source, not shipping a product.

The project is not a template you unzip and publish. It is a source tree with a solution file, a CMakeLists.txt, sample projects under Samples/, and an Editor/ directory. There is no store listing for a runtime SDK, no versioned binary distribution described in the README beyond nightly editor builds linked from the GitHub Actions badge, and the README notes those nightly packages require a GitHub sign-in. If your team expects a vendor to hand you an installer and a support channel, this is the wrong shape of project.

The topics list on the repository reads like a feature inventory: audio, directx12, entity-component-system, fbx, game-engine, global-illumination, gltf, input, jolt-physics, lua, metal, pbr, raytracing, vrm, vulkan. Each of those is a subsystem you would otherwise assemble yourself. The cost of that breadth is that you inherit the engine's opinions about scene structure and rendering paths.

RenderPath, the global scene, and where your code attaches

The mechanism that matters most in Wicked Engine is the render path. The README's C++ example declares a game screen as `wi::RenderPath3D myGame;` and registers it with `application.ActivatePath(&myGame);`. From that point the application calls Start() once and then Update() and Render() every frame. A 2D path works the same way: `wi::RenderPath2D myMenuScreen;` is described as a path that "can only render 2D graphics by default (like a menu for example)", and it can be activated with a fade delay, as in `application.ActivatePath(&myMenuScreen, 0.8f);`, which stops the previous path.

Scene data lives in a global scene object that you reach through `wi::scene::GetScene()`. Models load into it with `wi::scene::LoadModel("myModel.wiscene");`. The engine also supports separate scenes: the README shows creating `wi::scene::Scene scene2;`, loading a model into it with a two-argument `LoadModel`, then combining it with `wi::scene::GetScene().Merge(scene2);`. That merge call is the interesting part. It implies the engine treats scene composition as something you can stage and combine rather than a single fixed world, which suits tools and editors more than it suits a hardcoded level pipeline.

Initialization is asynchronous. The README warns that `application.Initialize();` starts initialization and that "If you start calling engine functionality immediately before application.Run() gets called, then you must first initialize the application yourself." That is a real ordering constraint, and it is the kind of detail that produces confusing failures if you skip the Initialize call and touch the scene too early. The entity-component-system topic in the repository listing tells you how the scene is organised internally, but the README's own examples stay at the level of loading models and activating paths.

Building Wicked Engine on Linux with CMake

The README gives a Linux dependency list and a CMake build sequence. It states you need CMake 3.7 or newer, a C++17 compliant g++ compiler, and SDL2. The dependency install commands are:

sudo apt update
sudo apt install libsdl2-dev
sudo apt install build-essential

With those in place, the README's example build in Release mode is:

mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make

The README points to `.github/workflows/build.yml` (the linux section) as a sample build script for Ubuntu, so if the four commands above fail on your distribution, that file is the reference the project itself maintains. On Windows the README gives a different route: open `WickedEngine.sln` with the latest Visual Studio, press F5, and the engine and editor are built and started. It also documents a CMake path on Windows with `cmake -B build` followed by `cmake --build build --config Release`.

For a first real use, the README's minimal application is short. It includes `"WickedEngine.h"`, constructs `wi::Application application;`, assigns the window with `application.SetWindow(hWnd);`, and loops on `application.Run();`. That is the skeleton. To see something, you would follow the basics example and activate a `wi::RenderPath3D`, then load a model into the global scene. Note what the README does not give: it does not document a command line for launching the editor with a specific project file, and it does not describe a package manager install. The documented acquisition routes are cloning the Git repository, downloading a zip, or the nightly editor builds behind a GitHub sign-in.

Console support is documented as private, and other gaps

The platforms list includes Xbox Series X|S and PlayStation 5, which makes the next line easy to miss: "Console specific extension files required for building are currently private." So the console entries describe a capability of the engine, not something a reader of this repository can build. If your project's first target is a console, the public source tree does not get you there, and no timeline for opening those files appears in the README.

There are smaller gaps worth knowing before you start. The README does not document rollback or version migration for `.wiscene` files, so a scene saved by one build and opened by another is an untested assumption on your side. It does not describe a headless or server build, so a dedicated server using this engine is not a documented path. It also does not state minimum GPU requirements for the DirectX 12, Vulkan or Metal backends; the platform list names the APIs through the repository topics, but the README itself does not pair them with hardware floors.

The asynchronous initialization warning above is the most concrete failure mode the README admits. The second is scale: the repository is a full engine with an editor, samples, and a scripting layer, and the C++ documentation lives in `Content/Documentation/WickedEngine-Documentation.md` rather than inline in the README. Reading that file is not optional if you intend to subclass a render path.

Wicked Engine against Godot, O3DE and ezEngine

The comparisons people search for are Godot, O3DE, ezEngine and Flax Engine, and the difference is not features, it is the integration surface. Godot is a general application engine with its own scene format, its own GDScript language and a large ecosystem of add-ons; you adopt Godot as your development environment and write game logic inside it. Wicked Engine's README positions it as a C++ framework first, with the editor and Lua scripting as additional entry points. If your team wants to write C++ against a rendering and scene API and keep control of the application loop, that is closer to Wicked Engine's shape than to Godot's.

O3DE and ezEngine are the nearer comparisons in kind: both are open source engines written in C++ with their own editors and their own component models. The practical difference for a reader of this repository is documentation surface and scale. O3DE documents a much larger toolchain and a Gem-based extension system; ezEngine documents its own build and editor workflow. Wicked Engine's README is short by comparison and points outward to a PDF editor manual, a C++ documentation file and a Lua scripting API file. That means less prose to read and more source to inspect.

Flax Engine sits differently again: it is an engine with a C++ and C# scripting story and a packaged editor distribution. Wicked Engine's documented acquisition is source-first, with nightly editor builds as the exception. If a packaged editor download is a hard requirement, that difference decides the choice before any rendering feature does.

Licence, maintenance and the cost of tracking master

The repository is MIT licensed, with the licence text in `LICENSE.txt`. MIT is permissive: it allows use in closed-source products, and it requires that the copyright notice and permission notice be included in copies or substantial portions of the software. It provides no patent grant and no warranty. That is the general shape of the licence, not legal advice; if your organisation has a policy on permissive licences or on the third-party components listed in `third_party_software.txt`, check that file before you build, because the engine bundles dependencies whose terms are separate from the MIT grant on Wicked Engine itself.

On maintenance, the last push to the default branch was on 2026-09-21. Recent releases are v0.72.113 on 2026-08-24, v0.72.106 on 2026-08-06, and v0.72.101 on 2026-07-06. The version numbers move in the third component, which suggests frequent small releases rather than rare large ones. There is no long-term support branch described in the README, and no deprecation policy for the C++ or Lua APIs.

Upgrade cost therefore falls on you. Because the documented path is cloning the repository or building from source, tracking the project means either following master or pinning a tag and merging forward yourself. The README does not describe a compatibility guarantee between releases, so the practical approach is to pin a tag such as v0.72.113, build it, and diff the C++ and Lua documentation files when you move. Those two files, `Content/Documentation/WickedEngine-Documentation.md` and `Content/Documentation/ScriptingAPI-Documentation.md`, are the changelog you actually have.

Editorial conclusion

Adopt Wicked Engine if you want a C++ graphics framework you can read and modify, or a Lua-scripted editor for prototyping rendering work, and you are comfortable building from source. Do not adopt it if you need a packaged SDK with a support contract, or if your target is a console: the README states that the Xbox Series X|S and PlayStation 5 extension files required for building are private. Before committing, verify that the RenderPath subclass you need exists in the C++ documentation, and confirm the Lua scripting API covers the systems your gameplay code touches.

Frequently asked questions

Official sources

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