# Cytopia: an isometric city builder, last released in 2020

> Cytopia is a GPL-3.0 pixel-art city building game with a custom isometric engine written in C++ on SDL2, procedural terrain, a Qt tile editor and a stated focus on mods. The newest release is v0.2.1 from 2020-04-14 while the last commit is from 2026-09-04, and in-game mod downloading, mod scripting and gameplay mechanics are all still on the planned list.

**CytopiaTeam/Cytopia** — :deciduous_tree::house_with_garden::office::evergreen_tree: A city building simulation game

- Repository: https://github.com/CytopiaTeam/Cytopia
- Website: https://www.cytopia.net
- Stars: 2,168 · Forks: 129
- Language: C++
- License: GPL-3.0
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/cytopiateam-cytopia

## The last release is from 2020, the last commit is from 2026

Two dates define what this project is right now, and they are six years apart.

The three most recent releases are v0.1.1 tech preview on 2019-03-16, v0.2 The Map Update on 2020-02-20, and v0.2.1 Jimproved on 2020-04-14. The last push to the repository was on 2026-09-04.

So the newest tag is v0.2.1, from April 2020, and the default branch has roughly six years and five months of commits on top of it. Nothing has been released since.

That gap is the first thing an evaluator has to come to terms with, because it changes what the project is. This is not an abandoned project: the last push is under a month old, and the presence of a Renovate configuration, a SonarQube properties file, a clang-format file, a tests directory and a Doxygen configuration in the repository root is the profile of a repository where work is happening. It is a project with an active codebase and an inactive release train.

The consequences are concrete. If you clone and build master, you get six years of work that no packaged build contains. If you download a release, you get April 2020. If you are a distro packager reading the release page, you have nothing to package since 2020, and the itch.io page and the website are the routes a player would use instead.

The release naming is worth a note as well, because it is a personality signal. v0.2.1 is codenamed Jimproved, which is a pun on improved that inserts a first name, and v0.2 is The Map Update. That is a maintainer or team who names releases for the people who did the work rather than for the version, which is a good sign about the culture and a poor sign about release discipline, though those are not the same thing.

The version number itself is the third signal. v0.2 after three years is consistent with a project that has not yet declared its feature set stable, which matches the planned-features list discussed below. A 0.2 that is six years old is less a version than a statement that the team has not reached 1.0 and is not in a hurry.

For an evaluator, the practical split is this. If you want to play a game, the honest answer is that the newest playable build is from 2020. If you want to read an isometric renderer, a procedural terrain generator and a Qt-based content pipeline written in modern C++, the master branch is the artefact and the README's feature list is roughly accurate for it.

## Big focus on mods, with the mod infrastructure still planned

The README's second sentence is the project's pitch. Cytopia is a free, open source retro pixel-art city building game with a big focus on mods.

The features that are actually listed as current are: a custom UI system, an SDL2 based rendering engine written in C++, camera panning, zooming and relocating, terrain manipulation, procedural terrain generation, pixel-art graphics, an original soundtrack with ambient noises and sound effects, and a Qt based tile editor for editing TileData JSON files.

Set those against the planned list, and the shape of the project becomes clear. The planned features are biomes, an OpenGL renderer, gameplay mechanics, an in-game mod downloading mechanism, Android and iOS, and a scripting language for mods like LUA.

Three of those six are the mod story. In-game mod downloading means there is currently no way to obtain a mod from inside the game, so a mod is a directory you download from somewhere else and place yourself. A scripting language for mods means there is currently no way to give a mod behaviour, so a mod is data, not code. And gameplay mechanics means there is currently no game.

That last one is the most important. A city builder is a simulation: population, economy, services, budgets, growth. None of that is in the current feature list, and gameplay mechanics is on the planned list. What exists is a terrain generator, an isometric renderer and a content editor. That is a city editor, or a level editor for a city, and it is a perfectly respectable thing to build first because the renderer and the tile pipeline are the hard parts.

The tile editor is the part that makes the mod focus real rather than aspirational, and its design is worth describing. It is a Qt application for editing TileData JSON files, so the content format is JSON and the tool to author it is a desktop GUI. The tiles in the game are therefore data files, and a person making content for Cytopia writes or edits JSON and validates it in the editor rather than hand-authoring binary assets. That is a good decision for a modding community, because JSON is diffable, reviewable, mergeable and readable without any tool at all.

The one thing to note is that Qt is not in the prerequisites list. The list is CMake, Conan, SDL2, SDL2_ttf, SDL2_image, OpenAL, zlib, libnoise, libogg, libvorbis, libpng and imgui. Qt is the tile editor, not the game, so it is a separate build target and probably a separate repository or a CMake option. The README does not say which, so anyone wanting to modify the editor needs to work that out.

There is also an asset attribution line that says more about how this kind of project is built than any feature list. Pixel-art graphics made by a graphics team lead by Kingtut 101, and an original soundtrack, ambient noises and sound effects made mostly by MB22. Two named people doing the art and the audio, named in the README, while the engine is C++. That is the shape of an open-source game: a small technical team supported by a couple of dedicated artists.

## A software renderer today, OpenGL on the list

Cytopia has a custom isometric rendering engine, and the word custom is doing the work, because the engine is not wrapping anything.

The README describes it as an SDL2 based rendering engine written in C++, and OpenGL Renderer is on the planned features list. So what runs today is a software rasteriser built on SDL2, and the GPU path is future work.

That is a legitimate choice for this genre and worth understanding rather than judging. A pixel-art isometric city builder renders small sprites on a flat grid, and the pixel count is low: a 1920 by 1080 window of 32 by 32 pixel tiles is about two million pixels, and a naive blit loop handles that at hundreds of frames per second on a CPU that is also running the simulation. The reason a software renderer is defensible here is that the visual style is the constraint, not the performance budget. Chunky pixels and an isometric grid are exactly what you would want to draw without texture filtering and without a shader pipeline.

The consequence for a player is that it will run on old hardware and in environments where a GL context is a problem, which for a game people want to run on whatever machine they have is a feature. The consequence for a developer is that the interesting code is the rasteriser, and if you want to see how isometric sprite sorting, depth ordering and terrain layering are done in C++ without a GPU in the way, this is a small readable codebase.

The other current features are consistent with an engine-first project. Camera panning, zooming and relocating is the full set of camera operations, which means the player can move around a large procedural world, and that is only interesting if there is a world worth moving around. Terrain manipulation plus procedural terrain generation together mean both authoring and generation, and libnoise is in the prerequisites, which is the noise library that would generate the terrain. The city builder's spatial problem is therefore solved in both directions before the simulation exists.

The custom UI system is the third engine piece, and imgui is in the prerequisites, which is Dear ImGui, an immediate-mode GUI library. So the architecture is probably: a custom isometric renderer for the world, a custom UI for the game interface, and Dear ImGui for developer and editor tooling. The custom UI claim is worth flagging as a real cost, because a user interface is a large amount of work to write from scratch and a common source of bugs in games, but it is also what lets the interface look like a retro game rather than like a debug tool.

The audio stack is conventional and worth reading as a dependency map. OpenAL is the 3D positional audio API, libvorbis and libogg are the Vorbis codec and its container, SDL2_image handles image loading, SDL2_ttf handles fonts, zlib is compression, libpng is PNG decoding, and libnoise is terrain generation. Eleven libraries, each mapped to a subsystem, which is what a mature C++ game's dependency list looks like when it has settled.

## Conan and external/ in the same repository, and twelve prerequisites

The build story is a C++ build story with two dependency strategies and a list of prerequisites maintained by hand, and the details are worth laying out.

The prerequisites are CMake, Conan, SDL2, SDL2_ttf, SDL2_image, OpenAL, zlib, libnoise, libogg, libvorbis, libpng and imgui. Twelve items, each linked to its home page in the README. The supported platforms are Linux with clang or g++-5 or higher, Windows, and Mac.

The g++-5 floor is a data point about age. That is a 2016 compiler, which is consistent with a project that started around then and with a codebase that has not needed newer language features.

The dependency management is where the two strategies appear. There is a conanfile.py at the repository root, which is Conan's Python-based package manager recipe, and there is an external/ directory. Those are two different ways to get the same libraries onto the include path: Conan resolves and fetches them into a package cache, while external/ is a directory where they can be vendored in place. Projects end up with both when they started on one and later adopted the other without removing the first.

There is also a get_dependencies.sh script at the root, which is a third path again, presumably for platforms or people who would rather not use Conan at all. So the repository supports three ways of obtaining the same eleven native libraries, and the README does not say which is preferred or which is current.

That is the friction a new contributor meets, and the project's answer is a wiki page. The build instructions are not in the README; they are at a link to the project's Build instructions wiki page, and the coding guidelines are on another wiki page.

Documentation on a wiki has a specific property worth naming for an evaluator. It is outside the repository, so it is not version-controlled alongside the code, it does not go through pull request review, and anyone with wiki access can change it. That is convenient for a project with contributors of varying commitment and a problem for a project where the build has to be reproducible. It also means the build instructions and the code can drift without either noticing.

The rest of the build infrastructure is conventional and competently arranged. There is a CMakeLists.txt at the root with a cmake/ directory for modules, an ios.toolchain.cmake, a Doxyfile for the Doxygen documentation, a .clang-format for formatting, and a .github directory. The Doxygen output is published at cytopia-docs.netlify.app, so the API documentation is generated from the source and hosted on Netlify, which is the standard arrangement and means the docs are as current as the last build rather than as current as the last manual edit.

Two more files are worth reading for what they say about maintenance. There is renovate.json, which configures automated dependency updates, and sonar-project.properties, which configures SonarQube. For a project with eleven native C++ dependencies and no release in six years, having Renovate configured is the single most useful thing in the repository, because it is the mechanism that keeps a dependency list from rotting while the humans are working on something else.

## An iOS toolchain file for a platform that is not supported

There is a file at the repository root called ios.toolchain.cmake, and iOS is on the planned features list rather than the supported platforms list.

That is a small and very concrete gap between the file tree and the stated support, and it is worth describing because it says something about how the project works.

An ios.toolchain.cmake file is a CMake toolchain definition. It tells CMake how to invoke the compiler for a target that is not the host, in this case Apple's compiler set, with the right SDK, the right architecture flags and the right deployment target. Writing one is a non-trivial piece of work involving Xcode paths and SDK selection, and it is the kind of groundwork that gets done early in a cross-platform project precisely because it is annoying and blocks everything else.

So someone wrote it, and iOS support is still planned. There are a few readings and the README does not say which applies. Perhaps the toolchain was set up and the port stalled on something else, such as the touch input handling, the UI scaling, or the fact that an isometric renderer designed for a mouse and a keyboard needs a different interaction model. Perhaps it is used by a fork. Perhaps it is aspirational groundwork that nobody has got to.

What is not in question is the file's presence, and it is a good example of why the repository listing is worth reading alongside the README. The README says three platforms are supported and two are planned, and the tree says someone has already started on one of the planned ones.

The same pattern appears with the Android and iOS entries in a different form. Both are on the planned list, and both are the platforms where a city builder is most commercially plausible, because a city builder is a session game and the phone is a session device. Neither is in the prerequisites, the supported platform list, or anything else in the README.

There is one more file at the root that the README does not mention and that belongs in this group. index.html, at the top level of a C++ game repository, is almost certainly the GitHub Pages landing page, pointing at cytopia.net and the other links. It is a small thing, and it is the sort of file that accumulates in a project that has been running for a decade without anyone deciding it belongs in docs/ instead.

## A freenode channel and an LGTM config, both dead

Two references in this repository point at services that no longer exist, and both are in files that are still being maintained, which makes them a useful signal about what kind of attention the project gets.

The first is in the README. After pointing at the Discord server, it says: if Discord is not for you, visit our IRC channel on freenode at #Cytopia.

freenode was a large IRC network that carried a significant share of open-source development chat for two decades. It declined steadily through the 2020s as projects moved to Discord and Matrix, and the main freenode network was shut down in 2025. So the README's fallback for people who do not use Discord is a channel on a network that is gone.

That is a five-second fix, and the fact that it survived tells you the README is edited rather than maintained. It is also the kind of stale link that does real damage: someone reading the README, deciding not to join a Discord server, and following the IRC line wastes a few minutes finding a network that no longer resolves. It is worth flagging here because it is a concrete, dated, checkable defect, and because a reader evaluating the project's care should notice which files get attention.

The second is .lgtm.yml at the repository root. LGTM was a code quality service built around pull request annotations and automated JavaScript and C++ analysis, acquired by GitHub in 2019 and shut down in December 2021. The .lgtm.yml file is its configuration format, and it is still in the repository, next to a sonar-project.properties file that configures a service which does still exist.

So the project has SonarQube configured and LGTM configured, one of which works. Neither is mentioned in the README, so a contributor arriving through the wiki has no way to know which analysis runs on their pull requests.

The contrast with renovate.json is the interesting part. Renovate is current, actively used, and the most operationally valuable file in the root. LGTM is a dead service's config that nobody removed. The pattern is that the build and dependency automation is maintained and the peripheral integrations are not, which is a normal and forgivable shape for a volunteer project. It is also the reason a reader should treat the README's links with the specific attention that a five-year-old document deserves.

The other peripheral file worth mentioning is ReleaseNotes.txt, a plain text changelog at the root. For a project whose newest release is from April 2020, a text changelog that someone has been maintaining alongside six years of unreleased commits would be a genuinely useful artefact, and its presence alongside ReleaseNotes.txt is one of the first things to check when picking this up.

## Doxygen on Netlify, a wiki for build instructions, Discord for everything else

An assessment of this project's community and documentation infrastructure comes down to a list of surfaces, and reading it tells you what kind of project this is.

There is a Discord server, linked twice from the README, with the server ID in a badge and a second invite link in the header block. There is an itch.io page, which is where an indie game gets distributed and where a player would download a build. There is the project's own website at cytopia.net. There is the Doxygen documentation at cytopia-docs.netlify.app, generated from the Doxyfile in the repository and hosted on Netlify. There is a GitHub wiki with the build instructions and the coding guidelines. There is the GitHub repository itself, with issues. And there is the freenode IRC line, which no longer works.

Seven surfaces, six of them live. That is a well-organised project for its size, and the distribution of effort is informative. The technical surfaces are automated: Doxygen generates the API docs from the source, Renovate manages dependencies, SonarQube analyses the code, CMake builds it. The human surfaces are where a volunteer project actually needs people: Discord for conversation, the wiki for the knowledge that does not belong in the repository, and the issue tracker for bugs.

The wiki is the one that deserves a second look. Putting the coding guidelines on a wiki rather than in a CONTRIBUTING file in the repository means the guidelines are editable by anyone with wiki access, are not reviewed as pull requests, and are not versioned with the code they describe. For a project with a large modding and asset community that is a reasonable trade. For a project that wants contributors to write idiomatic C++ it is a weak one, and a reviewer has no way to know whether the guidelines they are following are current.

The Discord ID in the badge is 448344322887254018, which is a very old snowflake. Discord snowflake IDs encode their creation timestamp in the top bits, so a number in that range dates the server to the first years of the service. That is consistent with a project that has had a persistent community channel for most of a decade, which is a genuinely good sign about the thing that actually keeps open-source projects alive.

What is missing from that list is a roadmap beyond the planned features. The README has a Current Key Features list and a Planned features list, and nothing that says which planned item is next or roughly when. For a project whose last release was six years ago, that absence is the one that most affects an evaluator's ability to judge whether it is worth investing time in.

There is a credits.txt at the root, which is where a game keeps its attribution, and the README already names the graphics lead and the audio contributor. For a project built on SDL2, libnoise, Dear ImGui and Qt, with art and music by two named people, the credit file is likely a longer list of everyone who contributed a building, a tile or a sound.

## Conclusion

Use Cytopia if you want to build a custom isometric renderer and procedural terrain engine in C++ and read the code, or if you want to author tile content through JSON and a Qt editor and are content to run a six-year-old build. Do not adopt it as a game to play, because the planned features list includes gameplay mechanics, so what exists today is a terrain editor with a renderer rather than a city builder with a campaign. Do not expect mods to install themselves, because in-game mod downloading and a mod scripting language are both planned rather than shipped, which means a mod is a directory of assets you place by hand. Verify four things. Build from the master branch rather than a release, since the last tag is v0.2.1 from April 2020 and six years of work are not in it. Read the build instructions on the project wiki before you start, because the repository does not contain them and it depends on Conan plus twelve native libraries. Check that your platform is Linux, Windows or Mac, since Android and iOS are listed as planned even though an iOS CMake toolchain file is already in the tree. And ignore the README's IRC line and the .lgtm.yml file, both of which reference services that no longer run. The deciding fact is that this is an active codebase with an inactive release train, so the interesting thing about it is the engine rather than the game, and the mod focus is a stated direction rather than a current capability.

## FAQ

### What is Cytopia and what does it do?

It is a free, open source retro pixel-art city building game with a big focus on mods, built around a custom isometric rendering engine written in C++ on SDL2. The current features are a custom UI system, camera panning, zooming and relocating, terrain manipulation, procedural terrain generation, pixel-art graphics, an original soundtrack, and a Qt based tile editor for editing TileData JSON files.

### When was the last Cytopia release?

v0.2.1, codenamed Jimproved, on 2020-04-14, following v0.2 The Map Update on 2020-02-20 and v0.1.1 tech preview on 2019-03-16. The last push to the repository was on 2026-09-04, so the default branch carries roughly six years of work that is not in any release.

### Does Cytopia support mods yet?

Not in the way the description suggests. In-game mod downloading and a scripting language for mods such as LUA are both on the planned features list, so today a mod is a directory of assets or JSON tile data that you place yourself. The Qt based tile editor for TileData JSON files is the shipped modding tool, and Qt is not in the game's prerequisites because the editor is a separate build target.

### What are Cytopia's build dependencies?

CMake, Conan, SDL2, SDL2_ttf, SDL2_image, OpenAL, zlib, libnoise, libogg, libvorbis, libpng and imgui. Supported platforms are Linux with clang or g++-5 or higher, Windows and Mac, with Android and iOS listed as planned. The repository carries both a conanfile.py and an external/ directory as well as get_dependencies.sh, so there are three ways to obtain the native libraries.

### Does Cytopia use OpenGL?

Not yet. The current engine is a custom isometric renderer written in C++ on SDL2, which is a software rasteriser, and an OpenGL renderer is on the planned features list. For a pixel-art isometric grid at low pixel counts that is a reasonable choice, and it means the game runs without needing a GL context.

### What licence is Cytopia under and where is the documentation?

GPL-3.0, with license.txt and credits.txt at the repository root. API documentation is generated by Doxygen from the Doxyfile and published at cytopia-docs.netlify.app, while the build instructions and coding guidelines live on the project's GitHub wiki rather than in the repository, so they are not version-controlled alongside the code.

## Sources

- [CytopiaTeam/Cytopia on GitHub](https://github.com/CytopiaTeam/Cytopia)
- [License: GPL-3.0](https://github.com/CytopiaTeam/Cytopia/blob/master/LICENSE)
- [Project website](https://www.cytopia.net)
- [README](https://github.com/CytopiaTeam/Cytopia/blob/master/README.md)
- [Releases](https://github.com/CytopiaTeam/Cytopia/releases)

---

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