# Return To The Roots: a Settlers 2 remake that still needs the original game

> Return To The Roots is a fan project that rewrote The Settlers 2 from scratch so it would run on modern systems, with Linux, macOS and Windows builds, an online multiplayer goal and nightly packages. The catch is stated plainly: it keeps the original graphics and sound, so you still need a copy of The Settlers 2 Gold Edition to play it.

**Return-To-The-Roots/s25client** — Return To The Roots (Settlers II(R) Clone)

- Repository: https://github.com/Return-To-The-Roots/s25client
- Website: http://www.rttr.info
- Stars: 600 · Forks: 111
- Language: C++
- License: GPL-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/return-to-the-roots-s25client

## A rewrite that keeps the original graphics and sound

Return To The Roots is a fan project which aims to renew the original The Settlers 2. The stated goals are to extend new features such as a multiplayer mode via internet, and to support modern hardware and several operating systems like Windows Vista, Seven and 10, Linux and MacOS X, plus some smaller upgrades.

The reason a rewrite was necessary is that the original game was tied to its own era, and the project took the unusual decision to keep the original graphics and sounds, because they are still common and nice to be heard or seen.

That decision has a direct consequence for anyone installing it: you will still need an original The Settlers 2 Gold Edition version to play Return To The Roots. The project does not ship the assets, and the data and graphics folders are taken from the retail game.

For the people behind it, that is a preservation argument rather than a technical one. The alternative, redrawing the art in a modern style, would have produced a different game, and the appeal of a remake like this is that the thing you remember is the thing you play. The price is that the build is not self-contained, and the game cannot be distributed as a standalone download without the original data.

The project site is at rttr.info, and the copyright header in the source names Settlers Freaks with the span 2005 to 2025 and an SPDX identifier of GPL-2.0-or-later.

## Installing means handing the game its original data

The installation instructions are short and specific, and they assume you already have the retail game.

You download the game for your operating system from the downloads page, where there is a stable build that is usually more stable and a nightly build with the latest features and bug fixes, but which might be broken sometimes. Then you extract it into a folder of your choice.

Inside that folder you locate the file named `put your S2-Installation in here`, which is usually at the root or in the S2 folder, and you copy the DATA and GFX folder from the original The Settlers II Gold into the folder containing that file.

To start the game you run `rttr.bat` on Windows or `rttr.sh` on the other platforms, or the bundle on macOS, and those launchers auto-update the game and start it. The alternative is to start `s25client` directly, but the documentation warns that in that case updates and music might be missing.

There is one warning that will save you an afternoon if you read it first. Do not use symlinks, junction points or the equivalent for subfolders of your installation. Putting the game itself in a symlinked folder should work.

That asymmetry is the sort of detail that only surfaces after a bug report, and it is worth taking at face value: the game walks its data directories, and a symlinked subfolder changes the path relationships in ways it does not expect.

## Building on Linux and macOS with CMake

The Linux and macOS build path is the one most contributors use, and it is a conventional CMake build with a fairly long dependency list.

On Linux you need a C++14 compatible compiler, cmake, git, boost at least v1.71.0, libsdl2-dev, libsdl2-mixer-dev, libcurl-dev, libbz2-dev, lua5.2-dev with Lua 5.1 to 5.3 supported, gettext and libminiupnpc-dev. The readme notes that all of them can be installed with the package manager, and it also offers the narrower set of boost development packages if you do not want the whole library. On macOS the list is cmake, git, boost, sdl2, sdl2_mixer, gettext, miniupnpc and Lua 5.1 to 5.3, installable via homebrew, with a note to force link gettext so it is in your path.

Nix users can open a nix-shell to get a development environment with all the packages ready, and the repository ships a `shell.nix` for that purpose.

The checkout and build itself is:

```bash
git clone --recursive https://github.com/Return-To-The-Roots/s25client s25client
cd s25client
nix-shell # Optional, for Nix users only
mkdir -p build && cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make
```

The `--recursive` flag on the clone matters, because the project uses submodules for its external dependencies, and the release build type is what you want for the game rather than for development.

## Windows builds go through cmake-gui and a hand built Boost

The Windows path is older in style and more manual. You need cmake, boost, Visual Studio at least 2017, with the community edition free, and a Git client such as TortoiseGit.

The clone instructions give two routes. In Git bash it is the same recursive clone as everywhere else. With TortoiseGit you use the Git clone dialog, put the repository URL in, select the directory, and then right click the new folder, choose TortoiseGit and Submodule Update, make sure all modules are selected and that Initialize submodules is checked.

If boost is not installed, the readme gives a fast way: extract the boost archive into the `external/boost` directory so that `external/boost/bootstrap.bat` exists, run that batch file, then run the `b2.exe` it creates to build boost, and finally run `b2 install --prefix=%CD%` to install it where the system can find it. There are notes about using the latest Visual Studio toolset when several are installed.

The CMake step is done in cmake-gui, with the source directory and the build directory set, then configure, select the compiler version, and, if boost cannot be found, add an entry named `BOOST_ROOT` with the exact casing given, of type PATH, pointing at the boost installation. Press generate and open `build/RTTR.sln`.

The exact casing warning on `BOOST_ROOT` is the kind of thing that costs an hour when it is wrong, so the readme is doing you a favour by saying it.

## CMake options, submodules and the update rule

The build has a set of CMake options for controlling optimization and platform tuning, and the readme lists the ones you are most likely to want.

`RTTR_ENABLE_OPTIMIZATIONS` and `RTTR_ENABLE_WERROR` turn the optimization set and the warnings-as-errors behaviour on. `RTTR_OPTIMIZATION_VECTOR_EXT` enables vector extensions, on non-Windows x86 and x64 only. `RTTR_OPTIMIZATION_TUNE` tunes for the target CPU, on non-Windows only. `RTTR_TARGET_BOARD` selects a target board for ARM platforms such as the Raspberry Pi. The descriptions live in the CMake GUI or ccmake.

There is also a `dev-tools` submodule with prebuilt binaries for various platforms, so you can start building without compiling the dependency stack yourself. They are not compatible with every system, for example not with musl libc, so they are not used by default. You opt in by configuring with `-DRTTR_INCLUDE_DEVTOOLS=ON`, and CMake will then find them.

The update rule is the one to internalise. Because the project uses submodules, you always need `git pull && git submodule update --init --recursive` to get the latest version, and the readme notes that the `--init` and `--recursive` arguments are only required if new submodules have been added to the existing set.

The general shape of the repository matches that: an `external` directory for vendored dependencies, `libs` for the game's own libraries, `data` for game data, `extras`, `tools`, `tests`, and a `cmake` directory with the build system plus `copyDepsToBuildDir.cmake` for staging dependencies into the build output.

## Tests, sanitizers and continuous integration

For developers the readme recommends building in Debug mode with `-DCMAKE_BUILD_TYPE=Debug` and running the tests after `make`, through `make test` or `ctest --output-on-failure`.

There is also a sanitizer build. Passing `-DRTTR_ENABLE_SANITIZERS=ON` to CMake enables checks for undefined behaviour through UBSAN and for memory errors through ASAN, such as use-after-free or leaks, and the readme asks for a recent GCC or Clang compiler. After that, you run the tests or the application as usual.

That combination is the interesting part for a C++ project of this vintage. A codebase rewritten from a 1990s game and maintained by volunteers for two decades accumulates the kind of lifetime and pointer mistakes that a sanitizer finds quickly, and a CI configuration that runs the unit tests and static analysis on every push catches them before a player does.

The badges in the readme confirm that setup. There is a GitHub Actions workflow for unit tests, a separate one for static analysis, and coverage tracked on both Coveralls and Codecov.

The repository also carries a `Jenkinsfile`, a `.clang-format` and a `.clang-tidy` configuration, and a `Doxyfile.in` for generated documentation, so the code quality tooling is part of the project's own configuration rather than left to the host environment.

## Licence, packaging and a release line that stopped

The licence is GPL-2.0-or-later, stated in the SPDX header at the top of the source, and the repository has both a `LICENSE` file and a `LICENSES` directory, along with a `.reuse` directory. That combination indicates the project follows the REUSE specification for licence metadata, where every file carries its own licence and copyright information rather than relying on a single file at the root.

Packaging is documented separately in `PACKAGING.md`, which is the file to read if you want to produce a distribution rather than just build it. The project also has a `Jenkinsfile` for its own CI, a `shell.nix` for Nix users, a `doc` directory, and a `start.sh` with a `start.sh.cmake` counterpart, which is the launcher the instructions tell Linux and macOS players to use so that the game auto-updates and the music is found.

The one fact that should shape your expectations is the release history. The recent tags are v0.9.3 and v0.9.4, both on 2022-01-06, and v0.9.5 on 2022-02-28. The last push was on 2026-10-19, and the repository is not archived, so the code is being worked on while the tagged releases have not moved in more than four years.

That is consistent with a project whose own download page distinguishes stable builds from nightlies. The nightly build is where the current work is, and the stable tag is where the last known good state is recorded. If you want a version that is unlikely to break, take the stable build and accept that it is old.

## Conclusion

Return To The Roots suits a player who owns The Settlers 2 Gold Edition and wants it running on a modern system with a modern multiplayer roadmap, and who is comfortable building from source or installing a nightly. It is a poor fit if you do not have the original game, because the project deliberately reuses the original assets rather than shipping its own, and it is a poor fit if you need a supported release, because the newest tag is v0.9.5 from 2022-02-28 even though the last push was on 2026-10-19. Before you install, check whether the nightly build for your platform is listed, remember the symlink warning when you set up the data folders, and follow the project's own update rule of pulling with `git submodule update --init --recursive` so you are not running a half updated tree.

## FAQ

### Do I need the original Settlers 2 to play Return To The Roots?

Yes. The project keeps the original graphics and sound, so you need an original The Settlers 2 Gold Edition. You copy the DATA and GFX folder from the retail game into the folder containing the `put your S2-Installation in here` file.

### How do I build Return To The Roots on Linux?

Clone the repository recursively, optionally enter the nix-shell, create a build directory, run `cmake -DCMAKE_BUILD_TYPE=Release ..` and then `make`. The dependencies include a C++14 compiler, cmake, git, boost at least 1.71.0, SDL2, SDL2 mixer, libcurl, libbz2, Lua 5.1 to 5.3, gettext and miniupnpc.

### What is the dev-tools submodule for?

It contains prebuilt binaries for various platforms so you can start building quickly. They are not compatible with every system, for example not with musl libc, so they are off by default and you enable them with `-DRTTR_INCLUDE_DEVTOOLS=ON`.

### How do I run the tests and the sanitizers?

Build in Debug mode with `-DCMAKE_BUILD_TYPE=Debug`, then run `make test` or `ctest --output-on-failure`. Passing `-DRTTR_ENABLE_SANITIZERS=ON` enables undefined behaviour and memory error checks such as use-after-free and leaks with a recent GCC or Clang compiler.

### Why do I need to update the submodules every time?

The project uses submodules for its external dependencies, so the documented rule is always to run `git pull && git submodule update --init --recursive` to get the latest version. The readme notes that the `--init` and `--recursive` arguments are only needed if new submodules have been added.

## Sources

- [License: GPL-2.0](https://github.com/Return-To-The-Roots/s25client/blob/master/LICENSE)
- [Project website](http://www.rttr.info)
- [README](https://github.com/Return-To-The-Roots/s25client/blob/master/README.md)
- [Releases](https://github.com/Return-To-The-Roots/s25client/releases)
- [Return-To-The-Roots/s25client on GitHub](https://github.com/Return-To-The-Roots/s25client)

---

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