👥 Lesson 6.2: NetworkObjects, Spawning & Ownership

The NetworkObject

An ordinary GameObject exists on one machine. To make it exist across the network — spawned on the server and replicated to every client — it needs a NetworkObject component. This is the unit of network identity: it gets a unique NetworkObjectId, and everything networked (behaviours, variables, RPCs) lives on a GameObject that has one.

Any prefab you intend to spawn over the network must have a NetworkObject and be registered in the NetworkManager's network-prefabs list (or a Default Network Prefabs List). Registration is how a client, receiving "spawn object of type X", knows which prefab to instantiate. Forget to register a prefab and spawning it throws — the second-most-common beginner error after forgetting authority.

The Player Prefab

The most common spawn is "one avatar per player." Netcode automates it: assign a Player Prefab on the NetworkManager, and when a client connects, the server automatically spawns that prefab and gives ownership to the connecting client. Two players connect, two player objects appear on every machine, each owned by its respective player.

NetworkBehaviour & OnNetworkSpawn

Scripts on a networked object inherit from NetworkBehaviour instead of MonoBehaviour. That gives them the network context — IsServer, IsClient, IsOwner, OwnerClientId — and the crucial lifecycle hook OnNetworkSpawn(), which fires when the object becomes network-ready (this is where you set things up, not Awake/Start, because the network identity isn't ready that early):

using Unity.Netcode;
using UnityEngine;

public class PlayerController : NetworkBehaviour
{
    [SerializeField] Camera playerCamera;

    public override void OnNetworkSpawn()
    {
        // Runs on every machine that has this object. Branch by role.
        if (IsOwner)
        {
            // Only the player who owns this avatar drives it.
            playerCamera.enabled = true;
            enabled = true;               // enable local input handling
        }
        else
        {
            // Remote copies: no local camera or input.
            playerCamera.enabled = false;
        }
    }

    void Update()
    {
        if (!IsOwner) return;             // never move someone else's avatar
        // ... read input, request movement (Lesson 6.4) ...
    }
}

The pattern is everywhere in netcode: guard behaviour by role. if (!IsOwner) return; at the top of an input method ensures each machine only drives the avatar it owns; the remote copies just display what the network tells them.

Spawning from the Server

Beyond players, you'll spawn projectiles, pickups, enemies. The rule from Lesson 6.1 holds: only the server spawns. You instantiate the prefab and call .Spawn() on its NetworkObject — Netcode replicates it to all clients:

// Runs on the SERVER only (e.g. inside a server-side method or an RPC target).
public void SpawnPickup(Vector3 position)
{
    if (!IsServer) return;                       // guard: server authority

    GameObject go = Instantiate(pickupPrefab, position, Quaternion.identity);
    NetworkObject netObj = go.GetComponent<NetworkObject>();
    netObj.Spawn();                              // replicate to every client
}

To spawn something a specific player should control, use netObj.SpawnWithOwnership(clientId) instead. To remove it, the server calls netObj.Despawn() (optionally destroying it). A client that tries to call Spawn() gets an error — spawning is a server privilege.

Ownership

Ownership is which client (or the server) a NetworkObject "belongs" to. It matters because ownership decides who's allowed to drive certain things — an owner can be given write permission on a NetworkVariable, and RPCs can target the owner. Key facts:

• By default, spawned objects are owned by the server (owner client id 0 for the host). Player prefabs are the exception — owned by their player.
• IsOwner is true on the machine that owns the object; OwnerClientId is that client's id.
• The server can transfer ownership with netObj.ChangeOwnership(clientId) (e.g. a player picks up a movable crate and should now drive it).
• Ownership is not a security guarantee by itself — even the owner's inputs should be validated by the server for anything competitive. Authority still lives on the server.

A useful way to hold it: ownership answers "who drives this?", authority answers "who decides the truth?" Often the server keeps authority even over objects a client owns — the client requests, the server confirms.

Branching on Role

Because one build runs as server, host, or client, your networked code constantly asks "which am I?" The properties on NetworkBehaviour:

Most bugs in early netcode come from missing one of these guards — moving a non-owned avatar, running server logic on a client, or spawning off the server. Reach for the right check first and the logic follows.

Hands-on Challenge

Summary

🚀 What's Next?

Your player objects exist on every machine but don't yet agree on their state. In Lesson 6.3: NetworkVariables & State Synchronization we make the server's values automatically replicate to clients — health bars, scores, positions that stay in sync.