Planning a multiplayer game: what belongs to the client, server, backend and operations

Why "add multiplayer" is not one task

When a studio asks for multiplayer, the request usually sounds like a single feature. In practice it is a set of separate responsibility areas that run in different places, fail in different ways and are often owned by different people:

• the game client on the player's machine;
• the real-time game server that runs the match;
• the application backend that handles everything around the match;
• operations: building, deploying, observing and updating all of the above.

Most scope surprises in online projects come from the gaps between these areas, not from the areas themselves. Nobody decided whether the server or the client validates a hit, who allocates a server when a match starts, or what happens to a running match when a new build is released. This article goes through the four areas one by one, gives you a responsibility matrix you can reuse in your own planning, and ends with the decisions to clarify before you ask anyone for an estimate.

The game client: input, presentation and feedback

The client's job is to make the game feel immediate to one player. It reads input, renders the world, plays audio and effects, and shows the player what is happening. In an online game it also sends the player's intentions to the server and turns the server's updates back into a smooth picture.

What the client should not be is the final judge of anything that matters to other players. Damage, scores, inventory changes and match results are easy to manipulate on a machine you do not control. The usual rule is that the client proposes and the server decides.

Prediction is the main exception, and it should be a deliberate choice rather than a default. In fast action games, waiting for a server round trip before moving the player's own character or showing a shot feels sluggish, so the client simulates those actions locally and corrects itself when the authoritative result arrives. That correction step, reconciliation, is where much of the netcode complexity sits. A slower turn-based or co-op game may not need prediction at all. As a reference point, in VOXSYS, a competitive mobile VR shooter built by current Sourcegarden Studio team members in their previous VR Storm Studio roles, a client-predicted multiplayer framework was used to reduce perceived latency in combat.

Typical client responsibilities:

• input capture and sending player intentions to the server;
• rendering, audio, UI and immediate feedback;
• prediction and reconciliation for the actions that must feel instant;
• interpolation of other players and objects between server updates;
• clear handling of connection states: connecting, loading, disconnected, version mismatch.

The real-time game server: authority and simulation

The real-time server owns the truth of the match while it runs. It receives player inputs, runs the simulation, applies the game rules, and replicates the resulting state to every connected client.

Four questions define this layer:

• Authority. Which system decides each piece of state: movement, hits, pickups, world changes? Authority can differ per system, and it should be written down for each one.
• Simulation. What does the server have to simulate itself, and at what update rate? A shooter with physics and a mutable world asks far more of the server than a card game.
• Replication. What state is sent to which clients, how often, and in what budget? Bandwidth and update budgets are design constraints, not implementation details.
• Rule validation. Which client requests are checked before they are applied, and what happens when a check fails?

A common architectural choice here is between a dedicated server, a listen server (one player hosts) and a relay. Dedicated servers give the clearest authority model and protect fairness, but they bring a server build, hosting and operations work with them. That trade-off should be made explicitly at the start, because it changes the scope of every other area.

The application backend: only what the product needs

The backend is the set of services around the match: how a player gets into a game, and what survives after it ends. This is where scope tends to grow without anyone noticing, so start from what the product actually needs rather than from a list of everything an online game could have.

Areas a backend may cover:

• Identity: whether players need accounts at all, or whether a platform identity is enough.
• Session workflow: finding or creating a session, parties or lobbies, server allocation, and handing the client a server address and connection details.
• Persistence: which data must outlive a match: progression, inventory, settings, match results.
• Integrations: platform services, analytics or third-party backend platforms.

Each of these carries its own security, data-protection and maintenance responsibilities. Where a proven platform service already covers part of the flow, integrating it is usually cheaper than rebuilding it; custom services make sense where the game genuinely needs them. A prototype may need nothing more than a way to start a server and connect to it. If your main open question is how big this layer should be, our separate guide on scoping a game backend before an estimate goes deeper, and the game backend development page describes how we approach these services.

Operations: deployment, observability and failure handling

A dedicated server that runs on a developer's machine is not yet something a team can operate. Operations is the work that makes every other layer reproducible and visible:

• Build and deployment: an automated server build, a container or image, configuration per environment, and a repeatable way to start and stop servers.
• Observability: structured logs, metrics and health signals around sessions, server processes and service calls, so a player report can be traced to a cause.
• Version compatibility: a rule for which client builds may connect to which server builds, and a rollout process that does not break matches that are already running.
• Failure handling: graceful shutdown, reconnect behavior, full servers, crashed processes and failed service calls, each with defined behavior.
• Capacity and cost: documented assumptions about how many matches a server can host and what drives the infrastructure bill, measured rather than guessed.

Operations is easy to postpone because nothing in the first playable build needs it. It is also the area most likely to be missing from an estimate.

A responsibility matrix you can reuse

The table below is a starting template. The owner column names a role, not a headcount: in a small team one engineer may hold several roles, which is fine as long as the interfaces between the areas are still explicit.

If you cannot fill in a cell, that is usually the first thing to clarify, not something to leave for later.

The same architecture as a flow

Read as a sequence, the areas connect like this:

1. The player starts the client. If the game needs it, the client identifies the player through the backend or the platform.
2. The client asks the backend for a session. The backend finds or allocates a game server and returns its address and connection details.
3. The client connects to the game server, which checks version compatibility before admitting the player.
4. During the match the client sends inputs, the server simulates and validates them, and replicates state back. The client predicts only what was agreed.
5. When the match ends, the server reports the result to the backend, which persists whatever must survive.
6. Throughout, every layer emits logs, metrics and health signals that operations uses to deploy, monitor and update the system.

Questions that shape the technical design

The right architecture follows from a handful of product decisions. These are worth answering, even approximately, before the first technical meeting:

None of these needs a final answer to start. They do need a stated assumption, because an estimate is only as stable as the assumptions written next to it.

Example: how Bad Goons separates its systems

Bad Goons is Sourcegarden Studio's current original IP: a team-based PC shooter on a voxel battlefield that players dig, destroy and rebuild during a match. It is in active development, and the 64-player figure associated with it is a design target, not a measured capacity.

Its architecture treats the areas above as explicit production systems:

• Client: a Unity 6 game client.
• Real-time layer: FishNet as the networking framework, with prediction and reconciliation.
• Simulation: a voxel simulation whose world modifications must be synchronized to every player, one of the reasons authority sits on the server.
• Servers: authoritative dedicated servers running Unity headless builds on Linux.
• Operations: containerized deployment, with capacity, shutdown, health, logs and version rollout treated as game-facing concerns, because infrastructure behavior directly affects active matches and the ability to diagnose player reports.

The point of the example is not the specific stack. FishNet was chosen for this game; another game, platform or team may justify a different framework. The point is that each boundary is explicit, so the client, the server and the deployment can be built, tested and changed separately.

Buyer checklist: decisions to clarify before an estimate

Bring these answers, or your best current assumptions, to the first conversation with a multiplayer partner:

• Game mode and session model: co-op, competitive or persistent; match length; how players get into a match.
• Players per session as a design target, and an expected range of concurrent players if you have one.
• Authority model: dedicated server, listen server or relay, and which actions must be server-validated.
• Prediction: which player actions must feel instant, and which can wait for the server.
• Regions and latency expectations for your target audience.
• Platforms and whether crossplay is required.
• Engine and current codebase: engine version, existing networking framework, and whether the game was built with multiplayer in mind.
• Backend needs: identity, sessions or lobbies, persistence, integrations, and any platform service already in use.
• Operations ownership: who owns the hosting accounts, who deploys, who is alerted when a server fails, and whether support after handover is expected.
• Version policy: how client and server versions must match and how updates reach live matches.
• Handover expectations: which documents, builds and runbooks your team needs to own the result.
• Timeline, milestones and budget range, including what the first milestone must prove.

If several of these are still open, a focused architecture assessment or risk prototype is often a better first step than a full production estimate. That is the kind of work we scope through our multiplayer game development service.