// the find
Unity-Technologies/com.unity.multiplayer.samples.coop
A small-scale cooperative game sample built on the new, Unity networking framework to teach developers about creating a similar multiplayer game.
Boss Room is Unity's official reference implementation for Netcode for GameObjects (NGO), built as a playable 8-player co-op RPG. It covers the full stack of a real multiplayer game: lobby, character selection, server-authoritative gameplay, relay/session integration, and reconnection handling. Target audience is Unity developers who want to learn NGO patterns by reading production-quality (if educational) code, not by reading docs alone.
The index of resources in the README is genuinely useful — each pattern (NetworkList with custom serialization, client-driven anticipation animations, connection state machine) maps directly to a file and line, so you can find the relevant code without guessing. The connection management layer uses a proper state machine rather than scattered boolean flags, which is uncommon in samples of this kind. The reusable Utilities package (session manager, scene loading with synced progress bars, NetworkObjectSpawner) ships as an installable UPM package, so you can pull individual pieces into your own project without copying files. The separation of server and client character components — one object on the host has both, clients have only the client side — demonstrates the compositional pattern NGO actually expects, which most tutorials get wrong.
It's pinned to Unity 6000.0 LTS with no upgrade path documented; if you're on an earlier version or the next LTS cycle, you're on your own. The sample is server-authoritative but uses a single host-client model rather than a dedicated server, so everything you learn about authority still needs re-evaluation if you move to Multiplay or a headless build. Git LFS is required just to clone it, which breaks a surprising number of CI pipelines and is an unnecessary friction point for a teaching project. The action system uses ScriptableObjects as data containers but the dispatching logic is a long switch-like inheritance hierarchy — it models the problem clearly enough for a sample, but anyone who copies this pattern into a real game will hit scalability issues around 10-15 action types.