RecoilEngine, a fork of Spring 105 that Beyond All Reason still ships by date

A Spring 105 fork that changed its name and kept its engine

Recoil is described in its own README as an open source real time strategy game engine, and its homepage is recoilengine.org. The important structural fact is the ancestry: Recoil is a fork and continuation of the Spring engine, version 105.0. That single sentence tells you most of what you need to know about the code, the build system and the compatibility expectations, because a fork inherits its parent's architecture rather than designing a new one.

The continuation part is what the project has added. A fork that merely tracks upstream would be a packaging exercise; a continuation means the engine has moved on from the point where the fork was taken. The repository layout backs that up. Beyond the rts/ directory that holds the engine code there are tools/, cont/, doc/, test/, an installer/ directory, an AI/ directory, a coding-agents/ directory,, plus CMakeLists.txt, a Doxyfile, a VERSION.template and a coding-agents guide.

So the engine is not a bare code drop. It carries its own build configuration, documentation generation, packaging and agent-facing instructions, and the Beyond All Reason community runs the project through its Discord, which the README points at for help, suggestions, bugs and a forum.

The clone must be recursive or submodules stay empty

Getting the sources is one command, and the flag on it is not optional:

    git clone https://github.com/beyond-all-reason/RecoilEngine --recursive

The recursive flag pulls in submodules, and the repository does have a .gitmodules file, so a plain clone leaves you with a tree that looks complete and is not. For an engine with this many vendored dependencies, that is the kind of detail that turns into an afternoon of confusing build errors if you skip it.

The README frames the source as the primary path for developers, while noting separately that people who just want an engine binary can take a pre-compiled build from the releases page, usually as an installer or a package prepared for the operating system. The distinction matters for what you are evaluating. If you want to run the engine, a packaged build is the sensible starting point and the source tree is unnecessary. If you want to change the engine, the source tree and the submodule layout are the whole point, and the packaged binary teaches you nothing about how the build works.

Tags decide which Spring revision you are actually building

The README asks you to start with master as the primary branch and to verify that you are seeing tags. The check is a plain git tag, and the output it should produce looks like this:

>>> git tag
spring_bar_{BAR105}105.0-430-g2727993
spring_bar_{BAR105}105.1.1-1005-ga7ea1cc
spring_bar_{BAR105}105.1.1-1011-g325620e
spring_bar_{BAR105}105.1.1-1032-gf4d6126
spring_bar_{BAR105}105.1.1-1039-g895d540
spring_bar_{BAR105}105.1.1-1050-g5075cc0
...

The tag names encode the Spring 105 lineage, so they are the fastest way to confirm you are building against the engine generation the project expects. If those tags are missing, the README says the usual cause is that you cloned your own fork of the repository rather than the upstream version, and the fix is to add the upstream remote and fetch everything:

git remote add upstream https://github.com/beyond-all-reason/RecoilEngine
git fetch --all --tags

Then master has to point at upstream master, which the README does with a checkout and an explicit upstream tracking branch. The lesson for contributors is that a fork workflow means remote hygiene is part of getting a working build, not an afterthought.

Two build paths, one of them containerised

For people who just want an engine binary, the README recommends the Docker scripts documented in docker-build-v2/. For people who want to compile without Docker, in order to use a different compiler or to get a better setup with code completion in an IDE, the README points to a building without Docker article on the project website.

The split is the interesting part. A containerised build pins the toolchain and the dependencies for everyone, which is what you want for reproducible results and for continuous integration. Building outside the container gives you the compiler of your choice and a workable editing experience, at the cost of solving dependency discovery yourself. The repository supports both, and the docker-build-v2 directory with its own README is the documented entry point for the first one.

The repository root also shows how the project thinks about builds and checks. There is a .cmakelintrc for the CMake setup, a .travis.yml for the older continuous integration configuration, a Doxyfile for documentation generation and a .editorconfig and .gitattributes for consistent formatting. The AI/ and coding-agents/ directories suggest that automated tooling is expected to work inside this tree rather than being bolted on from outside.

Custom terms, GPL texts in the tree, and an AI usage policy

Licensing here needs a careful reading rather than a badge. The README says only that the terms are documented in the LICENSE file, and the licence field for the repository is one GitHub cannot classify. So the authoritative answer is the file, not a summary. The repository does ship gpl-2.0.txt, gpl-2.0.html, gpl-3.0.txt and gpl-3.0.html alongside COPYING and LICENSE.html, which tells you the tree carries both GPL 2.0 and GPL 3.0 texts, but which of them applies to which part, and what the additional terms are, is something you have to determine from the LICENSE and COPYING files rather than assume.

There is a second policy document with the same kind of force. The README asks anyone using AI tools to adhere to the AI usage policy, pointing at AI_POLICY.md in the repository, and the tree carries both that file and an AI/ directory. A project that ships an explicit policy for machine-generated contributions is telling contributors what it expects, and the policy is the thing to read before you run an agent over the codebase.

For a GPL-era engine, these are ordinary documents, and for an adopter the practical step is to read LICENSE, COPYING and AI_POLICY.md in the checkout before distributing anything built from it.

Releases are named by date, and the push cadence is weekly

The release naming is unusual and worth understanding before you write any automation around versions. The listed releases are 2026.09.01, published on 2026-09-18, then 2026.07.04 and 2026.07.03, published on 2026-08-04 and 2026-08-03. The names look like dates but the publication dates lag behind them, so a tag like 2026.07.04 was published in August.

That convention means a version string tells you when a build was cut rather than which semantic version it is, and it means there is no minor or patch distinction to reason about. There is also no 1.x to 2.x progression to track. If you pin a dependency, you pin a date.

The last push to master was on 2026-10-20, so the tree is moving. The engine itself lives in rts/, with the test/ directory holding the test suites, doc/ the documentation, installer/ the packaging work, and tools/ the auxiliary tooling, and a VERSION.template file, which fits a project that names builds by date.

Editorial conclusion

Adopt RecoilEngine if you want to contribute to or build on an actively worked real time strategy engine with a reproducible Docker build and a known Spring 105.0 ancestry, and expect to read the LICENSE file yourself since the licence terms are custom and the repository also ships GPL 2.0 and GPL 3.0 texts. Do not adopt it if you need a packaged game, an engine with a conventional semantic version and a stable plugin API, or a build you can set up without reading the docker-build-v2 documentation. Verify first that the tags visible after your clone match the spring_bar_ tag list, that master tracks upstream master with the fetch and checkout commands, and that your use complies with AI_POLICY.md before running AI tooling over the tree.

Frequently asked questions

Official sources

1. beyond-all-reason/RecoilEngine on GitHub
2. Issues
3. Project website
4. README
5. Releases