Daemon Game Engine: The C++ Foundation Powering Unvanquished

What Daemon Is and Who It Is For

Daemon is the standalone game engine that powers Unvanquished, a community-developed multiplayer first-person shooter available at unvanquished.net. The engine handles the client renderer, audio, netcode, and physics. Game logic, maps, and asset packages reside in a separate repository at github.com/Unvanquished/Unvanquished and are not bundled with the engine.

The engine is published under BSD-3-Clause. The game logic carries its own license. That split matters for anyone who wants to build a new game on top of Daemon: the engine is permissively licensed, but there is no documented API in this repository for attaching different game logic. The architecture is specific to the Unvanquished ecosystem.

The primary audience is contributors to Unvanquished itself and teams willing to study the Unvanquished game-logic interface to build an FPS title on a tested C++ foundation. Developers who need a self-contained environment with tooling and asset pipeline support will find the scope too narrow.

Source Layout, Submodules, and the Dependency List

The repository is a CMake workspace with several top-level directories: src/ holds the core C++ source, libs/ and external_deps/ hold vendored and submodule dependencies, cmake/ holds platform-specific toolchain files, and pkg/ is the placeholder for runtime asset packages.

Git submodules must be initialized before CMake runs. Skipping this step causes the build to fail with complaints about missing files in libs/crunch/ or similar directories. The README lists 15 required runtime libraries: zlib, libgmp, libnettle, libcurl, SDL2, GLEW, libpng, libjpeg at version 8 or later, libwebp at version 0.2.0 or later, Freetype, OpenAL, libogg, libvorbis, libopus, and libopusfile. Each has a minimum version constraint. On Linux, these arrive through the system package manager; on macOS, through Homebrew; on Windows, the README recommends MSYS2 with the MinGW toolchain. The optional ncurses library adds a console interface for the dedicated server but is not required.

Cloning and Compiling the Engine

The safest way to clone is with submodules included from the start:

git clone --recurse-submodules https://github.com/DaemonEngine/Daemon.git

If the repository was already cloned without that flag, initialize the submodules separately:

git submodule update --init --recursive

With dependencies in place, the standard out-of-source CMake build writes binaries to a new build/ directory:

cmake -H. -Bbuild
cmake --build build -- -j4

The -j4 flag distributes compilation across four cores. On Linux, replacing it with -j$(nproc) uses all available cores. The build system supports GCC 9 or later, Clang 11 or later, and Visual Studio 2019 or later. On Windows with Visual Studio, run CMake first, then open the generated Daemon.sln and compile from the IDE.

Cross-Compiling to Windows from a Linux Host

The cmake/ directory ships two cross-compilation toolchain files for teams that build Windows binaries on Linux, such as in a CI pipeline. The 64-bit target uses:

cmake -H. -Bbuild -DCMAKE_TOOLCHAIN_FILE=cmake/cross-toolchain-mingw64.cmake
cmake --build build -- -j4

For a 32-bit Windows binary, substitute cross-toolchain-mingw32.cmake. This approach depends on MinGW being present on the Linux host. It lets a single Linux build machine produce Windows-compatible engine binaries without a separate Windows runner, which is useful for small teams maintaining multiple platform targets.

Running a Client and a Dedicated Server

After a successful build, two binaries are available. The client is daemon, the headless dedicated server is daemonded. Both require a pkg/ directory containing the .dpk asset packages for the game, placed next to the binary.

Starting the client:

./daemon

Starting a dedicated server with a specific map:

./daemonded +map <mapname>

On Windows, the README notes that the binaries are named daemon.exe and daemonded.exe instead. Valid map names are game-specific; for Unvanquished the full list and server configuration options are documented in the Unvanquished repository, not here. There are no bundled test maps or sample assets in this repository.

Limitations: No Releases, No Editor, Thin Documentation

The repository has no GitHub releases. There are no pre-built binaries for the engine itself. Every developer must build from source, which means satisfying 15 runtime library dependencies at specific minimum versions before CMake succeeds. On Windows, this requirement makes MSYS2 with MinGW the practical starting point, which adds setup overhead.

The README does not document a plugin or extension API for game logic. The connection between the engine and the Unvanquished game logic is through an interface that lives in the Unvanquished repository, not here. A developer who wants to write a new game would need to study that interface from the source.

In-repository documentation is limited to the build process. For engine concepts, the README points to the Unvanquished wiki. There is no API reference in the repository.

Daemon Compared to a General-Purpose Open-Source 3D Engine

A common alternative in the open-source 3D space is Godot Engine. Godot is a general-purpose engine: it ships a full scene editor, supports multiple 3D and 2D workflows, exports to Windows, macOS, Linux, Android, iOS, and the web, and has a large community producing tutorials and plugins. It uses GDScript or C# for game logic and handles asset import for common 3D formats.

Daemon takes a different path. It has no built-in editor. Its asset packaging format is .dpk, which is specific to the Unvanquished ecosystem. The engine is designed for a single genre and a single production game, which means its renderer, netcode, and game loop reflect the specific requirements of that project rather than a general API. Teams building a new FPS that want to start from a known, working codebase and are willing to work within those architectural constraints may find Daemon's maturity in that specific domain useful. Teams that need broader format support, tooling, or community resources will find Godot or a comparable engine a better fit.

Editorial conclusion

Daemon is the right choice for teams working directly on Unvanquished or building an FPS title that reuses its architecture and asset format. It is not a general-purpose game engine: it ships no scene editor, no asset import pipeline for arbitrary formats, and no in-repository documentation of its game-logic interface. Before adopting it for a new project, confirm your game can supply a complete pkg/ directory of .dpk assets, since the engine binary will not start without one. The last push was on 2026-09-07, indicating active development continues.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository