Dagor Engine: Gaijin's C++ Engine and Toolchain, Built from Source

What Dagor Engine is, and who the repository is written for

Dagor Engine is the engine and tools source code from Gaijin Games KFT, published on GitHub under GaijinEntertainment/DagorEngine. The description is literal: engine and tools source, in C++. There is no homepage field, so the repository itself is the documentation entry point.

The README is addressed to someone building a game, not someone evaluating an engine. It opens with environment requirements rather than features: Windows 10 (x64), 16 GB of RAM, 200 GB of HDD or SSD space. That is the whole stated audience test. If you cannot give the build a Windows 10 x64 machine and a large amount of free disk, the documented path does not apply to you.

The repository layout matches that framing. There is a build_all.py at the root, a make_devtools.py beside it, an outerSpace directory, a prog directory, a samples directory, and a _docs folder. The samples that appear in the README and in the repository tree are skiesSample, testGI, and dngSceneViewer. The release notes for dagor_2026_08_01 describe the build as containing the engine, tools, basic samples, the OuterSpace game sample, and the daNetGame scene viewer. That is a coherent picture: source, a toolchain, and two kinds of sample, one a small game and one a viewer for a larger scene format.

The three-stage build: jam for code, compile_shaders for shaders, dabuild for resources

The mechanism the README describes is deliberately split. A Dagor project is not one build command. It is three, run from three different directories, each producing output in a different place.

Code is built by navigating into a sample's prog folder and running jam. The README says jam builds the jamfile script found in that folder, and that the resulting executable is placed in the sample's game folder. jam is described as a small build tool used in DagorEngine instead of Make and similar tools. It arrives through the devtools setup, not through your system package manager.

Shaders are built separately. From the prog\shaders folder you run one of the compile_shaders_* scripts, and the shader dump file lands in the game\compiledShaders folder. Resources are built third: from the develop folder you run dabuild.cmd, and the built game resources land in game\res.

The directory convention ties this together. In the README's own example, a sample has three sibling folders: prog holds game source code, develop holds initial assets, and game is where assets are placed after building and where executables live. Once you know that mapping, the build commands stop looking arbitrary. They are three inputs feeding one output directory.

What the README does not do is explain the dependency graph between the three stages, or what a shader dump actually contains. It tells you where the file goes, not what reads it.

Installing the toolchain: make_devtools.py and what it downloads

The documented install path has two phases: fetch the devtools, then fetch the binary data. Both are scripted, and both need a decision from you before you start.

The README insists on a project folder at the root of a drive, with a name that contains no spaces and no non-Latin characters. It gives this example:

md X:\develop && cd X:\develop
git clone https://github.com/GaijinEntertainment/DagorEngine.git
cd DagorEngine

After cloning, the devtools script takes the toolchain folder as its argument and creates that folder if it does not exist. Run it as administrator, or expect installers inside it to prompt for permission:

python3 make_devtools.py X:\develop\devtools

The README says the script will also ask to add the devtools path to PATH and to set the GDEVTOOL variable to point at it. It asks whether you want the 3ds Max SDK, in case you plan to use 3ds Max plugins. When it finishes, that folder holds the SDK set the README lists, including aftermath-2025.5.0.25317, Agility.SDK.1.619.3, AGS.SDK.6.3.0, astcenc-4.6.1, DXC-1.8.2505.1, FidelityFX_SC, ispc-v1.23.0-windows, LLVM-21.1.8, nasm, openxr-1.1.54, streamline-2.14.1, vc2019_16.11.34, vc2022_17.14.4, win.sdk.100, win.sdk.81, plus ducible.exe, pdbdump.exe, and jam.exe. FMOD Studio SDK 2.02.15 is listed as optional and only needed if you plan to use the FMOD sound library.

Restart the command line console afterwards so the new environment variables are visible. That step is easy to skip and produces confusing failures later.

The binary data you must extract before build_all.py will work

Source alone is not enough. The README states that tools-base.7z must be unpacked into the DagorEngine root to get mandatory binary files in place. Without it, the build has missing pieces.

Two more archives are conditional. samples-base.7z contains initial assets that get compiled into binaries the sample games load; the README notes that if you only plan to build the executable and shaders, this data is not mandatory. outerSpace-devsrc.7z holds initial assets for the OuterSpace sample. A fourth archive, dngSceneViewer.7z, carries binary data for the east_district sample with dngSceneViewer, and the README says windows-x86_64 executables are included in it.

The README also points at the releases page for prebuilt binaries, with the caveat that they may be a bit out of date. Those archives are named tools-prebuilt-windows-x86_64.7z, tools-prebuilt-windows-arm64.7z, tools-prebuilt-linux-x86_64.tar.gz, and tools-prebuilt-macOS.tar.gz. That list is the only place in the README where Linux, macOS, or ARM64 appear, and it appears for prebuilt tools, not for a documented source build. make_devtools_linux.py and make_devtools_macOS.py do exist in the repository root, but the README's build instructions are written for Windows throughout.

Once the archives are in place, build_all.py at the repository root builds the entire toolkit from source. The README warns plainly that this may take a considerable amount of time, then says the script goes on to build game and UI resources using daBuild and other utilities. The README text is cut off mid-sentence at that point, so what follows in the original is not shown here.

Running a sample: skiesSample end to end

The README gives a concrete worked example for skiesSample, and it doubles as a way to check that your toolchain is sane. Do the stages in order, because the later ones depend on tools the earlier ones produce.

Build the code first. Navigate to the sample's prog folder and run jam; the executable appears in the game folder:

cd X:\develop\DagorEngine\samples\skiesSample\prog
jam

Then build shaders from the shaders subfolder using one of the compile_shaders_* scripts. The README does not name which script to pick, so check what is present in that folder before running one. The output is a shader dump placed in skiesSample\game\compiledShaders.

Then build resources from the develop folder with dabuild.cmd. The output lands in skiesSample\game\res:

cd X:\develop\DagorEngine\samples\skiesSample\develop
dabuild.cmd

Two larger samples have their own driver scripts instead of this manual sequence: outerSpace\prog\build.py and samples\dngSceneViewer\prog\build.py. The README is explicit that these scripts use DagorEngine tools, so the tools must already be built or downloaded as the prebuilt archive before you run them. That ordering constraint is the single most common way to waste an afternoon here.

Where Dagor Engine is the wrong choice

The strongest limitation is not a bug, it is the shape of the project. Dagor Engine is a shipped engine released as source, not a framework designed for outside adoption. The README never mentions a plugin API, a scripting layer for gameplay code, or a supported upgrade path between releases. If your plan depends on extending the engine without touching C++, the documentation does not describe how.

The environment requirements are a real gate rather than a formality. Windows 10 x64, 16 GB of RAM, and 200 GB of disk is the stated floor for building and using the toolkit. The devtools script pulls a long list of vendor SDKs and two separate MSVC toolchains, so the build environment is not something you recreate casually on a CI runner.

Build time is another honest constraint. The README says building the entire toolkit from source may take a considerable amount of time, and it offers prebuilt binaries on the releases page as the shortcut, with the warning that those may be a bit outdate. There is no documented incremental story for the toolkit itself.

Finally, the documentation is thin in specific places. The README does not document rollback, does not describe how to upgrade from one release tag to the next, and does not explain what the shader dump contains or which compile_shaders_* variant to run. The repository has a _docs directory, but the README does not walk through it.

Dagor Engine compared with Unreal Engine

The comparison people search for is Dagor Engine versus Unreal. The difference in approach is not a feature list, it is what the download contains and who maintains the workflow.

Unreal Engine is distributed as an editor-first product. You install a launcher, you get a binary editor, and the C++ source is an optional layer you can add. Projects are created inside the editor, and the engine version you pick is the engine version you build against.

Dagor Engine as documented here is source-first and command-line-first. There is no launcher and no editor install step in the README. You clone the repository, run a Python script to assemble a devtools folder, extract binary archives into the repository root, and then drive builds through jam, compile_shaders_* scripts, and dabuild.cmd. The output of a build is a game folder with an executable, a compiledShaders directory, and a res directory.

That difference has consequences. With Dagor you get the full engine and tool sources in one repository, which is what you want if you intend to modify rendering, shaders, or tooling. In exchange, you accept a Windows 10 x64 build environment, a vendor SDK set downloaded by script, and a build sequence you assemble yourself. The README's own sample scripts, build_all.py and the per-sample build.py files, exist precisely because the manual sequence has several steps that must happen in order.

Maintenance, releases, and what the licence does not tell you

The repository is not archived, and the last push was on 2026-09-20. Releases are tagged on a rough cadence rather than a fixed schedule: dagor_2026_08_01 was published on 2026-08-05, dagor_2026_05_02 on 2026-05-02, and dagor_2025_08_31 on 2025-08-31. Each release note describes the same contents: engine, tools, basic samples, the OuterSpace game sample, and the daNetGame scene viewer. If you pin to a tag, that is the bundle you get.

The upgrade cost is dominated by the devtools folder rather than the engine source. Because make_devtools.py downloads and configures a fixed SDK set, a version bump in that set, for example the LLVM, DXC, or Agility SDK entries the README lists, means re-running the script and re-verifying that your build still produces a working executable. The README does not describe a migration path between releases, so treat each tag as a fresh checkout plus a fresh devtools run.

The licence is listed as NOASSERTION, which means GitHub could not match the LICENSE file to a known licence template. The README does not discuss licensing terms at all. That is not a reason to avoid the project, but it is a reason to read the LICENSE file in the repository root yourself and have someone qualified determine what it permits for your distribution model. Nothing in the README substitutes for that reading.

Editorial conclusion

Adopt Dagor Engine if you need the full C++ source of a shipped engine and toolset, you are on Windows 10 x64, and you can give it a dedicated drive with 200 GB free. Do not adopt it if you want a cross-platform editor workflow, a small dependency footprint, or a documented plugin API: the README describes a Windows build path, a large downloaded SDK set, and no plugin model. Before committing, verify three things on your own machine: that make_devtools.py completes and sets GDEVTOOL, that tools-base.7z extracts into the repository root, and that jam builds the skiesSample executable into the skiesSample\game folder. If the jam step fails, nothing downstream is worth debugging yet.

Frequently asked questions

Official sources

1. GaijinEntertainment/DagorEngine on GitHub
2. Issues
3. README
4. Releases