# unitystation is an open source Unity game kept alive by its contributors

> unitystation is a C# and Unity project for a Space Station 13 derivative, licensed AGPL v3 for code written since March 2017 with assets under CC BY-SA 3.0. Its release tags stopped in 2017 while the develop branch kept moving, so what you actually adopt is a snapshot of a community branch rather than a published version.

**unitystation/unitystation** — The original unitystation

- Repository: https://github.com/unitystation/unitystation
- Website: https://unitystation.org
- Stars: 734 · Forks: 619
- Language: C#
- License: AGPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/unitystation-unitystation

## A game project whose badges admit the state of the code

unitystation is described in the repository description as the original unitystation, and the README says the project has been active since late 2016. It is a Space Station 13 derivative, indicated by the ss13 topic tag, and the primary language is C#. Two badge images at the top of the README set the tone more honestly than most open source projects dare to. One reads CONTAINS TECHNICAL DEBT and the other reads BUILT WITH RESENTMENT. That is not decoration, it is the operating assumption of the project: it is community maintained, it accumulates debt on purpose, and contributors are expected to deal with both. The project also has a public presence beyond the repository, with a homepage at unitystation.org, a Steam listing, a Discord server, a Patreon page, a blog and a changelog page. The audience is therefore contributors and players who want to shape the game rather than consume a finished product, and the technical setup assumes you will install a full Unity editor and build from source.

## Two licence eras split at a commit from 2017

The licence structure is the single most consequential fact in the repository. The README states that all code after commit 44695c862d6d84cfc99354d6dfba1f0b70f20407, dated 2017/03/12 at 11:39 PM CET, is licensed under GNU AGPL v3. All code before that commit is under GNU GPL v3. The README also asks anyone who committed code before that date to get in touch if they want their contributions moved under AGPL v3 instead. That split is unusual and has a direct consequence: a fork does not carry a single clean grant, and code written by different contributors may sit under different terms. The AGPL part is the demanding half. It reaches past distribution of the binary to modifications offered over a network, so a hosted multiplayer instance built from this code is a case your own legal review has to think about. Assets are handled separately, with icons and sound under Creative Commons 3.0 BY-SA unless otherwise indicated, and the README notes that tools are included in the same terms unless their own readme says otherwise. Read the LICENSE file in the develop branch before reusing anything.

## What the repository layout reveals about the build

The top level directory listing shows how the project is organised, and it is more informative than the README on this point. UnityProject/ holds the Unity side of the codebase, with the C# scripts and the scene and asset data that the editor consumes. AddressableContent/ suggests content is loaded through Unity's addressables system rather than being pulled in wholesale, which is what a large project with streamed assets normally does. AssetLibrary/ is a separate location for shared assets, and Tools/ and Analyzers/ point to editor tooling and static analysis that run alongside the game code, with CodeScanList.json at the root serving as a configuration file for those checks. A Docker/ directory means part of the workflow is containerised, and mkdocs.yml with a docs/ directory shows the documentation is built as a site, which is where the contribution guides that the README links to are published. There is also a .github/ directory with a test workflow, and the README carries a tests badge. No source file layout beyond this is documented in the README, so the split between gameplay code, server code and tooling cannot be confirmed from what is written here.

## Getting the project open in Unity 6000.2.10f1

Contribution starts with the editor, not with the code. The README's Quick Start guide gives six steps, and the middle of them pin the exact editor build you need.

```bash
1. [Get Unity Hub](https://unity3d.com/get-unity/download)
3. Fork the repo
4. Add your changes
5. Read the contribution guidelines
6. Submit a pull request
```

The step between the first and the third is to install editor version 6000.2.10f1, which the guide links to the Unity editor archive. The editor version is exact, so a contributor on a different Unity release will not get a matching project. Two warnings in the README matter for planning your first afternoon. The project is highly recommended to run on an SSD in the editor, and the first time import can take up to an hour or 15 minutes depending on your machine, while subsequent launches should take at most a minute. So the practical first session is long and mostly unattended: install the editor, fork the repository, open it once, let the import finish, and only then look at the contribution guidelines before you change anything. The publish model is a fork plus a pull request rather than a direct commit, which means you need write access to your own fork and a workflow that matches how the project reviews changes.

## No release tag since 2017 while the branch kept moving

Here is the release record: 0.1.3, tagged as an archive release, on 2017-07-16; 0.1.21, a Boxstation Deathmatch demo, on 2017-05-15; and 0.0.41, marked as depreciated, a DeathMatch demo, on 2017-05-03. Every published tag predates 2018. The repository itself is not archived, and the last push was on 2026-10-17 on the develop branch, which is the default branch. Put those two facts together and you get the shape of this project: the code is alive, the published artefacts are not. Anyone evaluating unitystation as a dependency, a base for a fork or a reference implementation should be looking at the develop branch rather than at a release, and should treat it as a moving target that you pin to a specific commit. The versioning also tells you that the demo concept has moved on, since the two most recent tags are named after DeathMatch and Boxstation demos, which suggests the current branch carries something different from what those artefacts contain. The README points to the changelog page on the project website for what changed, which is the more useful artefact than the tag list.

## Where this project fits against writing your own Unity game

The choice is between adopting a community codebase and starting from an empty Unity project. Starting fresh gives you a clean project, no inherited technical debt and no licence history to reason about, but it means writing the gameplay code, the asset pipeline and the tooling yourself. Unitystation gives you an existing C# and Unity codebase, an addressable content setup, an asset library, editor tooling with analysis configured through CodeScanList.json, container support in the Docker/ directory and a published documentation site, and it gives all of that to you along with the AGPL obligation and the debt that comes with it. A third path is to work on the upstream project rather than a personal fork, which the contribution flow explicitly supports since pull requests go to the project. The practical difference is where your changes live. A fork under AGPL v3 is something you must keep publishing source for if you run it as a service, whereas contributing upstream keeps your code inside a project that already handles that. For a team that wants to build a derivative and operate it, the licence question is the deciding factor, not the tooling.

## Conclusion

unitystation suits a contributor who wants to work on a community owned Space Station 13 derivative in Unity and is prepared for a heavy editor workflow and a licence that obliges you to publish source for networked deployments. It is the wrong choice if you need a packaged, versioned release with a stable binary, because the newest tag on record is 0.1.3 from 2017-07-16 while the develop branch has been pushed as recently as 2026-10-17. Before you commit, open the develop branch in Unity 6000.2.10f1 on an SSD and let the first import finish, since the README warns that it can take up to an hour, and confirm in the LICENSE file which of the two licence eras applies to the code you plan to reuse.

## FAQ

### Which Unity editor version does unitystation require?

The contribution guide says to install editor version 6000.2.10f1 through Unity Hub, and the README recommends running the project on an SSD. The first time import can take up to an hour, while later launches should take at most a minute.

### What licence applies to unitystation code and assets?

Code committed after 44695c862d6d84cfc99354d6dfba1f0b70f20407 on 2017/03/12 is under GNU AGPL v3, and earlier code is under GNU GPL v3, with contributors asked to get in touch to move older contributions under AGPL. Assets including icons and sound are under Creative Commons 3.0 BY-SA unless indicated otherwise.

### How do I contribute changes to unitystation?

Install Unity Hub and the 6000.2.10f1 editor, fork the repository, add your changes, read the contribution guidelines and submit a pull request. The README also points to a Discord server for the community and a Quick Start guide hosted with the project documentation.

## Sources

- [License: AGPL-3.0](https://github.com/unitystation/unitystation/blob/develop/LICENSE)
- [Project website](https://unitystation.org)
- [README](https://github.com/unitystation/unitystation/blob/develop/README.md)
- [Releases](https://github.com/unitystation/unitystation/releases)
- [unitystation/unitystation on GitHub](https://github.com/unitystation/unitystation)

---

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