Megacity Metro is a Unity sample with 150 players per session, and it publishes its own first build time estimates

The sample is a benchmark as much as a game

Megacity Metro is an action-packed shooter based on the original Megacity sample, and it is built to show what Unity's current stack can do rather than to be finished.

The important points of the demo are listed in the README, and they are the shape of the whole thing. Large-scale streaming and rendering with the Entity Component System, 150 players per game session, server-authoritative gameplay with feature prediction, interpolation and lag compensation using Netcode for Entities. Unity Gaming Services integration for Game Server Hosting, Matchmaking and Vivox voice chat. Universal Render Pipeline and Entities Graphics for rendering. Unity 6 rendering features such as Render Graph and Spatial Temporal Anti-Aliasing. And cross-platform support for Windows, Mac, Android and iOS.

The repository description says 128 or more players, while the overview text says 150 players per game session, and the important points list says 150 players per game session. The figure that matters for your capacity planning is the one in the detailed list.

Two things in that list are worth pausing on. Server-authoritative gameplay with feature prediction is the hard part of any networked shooter, and the fact that the sample ships it means the code shows the pattern rather than just describing it. And the note that integration through the Multiplayer Services SDK is coming soon tells you which parts are complete and which are stubs, which matters if you are trying to reproduce the Game Server Hosting flow.

The homepage is the Unity demo page for the megacity competitive action sample, and the licence is the Unity Companion License, which the README points at a separate LICENCE.md file for the legal detail. The licence is not a standard open source grant, and that is worth knowing before you copy code out of it.

The build time estimates are the most useful paragraph in the README

The Getting Started section opens with a warning that the sample is large and that the first time cloning and playing may take more time than expected, with subsequent plays loading much quicker because of caching. Then it gives the numbers.

Cloning the Megacity Metro repo takes up to 20 minutes. Opening the project with library build takes up to 20 minutes. Building the project for each platform for the first time takes up to 50 minutes.

Almost no project tells you this, and every project should. A sample that silently takes an hour to open looks broken, and an engineer who has not been told will assume the project is at fault rather than the size of it.

The escape hatch is in the same paragraph. Navigate to Project Settings, then Other Settings, then Configuration, then C++ Compiler Configuration, and set Debug if you need to compile faster than optimal. That is a real setting, because this project uses the IL2CPP scripting backend, and the build support modules in the quick start confirm it, telling you to include Windows and Mac Build Support with IL2CPP.

So the cost is a native compilation of a large codebase, and the way to make it bearable is to trade optimisation for speed on the first build.

The clone has its own requirement. Megacity Metro uses Git LFS to handle all large assets required locally, so you must install Git Large File Support before cloning, and the README notes that direct download of the project is not currently supported for this repository. That last detail saves an afternoon for anyone whose network cannot reach the LFS objects, since there is no zip to fall back on.

The quick start needs specific build support modules

The five quick start steps are simple, and step one is where the real work is.

Install a compatible Unity Editor version, and the README highly recommends using the version specified in `ProjectSettings/ProjectVersion.txt`. During the installation, make sure to include Windows and Mac Build Support with IL2CPP, Windows and Mac Dedicated Server Build Support, Android and iOS Build Support if you plan to build for mobile, and Linux Dedicated Server Build Support.

That list of modules is effectively a description of what the project contains. Dedicated server build support for two desktop platforms plus Linux means the project has real server targets, not just a client that fakes authority locally. Mobile build support means the project targets iOS and Android. And IL2CPP for Windows and Mac means the native compilation path, which is the source of the fifty minute build.

The remaining steps are ordinary Unity work. Add the project to the Unity Hub by clicking Add and selecting the root folder of the cloned project, open the Menu scene located in `Assets/Scenes/Menu`, click Play, and start the Single Player mode.

That last point is the one to note. Multiplayer requires more setup, which the README says is explained next, and the single player mode is the entry point for evaluating the sample without standing up a server and a matchmaking backend. For a sample whose headline feature is 150-player multiplayer, the sensible way in is still the single player path, and the multi setup is a separate document in the Documentation directory.

The documentation is organised as a set of task guides

The contents and quick links at the top of the README point at a Documentation directory with a specific shape, and the naming tells you what the reader is expected to do.

There is the Megacity Metro Overview, the Megacity Metro Prerequisites, a Multiplayer Setup guide, an Add Unity Gaming Services guide, an Index of Resources in this Project, an Assemblies page and a Netcode Attributes page.

The Assemblies and Netcode Attributes documents are the ones that make this a reference rather than a demo. An index of resources tells you where the code lives, which matters in a project this size, and a page on netcode attributes is a reference for the specific annotations that drive the replication behaviour. If you are trying to understand how the prediction and lag compensation are configured, that page is the place to look.

The script index and the assemblies page together are the answer to the question every reader of a Unity sample asks, which is where do I change this. In a project built on Entities with native plugins, the assembly boundaries decide what can be edited safely, so a document that lists them is not a nicety.

There is also a `NativePlugins/` directory at the repository root, alongside `Assets/`, `Packages/`, `ProjectSettings/` and `Documentation/`. The native plugins are there because the project uses the Entities stack and the physics or rendering work that cannot stay in managed code.

The gameplay controls are documented as a table. Mouse movement or the arrow keys steer, left click or space shoots, W and S thrust and reverse, A and D steer, E and Q roll, Tab opens the leaderboard, V toggles Vivox, P opens the netcode panel stats, and Escape opens the in game menu. The netcode panel on P is the debugging entry point, and the leaderboard on Tab is where the Game Server Hosting and Matchmaking integration surfaces.

A sample that refuses pull requests

The disclaimer is one line and it is unusual enough to state plainly.

This repository does not accept pull requests, GitHub review requests, or any other GitHub-hosted issue management requests.

That is a deliberate choice for a sample project, and it has a practical consequence. You cannot contribute a fix, you cannot open an issue to report a problem, and the code is a snapshot rather than a maintained dependency. If you find a bug, your options are to work around it in your own fork or to read the source and understand it.

Combined with the Unity Companion License, the picture is clear. This is a reference artefact published by a vendor so that engineers can read it and take the patterns from it, not a community project that grows through contributions.

That is a perfectly reasonable model for a sample, and it changes how you should read the code. You are reading it for the patterns, the assembly structure, the netcode configuration and the rendering setup. You are not expecting the netcode layer to be patched when Netcode for Entities changes, and the fact that the release tags are absent from the repository history, with the project tracking its own versions through the Unity editor version and the package manifest, is consistent with that.

The `Packages/` directory at the root holds the package manifest with the DOTS and Netcode package references, and `ProjectSettings/ProjectVersion.txt` is the file the README tells you to read for the editor version. Those two files are the two things to look at first if you are picking up the project, because they tell you what the sample assumes about the rest of the stack.

The last push to the repository was on 2026-04-10, the default branch is `master`, and the repository is not archived. The topic list adds the vocabulary the project uses, dots, multiplayer, netcode, samples, services, ugs and unity.

Editorial conclusion

Adopt Megacity Metro as a reference implementation if you are building a Unity multiplayer game with Netcode for Entities and want to see server authoritative gameplay, prediction and lag compensation in a working project. Do not adopt it as a starting point for your own game, because the repository does not accept pull requests and the Unity Companion License is not a permissive open source licence. Verify first that the Unity Editor version in ProjectSettings matches the one you can install, that the build support modules you need are selected, and that you have the time and disk for the initial clone and library build before you plan a workshop around it.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Unity-Technologies/megacity-metro on GitHub