Space Station 14 splits its engine into a separate repository on purpose

Two repositories that could have been one, folded into one

The first paragraph says the game is a remake of an earlier title running on a homegrown engine written in C#. The second paragraph gives the reason this repository is shaped the way it is. It is the primary repository, and to prevent people forking the engine on its own, a content pack is loaded by both the client and the server, and that content pack contains everything needed to play the game on one specific server. So the engine has no standalone interface: you cannot build against it, because the thing you would build against is only meaningful with content attached. That is an unusual governance choice and it explains the rest of the layout.

Who this repository is for

The readme answers two audiences in adjacent sentences. If you want to host a server or create content, this is the repository you need, and it contains both the engine and the content pack used while developing new packs. That second clause is the important one for contributors: the repository carries the example pack that every new pack is developed against, so a change to the engine and a change to the example are reviewed together. A separate documentation site covers the content, the engine, the game design and more, and two of its pages are called out specifically because they deal with licensing and attribution rather than documentation.

Translations are refused, forks are the route

The contributing section is warm in tone and specific in policy. Contributions are accepted from anybody, the chat server is given as the place to ask, and a separate issue repository is listed as work anyone can pick up, with an explicit invitation not to be afraid to ask for help. Then two constraints. Changes must follow the contribution guidelines, which are on the documentation site rather than in the repository. And the project is not currently accepting translations on its main repository, with the alternative given as creating a fork or contributing to one. So localisation is deliberately pushed out of the main tree, which keeps the engine and the reference content pack untranslated at the source.

Generated contributions are refused by example, not by principle

There is a section with a heading that names the subject directly, and its content is a list. The project does not accept low-effort or wholesale machine-generated contributions, and the list is more useful than the principle because it names the artefacts: any code including configuration files produced by an assistant, machine-created artwork, sound files and other assets, and auto-generated documentation, issue reports or pull request descriptions. One exception is stated, single-line completion in an editor. So the line is drawn at effort and reviewability rather than at authorship, which is a defensible way to write such a policy.

Building needs a Python step before any compilation

The build instructions are three numbered steps and the middle one is the one people miss. Clone the repository. Then change into the project directory and run a Python script, whose stated purpose is to initialise the submodules and load the engine. Only then does compilation begin, with the server built by the standard build command for the language, and a link to a more detailed setup page.

python RUN_THIS.py

The script is named after what it does, which is at least an honest piece of naming for a bootstrap step. So a build is not a single command, and the Python step is what pulls in the engine that the first paragraph said lives here anyway.

Code under one licence, assets under another, and a third case

The licence section makes three statements rather than one. All code in the content repository is under a permissive licence. Most assets are under a share-alike attribution licence unless stated otherwise, and each asset carries its licence and copyright in a metadata file, with a specific item linked as the example of where to look. Then a note that some assets are under non-commercial variants of the same family and must be removed if you want to use the project commercially. So the code is permissive, most art is share-alike, and a subset of the art cannot be used commercially at all, which is the detail a pack author has to check.

A solution file, a shell environment, and eight run scripts

The repository root describes the build tooling. A solution file and a shared packages properties file sit at the top, with a global package version file and a package source configuration, which is the shape of a large solution with many projects. There is a directory for the engine, one for shared and server database projects, and a long series of content projects, including one named for benchmarking content, one for integration tests, one for map rendering and one for a linter. Then the parts that make this project unusual: a directory containing an environment definition with a lock file, a shell entry point, an editor configuration for a language server, a subdirectory of run configurations, and eight shell scripts, paired by client and server, by plain and tooling variants.

Editorial conclusion

Space Station 14 suits a contributor who wants to change the game itself rather than add to an existing server, and who is prepared to initialise submodules before anything compiles. It does not suit someone who wants to write a content pack against a public engine interface. Before contributing, read the AI-generated contributions disclaimer, since the project rejects wholesale generated code and assets rather than merely discouraging them, and check the asset licensing note before using anything commercially.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes