# ECS Network Racing: a Unity multiplayer racing sample on Entities and Netcode

> This sample puts Unity Entities, Netcode for Entities, Unity Physics, Jobs and Burst behind a playable networked racing game, so the architecture of a real multiplayer title is readable in one project. It requires a specific editor version and Git LFS, and its build times are the known weak point.

**Unity-Technologies/ECS-Network-Racing-Sample** — ECS multiplayer racing sample to showcase using Unity Entities and netcode with best practices

- Repository: https://github.com/Unity-Technologies/ECS-Network-Racing-Sample
- Stars: 767 · Forks: 146
- Language: C#
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/unity-technologies-ecs-network-racing-sample

## Two version numbers, and the one that actually matters

The setup requirements are stated in a way that looks contradictory until you read it carefully. The README says the project requires Unity 6000.2.11f1 or later, and then immediately below says the current tested version is 6000.1.15f1, which is an earlier release than the stated minimum.

So there are two numbers in play. One is the floor the project asks you to run, 6000.2.11f1, and the other is the editor version the project is currently tested against, 6000.1.15f1. The README links to the Unity release notes for 6000.2.11f1, which suggests that the requirement moved forward and the tested figure has not caught up, or that the two refer to different things. Either way, an adopter should not treat either number as gospel and should expect to spend time on version compatibility.

The Unity Hub link is provided as a one-click route into the right editor build:

```bash
unityhub://6000.2.11f1/7134d7685e5d
```

The project version itself is given as 3.0.0, and the repository has no GitHub releases, so there is no tagged history to diff against and the project version in the repository is the only version marker. The last push was on 2026-10-19, so the tree is being worked on rather than abandoned.

## Git LFS is not optional for this repository

The first line of the README is a warning, and it is the kind that saves an afternoon: the repository requires LFS, and you must clone it using LFS rather than downloading it as a ZIP.

That instruction exists because the repository contains binary assets that Git LFS stores outside the normal object database. A ZIP download of the repository will not contain the real files, and the project will fail in ways that are hard to trace, because the version control history looks intact and the assets are simply wrong. The top level of the tree does include a .gitattributes file, which is where the LFS tracking rules for those paths are declared, along with a .gitignore and a .github directory.

The practical instruction is therefore short. Clone with a Git client that has LFS support, and verify that the asset sizes in your working copy are plausible before you open the project. If you are on a machine where Git LFS is not installed, the README's requirement is a hard stop rather than a warning, and there is no partial path through it, since the assets are what the project renders.

## What the sample is actually built on

The feature list is the clearest description of what a project like this has to get right, and the entries are Unity stack names rather than game features. Netcode for Entities handles the multiplayer layer. Baking converts authoring data into runtime entities. ISystem is the unmanaged system pattern. Unity Physics provides the simulation. Jobs and Burst are the performance machinery underneath, and Vivox is listed for voice communication.

Reading that list as a set of dependencies rather than a feature set tells you what the sample is demonstrating. A networked Entities game has to solve three problems at once: a data oriented simulation that can run across many entities, a network layer that keeps clients and server agreeing on state, and a physics simulation that behaves predictably when one side is authoritative and the other is predicting locally. The sample puts all three in one project so they can be read against each other.

The new features section points at the package documentation for each layer, including a vehicle package, detailed static mesh collision under Unity Physics, the new input system, and the Multiplayer Play Mode tool. The last of those is the one that changes the developer loop rather than the runtime, since it is what allows a client and a server to run inside the editor.

## Running the demo needs the PlayMode tools, not a build

The demo runs in the editor, and the README's steps are all editor operations. You open the Multiplayer menu and choose the PlayMode Tools window, select PlayMode Type as Client Server, open the scene at Project/Assets/Scenes/MainMenu.unity, pick a car for the race, and then either wait in the lobby for other players or press the Left Menu button followed by the Start button to start the race yourself.

That flow is a good sign for the project. The Multiplayer Play Mode tool lets you run a client and a server in the same editor session, which is how you test netcode behaviour without building two players and finding a second machine. The presence of the multiplayer.playmode package at version 2.0 in the linked documentation matches the tool named in the menu path.

The controls are listed plainly, with the throttle on the Up Arrow or W, the brake and reverse on the Down Arrow or S, and steering on the Left and Right Arrows or A and D. The new input system is one of the listed features, so the bindings are likely handled through that rather than through the legacy input manager, though the README does not spell out the asset that holds them.

## Shader variant compilation is the known weak point

There is one known issue, and the README is direct about it: build times are taking much longer than expected, because all the shader variants are being compiled and not only the ones actually used in the project.

That is a specific and common problem in Unity projects with a large shader library, and it has a specific shape. A player build compiles variants for every shader in the project, and if the project includes shaders with many keywords, the count of possible permutations grows quickly. In a project whose content is a handful of cars and a track, that is a build that should take minutes, and a project that also carries the vehicle, physics and netcode packages ships with more shaders than its own content implies.

For a sample meant to be read and run, this is the difference between opening the project and waiting for it. A developer who does not know what the issue is will assume the project is broken. A developer who does know it will look for a shader stripping or variant restriction setting in the project settings, and the project does have a ProjectSettings directory at the top level of the tree where such a configuration would live.

## A sample to read, not a codebase to own

The repository layout is the minimal Unity project shape: an Assets directory, a Packages directory, a ProjectSettings directory, a .multitool file, a .gitattributes file, a .gitignore, a .github directory, a README and a file named LICENCE.md with the British spelling.

That last file is the reason to read the repository before using it. The project listing records the licence as a custom one that GitHub cannot classify, and there is a licence document in the root. For a sample you intend to read, that is a formality. For a sample you intend to build on, to lift a system or a shader out of, or to use as the starting point for a commercial title, the terms of that document are the thing that decides whether you can.

The scope of the project also deserves a clear statement. It is a sample, and the description says it exists to show how Unity Entities and netcode are used with best practices. That framing tells you what to expect from reading it: a worked example of how these packages fit together in a game, with a race as the vehicle for the demonstration. It does not claim to be a general purpose netcode library, and it does not claim to be a starting point for a project of your own. The code is organised under Assets, and the Packages directory holds the package manifest that pins the versions the sample was built against, which is the fastest way to see the full dependency surface of the project.

## Conclusion

Adopt this project as a reference, not as a template to fork, if you are building a networked Unity game and want to see Entities, netcode prediction, baking and jobified physics assembled in a working project rather than in isolated documentation. Keep away if you need a build you can ship in a day, because the README lists long build times caused by compiling all shader variants as a known issue, and skip it if you are on a machine without Git LFS, since the repository assets require it. Before you start, read LICENCE.md in the repository root, because the project carries a custom licence that GitHub cannot classify, and pin the editor to 6000.2.11f1 or later as the README requires.

## FAQ

### What is the ECS Network Racing sample and what does it demonstrate?

It is a Unity multiplayer racing sample that showcases using Unity Entities and netcode with best practices. The listed features are Netcode for Entities, baking, ISystem, Unity Physics, Jobs, Burst and Vivox, so the sample exists to show those layers working together in a playable project.

### What do I need to run the ECS Network Racing sample?

You need Git LFS, since the repository requires LFS and the README says not to download it as a ZIP, and Unity 6000.2.11f1 or later, with the current tested version listed as 6000.1.15f1. A Unity Hub link is provided for the required editor build.

### How do I run the multiplayer demo in the editor?

Open Multiplayer and then Window: PlayMode Tools, set PlayMode Type to Client Server, and open the scene at Project/Assets/Scenes/MainMenu.unity. Choose a car, then either wait in the lobby for other players or press the Left Menu button and then Start to begin the race.

### What are the known problems with the ECS Network Racing sample?

The README lists one known issue: build times are much longer than expected, because all the shader variants are being compiled rather than only the ones used in the project. The repository also has no GitHub releases, so there is no tagged build to compare against.

## Sources

- [Issues](https://github.com/Unity-Technologies/ECS-Network-Racing-Sample/issues)
- [README](https://github.com/Unity-Technologies/ECS-Network-Racing-Sample/blob/master/README.md)
- [Unity-Technologies/ECS-Network-Racing-Sample on GitHub](https://github.com/Unity-Technologies/ECS-Network-Racing-Sample)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/unity-technologies-ecs-network-racing-sample