A save service, a session service, and netcode can all handle state or move information. That overlap makes it easy to ask the wrong question: “Which one should handle multiplayer?”
It helps to split the problem into three jobs: durable data, session coordination, and real-time game synchronization. A project may use one provider for more than one job, but the responsibilities remain distinct.
1. Durable data: what should remain after play?
This layer stores information that needs to survive a session: player preferences, saved progress, account-linked inventory, or results that matter across matches. Unity describes Cloud Save as a place for player and game data that can be accessed across devices. That is a persistence job; it does not, by itself, decide what a player is allowed to earn or equip.
For every important write, ask two questions:
- Does this need to persist beyond the current session?
- Who is allowed to write it, and what must be checked first?
A player changing a sound preference may be a low-risk write. A competitive reward or paid entitlement can require a stronger authority and review path. The right enforcement depends on the game and the service configuration. A database rule or cloud function is a tool for enforcing a rule; it is not proof that the rule is complete.
2. Session coordination: who is playing together?
Before a match starts, a game may need to create a session, let players join, keep track of membership, or share connection details. Those tasks help players meet and connect. They do not automatically simulate the match.
Unity's Multiplayer Sessions documentation describes sessions as a coordination point for connected players and connection setup. Unity's Sessions building block documentation explicitly separates sessions from gameplay synchronization. This is a useful boundary: a lobby can say who is in a match, while a networking and game-simulation design determines how the match proceeds.
3. Real-time synchronization: what must agree during play?
Movement, attacks, collisions, and other moment-to-moment actions belong to the active simulation and its networking model. Unity Netcode packages support real-time synchronized gameplay. Netcode moves or reconciles information among players. The game still needs a deliberate authority model: which machine or service decides the result, how clients predict or display it, and what happens when messages arrive late or out of order.
There is no single authority model for every Unity game. Unity documents both Netcode for GameObjects and Netcode for Entities. Its session connection options include direct and client-hosted connections, and allow custom network handlers. Pick based on the game's fairness needs, player count, target platforms, latency expectations, operating capacity, and budget.
Trace one player flow
Consider a match that awards a persistent reward:
- A session service helps the players find or join the match.
- The active game simulation processes inputs and determines what happened.
- If the reward matters to competition or an economy, the appropriate trusted authority checks the result.
- The accepted result is written to durable data so it remains available after the match.
In a casual local game, some of these responsibilities may be intentionally simpler. In a competitive or economy-driven game, they may need stronger separation. The important point is to choose that boundary deliberately instead of assuming that “the backend” or “the network” handles everything.
A quick responsibility checklist
For one player action, write down:
| Question | Likely responsibility |
|---|---|
| Must this value survive a session or device change? | Durable data / backend |
| Does it describe who is in a match or how they connect? | Session coordination |
| Must it be synchronized while the match is actively running? | Networking and game simulation |
| Could a modified client gain an unfair or valuable result by changing it? | Define a trusted validation authority |
| What happens after disconnect, retry, or duplicate submission? | Specify behavior across the responsible layers |
These are prompts, not a drop-in architecture. Some features cross layers: a match result may be produced by the simulation, validated by an authority, and then saved by a backend. Name each handoff in the design.
Keep the boundaries visible
The backend is not automatically your real-time netcode. A lobby or session is not the match simulation. Replicating an object does not automatically validate a reward. And adding a server does not, by itself, make every game rule secure.
Before choosing services, sketch one flow from player input to the state other players or future sessions will see. Mark who owns each decision and what should happen when a step fails. That small map usually exposes missing responsibilities earlier than comparing long feature lists.
References
- Unity Cloud Save
- Introduction to Multiplayer Sessions
- Multiplayer Sessions building block
- Unity's Netcode packages
- Network connection options
ShipIt builds tools for Unity developers. Website
Top comments (0)