Netcode for GameObjects (Unity)

Unity's first-party networking package, "a high-level networking library built for Unity for you to abstract networking logic" over the GameObject and MonoBehaviour workflow. Read from the 2.13 manual on 2026-08-25. Unity 6.0 and later; Mono and IL2CPP; Windows, macOS, Linux, iOS, Android, XR, most console platforms, and WebGL (needing package 1.2.0+ with Unity Transport 2.0.0+).

The thing the other two engines do not offer: a topology choice

Netcode for GameObjects ships two network topologies, and picking between them is a project decision rather than a given.

Client-server — "the server has final authority on the state of the game." Clients send updates; the server runs the simulation. Unity's own summary of the trade: centralized authority, better resistance to cheating, better tick rates, and the cost of running dedicated servers. Available as a dedicated server or as a listen server.

Distributed authority — "game instances share responsibility for owning and tracking the state of objects." A lightweight central service keeps minimal state and routes traffic; no server runs the simulation. Cheaper to operate, lower latency because instances message each other more directly, and more vulnerable to cheating, which Unity says plainly rather than burying.

The manual does not state a maximum client count for either topology.

NetworkVariable — state, as opposed to messages

The distinction the package draws is between one-time communication (RPCs, custom messages) and persistent state. A NetworkVariable wraps a value and keeps it synchronized; you touch the real value through .Value.

It syncs on two occasions: a late joiner gets the current state when the NetworkObject spawns, and a change raises OnValueChanged on subscribers with both the old and new value.

Permissions are set in the constructor and are the ownership model in miniature. Read is Everyone by default or Owner. Write is Server by default or Owner. So the out-of-the-box posture in a client-server project is exactly Unreal's: the server writes, clients read.

The constraints are worth recording because they shape gameplay code. A value can only be set during initialization or while the NetworkObject is spawned. Supported types are primitives, Unity built-ins, enums, FixedString, and anything implementing INetworkSerializable. Plain strings are not supported — they are immutable, so every update would allocate and feed the garbage collector. Collections need an explicit CheckDirtyState() call for a change to be noticed.

Against the other two engines

Unity is the only one of the three that makes the authority topology itself a supported choice rather than a fixed property of the engine, which is the sharpest difference the 2026-08-25 reading found. unreal-replication has one topology and tunes bandwidth instead; godot-multiplayer-api has one topology and makes authority reassignable per node, which is a smaller version of the same idea.

Related

netcode · unreal-replication · godot-multiplayer-api · unity-engine · game-networking-fiedler