Dæmon im Detail: die 3D-Engine hinter dem Shooter Unvanquished, gebaut mit CMake und C++14
Dies ist eine plattformübergreifende Open-Source-3D-Game-Engine für First-Person-Shooter mit fokussierter Weiterentwicklung und regelmäßiger Pflege.
Auf einen Blick
- Was ist das?
- Der Autor eines Multiplayer-Ego-Shooters braucht eine Engine, die schnelle Bewegung, Netzwerkplay und alte Codebasen verträgt. Dæmon ist genau diese Engine, und das README erklärt, wie man sie aus dem Quellcode zum Laufen bringt.
- Für wen ist es gedacht?
- Dæmon eignet sich für Teams, die an einem Ego-Shooter im Umfeld von Unvanquished arbeiten oder eine BSD-3-lizenzierte Engine mit id-Tech-Wurzeln selbst weiterentwickeln wollen. Vor dem Build lohnt der Blick auf die 15 Pflichtabhängigkeiten und auf die 287 offenen Issues, denn beide zeigen, wie viel Eigenarbeit ein eigenes Spielprojekt auf dieser Basis verlangt.
- Darf ich es kommerziell nutzen?
- Ja. BSD-3-Clause ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 8 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C++, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Die Engine hinter Unvanquished: Standalone-Basis für Ego-Shooter
Dæmon ist die eigenständige Engine, die den Mehrspieler-Ego-Shooter Unvanquished antreibt. Das Repository DaemonEngine/Daemon enthält den Engine-Code, während die Spiellogik von Unvanquished in einem eigenen Repository unter Unvanquished/Unvanquished liegt. Diese Trennung ist bewusst: Andere Teams können die Engine nutzen, ohne den Spielinhalt mitzuschleppen.
Die Projektbeschreibung ordnet Dæmon als plattformübergreifende 3D-Engine mit Fokus auf Ego-Shooter-Gameplay und gemeinschaftliche Entwicklung ein. Die Zahlen im Repository: 383 Sterne, 75 Forks und 287 offene Issues, Programmsprache C++, Lizenz BSD-3-Clause, Standard-Branch master. Fertige Spieldownloads inklusive Engine-Builds gibt es auf der Unvanquished-Seite unter unvanquished.net/download/, wer nur spielen will, greift dort zu statt selbst zu kompilieren.
Workspace-Anforderungen: Compiler ab gcc 9, clang 11 und MSVC 2019
Für das Abrufen und Bauen braucht es laut README drei Dinge: git, cmake und einen C++14-fähigen Compiler. Aktuell unterstützt werden gcc ab Version 9, clang ab Version 11 sowie Visual Studio beziehungsweise MSVC ab Visual Studio 2019. Ältere Compiler werden nicht versprochen.
Unter Windows empfiehlt das README MSYS2 als Weg, mit MinGW zu bauen. Für 64 Bit sind die Pakete mingw-w64-x86_64-gcc, mingw-w64-x86_64-cmake und make nötig, für 32 Bit die entsprechenden i686-Varianten. Die Abhängigkeitsliste ist lang: zwingend sind zlib, libgmp, libnettle, libcurl, SDL2, GLEW, libpng, libjpeg ab Version 8, libwebp ab 0.2.0, Freetype, OpenAL, libogg, libvorbis, libopus und libopusfile; optional kommt ncurses dazu. Fast alles davon stammt aus dem klassischen Werkzeugkasten von Multimedia-Anwendungen, nur libgmp und libnettle fallen als Kryptografie-Bibliotheken etwas aus dem Rahmen.
Submodule zuerst: der Schritt vor jedem Build
Bevor irgendetwas kompiliert wird, müssen mehrere Unter-Repositories geholt werden. Bei einem frischen Checkout lautet der Befehl git clone --recurse-submodules https://github.com/DaemonEngine/Daemon.git. Wer das Repository bereits geklont hat, wechselt ins Verzeichnis Daemon/ und führt git submodule update --init --recursive aus.
Das README warnt ausdrücklich vor dem häufigsten Fehler dieses Schritts: Beschwert sich cmake über fehlende Dateien im Ordner libs/crunch/ oder in ähnlichen Verzeichnissen, wurde das Abrufen der Submodule übersprungen. Die eigentliche Liste der Unter-Repositories steht im README nicht; sie steckt in der Git-Konfiguration des Projekts. Diese Vorbedingung ist der einzige echte Stolperstein zwischen Clone und lauffähigem Build, alles danach folgt Standard-CMake-Praxis.
Build mit cmake -H. -Bbuild und der Daemonded-Weg zur Server-Binary
Unter Linux, macOS und MSYS2 beschränkt sich der Build auf zwei Aufrufe: cmake -H. -Bbuild erzeugt das Build-Verzeichnis, cmake --build build -- -j4 kompiliert. Statt der 4 lässt sich -jN setzen, wobei N die Kernzahl ist; unter Linux liefert nproc diesen Wert, das README empfiehlt also -j$(nproc). Die erzeugten Dateien landen im Verzeichnis build.
Unter Windows mit Visual Studio läuft es grafisch: CMake starten, Compiler wählen, dann die erzeugte Daemon.sln öffnen und kompilieren. Wer von einem Linux-Host aus Windows-Binaries bauen will, nutzt eine Toolchain-Datei: cmake -H. -Bbuild -DCMAKE_TOOLCHAIN_FILE=cmake/cross-toolchain-mingw64.cmake für 64 Bit, für 32 Bit heißt die Datei cross-toolchain-mingw32.cmake. Das ist der übliche Weg für Entwickler, die unter Linux arbeiten, aber Windows-Spieler versorgen wollen.
Client und Server: daemon und daemonded mit .dpk-Dateien im pkg-Ordner
Eine gebaute Engine braucht Spieldaten. Laut README verlangt der Start einen Ordner pkg/, der mit .dpk-Dateien des gewünschten Spiels gefüllt ist, und dieser Ordner muss neben der Binary daemon liegen. Der Client startet dann mit ./daemon, unter Windows mit daemon.exe.
Für Serverbetreiber gibt es die grafiklose Variante daemonded beziehungsweise daemonded.exe. Eine Karte lädt man über ein Startargument: ./daemonded +map <mapname>. Das README weist darauf hin, dass Kartennamen und weitere Optionen spielspezifisch sind und verlinkt für Details auf die Serverkonfigurations-Dokumentation von Unvanquished. Mit dieser Zweiteilung aus Client-Binary und dediziertem Server deckt die Engine beide Betriebsarten ab, die für einen Mehrspieler-Shooter relevant sind.
Was das README nicht sagt: Funktionen, Leistung, Fahrplan
Das README ist ein Build- und Betriebsdokument, mehr nicht. Es erklärt weder Renderer-Details noch Netzwerkarchitektur, keine Leistungszahlen und keinen Fahrplan. Auch zur Anbindung eigener Spiellogik schweigt es; der einzige Hinweis führt zur Spiel-Repo von Unvanquished, wo die Logik als Referenzimplementierung liegt.
Für eine Bewertung bedeutet das: Wer wissen will, ob Dæmon zum eigenen Projekt passt, muss über das README hinaus lesen, etwa in den Issue-Tracker mit seinen 287 offenen Meldungen oder in die Commit-Historie auf master. Positiv ist die Lizenz zu vermerken: BSD-3-Clause erlaubt kommerzielle Nutzung und Modifikation bei Namensnennung und ohne Gewährleistung. Die Plattformmatrix im README zeigt zudem drei CI-Systeme für Windows, macOS und Linux, was auf kontinuierlich geprüfte Builds auf allen drei Systemen hindeutet.
Fazit: Dæmon als Ausgangspunkt für Shooter-Projekte mit Eigenaufwand
Dæmon richtet sich an zwei Gruppen: Spieler von Unvanquished, die fertig gepackte Downloads nutzen, und Entwickler, die eine altbewährte Shooter-Engine als Basis für eigene Experimente suchen. Für die zweite Gruppe liefert das README einen klaren Weg: git clone --recurse-submodules, cmake -H. -Bbuild, cmake --build build -- -j$(nproc), dann .dpk-Dateien neben die Binary legen.
Der Preis dieser Basis ist der Unterhalt: 15 Pflichtabhängigkeiten müssen auf dem Zielsystem vorhanden sein, und die 287 offenen Issues zeigen, dass an der Engine laufend gearbeitet wird. Wer ein fertiges Spiel will, lädt von unvanquished.net/download/; wer die Engine selbst bauen oder weiterentwickeln will, folgt den Schritten aus dem README und prüft vorher die Compiler-Versionen, denn unter C++14-Mindestanforderung kommt man nicht durch.
Redaktionelles Fazit
Dæmon eignet sich für Teams, die an einem Ego-Shooter im Umfeld von Unvanquished arbeiten oder eine BSD-3-lizenzierte Engine mit id-Tech-Wurzeln selbst weiterentwickeln wollen. Vor dem Build lohnt der Blick auf die 15 Pflichtabhängigkeiten und auf die 287 offenen Issues, denn beide zeigen, wie viel Eigenarbeit ein eigenes Spielprojekt auf dieser Basis verlangt.
Community-Notizen