🌐 Lesson 6.1: Networking Foundations — Client/Server & Topologies

Why It's Hard

A single-player game reads input and updates the world in the same instant. A networked game can't. Three hard facts shape everything:

• Latency. A message from one machine to another takes tens to hundreds of milliseconds. By the time you see another player's position, it's already old.
• Loss & order. Packets get dropped, duplicated, or arrive out of order. You can't assume every message lands, or lands in sequence.
• Trust. You control the server, not the players' machines. Any value a client sends could be forged by a cheater.

Every networking technique — authority, prediction, interpolation, reliable vs unreliable channels — exists to cope with one of these. This module focuses on getting a correct, cheat-resistant multiplayer game working; the advanced smoothing techniques (client-side prediction, lag compensation) are a specialisation we point to at the end.

Topologies

A topology is the shape of who-talks-to-whom. Two broad families:

Nearly all modern multiplayer — and all of this module — uses client-server. It gives you a single source of truth, a natural place to enforce rules, and a far easier security story. Netcode for GameObjects is a client-server library.

Host vs Dedicated Server

Client-server has two flavours, and Netcode supports both:

A host is just "server + client in one process." Everything you write works the same either way, which is why you'll usually develop with a host (one machine, easy to test) and can deploy as a dedicated server later without rewriting your gameplay code.

The Authoritative Server

Here's the single most important rule in this module: the server owns the truth. Clients send requests ("I want to move here", "I fired"); the server decides what actually happens and tells everyone the result. Clients never directly set shared game state.

Why? Because you don't control the players' machines. If a client could declare "my health is 999" or "I'm standing on the objective", a cheater would. With an authoritative server, a hacked client can send a lie, but the server validates it against the rules and rejects it — the worst a cheater can do is desync their own screen. This is the backbone of fair multiplayer.

Netcode for GameObjects

Netcode for GameObjects (NGO) is Unity's official high-level networking library for the GameObject workflow. It handles connection, spawning networked objects, synchronising state, and remote calls, over a pluggable transport (Unity Transport by default). Install it from the Package Manager, then add a NetworkManager component to a scene object — it's the brain of the whole session.

The NetworkManager holds your transport, the list of spawnable network prefabs, and the connection settings. Its singleton, NetworkManager.Singleton, is how your code starts and queries the session. Around it you'll build with two more types you'll meet next lesson: NetworkObject (marks a GameObject as network-spawnable) and NetworkBehaviour (the base class for networked scripts, replacing MonoBehaviour).

💡 One codebase, three roles. The same build can run as host, server, or client — which role it takes is decided at runtime by which "Start" method you call. Your networked scripts check IsServer/IsClient/IsOwner to branch behaviour.

Starting a Session

With a NetworkManager in the scene, starting a session is one call. A tiny UI to pick a role is the classic first script:

using Unity.Netcode;
using UnityEngine;

public class ConnectionMenu : MonoBehaviour
{
    void OnGUI()
    {
        // Only show the menu before a session has started.
        if (NetworkManager.Singleton.IsClient || NetworkManager.Singleton.IsServer)
            return;

        if (GUILayout.Button("Host"))   NetworkManager.Singleton.StartHost();   // server + client
        if (GUILayout.Button("Server")) NetworkManager.Singleton.StartServer(); // dedicated
        if (GUILayout.Button("Client")) NetworkManager.Singleton.StartClient(); // join a host/server
    }
}

• StartHost() — become the server and a local player. The go-to for testing.
• StartServer() — become a headless dedicated server, no local player.
• StartClient() — connect to a server at the transport's configured address.

To test locally, build the game, run one instance and click Host, run another and click Client — the client connects to 127.0.0.1 by default. That two-window loop is how you'll iterate on everything in this module.

Hands-on Challenge

Summary

🚀 What's Next?

You can start a session; now you need things in it. In Lesson 6.2: NetworkObjects, Spawning & Ownership we make GameObjects network-aware, spawn player objects, and untangle who owns and controls what.