Unvanquished keeps the game logic separate from the engine and the assets

Three pieces, and the README tells you which one you need

The most important paragraph in the README is the one about what this repository is. It contains the source code for the game logic of Unvanquished. If you only want to play the game or run a server and want to rebuild, you only need to build the Dæmon engine and download the game's assets. You need to build this repository if you want to contribute to the game logic or make a mod with custom game logic binaries. That split is unusual and it is deliberate, because the engine is a separate project with its own repository and its own release cycle, and the assets are data rather than code. The consequence for a reader is that the build is a three-part assembly, and the README spends its first screen telling you which parts you actually need, so a player is not sent to compile a C++ game they only wanted to run. The project also publishes ready-to-use downloads on its download page, and the description calls it a free and open source FPS and RTS hybrid game powered by the Dæmon game engine.

A Tremulous continuation rather than a new game

The project description says that Unvanquished is historically based on Tremulous as a continuation with decades of work over it, and the repository's own topic list carries tremulous alongside the engine and the idtech3 lineage. That history is visible in the structure. The build system is CMake with several sub-projects, src.cmake for the game logic, rmlui.cmake for the interface toolkit, lua.cmake for the scripting layer, and a daemon/ directory that is a submodule pointing at the engine, plus libs/ for the vendored dependencies, tools/, a debian/ directory for packaging, a macosx/ directory, a dist/ directory, and a .urcheon/ directory for the community infrastructure. The C++ sources live under src/, and there is a .git-blame-ignore-revs file, which is the convention for a project that runs automated formatting across its history and wants the blame view to stay readable.

Cloning with submodules, because the engine is a submodule

Unvanquished requires several sub-repositories to be fetched before compilation, and the README is explicit about the consequence. If you have not yet cloned the repository, use the recursive form:

git clone --recurse-submodules https://github.com/Unvanquished/Unvanquished.git

If you have already cloned it, run the submodule update instead:

cd Unvanquished/
git submodule update --init --recursive

The diagnostic for skipping this step is in the README, that if cmake complains about missing files in the daemon/ folder or a similar issue, then you have skipped it. That is a genuinely good piece of error reporting, because the alternative failure mode, a half-configured engine, would otherwise be an afternoon of confusion. The same structure explains the build layout, with daemon/ holding the engine submodule and pkg/ holding the assets, since the build has to find both in the right place.

The build, on three platforms

Building needs git, cmake, python 2 or later with python-yaml and python-jinja, and a C++14 compiler, with gcc 9 or newer, clang 11 or newer, or Visual Studio and MSVC at least 2019 actively supported. On Linux and macOS the output goes into a new build directory:

mkdir build; cd build
cmake ..
make -j4

The -j4 is a hint rather than a rule, and the README explains that you can use -jN with your number of CPU cores, and that Linux systems usually provide nproc so you can write -j$(nproc). On Windows with MSYS2, which the project calls the recommended way to build using MinGW on a Windows host, the generator changes:

mkdir build; cd build
cmake .. -G "MSYS Makefiles"
make -j4

On Visual Studio you run CMake, choose your compiler, open Unvanquished.sln and compile. And there is a cross-compile path from Linux to Windows, using a toolchain file, with a separate file for 32-bit builds:

mkdir build-win64; cd build-win64
cmake .. -DCMAKE_TOOLCHAIN_FILE=../daemon/cmake/cross-toolchain-mingw64.cmake
make -j4

The build produces both the engine and the game logic, and the README says building both is more convenient for testing and debugging, which is a good default for a project where most contributors change both.

The dependency list, which is the real cost of building it

The required libraries are listed and they are not a short list: zlib, libgmp, libnettle, libcurl, SDL3, GLEW, libpng, libjpeg 8 or newer, libwebp 0.2.0 or newer, OpenAL, libogg, libvorbis, libopus and libopusfile. The optional ones are Freetype, Lua and ncurses, and for the two optional ones that ship as submodules the note is that a submodule will be used if the library is not available. That is a friendly arrangement, since it means a contributor does not have to install a font library and a scripting runtime to compile the game. The stack also tells you what the project is, with SDL3 and OpenAL for the window, the input and the sound, GLEW for the OpenGL extensions, and the image and audio codecs listed individually, which is the price of shipping a game that runs on a wide range of hardware. On Windows, the MSYS2 package list is given for both architectures, with the 64-bit set being mingw-w64-x86_64-gcc, mingw-w64-x86_64-cmake and make, and the 32-bit set being the i686 equivalents.

The assets are a download, and the script is the way to get them

The game assets are not in the repository. If you do not have them, you can download a universal zip from the download page, and the pkg/ folder can be stored in the homepath. Otherwise there is a package downloader script, and it can use aria2c, curl or wget, with aria2c recommended, and you can run ./download-paks --help for the options:

./download-paks build/pkg

The snippet places the pkg directory in the libpath of the Dæmon engine you are building, so it is only found automatically from that build directory, and if you would rather the paks be found from all installations and build directories, the recommendation is to download them into the pkg/ subdirectory of the homepath instead. That is a small detail with a real effect on whether a second checkout on the same machine finds the assets, and the same reasoning applies at runtime, where the client is started as ./daemon and takes a -pakpath option to load assets from a pkg/ folder stored somewhere else. On Windows the same commands use daemon.exe and daemonded.exe.

The community infrastructure around the code

The project runs several channels at once, with badges for IRC, Matrix, Discord and a Flatpak release, and the translation setup is the part worth reading for anyone who wants to contribute. The game is translated on Weblate, and the README explains why that is the easier way to contribute translations, because it offers a central place where people can contribute and review translations while reducing the risk of merge conflicts, and because Weblate preserves authorship and automatically produces commits that can be associated with your GitHub account. There is a separate updater repository with its own releases, and the wiki has a page on Linux packages for people who want to create or use packages for package managers. The activity level is visible in the release history, with the Beta 56 release on 2026-03-25, its patch 1 the same day, patch 2 in May, and the last push on 2026-10-15, so the game is in a steady patch cycle with continuous work on the master branch.

Editorial conclusion

Unvanquished is worth building if you want to work on a game with a real community and a long history, because the code base is a documented CMake project with an upstream engine and a separate asset pipeline, so a contributor is joining a structure that already exists. It is the wrong project if you want a game you can install and play in ten minutes, because the engine, the game logic and the assets are three separate downloads, and the wrong project if you want to write a mod without touching C++. Before you start, read the requirements list rather than the wiki, since the dependency set is long and specific, and check the platform you are on, because the Windows path is MSYS2 or Visual Studio and the Linux path is the smooth one.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Unvanquished/Unvanquished on GitHub