Netcode for GameObjects and the transport seam it never documents

A high-level SDK for MonoBehaviour code, not a transport

The repository describes Unity-Technologies/com.unity.netcode.gameobjects as a high-level netcode SDK that gives GameObject and MonoBehaviour workflows networking inside Unity, then says it sits on top of an underlying transport layer. Those two clauses settle what the tool is. It is not a packet library you bolt onto a socket; it is the layer that turns Unity objects into something a second Unity instance can keep in step with the first.

That makes the audience narrow and predictable. You already write against Unity's component model, a scene holds prefabs and MonoBehaviours rather than an entity graph, and the alternative is hand-rolling object spawning plus per-object state resends in every project that ships. The code is C#, and the repository topics read multiplayer, networking, netcode and owner-multiplayer-sdk, which places it as Unity's own answer rather than a community add-on.

Where it stops is equally definite. One sentence covers runtime platforms, one covers where to ask questions, and nothing between them describes what synchronizing an object costs in bandwidth or code. A reader deciding between this and building directly on a raw transport gets a clear boundary and no numbers.

The seam between object sync and bytes is undocumented

The project description splits the stack in two: an SDK for GameObject and MonoBehaviour workflows, and an underlying transport layer beneath it. From the other side, the README says the framework is interoperable with many low-level transports and links the official Unity Transport Package as its example. So the design is deliberately transport-agnostic, and the second package you actually need is a choice this repository never enumerates.

Interoperability stated that way is a claim about a boundary, not a list of integrations. No interface name for a transport appears anywhere. No tick rate, payload ceiling, reliability mode or channel count is given. Nothing explains how a transport gets registered with the SDK, or what happens when a session opens against a transport that does not implement the expected surface.

For a team that already owns a transport, that boundary is the point of the package. For a team starting from nothing it means two decisions before a single object can be spawned, and the second one is documented somewhere other than here.

The two-package tree hides most of the repository

The development section states that the repository is broken into multiple components, each one implemented as a Unity Package, and then prints a tree with 2 entries. Both lines carry annotations, and those annotations settle the packaging question.

    .
    ├── com.unity.netcode.gameobjects           # The core netcode SDK unity package (source + tests)
    └── testproject                             # A Unity project with various test implementations & scenes which exercise the features in the above packages.

The real root is wider than that picture. Counting the top-level entries gives 9 directories and 12 files, and the tree names 2 of those directories. Absent from it: `Examples/`, `minimalproject/`, `Tools/`, `dotnet-tools/`, `apiupdaterproject/`, `.github/` and `.yamato/`. Root files such as `ValidationExceptions.json`, `pvpExceptions.json` and `.pr_agent.toml` sit at the top level with no explanation in the README.

Read the two annotations closely, because they decide what ships. `com.unity.netcode.gameobjects` is described as source plus tests, so the unit tests live inside the package directory and travel with it. `testproject` is the consumer, a Unity project with various test implementations and scenes that exercise the features in the package above. What you install is the package; what you clone for verification is both.

One Unity version under a plural heading

Compatibility gets a single sentence of setup and a bulleted list. The heading promises more than the list delivers: it says the package targets the following Unity versions, then names exactly 1, Unity 6 (LTS). There is no entry for an earlier editor, and no statement about what happens when a project is opened on one.

Runtime coverage is broader and more concrete: Windows, MacOS, and Linux, then iOS and Android, then most closed platforms, such as consoles. Consoles arrive with a condition attached, because the README says to contact Unity for more information about specific closed platforms. The most locked-down targets are exactly the ones you cannot read about in public.

That gap leaves a fingerprint. The repository topics still carry unity-3d and unity3d, two tags that do not match the single editor name in that list. Topic tags are not a compatibility promise, but they are what a searcher reads first, and here they point at a different generation of Unity than the one supported version.

Acquisition is a documentation URL, not a command

Look for an install step in the README and you find 2 links and no instructions. There is no package manager command, no version to pin, no manifest line, no dependency list. The Getting Started section sends you to the Multiplayer Docs Site for package and API documentation plus information about samples, then offers a quickstart guide for basic networked tasks.

That is the entire acquisition path in this repository. The manual and the API reference live under the package name in the Unity documentation set, and the API link opens the NetworkManager page directly rather than a listing, at `docs.unity3d.com/Packages/com.unity.netcode.gameobjects@latest` with `?subfolder=/api/Unity.Netcode.NetworkManager.html`. Nothing in the repository states which package version that documentation describes, so what you read is whatever Unity publishes at the time, not the line you pinned.

Support follows the same route as the docs. Questions, networking advice and discussion go to the Discord community or to the Netcode for GameObjects section of the Unity forums, and the roadmap link resolves to the Unity platform multiplayer page rather than a file inside the repository. Bug reports and feature requests are delegated to `CONTRIBUTING.md`.

Choosing a package line the tags do not explain

Version state here rewards a close look. The release record puts v2.13.3 at 2026-09-21T11:48:34Z and NGOv3.0.0 at 2026-09-21T11:52:28Z, 4 minutes apart on the same day, while the default branch is `develop-3.x.x`. The last push was on 2026-09-28, 7 days after both.

A patch on one line and a major on another were cut minutes apart, so neither is a clean successor in time. A project sitting on 2.13.3 is not behind by accident. What the repository does not contain is any migration guide, compatibility table or rollback procedure between the 2.x and 3.x lines, which leaves the decision of which line to take, and what to do when the other one stops moving, entirely with the team doing the work.

Nothing at the root reconstructs that history either, since the 12 top-level files include no change notes of any kind. For a package whose whole job is deciding which copy of an object is correct, the missing artifact is the one a migrating team needs most.

The alternative is owning object sync yourself

The real alternative is named in the repository itself. Keep the low-level transport, the kind the README links when it points at the Unity Transport Package, and write your own GameObject and MonoBehaviour synchronization on top. The difference in approach is ownership of the object layer: a transport moves bytes between endpoints and asks nothing about your scene, while the SDK adds object lifecycle, per-object state and the spawn and despawn traffic a Unity project needs. Teams with a hand-rolled sync layer already have something concrete to compare against.

The same split explains where this is the wrong tool. It does not enumerate the transports it actually works with, it publishes no topology, no object count ceiling and no bandwidth or memory figure for a replicated prefab, and it says nothing about host migration or shutdown. Those are the questions a network programmer asks on day 1, and none of them are answered here.

The topics still read hlapi, mlapi, netcode and networking, which names a lineage the README never explains. A team arriving from Unity's earlier networking packages arrives with questions about what was renamed, what was dropped and what to migrate, and finds no migration note waiting.

Four example folders and one unexplained project

`Examples/` holds 4 directories: `CharacterControllerMovingBodies`, `DocumentationExamples`, `OverridingScenesAndPrefabs` and `PingTool`. Two names state a Unity problem outright, moving bodies with a character controller and overriding scenes and prefabs. The other 2 only gesture at documentation samples and a ping tool, which is also the last place in the repository where anything resembling latency tooling is mentioned by name.

None of the 4 appears in the development tree, and neither does `minimalproject/`, a top-level Unity project directory whose purpose the README does not state. Nor does the pairing of `ValidationExceptions.json` with `pvpExceptions.json`, 2 root files whose names hint at a validation workflow that no document describes. `dotnet-tools/` and `apiupdaterproject/` are equally unexplained, and `.yamato/` sits there as a dot-directory beside `.github/`.

A reader trying to learn the intended layout of a multiplayer scene has to infer it from directory names. Compare that with the packaged reference: manual, API pages and samples all live one domain away, which is a deliberate choice about where this project keeps its answers rather than an oversight in the package itself.

Editorial conclusion

Adopt it when your team already writes Unity components and would rather ship object synchronisation than build it, and when you already hold a transport you trust. Do not adopt it on the strength of this repository alone: it names no transport interface, no editor version besides Unity 6 (LTS), no migration route between the 2.13.x and 3.0.0 lines, and no way to tell which package version the online manual describes. Verify first that the transport you plan to pair it with matches what NetworkManager expects.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Unity-Technologies/com.unity.netcode.gameobjects on GitHub