Game Server Development Series — Part 1: Introduction to Online Game Servers

Leeting Yan

Online multiplayer games—from small casual titles to massive MMOs—are powered by one critical element:
the game server.

This chapter gives a clear, friendly, and complete introduction to what game servers are, why they exist, how they work, and what technologies surround them.
It is written for total beginners, but structured with the accuracy expected of modern production systems.

1. What Is an Online Game Server?

A game server is a backend program running on a remote machine.
It manages all shared rules, simulation, and persistence in a multiplayer game.

The server maintains:

  • Game rules & combat calculations
  • Player positions & movement
  • Skill effects & projectiles
  • Inventory, items, and currency
  • Match state or persistent world state
  • Social systems (chat, party, guilds)

2. Why Do Games Need Servers?

There are three core reasons every multiplayer title relies on a server.

2.1 Fairness — Preventing Cheating

If the client (player’s device) decided outcomes:

  • Speed hacks
  • Teleporting
  • Infinite ammo
  • Forged position updates
  • Fake currency

…would be extremely easy.

The server solves this by being authoritative and rejecting invalid player actions.

2.2 Consistency — A Shared Reality

Without a central authority:

  • Player A might see a hit
  • Player B sees a miss
  • Objects don’t sync
  • Loot duplicates

The server ensures every client observes the same final result.

2.3 Security — Protecting Progress

The server stores:

  • Accounts
  • Characters
  • Inventory
  • Currency
  • Achievements
  • Match history

Progress cannot be forged or altered by hacking the game client.

3. The Authoritative Client–Server Model

The model used by nearly all modern online games:

  1. Client sends input (“move”, “shoot”, “use ability”).
  2. Server validates and simulates outcomes.
  3. Server sends updates back to all players.
flowchart LR
    Client1([Client A]) --> Server((Authoritative Game Server))
    Client2([Client B]) --> Server
    Client3([Client C]) --> Server
    Server --> DB[(Database)]

The server decides the truth.
Clients display the truth.

4. Types of Online Game Servers

Not all multiplayer games work the same. Here are the major categories.

4.1 Real-Time Action Servers (FPS, MOBA, Racing)

Used in games like Valorant, CS2, Rocket League.

Characteristics:

  • Tick-based simulation (20–60 ticks per second)
  • Extremely low latency requirements
  • Often use UDP
  • Predictive clients (prediction, interpolation, rollback)

4.2 Turn-Based Game Servers (Strategy, Card, Board Games)

Used in Hearthstone, Auto Chess, Pokémon TCG.

Characteristics:

  • Lower real-time requirements
  • Uses HTTP or WebSocket
  • Actions processed as discrete events
  • Easier to scale horizontally

4.3 Persistent World Servers (MMO, SLG, Survival)

These power games like EVE Online, WoW, Rust, mobile SLGs.

Characteristics:

  • 24/7 long-running world simulation
  • Zones, shards, regions
  • Large persistent datasets
  • Complex load balancing and anti-cheat
  • Significant database design challenges

4.4 Match/Room Servers (Battle Royale, Arena, Co-op)

Characteristics:

  • Server exists only for one match
  • Spun up dynamically
  • Each match runs its own simulation
  • Deallocated after match completion

This is common in scalable cloud architectures.

5. Responsibilities of a Game Server

A server is far more than a connection handler.
It is the core engine of multiplayer gameplay.

5.1 Managing Player Connections

  • TCP / UDP sockets
  • WebSocket for browsers
  • User authentication
  • Reconnect & disconnect handling
  • Rate limiting & flood protection

5.2 Validating and Simulating Gameplay

Typical tasks:

  • Movement
  • Physics
  • Collisions
  • Projectiles
  • Combat & hit resolution
  • Skill behavior
  • AI entities
  • Timers and cooldowns

The server executes everything authoritatively.

5.3 Syncing and Broadcasting State

Two common approaches:

  • Snapshots (send full state periodically)
  • Deltas (send only changes)

State sync flow example:

sequenceDiagram
    Client->>Server: Input (move/shoot)
    Server->>Server: Validate + simulate
    Server->>Client: State update (delta)

5.4 Storing Player Data

Includes:

  • Account
  • Stats & progression
  • Inventory
  • Items & currencies
  • Match history

Persistence typically uses:

  • SQL (PostgreSQL, MySQL)
  • NoSQL (Redis, MongoDB)
  • Blob/object storage

5.5 Preventing Cheating & Abuse

  • Input sanity checks
  • Anti-speedhack
  • Collision verification
  • Behavior analysis
  • Anti-bot detection
  • Server authoritative hit detection

Cheat prevention starts at architecture level, not as an afterthought.

5.6 Providing Meta Services

These include all out-of-match features:

  • Matchmaking
  • Lobby / party systems
  • Chat
  • Friends & guilds
  • Leaderboards
  • Events & seasons
  • Purchase & economy systems

6. The Technology Ecosystem Behind Game Servers

Game servers operate within a broader backend ecosystem.

6.1 Gateway / Proxy Layer

Handles:

  • Connection routing
  • Traffic load balancing
  • DDoS protection
  • Region selection
  • Protocol translation

Examples:

  • Envoy
  • NGINX
  • Cloudflare Spectrum

6.2 Compute for Game Logic

Common languages:

  • Go (robust networking, low latency)
  • Rust (safety + performance)
  • C++ (AAA real-time simulation)
  • Java/Netty (high throughput networking)
  • Node.js (light casual multiplayer)

6.3 Storage Layer

  • SQL → persistent data, accounts
  • NoSQL → leaderboards, sessions, cache
  • Redis → hot data, rate limiting
  • Kafka / NATS → events

6.4 Protocols

  • UDP → real-time action
  • WebSocket → browser games
  • HTTP/gRPC → meta services
  • Custom binary protocols for efficiency

6.5 Analytics & Telemetry

  • ClickHouse
  • BigQuery
  • Prometheus + Grafana
  • ELK / Loki for logs
  • Traces via OpenTelemetry

These systems help detect lag, cheating, and reliability issues.

7. Example Online Game Architecture

Below is a simplified but realistic architecture map.

flowchart TB
    Client((Player Client))
    Gateway((Gateway / Load Balancer))
    RoomSrv[Room / Match Server]
    WorldSrv[World Server]
    MatchSrv[Matchmaking Service]
    AuthSrv[Authentication]
    DB[(SQL Database)]
    Cache[(Redis Cache)]
    MQ[(Message Queue)]

    Client --> Gateway

    Gateway --> AuthSrv
    Gateway --> MatchSrv
    Gateway --> RoomSrv
    Gateway --> WorldSrv

    AuthSrv --> DB
    RoomSrv --> Cache
    WorldSrv --> DB
    MatchSrv --> MQ

This architecture supports:

  • Real-time gameplay
  • Persistent worlds
  • Matchmaking
  • Upscaling via multiple rooms
  • Safe data consistency
  • Observability

8. Summary

You now understand the fundamentals of online game servers:

  • Why servers exist
  • What problems they solve
  • Their responsibilities
  • Different server types
  • How real-time synchronization works
  • The surrounding backend ecosystem
  • High-level architecture

This knowledge forms the base for the rest of the series.