Multiplayer Networking in Games
- #networking #gamedev #multiplayer
- 241 words, Read time 1 minute, 12 seconds
Before I could build multiplayer AirHockey, I had to actually understand how multiplayer works.
The first idea to unlearn is that both players see the same thing at the same time, but actually they do not. Each screen is showing its own slightly out-of-date guess, and the whole job of networking is to keep those guesses close enough that nobody notices.
It starts with the tick rate: instead of firing an update on every tiny change, the game advances in fixed steps, maybe 30 or 60 times a second, and sends a snapshot of the world on each tick. Fewer ticks means less bandwidth but choppier motion. More ticks means smoother play and a heavier pipe.
Then comes the gap between ticks. If I just snapped the puck to each new position as it arrived, it would stutter across the table. So the receiving side does interpolation: it holds the incoming snapshots and slides smoothly between them, rendering a hair in the past on purpose so it always has two points to move between.
The trick that interests me the most is client-side prediction. Waiting for a full round-trip before your own paddle moves feels awful, so the client moves it immediately and assumes it guessed right. When the authoritative update comes back, it reconciles: if the prediction matched, great, and if not, it corrects.
Summary: Multiplayer is basically deciding whose version of reality is correct, settled many times a second.