# RobustToolbox: the engine underneath Space Station 14 > RobustToolbox is a C# multiplayer game engine written and maintained by the Space Station 14 community, split across shared, client and server projects with a large body of source generators. It does not run on its own, because the content lives in a separate repository, and its licence file is a composite of several terms rather than a single standard one. **space-wizards/RobustToolbox** — Robust multiplayer game engine, used by Space Station 14 - Repository: https://github.com/space-wizards/RobustToolbox - Website: https://spacestation14.com - Stars: 707 · Forks: 770 - Language: C# - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/space-wizards-robusttoolbox ## An engine that refuses to start on its own The single most important sentence about RobustToolbox is in its Building section: this repository is the engine part of Space Station 14, the base engine all SS14 servers are built on, and as such it does not start on its own. It needs the content repository. That split is the design, not an inconvenience. RobustToolbox is the runtime and the systems layer, while the content repo holds the actual game: entities, prototypes, maps, art, and the YAML or similar content definitions that describe a space station and everything on it. The README tells contributors to use the content repo for actual development even when you are modifying the engine itself, which tells you how the project thinks about the boundary between mechanics and content. The comparison the README offers is telling. It says to think of the engine as BYOND in the context of Space Station 13. BYOND was the platform where the entire genre of multiplayer roleplaying games was built, and comparing an engine to it is a way of saying this is infrastructure for a community of game makers rather than a product with a studio behind it. The primary language is C#, the default branch is master, and the homepage points at the Space Station 14 project site. There is a standing ambition to widen that. The README notes the engine is primarily being developed for Space Station 14 while the team is working on making it usable for both singleplayer and multiplayer projects, and it links separate template repositories for those two cases. The word primarily is doing work there, and it is the honest way to read this repository. ## Shared, client and server are three separate projects The top-level tree is where the architecture becomes visible, and it is unusually well partitioned for an engine. `Robust.Shared`/ holds the code both sides need: `Robust.Shared.Maths`/ for the vector and matrix types, `Robust.Shared.Scripting`/ for the scripting layer, `Robust.Shared.CompNetworkGenerator`/ and `Robust.Shared.EntitySystemSubscriptionsGenerator`/ for generated networking and entity plumbing, and a family of test projects alongside them, including `Robust.Shared.IntegrationTests`, `Robust.Shared.Maths.Tests`, `Robust.Shared.Maths.Testing` and `Robust.Shared.Testing.` On top of that sit `Robust.Client`/, `Robust.Server`/ and a matching pair of test projects, `Robust.Client.Tests`, `Robust.Client.IntegrationTests`, `Robust.Server.IntegrationTests` and `Robust.Server.Testing.` The client side is further split, with `Robust.Client.Injectors`/ for dependency injection wiring, `Robust.Client.NameGenerator`/ for character name generation, and `Robust.Client.WebView`/ for embedding a browser surface in the client. The layering is the point. A shared project that is tested on its own, a client project that can be integration tested against it, and a server project that can be tested against the same shared code is a structure that supports automated testing rather than manual play-testing. The number of test projects in this tree, including `Robust.UnitTesting`/, `Robust.Analyzers.Tests`, `Robust.Packaging.Tests` and `Robust.Generators.UnitTesting`, is the clearest signal of the project's engineering priorities. The naming convention throughout is `Robust.*`, and the solution file appears twice in the tree, as RobustToolbox.sln.DotSettings alongside the newer RobustToolbox.slnx format, which suggests the project has moved toward the slnx layout while keeping the DotSettings file for IDE configuration. ## Source generation is treated as a first-class concern Four separate projects in the tree exist purely to generate code. `Robust.Generators`/ and `Robust.Generators.UnitTesting`/ handle general generation, `Robust.Serialization.Generator`/ handles serialization, `Robust.Shared.CompNetworkGenerator`/ handles the networked component layer, and `Robust.Shared.EntitySystemSubscriptionsGenerator`/ handles entity system subscriptions. There is also `Robust.Roslyn.Shared`/ for code shared between the generators, and `Robust.Analyzers`/ with its own test project for static analysis rules. This is a large investment for a community project, and it explains a good deal about how the codebase stays coherent. A multiplayer game engine has to keep the client's and server's views of an entity in agreement, and it has to keep serialized state readable across versions. Both are tasks that source generators handle well, because the code is derived from a single declaration instead of being maintained by hand in several places. The presence of `Robust.Analyzers`/ as a separate project with its own tests also means the style and correctness rules are enforced by the compiler rather than by review comments. For a contributor, that is a faster rejection signal than a human reviewer, and it explains why the tree separates the analyzer from the rest of the build. One caveat for anyone evaluating the build: a code generator stack means the build depends on the Roslyn and MSBuild toolchain, not just on the .NET SDK. The tree carries global.json, which pins the SDK version the project expects, and Directory.Packages.props, which is the central package management file for the whole solution. ## Vendored dependencies reveal what the engine is built on Several third-party libraries are vendored directly into the tree rather than pulled from a package feed. Lidgren.Network/ is there, which is a networking library for UDP based communication and fits a multiplayer server that has to handle many clients. NetSerializer/ is a high performance serialization library, which is the other half of what a game server needs. cefglue/ is a binding layer for the Chromium Embedded Framework, which is how a modern game client embeds web content such as the in-game player-facing browser view. The UI side is anchored by Avalonia.Base/ and `Robust.Xaml`/, with XamlX/ alongside them for XAML compilation, and Resources/ for the assets the engine ships. The relationship between these and the rest is not something the repository documentation explains, and that is a fair criticism: the vendored copies make the build self-contained at the cost of a reader having to work out which parts are upstream code and which are maintained here. Other directories show the same split. BuildFiles/ and MSBuild/ hold the build plumbing, Imports/ holds shared build imports, Tools/ holds developer tooling, Schemas/ holds schema definitions, and docs/ holds documentation, while `Robust.Docfx`/ indicates that documentation is generated with DocFX. Packaging has its own project, `Robust.Packaging`/, with `Robust.Packaging.Tests`/ beside it, which is where the build of distributable client and server artefacts would live. ## Licensing is split across several files, not one The licence situation here is more careful than a single badge suggests. The repository carries three separate licence files at its root: LICENSE-GPLv3.TXT, LICENSE-MIT.TXT and LICENSE-ASSETS.TXT, plus a legal.md file that the README points to for licences and copyright. A LICENSE file also sits at the root, and the machine-readable licence field is a custom one that GitHub cannot classify. Three licence texts in one repository is not redundancy, it is a statement that different parts of the tree carry different terms. The code, the assets and at least one other category are licensed differently, and the GPL text next to the MIT text makes it plausible that the distinction is between the engine code and the game content or assets rather than between all code and all assets. The legal.md file is the document that resolves which is which, and it is the one to read before you ship anything. This is not legal advice, and the point to make is procedural. A licence scanner that reports a single category for the repository is not telling you the terms that will attach to the artefacts you redistribute, and the same caution applies to the vendored libraries, which come with their own terms regardless of what the root licence files say. For a project of this size, having the legal position split into four documents is also a maintenance commitment that a smaller project would not take on. ## Versions move fast and the release notes are in the repository The recent releases are v289.0.3 from 2026-09-14, v284.0.0 from 2026-07-24 and v283.1.1 from 2026-07-24. The numbering is high and the increments are large, and two of these three shipped within a minute of each other on the same day, which is the signature of a project that cuts a release for a set of separate reasons rather than one product build. The version numbers are not a compatibility promise you can read off the tag, so RELEASE-NOTES.md in the repository root is the place to look for what actually changed. Its presence in the tree is useful precisely because a tag alone tells you nothing about whether a change affects the API you call or the content format your server loads. The project is not archived and the last push was on 2026-10-20, so the engine is under active work at a rate that produces a release every few weeks at least. The homepage is the Space Station 14 site, and the project links point to a website, a Discord server, a forum, a Steam page and a standalone download for nightlies, which is the distribution shape of a game that ships continuously rather than in yearly editions. ## How to work with the engine, and who should not The contribution path is open and informal. The README says contributions are accepted from anybody, points to a list of issues that need doing where anyone can pick one up, and suggests getting in touch on Discord or IRC. The wiki is documented as covering Space Station 14 content, engine, game design and more, along with resources for new contributors, and the contributing section tells newcomers not to be afraid to ask for help. For a reader deciding whether this engine fits their project, three conditions stand out. First, the engine is C# and built around .NET with MSBuild, source generators and analyzers, so a team that does not already live in that stack inherits a learning curve in the tooling, not just in the APIs. Second, the engine expects to be paired with a content repository, so a new project starts from a template, and the templates for singleplayer and multiplayer projects are linked from the README. Third, and most decisively, the conventions of the engine are the conventions of Space Station 14. Entity systems, networked components and content schemas are designed for a top-down multiplayer roleplaying game with a large community. A team whose goal is a different kind of game inherits all of that shape. The engine is best understood as the infrastructure of one very large community project, offered to others, rather than as a general purpose engine with a broad user base. ## Conclusion Adopt RobustToolbox if you are building a multiplayer game in C# and want an engine that already handles a live server with many connected clients, and if you are willing to work inside a community project whose conventions are set by Space Station 14. Do not adopt it expecting a self-contained engine, since the repository explicitly does not start on its own and expects a separate content repository, and do not plan a commercial release on the assumption that a single licence covers the whole tree, because legal.md splits the code, the assets and the tooling into separate terms. Before you commit, read legal.md and the three LICENSE files at the repository root, look at RELEASE-NOTES.md to see how the version cadence is communicated, and confirm that global.json and Directory.Packages.props give you a toolchain and package baseline you can live with. ## FAQ ### What is RobustToolbox and what is it used for? It is a C# multiplayer game engine primarily developed for Space Station 14, and the README describes it as the base engine all SS14 servers are built on. The team is working on making it usable for standalone singleplayer and multiplayer projects through separate template repositories. ### Can I run RobustToolbox on its own? No. The README states that the repository is the engine part of Space Station 14 and does not start on its own, because it needs the separate content repository. For actual development, the guidance is to use the content repo even when modifying the engine itself. ### What licence applies to RobustToolbox? The repository carries several licence files at its root, including LICENSE-GPLv3.TXT, LICENSE-MIT.TXT and LICENSE-ASSETS.TXT, and the README directs you to legal.md for licences and copyright. Different parts of the tree are under different terms, so read that file rather than relying on the repository badge. ### How is the RobustToolbox codebase organised? The tree separates `Robust.Shared`/ for code used by both sides, `Robust.Client`/ and `Robust.Server`/ for the two sides, and a large set of test projects including `Robust.Shared.IntegrationTests`, `Robust.Client.IntegrationTests` and `Robust.Server.IntegrationTests.` Several projects exist purely to generate code, such as `Robust.Serialization.Generator` and `Robust.Shared.CompNetworkGenerator.` ### How do I contribute to RobustToolbox? The README says contributions are welcome from anybody, points to the repository issue list where anyone can pick up work, and suggests asking for help on Discord or IRC. Documentation for the engine, content and game design lives in the project wiki, and the legal side is covered in legal.md. ## Sources - [Issues](https://github.com/space-wizards/RobustToolbox/issues) - [Project website](https://spacestation14.com) - [README](https://github.com/space-wizards/RobustToolbox/blob/master/README.md) - [Releases](https://github.com/space-wizards/RobustToolbox/releases) - [space-wizards/RobustToolbox on GitHub](https://github.com/space-wizards/RobustToolbox) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/space-wizards-robusttoolbox