Going from one match to a live service: matchmaking players into sessions, running fleets of dedicated servers, sharding a large world, and stopping cheaters — the operational side of online games.
A live game needs a backend that groups players into matches and places each match on a server. Matchmaking gathers a set of compatible players (by skill, region, mode), then allocates a dedicated server instance and hands every player its address and a join token. Dedicated servers — hosted by you, with public IPs — sidestep NAT problems and give the authoritative, cheat-resistant environment competitive games require.
The path from "press play" to "in a match":
1. player queues -> MATCHMAKER groups compatible players
(by skill/MMR, region/latency, game mode, party)
2. matchmaker ALLOCATES a dedicated server instance from a fleet
(an orchestrator like Agones on Kubernetes spins one up / assigns one)
3. server is authoritative for that match; players get its IP+port + a TOKEN
4. clients connect (UDP) directly to the server and play
5. match ends -> server reports results, is recycled/scaled down
Dedicated servers (public IP, you host them) dodge NAT and give the
authoritative, cheat-resistant environment competitive games need.Online games scale horizontally: each match or zone runs on a server instance, and you add instances as players grow — the same container-orchestration approach from the DevOps courses, applied to game servers. For a single huge world (an MMO), you shard it: split the world into zones each owned by a different server, and hand players off at the boundaries. Understanding that game backends scale like other distributed systems demystifies operating them.
Scaling a game backend = distributed systems (see the Software Architecture +
Kubernetes courses), applied to game servers:
MANY SEPARATE MATCHES each match/lobby -> its own server instance;
add instances as demand grows (auto-scale a fleet).
orchestrate with Kubernetes + Agones.
ONE HUGE WORLD (MMO) SHARD the world into zones, each owned by a different
server; hand players off at zone boundaries.
(interest management, earlier, keeps each zone cheap.)
stateless backend services (auth, matchmaking, inventory) scale like any
web service; the game SIM servers are the stateful, latency-critical part.The authoritative server is your foundation of anti-cheat — it validates every action, so a hacked client cannot fabricate state — but it does not stop everything. Aimbots and wallhacks exploit information the client legitimately has, so you also minimize what you send (do not replicate enemies a player should not see — interest management doubles as anti-cheat), detect anomalies server-side, and run client-side anti-cheat for the rest. Cheating is an ongoing arms race, not a solved problem.
# server-side validation is the core of anti-cheat: reject the impossible.
def validate(player, cmd, world):
if cmd.move.length() > 1.001: return False # speed hack
if distance(player.pos, cmd.claimed_pos) > player.max_step: return False # teleport
if cmd.fire and player.ammo <= 0: return False # infinite ammo
if world.now - player.last_shot < player.cooldown: return False # rapid fire
return True
# authoritative server stops FABRICATED state. But it can't stop cheats that use
# info the client legitimately has:
# aimbot/wallhack -> DON'T SEND what the player shouldn't see (interest mgmt
# is also anti-cheat), detect anomalies server-side (impossible accuracy),
# + client-side anti-cheat (kernel drivers) for the rest.
# it's an ongoing ARMS RACE, not a one-time fix.Server-side game development ties everything together: network programming for the transport, an authoritative simulation with replication and prediction for the gameplay, concurrency to serve many players, databases and services for persistence and matchmaking, and cloud infrastructure to run it all at scale. Each piece has its own course; this roadmap is how they combine into an online game that stays fair, responsive, and available.
Server-side game development, assembled:
TRANSPORT sockets, UDP + reliability (Network Programming course)
SIMULATION authoritative tick loop, replication, prediction, lag comp
(this course)
CONCURRENCY serve thousands of connections (Server Concurrency course)
PERSISTENCE accounts, inventory, stats (PostgreSQL / NoSQL / Caching)
SERVICES matchmaking, chat, RPC (REST / gRPC / message queues)
INFRA fleets, autoscale, deploy (Docker / Kubernetes / Cloud)
SECURITY TLS, auth, anti-cheat (Applied Crypto / Auth)
No single piece is the "server"; the game is the SYSTEM. This roadmap wires
them into an online game that stays fair, responsive, and available at scale.