Facepunch/sbox-public: building the s&box engine from source

What sbox-public is for, and who should not clone it

The README is direct about the split. If your goal is to create games using s&box, it points you at the getting started guide on sbox.game. The repository exists for people building the engine from source, and it says so in the first paragraph: this is for those who want to contribute to the development of the engine. That single sentence should decide most readers.

What the checkout contains is the C# engine, the editor, the tooling and the game content. The native Source 2 core is not in the tree. It arrives as prebuilt binaries that the setup script downloads for your platform, which is why no C++ toolchain appears in the prerequisites. The only hard requirements listed are Git, the .NET 10 SDK, and an IDE for the C# code, with Visual Studio 2026 or Rider suggested on Windows and Rider or VS Code on Linux and macOS.

So the audience is narrow by design: engine contributors, people writing editor extensions against the C# layer, and anyone who needs a local build to reproduce a bug. Game authors who simply want to ship something are being routed to Steam, and the README repeats that routing in the Getting the engine section.

How the split between C# and Source 2 actually works

The architecture visible here is a managed layer over a native core. The repository holds engine/, game/ and the setup scripts; the Source 2 binaries land in game/bin. Setup fetches those binaries, and the Git hook that runs on pull regenerates the interop bindings that let the C# code call into them. That regeneration is the mechanism worth understanding, because it means the boundary between the two halves is machine-produced rather than hand-written.

The same mechanism drives upgrades. The README states that pulling on Git runs a hook which fetches any new native binaries or content that changed and regenerates the interop bindings. Build the C# code from your IDE as usual, or rerun Setup.bat for a full incremental rebuild including shaders and content. That is a reasonable arrangement for a project whose native half is closed to outside contributors: you cannot rebuild Source 2, so you consume it, and the hook keeps the bindings in step with whatever binary version you just pulled.

The cost is that the C# side is not self-contained. A build is only meaningful against a matching set of native binaries, and the repository gives you no way to produce those yourself. The README does not describe a pinned manifest or a way to select an older binary set, so the practical state of a checkout is whatever the hook last fetched.

Installing the s&box engine from source on Windows, Linux and macOS

The README gives the same two commands for every platform, then a platform-specific setup step. Clone first, then run the setup script for your system. On Windows 10 or 11 x64 that is Setup.bat; on Linux x64 and on Apple Silicon macOS it is ./Setup.sh. Intel Macs are not supported, and the README says so plainly.

# Clone the repo
git clone https://github.com/Facepunch/sbox-public.git
cd sbox-public

# Windows
Setup.bat

# Linux / macOS
./Setup.sh

Setup downloads the native Source 2 binaries for your platform. On Linux the binaries target the Steam Linux Runtime, and the README notes that most distros should work without promising more than that.

Once setup completes, the game and the editor run from the game folder: the README names sbox for the game and sbox-dev.exe for the editor. There is no separate launch command documented beyond that location, so expect to run the editor from inside game/ rather than from a global install.

For day to day work the loop is short. Edit C# in your IDE and build from there. When you want a full incremental rebuild that includes shaders and content, rerun Setup.bat. Pulling on Git handles the binary and binding refresh on its own through the hook.

The licence boundary inside game/bin

The engine source is MIT licensed, and the README says so before it says anything else about licensing. The next paragraph qualifies it. Certain native binaries in game/bin are not covered by the MIT license; they are distributed under the s&box EULA, and you must agree to its terms to use them. A third category exists as well: third-party components that keep their original licences and are listed in game/thirdpartylegalnotices.

That gives a checkout three licence zones rather than one, and the repository metadata reflects the ambiguity by reporting NOASSERTION rather than MIT. For someone reading the C# source this changes nothing. For anyone redistributing a build, bundling the editor, or shipping a product that includes game/bin, the EULA is the governing document for the part that makes the build run. The README does not summarise the EULA's terms, so the only honest step is to read it. This is a description of what the files say, not legal advice.

Where this repository is the wrong tool

Building from source buys you nothing if you are not changing the code. The setup path is longer than a Steam install, it adds a .NET 10 SDK requirement and an IDE to your machine, and it commits you to keeping a large checkout in sync through a Git hook. The README's own routing makes the point: game creators are sent to the getting started guide, not to Setup.bat.

Platform coverage is another boundary. Intel Macs are excluded outright. Linux support is described as targeting the Steam Linux Runtime with a hedge that most distros should work, which is not the same as a tested matrix. If your machine is unusual, the source route is the one most likely to fail, and the failure will happen in a script you did not write.

There is also a maintenance asymmetry. You can read and modify the entire C# engine, the editor and the tooling, but the Source 2 core underneath is a downloaded artefact. If a bug lives in the native half, a local build does not help you fix it. The README points bug reports and feature requests at the issue tracker rather than describing any path for outside patches to the native code.

sbox-public against Godot and other source-first engines

The obvious comparison is an engine where the whole stack is open source and buildable, such as Godot. There, cloning the repository and compiling gives you the complete engine, editor included, with no downloaded binary core and no separate end-user licence layered on top of the source licence. The build is heavier and needs a C++ toolchain, but nothing in the resulting binary falls outside the repository's own licence.

s&box inverts that trade. The C# half is open and the native half is not, which keeps the build light and removes the C++ toolchain from the prerequisites entirely. What you give up is the ability to rebuild or audit the part that does the rendering and simulation. For an engine contributor working on editor features, C# APIs or game content, that is a reasonable deal. For someone who wants to be able to rebuild every line of the engine they ship, it is a disqualifying one, and no amount of C# access compensates.

The same distinction separates this repository from using s&box as a product. Steam gives you the editor as a finished application. The source route gives you a development checkout with a hook that rewrites its own bindings. Those are different tools that happen to share a name.

Keeping a checkout current, and what that costs

The upgrade story is deliberately automatic. Pulling on Git triggers a hook that fetches changed native binaries and content and regenerates the interop bindings, so staying current is mostly a side effect of pulling. The manual fallback is rerunning Setup.bat for a full incremental rebuild that includes shaders and content.

The cost is that you do not choose when the native core moves. A pull can change the binaries under you, and the README does not document a way to pin or roll back to a previous set. If you are bisecting a regression, that is a real constraint: the C# history is yours to inspect, the binary history is not. The README is also silent on how large the downloaded binaries and content are, so disk and bandwidth planning has to come from your own first setup run.

On the repository's own state, the last push was on 2026-11-02 and the project is not archived. Nothing in the README describes a release cadence, and the repository has no published releases, so the Git history is the only signal available about how often the C# side moves.

Editorial conclusion

Adopt this repository only if you intend to modify the engine, the editor or the C# tooling, and you accept that the native Source 2 binaries in game/bin sit outside the MIT licence and under the s&box EULA. If you want to make a game with s&box, install the editor from Steam and start with the getting started guide instead. Before you clone, confirm you are on Windows 10 or 11 x64, Linux x64 or Apple Silicon, that .NET 10 SDK is installed, and that you have read game/thirdpartylegalnotices before redistributing anything from the checkout.

Frequently asked questions

Official sources

1. Facepunch/sbox-public on GitHub
2. Issues
3. Project website
4. README