Design Multiplayer Game Network Architectures

Provides networking architecture and synchronization principles for multiplayer game development, organized as decision trees and reference tables covering server architecture selection, state/input synchronization, network bandwidth optimization, server-authoritative security, and matchmaking.

Use this skill when working on multiplayer game development tasks or workflows that need networking architecture guidance, best practices, or checklists. Do not use it for tasks unrelated to multiplayer networking, or when a different domain or tool is actually needed.

Architecture selection runs through a decision tree by multiplayer type: competitive/real-time games should use a dedicated authoritative server, cooperative/casual games can use a host-based model (one player acts as server), turn-based games can use simple client-server, and massive/MMO games need distributed servers. A comparison table rates dedicated (low latency, high cost, strong security), P2P (variable latency, low cost, weak security), and host-based (medium latency, low cost, medium security) against each other.

Synchronization principles cover state sync (syncing game state, best for simple games with few objects), input sync (syncing player inputs, best for action games), and a hybrid of both for most games - plus lag compensation techniques: client-side prediction of server outcomes, interpolation to smooth remote players, reconciliation to fix mispredictions, and lag compensation that rewinds state for hit detection.

Network optimization covers bandwidth reduction via delta compression (sending only changes), quantization (reducing precision), priority ordering (important data first), and area-of-interest filtering (only nearby entities) - alongside recommended update rates: position at 20-60 Hz, health and inventory only on change, chat only on send.

Security principles are built on server authority: the server validates every client claim (did a hit actually register, was the player in a valid state, was the timing possible) rather than trusting client reports. Anti-cheat measures map directly to exploits: server-validated movement stops speed hacks, server-validated sight lines stop aimbots, server-owned inventory stops item duplication, and withholding hidden data from the client stops wall hacks.

Matchmaking factors covered: skill (fair matches), latency (playable connection), wait time (player patience), and party size (group play support).

Anti-patterns flagged: trusting the client instead of treating the server as authority, sending all data instead of only what's necessary, ignoring latency instead of designing for a 100-200ms baseline, and syncing exact positions instead of interpolating/predicting.

Multiplayer game developers and network engineers choosing a server architecture, designing state synchronization and lag compensation, optimizing bandwidth, or hardening against common cheats - without re-deriving these networking trade-offs from scratch each project.