Zero-K: a Spring RTS where the repository holds only the game module

This repository is the game module and nothing else

The most useful sentence in the README is the one that says what the repository is not. This repository contains only the game module files, without any associated infrastructure code, tools, or artwork sources, and those are in other repositories.

That is a distinction that matters more than it first appears. A Spring total conversion is not a self-contained program. The engine, the lobby client, the tooling and the source assets live elsewhere, and what sits in this tree is the content that the engine loads: the rules, the unit definitions, the interface and the assets. Anyone who clones this and expects a build to produce a game will not find one, and anyone who wants to run the game does it through the lobby, which the README points to as the download route.

The game itself is described as an RTS game with physical projectiles and smart units, running on the Spring Engine, with a focus on the interface. The project topics list cross-platform, modding and open source alongside the sci-fi and real-time-strategy labels, and the homepage is zero-k.info, where the README also points for the development guide.

So the correct way to read this repository is as a large, mature piece of game content written in Lua, maintained as a live project, and shipped to players through an engine's ecosystem rather than as a package.

A Spring mod is Lua in a handful of directories

The top-level listing shows the shape of a Spring game module, and the Lua directories are the most legible part of it.

There is a directory named LuaAI, with a LuaAI.lua file beside it, a directory named LuaRules, one named LuaUI with a luaui.lua file, one named LuaGaia, and one named LuaIntro. Each name is a label rather than a description, and the README does not document what any of them contain, so the only honest statement is that the game's logic is split across five Lua areas plus the engine-level files that sit beside them.

Those engine-level files are the interesting ones because they are the ones with names that describe their role. EngineOptions.lua and ModOptions.lua are the option declarations for the engine and the mod, modinfo.lua is the manifest that names the mod and its version, and ValidMaps.lua is a list rather than a rule. There is also a features/ directory, a modules/ directory, a gamedata/ directory, and a scripts/ directory, none of which the README explains.

Two conventions are visible without any documentation. A .luacheckrc file at the root means the Lua is linted, and an .editorconfig means whitespace is handled by tool rather than by habit. There is also an ai_policy.md file, which is unusual to find in a game repository and suggests the project documents how its AI is expected to behave as well as how it is written.

Content directories, and a unit system of its own

Most of the tree is data rather than logic, and the split is informative about how the game is built.

The gameplay content lives in units/ and weapons/, with gamedata/ sitting alongside them, which is the conventional division of a real-time strategy: units are the things you command, weapons are what they fire, and the data directory holds the numbers that connect them. The physical projectiles the README mentions as a feature of the game belong in that same layer.

The graphics side is spread across more directories than most projects use. There is a shaders/ directory, two separate directories for model surfaces, one of them carrying a GL4 suffix, an Objects3d/ directory for models, bitmaps/ and icons/ for images, unitpics/ plus a unitpics_9_11/ directory for unit portraits, sidepics/ for the small side panel images, effects/ for visual effects, sounds/ for audio and Anims/ for animation data. The presence of a second model surface directory with a GL4 suffix suggests the project keeps different surface sets for different graphics backends.

The most interesting entry is lups/. A .lup file is the Lua unit system, a Spring mechanism where a unit is defined by a script rather than by configuration, and a dedicated directory of them in the repository is a sign that the game leans on that mechanism rather than treating it as an edge case.

Also worth noting are modularCommAPI/, which is a communication API for the lobby, and the .tx/ directory, which is the configuration layout used by translation tools. The game ships in more than one language, and the translation files are managed as a separate layer from the Lua code.

The lobby is how players get the game

The README is very short on usage, and the reason is that the distribution channel is the engine's own. To play the game, you need to download the lobby, and the README links the lobby download alongside a link to the engine and a link for learning how to import content directly into the engine, which points at the Spring wiki page on project structure.

Those two routes are the whole story for a player. The first is the ordinary path: install the lobby client, and the game arrives through it. The second is the path for someone working on the content itself, where importing the files into the engine directory is the way to see a change without going through the lobby's distribution.

For a project with a dedicated directory for lobby communication, that split is the expected shape. The modularCommAPI/ directory is where the game talks to the lobby, and the fact that it has its own directory rather than being scattered through the Lua code suggests the protocol is treated as a boundary.

The artwork point from the first section comes back here. Since the artwork sources are in other repositories and only the artwork itself is here, the boundary between a content repository and an infrastructure repository is also the boundary between a copyleft work and a set of assets that may carry their own terms. The README's own development guide at zero-k.info, linked under Zero-K:Developing, is where that is meant to be worked out.

Five licence files in one tree, and only one of them is the project's own

The licence story is the most complicated part of this repository, and the file list makes it plain. The project is listed as GPL-2.0, and the root holds GPL.txt, LGPL.txt, MIT.txt, freeartlicense1.3.txt, al2.0.txt, legal.txt and the LICENSE file itself, plus EoWcredits.txt.

Several things follow from that inventory. The game code being GPL-2.0 is consistent with a project that is free software and takes contributions, and the README's own link structure points at a LICENSE file for the badge. But the presence of LGPL.txt, MIT.txt, a Creative Commons licence file and an Apache 2.0 text alongside it means the tree carries third-party and separately licensed files, which is normal for a game with bundled assets and libraries, and it means a single licence label does not describe the whole tree.

That is why legal.txt and EoWcredits.txt are in the listing at all. A credits file is what you use to attribute bundled work, and a legal file is where the mixture is explained. The README does not summarise any of it, so a distributor has to read those files rather than rely on the badge.

The other side of the same coin is the statement that artwork sources are not in this repository. If the sources are elsewhere and the exported assets are here, then anyone who wants to modify the art or redistribute it is working across two repositories with two sets of terms, and the tree's licence files are the place where that arrangement is recorded.

No releases, daily commits, and a project that runs on its engine

The project has no GitHub releases. The version of a Zero-K build is whatever the lobby serves, and the repository has no tags to point at, which is consistent with a game distributed through a client rather than downloaded as an archive.

What the repository does show is activity. The last push was on 2026-10-19, the repository is not archived, and the default branch is master. The topics list includes modding, which is the point of the whole structure: a project like this is a mod first and an application second, and the ecosystem around it is where other people's code plugs in.

The development guide on the wiki is the piece to read next, along with the .luacheckrc configuration, because a Lua codebase of this size depends on agreed conventions that the README itself does not state. The ai_policy.md file is worth a look on the same grounds, since a game with smart units usually has opinions about what its AI is allowed to do.

For an engineer deciding whether to spend time here, the case is narrow but clear. If you want to read how a large Lua game is organised under an engine's conventions, or you want to contribute to one, the tree is legible and the conventions are documented elsewhere. If you want to run Zero-K, the lobby is the route and this repository is not part of it.

Editorial conclusion

Use this repository if you want to read or modify a Spring total conversion at the scale of a real game, because the Lua layout with separate AI, rules, UI and introduction directories is exactly what the engine expects from a mod, and the asset directories show how a large amount of content is kept separate from code. Do not treat it as a self-contained buildable project, since the README states there is no infrastructure code, no tools and no artwork sources here, and the game is distributed through the Spring lobby rather than by cloning and building. Before you fork or redistribute anything, read the five licence files in the tree, because the code, the artwork and the bundled third-party assets are not all under the same terms, and check the development guide linked from the README for how changes are expected to be structured.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. Project website
4. README
5. ZeroK-RTS/Zero-K on GitHub