Thrive: Building a Godot Evolution Game in C#

What Thrive Is and Who the Repository Is For

Thrive is an evolution game: the player guides an organism through a biology and strategy sandbox, and the repository is the main development home for it. The README points players at the Steam and Itch.io store pages and at the studio's releases page, which is the honest split. The code repository is not the product page.

The people this repository is written for are contributors. The README breaks them into programmers, modellers and texture or GUI artists, and sound engineers, and each group gets a different path. Programmers compile the game themselves. Artists install Godot and work on the project files. Translators go through a separate Weblate instance rather than the source tree. If you are none of those, the README has nothing for you beyond the store links and the community forum.

The project is not archived, and the last push to master was on 2026-09-23, so the codebase is moving. That matters less than it sounds for a newcomer: the setup guide, the style guide and the AngelScript primer in doc/ are the documents that decide whether your first pull request survives review, and they are the ones to read before touching anything.

How the Repository Is Wired Together

The layout is a Godot project with the game logic in C#. src holds the core game code and the Godot scenes, and project.godot at the top level is the Godot project file. assets holds models and other binaries, and the README states plainly that the big files there use Git LFS, so a plain clone without LFS leaves you with pointer files instead of art. Better editable versions of some assets live in a separate Thrive-Raw-Assets repository.

Two directories carry the tuning surface. simulation_parameters contains JSON files plus C# constants for tweaking the game, which is the closest thing to a data-driven balance layer. shaders and addons sit alongside it, and third_party, lib and native_libs hold external code and native dependencies. test exists, but the README says the tests do not currently exist for the Godot version, which is a real gap rather than a detail.

The build story spans more than C#. CMakeLists.txt and a merge_drivers directory sit at the top level, and the repository ships a flake.nix and flake.lock plus a podman directory. That is a project that has native pieces and reproducible build environments in mind, not a pure managed-code game. The history was rewritten at some point to strip large binaries added before LFS, and the original history is kept on a separate original_master branch.

Setting Up a Thrive Development Build

The README does not inline the build steps. It points to doc/setup_instructions.md and, for anyone new to the engine, doc/learning_godot.md. Treat those two files as the source of truth, because the exact engine version and toolchain are pinned there and not in this article.

The one prerequisite the README does state outright is Git LFS. Without it you get the asset folder's large files as small text pointers, and the game will not have its models. Install it before you clone, or run the fetch afterwards:

git lfs install
git clone https://github.com/Revolutionary-Games/Thrive.git

Once the repository is on disk, the helper scripts are run through dotnet. The README gives this example directly, and it is the fastest way to see what tooling exists:

dotnet run --project Scripts -- help

You should see the script runner print its available commands rather than a build error. If it fails, the failure is in your .NET SDK setup, not in the game, and global.json at the repository root is what pins the SDK expectation.

For code changes, Thrive.sln and Thrive.csproj are the entry points for an IDE. Before submitting anything, read doc/style_guide.md, which covers both formatting and git usage. That document, not this article, is what reviewers will hold you to.

Contributing Art, Sound and Translations Without Writing C#

The repository is deliberately open to non-programmers, but the mechanics are uneven. Artists install Godot and work on the project files using the same setup guide as programmers. The README then adds a constraint: committing to the Git LFS server yourself is currently limited to Thrive developers, so outside artists hand assets to a developer who commits them. That is a real bottleneck, and the README describes it as temporary, with self-service LFS commits planned at a later time.

Modellers have an extra step. There are separate import instructions on the developer wiki for bringing models in, and the README links them rather than repeating them. Skipping that page is the usual way an asset contribution stalls.

Translation is the cleanest path in. The README sends translators to doc/working_with_translations.md, and the project runs on a Weblate instance with its own progress badge. If your goal is to help without learning Godot, this is the route with the fewest obstacles.

One thing the README does not document is a rollback or revert procedure for a bad asset commit. If you push something wrong, the recovery path is ordinary git history rewriting, and the project's own history rewrite is a reminder that this is not a casual operation.

Where Thrive Stops Being the Right Tool

The clearest limitation is stated in the README itself: tests do not currently exist for the Godot version. The test directory is present, but it does not cover the engine build. For a contributor that means your change is validated by review and by playing, not by a suite that catches a regression before a human does. For anyone hoping to study Thrive as an example of a well-tested C# game codebase, that expectation is wrong.

The second constraint is size and assets. This is a game repository with binary models, Git LFS, a separate raw-assets repository, and a third_party directory. It is not a small library you can vendor into another project. Cloning it, building it and iterating on it costs disk, bandwidth and a Godot install.

The third is that the repository is a game, not a simulation library. If you want an evolution or population model to embed in your own software, Thrive's simulation_parameters JSON and C# constants are tuned for gameplay, and the README describes them as a way to tweak the game, not as a published API. There is no documented interface for driving the simulation from outside the game.

Finally, if you only want to play, none of this applies to you. The README's own first move is to send you to Steam or Itch.io.

How Thrive Differs From a Conventional Engine Project

The obvious comparison is a general-purpose Godot game template or a commercial evolution sim. The difference is in what is versioned. A typical Godot project keeps scenes and scripts together and leaves art to the artist's disk. Thrive versions the art through Git LFS, keeps a second repository for editable source assets, and rewrites history when binaries bloat the pack. That is an unusual amount of infrastructure for a game repository, and it exists because the assets are large and the contributor base is distributed.

Against a closed-source evolution game, the difference is the tuning layer. simulation_parameters exposes the numbers that shape the simulation as JSON and C# constants in the repository, so a contributor can change how the game behaves without reverse engineering anything. A closed game gives you a settings menu; Thrive gives you the values.

Against a pure C# project, the difference is the native surface. CMakeLists.txt, native_libs, third_party, flake.nix and the podman directory mean the build is not just dotnet build. If your mental model is a managed-only codebase, the setup guide will correct it quickly.

Licence and the Cost of Staying Current

The repository's licence is reported as NOASSERTION, and the top level contains both LICENSE.txt and gpl.txt. That combination is worth reading yourself before you reuse code, because the two files do not obviously describe the same terms and the repository metadata does not resolve which applies. This is not legal advice; it is a reason to open both files and, if you plan to redistribute, ask the project directly through its forum or Discord.

The upgrade cost is the ordinary cost of tracking a moving game. The last push was on 2026-09-23, and the release cadence visible in the release list runs from v1.0.1.1 in March 2026 through v1.1.0 in May to v1.6.0 in August. If you fork, you inherit the job of rebasing onto that. The setup guide and the style guide are the documents that change when the toolchain moves, so a fork that pins an old Godot version will drift from them.

There is no documented deprecation policy in the README, and no statement about how long a given branch or API is supported. Plan for that by reading doc/ and the developer wiki rather than assuming stability.

Editorial conclusion

Thrive is for people who want to read or modify a real C# and Godot codebase, or who want to contribute art and translations to a game that ships under the GPL. It is not the tool for someone who just wants to play: buy it on Steam or Itch.io instead. Before you start, read doc/setup_instructions.md, install Git LFS, and check whether the code you plan to touch has tests, since the README says the Godot version has none.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Revolutionary-Games/Thrive on GitHub