Open-source project
Wargus/stratagus avatar
Wargus/stratagus

Stratagus: the C++ engine behind Wargus, War1gus and Stargus

The Stratagus strategy game engine

738 stars141 forksC++GPL-2.0

At a glance

What is it?
Stratagus is a GPL-2.0 C++ real time strategy engine maintained in the Wargus organisation, and the games people actually play are separate repositories that ship it. Its tagged releases stop at v3.3.2 in 2022 even though the engine itself was pushed on 2026-10-18, so the build and packaging pipeline matters more than the version number.
Who is it for?
Adopt Stratagus if you are maintaining a data driven fantasy real time strategy game and want an engine that three separate games already run on, and if you can live with GPL-2.0 obligations for anything you distribute. Do not adopt it as a general purpose engine for a new genre, and do not plan around a tagged version, because the newest release is v3.3.2 from 2022-08-10 while the last push was on 2026-10-18.
Can I use it commercially?
Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?
Yes. The repository last received commits 5 days ago.
What is it written in?
Mainly C++, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The engine is a library; the games are separate repositories

Stratagus is the engine, not a game. The repository description calls it "The Stratagus strategy game engine", and the README banner describes it as a free fantasy real time strategy game engine. Nothing in the repository is a playable title on its own. What exists here is the C++ core that a game, its data files and its rules are built on.

That separation is visible in the release links. The Windows installers live in three other repositories, Wargus, War1gus and Stargus, and the README notes that on macOS the engine comes bundled inside the app bundles for those same three games. The Linux side follows the same pattern, with Launchpad recipes named stratagus-github, war1gus-github, stargus-github and wargus-github, each one a separate build target for a separate product.

For an engineer, this reframes the adoption question. You are not installing a game, you are picking a foundation for one. The people who use Stratagus are teams who want the engine, rules and unit model of a late 1990s style real time strategy and want to reshape them, and they are usually already working inside one of those game repositories rather than starting from the engine tree alone.

A CMake tree with game headers, translations and a Python test layer

The repository layout describes the architecture better than the README does. The root holds a CMakeLists.txt, a cmake/ directory of modules, a cmake-variants.yaml that presumably enumerates build variants, and cmake_uninstall.cmake.in for generated uninstall rules. Underneath sit src/ for the C++ engine, gameheaders/ for the shared game-facing headers, third-party/ for vendored dependencies, and tools/ for helper scripts.

Three entries deserve attention. The .gitmodules file means third-party dependencies arrive as submodules, so a fresh clone needs its submodules initialised before a build can succeed. The po/ directory holds translation catalogues, which confirms the engine is meant for a localised audience rather than a single language release. And the presence of pytest.ini, a pytests/ directory and an external_ai_example.py says the project mixes Python into its development workflow, most likely around the AI scripting side of a strategy game rather than around the C++ core.

Three build systems produce three different artifacts

Stratagus ships through three distinct pipelines, and each one exists for a different consumer. Windows builds run on Appveyor, Linux builds run on GitHub Actions, and the Ubuntu packages are built on Launchpad. The README carries the CI badges for the first two, so a failing Windows build or a failing Linux build is visible from the project page before you try anything.

On Linux the current artifacts are AppImages. The README describes the manual path: open the appimage.yml workflow, find the latest successful run for the master branch, and scroll down to download the game you want. That is a developer-oriented distribution rather than a storefront, and it is described as a dev build, so what you fetch is whatever the branch currently produces.

For users on Debian and Ubuntu there is a Launchpad archive with deb packages, and the README is explicit that the packages you probably want are named wargus, war1gus and stargus rather than the engine itself. It also states that the OpenSUSE, Fedora and Arch Linux communities maintain packages of their own, so distribution is not something the upstream project controls end to end. A packaging maintainer therefore has to choose between tracking the upstream AppImage, tracking the community packages, or producing their own from the engine source.

doc/install.html is where the real installation instructions live

The README is a signpost, not a manual. It points to three files in the doc/ directory and expects the reader to open them: doc/index.html for general information and licence information, doc/install.html for installation instructions, and doc/changelog.html for the changelog.

bash
Read 'doc/index.html' for general information and license information.
Read 'doc/install.html' for Stratagus installation instructions.
Read 'doc/changelog.html' for the Stratagus changelog.

Because the README itself carries no build command, anyone writing a setup guide for this engine should open doc/install.html and follow that rather than reconstructing a build from the CMake files. The repository does, however, show enough about the process to narrow the search. There is a .clang-format file and an .editorconfig file, so the project expects a consistent formatting workflow, and the presence of .vscode/ and .travis.yml suggests the developer experience has been tuned around Visual Studio Code. The README also points to a video that walks through setting up a development environment on Windows using VSCode, which is the fastest answer for the platform where the build instructions are least visible on the page itself.

The HOWTO-NEW-RELEASE file at the root is the maintainer's counterpart, describing how a release is put together. It is the document to read before you tag anything.

A tests directory and an AI example show the scripting surface

Two paths in the tree hint at how the engine is exercised. The tests/ directory holds native tests, and pytests/ plus pytest.ini hold Python driven ones, with external_ai_example.py sitting at the repository root as a working example of driving the AI side from Python. The pytest.ini file at the root is what tells pytest where the suites live and how they are configured.

For a strategy engine, the AI is the part most likely to need to be scripted rather than compiled, so an example that lives outside the C++ tree and is invoked from Python is a meaningful design signal. It suggests the engine exposes its state in a way that an external program can drive, which is what makes scripted opponents and automated testing feasible at all.

What the repository does not show is how much of the game rules live in the engine and how much live in the game data. The gameheaders/ directory is where that interface would be defined, and the README does not document it. Anyone planning to extend unit behaviour, resource rules or pathing needs to read gameheaders/ and the corresponding headers under src/ before estimating the work, because a fork that turns out to modify compiled behaviour instead of data files is a very different proposition from one that edits data.

The version list understates how current the tree is

The release history and the commit history diverge here in a way that can mislead. The tagged releases are v3.3.1 on 2022-07-31 and v3.3.2 on 2022-08-10, followed by a continuous AppImage build entry dated 2023-01-14. Nothing in the release list is newer than that, while the last push to the repository was on 2026-10-18 and the repository is not archived. The repository carries a single topic, help-wanted, which is the maintainers' own signal that outside contributions are wanted.

So the engine is being worked on, and the published versions are not where that work is recorded. A consumer pinning to v3.3.2 is pinning to a tree from 2022, and a consumer building from master is building something the release list cannot describe. Neither is wrong, but they are different engineering postures, and the README does not say which one the games in the other repositories use.

The licence is GPL-2.0, with the COPYING file at the root and licence information also in doc/index.html. That matters more here than for a typical library because the engine ships inside games that people distribute as installers and packages. A team embedding Stratagus in a proprietary product needs to read the licence text and work out the obligations itself; nothing in the repository gives legal guidance, and this review does not either.

Editorial conclusion

Adopt Stratagus if you are maintaining a data driven fantasy real time strategy game and want an engine that three separate games already run on, and if you can live with GPL-2.0 obligations for anything you distribute. Do not adopt it as a general purpose engine for a new genre, and do not plan around a tagged version, because the newest release is v3.3.2 from 2022-08-10 while the last push was on 2026-10-18. Verify first by reading doc/install.html in a checkout, then run the AppImage workflow described in the README to see whether a current Linux build starts on your machine before you commit any code to it.

Frequently asked questions

How do I build Stratagus from source?

The README does not give a build command and points to doc/install.html for Stratagus installation instructions. The build itself is CMake based, with CMakeLists.txt and a cmake/ directory at the repository root, and third-party dependencies are pulled in through the .gitmodules file, so submodules need to be present before a build works.

Is Stratagus a game or an engine?

It is the engine. The README describes it as a free fantasy real time strategy game engine, and the playable games are separate repositories: Wargus, War1gus and Stargus, which publish their own Windows installers and macOS app bundles.

What is the latest Stratagus release and how active is the project?

The newest tagged release is v3.3.2 from 2022-08-10, preceded by v3.3.1 and a continuous AppImage build entry from 2023-01-14. The repository is not archived and the last push was on 2026-10-18, and it carries a help-wanted topic. The project is licensed GPL-2.0.

Official sources

  1. Issues
  2. License: GPL-2.0
  3. README
  4. Releases
  5. Wargus/stratagus on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/wargus-stratagus.svg)](https://hysenlabs.com/projects/wargus-stratagus)