Multiplayer Game

Patterns for building multiplayer games with RivetKit, intended as a practical checklist you can adapt per genre.

Starter Code

Start with one of the working examples on GitHub and adapt it to your game. Do not start from scratch for matchmaking and lifecycle flows.

Server Simulation

Game Loop And Tick Rates

Physics

Start with custom kinematic logic for simple games. Switch to a full physics engine when you need joints, stacked bodies, high collision density, or complex shapes (rotated polygons, capsules, convex hulls, triangle meshes).

Pick one engine per simulation. Keep frontend-only libs out of backend simulation paths and treat server state as authoritative.

Spatial Indexing

For non-physics spatial queries, use a dedicated index instead of naive O(n^2) checks:

Networking & State Sync

Netcode

Realtime Data Model

• Snapshots and diffs: Publish state as events. Send a full snapshot on join/resync, then per-tick diffs for regular updates.
• Batch per tick: Keep events small and typed. Batch high-frequency updates per tick.
• Avoid UI framework state for game updates: Use requestAnimationFrame or a Canvas/Three.js loop for simulation, not React state. Reserve UI framework state for menus, HUD, and forms.
• Broadcast vs per-connection: Use c.broadcast(...) for shared updates and conn.send(...) for private/per-player data.

Shared Simulation Logic

Shared simulation logic runs on both the client and the server. For example, an applyInput(state, input, dt) function that integrates velocity and clamps to world bounds can run on the client for prediction and on the server for validation.

• Hybrid modes: Client runs shared movement as primary authority, server runs it for anti-cheat validation.
• Server-authoritative modes: Client uses shared logic for interpolation and prediction only.
• Keep it pure: Movement integration, input transforms, collision helpers, and constants only.
• Put shared code in src/shared/: Keep deterministic helpers in src/shared/sim/* with no side effects.

Interest Management

Control what each client receives to reduce bandwidth and prevent information leaks.

Per-Player Replication Filters

• Filter by relevance: Send each client only state relevant to that player (proximity, line-of-sight, team, or game phase).
• Shooters and action games: Limit replication by proximity and optional field-of-view checks.
• Server-side only: Clients should never receive data they should not see.

Sharded Worlds

• Partition large worlds: Use chunk actors keyed by worldId:chunkX:chunkY.
• Subscribe to nearby chunks: Clients connect only to nearby partitions (for example a 3x3 chunk window).
• Use sparingly: Only when the world is large and state-heavy (sandbox builders, MMOs), not as a default for small matches.

Backend Infrastructure

Persistence

• In-memory state: Best for realtime game state that changes every tick (player positions, inputs, match phase, scores).
• SQLite (rivetkit/db): Better for large or table-like state that needs queries, indexes, or long-term persistence (tiles, inventory, matchmaking pools). Serialize DB work through a queue since multiple actions can hit the same actor concurrently.

Matchmaking Patterns

Common building blocks used across the architecture patterns below.

Actor Topology

Queueing Strategy

• Multiple players can hit the matchmaker at the same time, so actions like find/create, queue/unqueue, and close need to be serialized through actor queues to avoid races.
• Match-local actions (gameplay, scoring) do not need queueing unless they write back to the matchmaker.

Security And Anti-Cheat

Start with this baseline, then harden further for competitive or high-risk environments.

Baseline Checklist

• Identity: Use c.conn.id as the authoritative transport identity. Treat playerId/username in params as untrusted input and bind through server-issued assignment/join tickets.
• Authorization: Validate the caller is allowed to mutate the target entity (room membership, turn ownership, host-only actions).
• Input validation: Clamp sizes/lengths, validate enums, and validate usernames (length, allowed chars, avoid unbounded Unicode).
• Rate limiting: Per-connection rate limits for spammy actions (chat, join/leave, fire, movement updates).
• State integrity: Server recomputes derived state (scores, win conditions, placements). Never allow client-authoritative changes to inventory/currency/leaderboard totals.

Movement Validation

For any mode with client-authoritative movement (hybrid flows), clients may send position/rotation updates for smoothness, but the server must:

• Enforce max delta per update (speed cap) based on elapsed time.
• Reject or clamp teleports.
• Enforce world bounds (and basic collision if applicable).
• Rate limit update frequency (for example 20Hz max).

Architecture Patterns

Each game type below starts with a quick summary table, then details actors and lifecycle.

Battle Royale

Actors

Lifecycle

Arena

Actors

Lifecycle

IO Style

Actors

Lifecycle

Open World

Actors

Lifecycle

Party

Actors

Lifecycle

Ranked

Actors

Lifecycle

Turn-Based

Actors

Lifecycle

Idle

Actors

Lifecycle