# Daemon Game Engine: The C++ Foundation Powering Unvanquished

> Daemon is the open-source C++ game engine behind the Unvanquished multiplayer first-person shooter. It builds from source on Windows, macOS, and Linux via CMake and provides both a graphical client binary and a headless dedicated server binary, published under the BSD-3-Clause license.

**DaemonEngine/Daemon** — An open-source multi-platform 3D game engine focused on first-person shooter gameplay and community-driven development workflows.

- Repository: https://github.com/DaemonEngine/Daemon
- Website: https://unvanquished.net
- Stars: 389 · Forks: 75
- Language: C++
- License: BSD-3-Clause
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/daemonengine-daemon

## 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:

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

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

```bash
git submodule update --init --recursive
```

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

```bash
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:

```bash
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:

```bash
./daemon
```

Starting a dedicated server with a specific map:

```bash
./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.

## 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.

## FAQ

### Does Daemon include assets or maps I can use to test a build?

The engine repository does not ship game assets, maps, or .dpk files. Ready-to-run downloads of the Unvanquished game, which bundle the engine with all required assets, are available from the Unvanquished download page at unvanquished.net.

### Can I use Daemon to build a game other than Unvanquished?

The engine is licensed under BSD-3-Clause and can be reused, but the repository does not document a step-by-step path for attaching different game logic. The game-logic interface is defined in the Unvanquished repository, so building a separate game requires studying that interface directly.

### What C++ standard does the Daemon engine require?

Daemon requires a C++14-capable compiler. The README lists GCC 9 or later, Clang 11 or later, and Visual Studio 2019 or later as the actively supported toolchains.

## Sources

- [Official documentation](https://unvanquished.net)
- [Official README](https://github.com/DaemonEngine/Daemon#readme)
- [Project repository](https://github.com/DaemonEngine/Daemon)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/daemonengine-daemon