nomicon

    ↑ ↓ to move, Enter to open. Matches lesson text, headings and the labs' concept cards.

    Lessons

    How networked games hide the network

    One small game, run over a simulated network you can make worse. The problem: what latency, jitter and loss do to a game that just waits for the server. Client and server: drawing other players from snapshots, predicting your own, and the server rewinding time to judge your shots. Peer to peer: sending inputs instead of state, with lockstep and rollback. Then choosing a model for your game, and in practice: keeping entity ids in step between machines in flecs.

    The problem

    1. 1Latency, jitter and lossWhat the network does to a game that simply sends inputs to a server and draws whatever comes back: a round trip of delay on every key press, stutter when packets arrive unevenly, and freezes when they don't arrive at all. Drive it yourself and feel each one.

    Client and server

    1. 2Snapshots and interpolationDrawing other players from a server that sends the world a few times a second. Snap to the newest snapshot, interpolate between two old ones, or extrapolate past the newest: smoothness against how current the picture is. Then making snapshots smaller: quantising and sending only what changed.
    2. 3Prediction and reconciliationWhy your own player responds instantly even though the server is a round trip away: the client runs your inputs itself, keeps the ones the server hasn't confirmed, and when the server's answer arrives, rewinds to it and replays them. What goes wrong without each part, and smoothing the corrections that remain.
    3. 4Lag compensationYou see other players in the past, so aiming where you see them misses on the server. Lag compensation has the server rewind everyone to what you saw when you fired. Why it's necessary, what it costs the player being shot, and why servers cap how far back they'll go.

    Peer to peer

    1. 5Lockstep and rollbackSend inputs instead of state, and let every machine run the whole game. Lockstep waits for everyone's input before each frame; rollback guesses the missing inputs, and when the real ones arrive, rewinds and re-simulates. Input delay as the dial between them, and why both need a perfectly deterministic game.

    Choosing

    1. 6Choosing a modelWhich model suits which game: an authoritative server with prediction, interpolation and lag compensation for shooters, lockstep for strategy games, rollback for fighting games, and the mixes in between. The questions that decide it, and where the rest of the site fits in.

    In practice

    1. 7Networking in flecsTwo worlds that must agree on what an entity id means. Making ids match with make_alive, keeping local ids out of the way with entity ranges, choosing what to send with a Replicated tag, and sending frequent and rare data differently.

    The network is simulated in your browser with seeded randomness, so the same settings always give the same numbers. Code examples are in C++.