Colobot: Gold Edition keeps the Epsitec robot game alive as an open source project

A remake of the original game, kept alive by a community

Colobot: Gold Edition is a remake of the original Colobot, the game where a small robot explores a planet and programs itself in a C++-like scripting language, so that solving a puzzle means writing a loop rather than tapping a solution. The repository describes itself as the main source for the open source project, developed by TerranovaTeam and community contributors, based on the original game by Epsitec.

That lineage explains the shape of the thing. The Gold Edition is the community's continuation of it, and the feature list in the README is framed around that: play on any modern OS, new game modes such as Missions+ and CodeBattles for challenging yourself or your friends, mod support with custom levels and assets from the project's ModDB page, and improved visuals, quality of life additions and bug fixes.

The channels the project runs are visible in the README badges: the site at colobot.info, a Discord server, GitHub Discussions, a ModDB presence, and the usual YouTube, Reddit, Twitter and Facebook links. The updates page at colobot.info/category/news/updates is where the change announcements live, which is a better source for what actually changed than the release tags alone.

The project is licensed GPL-3.0, with LICENSE.txt at the top of the tree and a separate LICENSE-HEADER.txt for per-file headers. The default branch is dev, which tells you the main line of development is not where the tagged builds come from.

The repository holds source only, and the data is a submodule

The single most important thing to know before you clone this repository is that it is not the whole game. The README says plainly that the repository contains only the source code of the project, and that the game also requires data files which are provided as a git submodule and hosted in a separate repository, colobot-data.

The.gitmodules file at the top level and the data/ entry in the tree are the visible traces of that. A clone without submodule initialisation gives you code that compiles against data that is not there, and the failure will look like missing resources rather than an obvious error. Anyone building from source has to fetch the submodule content as a separate step before the game will run.

The rest of the layout is a modern C++ project with a CMake build. CMakeLists.txt sits at the root, alongside CMakePresets.json for build presets and a cmake/ directory with the module definitions, plus vcpkg.json for dependency management through the vcpkg tool. The code is split into colobot-app/, colobot-base/, colobot-common/ and desktop/, with CBot/ holding the game logic itself, lib/ and tools/ for shared code and command line tools, po/ for translations, test/ for tests, scripts/ for build and release helpers, and docs/ for the build instructions.

The presence of a Doxyfile.in points to generated API documentation, and a desktop/ directory with a po/ directory means the project ships Linux desktop integration and localised strings rather than being a single portable binary.

Packaged builds cover most Linux distributions already

If you are on Linux, compiling is probably not necessary. The README points at Repology for the packaged versions, and the badges name the specific distributions: Debian Unstable, an AUR package named colobot-gold, an openSUSE games Tumbleweed package, a Fedora Rawhide package, a GNU Guix package, and a Void Linux x86_64 package.

That list is the practical answer for most Linux users, and it is worth noting that the Arch package is named colobot-gold while the others use colobot. The packages exist in development and unstable channels rather than in stable releases, which fits a project whose default branch is dev and whose newest tagged build is an alpha.

Official builds for Windows, Linux and MacOS are linked from the download page at colobot.info/download-colobot-gold. Development builds are compiled on every push to the repository by GitHub Actions, with a workflow badge linking to the actions runs. So for a tester, the CI artefacts are the freshest option and the tagged alpha is the most stable one available.

The build documentation is split by environment, which tells you the project is genuinely built on all three platforms rather than only developed on one. There is INSTALL.md at the root for Linux, docs/INSTALL-MSYS2.md for Windows with the MSYS2 toolchain, a wiki page for building on Windows with MSVC, and docs/INSTALL-MacOSX.md for macOS. The presence of a separate MSVC wiki page outside the repository is a small but telling detail, since the MSVC build does not use the CMake path the other three share.

What the tagged releases actually tell you

The release history is short and honest. colobot-gold-0.2.0-alpha came on 2021-08-21, colobot-gold-0.2.1-alpha on 2023-08-07, and colobot-gold-0.2.2-alpha on 2024-12-23. Every tagged release is an alpha, and the gaps between them are measured in years rather than weeks.

This matters for how you read the activity indicators. The repository is not archived and the last push was on 2026-08-11, so commits are landing, and the CI badge confirms that every push produces a build. But the absence of a 0.2.3 tag since the end of 2024 means there is no named release that captures the current state of the dev branch. Anyone installing from a package repository or from CI is running a build that no release names.

The commit history and the updates page are therefore the real changelog, and the project acknowledges this by linking a news and updates category on its site as a feature bullet point, alongside the changelog material that would be expected in the repository.

The mod ecosystem is the other half of the project's life. The README points to a ModDB page for custom levels and assets, and the badge set includes ModDB and Discord, so the community activity sits on those platforms rather than in the issue tracker. A project with a two year gap between alphas can still be very much alive if the people playing it are the people patching it, and the mod page is where that happens.

What this repository is not suited for

There is a clear mismatch between what people want from a Colobot repository and what a source repository can give them, and it is worth stating plainly.

First, this is not a playable artefact. Cloning gives you a build tree, not a game, and the game needs the data submodule. For a player, the packaged builds and the download page are the route, and the source repository matters only if you intend to change the game or add a mod.

Second, the code base is old in its assumptions. The original game targeted hardware and compilers from a different era, and a project that has been carried forward through a community fork years of development is going to contain a mixture of eras. The vcpkg.json file means dependencies are pinned through a modern mechanism, and the CMakePresets.json suggests the build was modernised, but the surrounding code has had to be ported rather than rewritten. The README does not state a minimum compiler version or a C++ standard, which is itself a small gap for someone setting up a build from scratch.

Third, the docs situation is uneven. Some build guides live in the repository under docs/, one lives in a wiki, and the release announcements live on the site. A contributor following CONTRIBUTING.md at the root will find the conventions, but a user looking for one authoritative build guide will be redirected between three places.

None of that makes the project bad. It makes it a preservation project with the shape such projects always have, and it means the right question for most people is not whether to compile Colobot but which packaged build to install.

Editorial conclusion

Colobot: Gold Edition suits someone who wants to play the classic robot programming game on a current operating system or work on its C++ and CMake source, and it does not suit someone looking for a finished commercial release, since the newest tagged build is still an alpha from 2024. Before cloning, read the submodule step, because the repository contains only source code and the data files have to be fetched separately. Verify first that your platform has a packaged build, since Repology lists Debian, Arch, openSUSE, Fedora, Guix and Void packages that are a faster route than compiling.

Frequently asked questions

Official sources

1. colobot/colobot on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases