ezEngine: a C++ game engine modular by design, with a Windows-only renderer

Direct3D 11 bounds the full engine to Windows; non-rendering code goes further

ezEngine targets C++ game developers who want access to a full engine's source code and the ability to modify it. Its renderer uses Direct3D 11, which limits the full engine functionality to Windows. Work on a Vulkan renderer is ongoing, with no completion date given. An experimental Linux port of the editor exists in the repository, but according to the project it is not yet functional enough for productive use, which means the Windows constraint is current rather than historical.

This platform constraint does not appear in a footnote. It is stated on the first substantive line of the README, before any feature description, which makes it visible to anyone who evaluates the project before adopting it.

Non-rendering functionality is separate from the renderer. Everything outside the graphics layer compiles on Windows, Android, Linux and macOS. Game logic and utilities can run on those platforms using ezEngine's non-rendering subsystems, but any part of a project that depends on drawing to screen requires Windows. Where rendering ends is the boundary that determines which teams can use ezEngine today and which must wait for Vulkan.

Five steps to a working editor session, and a second batch file not covered anywhere

Five steps constitute the documented Windows build path. The first three run in a terminal:

git clone https://github.com/ezEngine/ezEngine.git
cd ezEngine
.\GenerateWin64vs2022.bat

After the batch file runs, you open the Visual Studio solution at `Workspace\vs2022x64\ezEngine_vs2022x64.sln`, build everything, then launch the `Editor` project from Visual Studio and open one of the sample projects. Those five steps are the complete Windows path given by the project.

A detail in the repository top-level entries that a skim of the build instructions would miss: both `GenerateWin64vs2022.bat` and `GenerateWin64vs2026.bat` are listed there. Only the vs2022 variant is documented anywhere in the README. There is no description of what `GenerateWin64vs2026.bat` does, when to use it, or whether it targets a different Visual Studio version. A developer with Visual Studio 2026 following the build instructions would run the vs2022 script without knowing the second file exists.

One more detail: `.gitmodules` sits at the repository root, a standard git submodule configuration file. The five documented build steps say nothing about initializing submodules, which is worth checking if a first build fails at a missing component.

The repository also holds `CMakeLists.txt`, `CMakePresets.json` and `CMakeUserPresets.json.template`, which are CMake build files. The CMake workflow is not described for Windows; the project points to ezengine.net/pages/docs/build/building-ez.html for non-Windows platforms.

Physics, sound and particles are plugins that can be removed or replaced

EZ is modular by design. Larger features are implemented through engine and editor plugins and can therefore be removed or replaced independently. The three named examples are sound through Fmod, physics through Jolt, and particle effects. Each is a plugin, not a compiled-in dependency.

For teams already licensed for Wwise or PhysX rather than Fmod or Jolt, the plugin boundary is where the integration work begins. The separation is not just an architectural description; it is the documented replacement point. For teams that do not need certain features, removing the plugin is described as supported rather than as a workaround.

Modularity also covers the non-rendering use case. In the project's own words, "even if you do not use the rendering functionality, EZ has a lot to offer to build your own engine on top of." That framing positions the foundation layer as independently useful. A team that wants a C++ base without adopting the full editor and renderer workflow can treat ezEngine as a library rather than an all-or-nothing package. Whether the foundation layer is documented thoroughly enough to support that use case on its own is a question the documentation site, not the README, must answer.

Visual scripting targets fast prototyping; custom C++ handles production authoring

The editor supports two code paths. Visual scripting is one, with its own documentation page on ezengine.net. In the project's description, the editor makes it possible to quickly prototype a game using visual scripting, placing it as a fast iteration tool. Whether visual scripting scales to production-size projects is a question the documentation does not address in the README.

Custom C++ is the other path. There is a C++ project generation page linked from the README, meaning the engine can create project scaffolding for a new C++ game module rather than asking a developer to wire up the integration manually. The code API documentation at ezengine.github.io/api-docs is listed as the reference for developers who need depth beyond the high-level overview.

One gap worth naming: the README presents visual scripting and C++ as separate workflows without describing how they interact. Whether a visual script prototype can be incrementally replaced with C++, or whether the two systems run in parallel within a single project, is not addressed in the repository documentation. A team choosing between the two paths needs to consult ezengine.net before deciding, because the README does not supply enough detail to make that choice from the repository alone.

Repository layout puts .clang-format and .clang-tidy at the root alongside coding guidelines

At the top level, the main content sits in Code/, Data/, Documentation/ and Utilities/ directories. Build infrastructure sits alongside them: CMakeLists.txt, CMakePresets.json and CMakeUserPresets.json.template, plus the two batch files. A .clang-format file and a .clang-tidy file both live at the root alongside CodingGuidelines.md, and those three together define the formatting rules, static analysis checks and coding standards expected from C++ contributions.

For a team considering a fork, the presence of .clang-format and .clang-tidy means the codebase has had consistent automated style enforcement applied to it. A modified build does not have to adopt those settings, but they provide a starting point for maintaining consistency after diverging from upstream.

For all topics beyond platform support, build steps and design philosophy, the project documentation points outward. Non-Windows build instructions, full API documentation and sample project details all require visiting ezengine.net. An offline read of the README gives a partial picture, not a complete one. For any team evaluating the engine before committing to it, that off-repository documentation is a required stop, not an optional one.

Visual Studio is a dependency, and building from the dev branch is the stated expectation

Building from source on the dev branch is described as the expected path, not an edge case. Prebuilt binaries exist for those who want them, but the project is explicit that building the engine yourself is the normal expectation. The practical consequence is that version pinning by commit hash replaces version pinning by tag, and a fix needed before the next official build has to be carried as a local patch.

For a team setting up a build pipeline, Visual Studio on Windows is a dependency. The `GenerateWin64vs2022.bat` script creates the Visual Studio solution file, after which the standard Visual Studio build process takes over with no additional configuration steps documented. That setup is a one-time cost, but it also describes the maintenance path for staying current with the dev branch: re-run the generator and rebuild when upstream changes warrant it.

The three most recent releases are release-26.9 from August 2026, release-26.3 from March 2026 and release-25.8 from September 2025, and the last push was on 2026-10-06. The MIT licence is in LICENSE.md at the repository root.

Cross-platform rendering and non-C++ workflows need a different engine

The clearest disqualifying case is a project that must render on Linux, macOS or mobile. ezEngine's renderer runs on Windows only. The Vulkan work will change that at some point, but the README gives no timeline, and a production project cannot depend on an incomplete port.

Teams without C++ fluency face a steeper onramp. Visual scripting in ezEngine is positioned for prototyping; production authoring assumes C++ knowledge. Engines like Godot offer GDScript and C# as primary languages alongside C++, support Vulkan rendering on Windows, Linux, macOS and Android, and publish versioned builds on a regular schedule that is publicly committed in advance. The architectural trade-off is that Godot was not designed as a modular C++ foundation in the same way ezEngine is. For teams that want close access to engine internals in C++, ezEngine's plugin boundaries and foundation layer are the argument for it. For teams that need to move quickly without writing C++, Godot fits that profile better.

A sparse README is also a real cost. Evaluating ezEngine thoroughly requires time on the documentation site, not just in the repository. For a team running a time-bounded comparison of game engines, that extra step adds to due diligence in a way that a self-contained reference document would not.

Editorial conclusion

ezEngine suits C++ developers who need a modular game engine on Windows and are willing to build from source. Plugin boundaries for Jolt physics and Fmod sound make it adaptable to different middleware choices. Any team that needs to render on Linux, macOS or Android today will find the engine cannot deliver that: the renderer requires Direct3D 11, and the experimental Linux editor is not yet functional for productive use. Before adopting, visit ezengine.net/pages/docs/build/building-ez.html for non-Windows build requirements, check the Vulkan status on the dev branch against your target, and run the sample projects from a local Windows build.

Frequently asked questions

Official sources

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