Concept: Supported Session Types

This save system is built for a co-op-shaped game: one authoritative machine running a world, and up to a handful of players in it. Single player, a listen server where the host plays, a dedicated server, and splitscreen on one machine all work with the same code and the same files. Nothing needs to be swapped out between them.

The four supported session shapes. The filled box is the machine with network authority; outlined boxes are clients.

The one rule

Authority owns the world and everyone's progression

Whoever is authoritative writes the World data and every player's Player data. A client writes only its own Profile. That single sentence is the whole model, and it is the same in all four shapes below - what changes between them is only which machine is authoritative and whether it also happens to have a player sitting at it.

The four shapes

Session	Authoritative	Writes World	Writes each player's Player data	Notes
Single player / Standalone	The one machine	Yes	Yes (one player)	No net driver. Identity comes from the local profile store.
Listen server	The host	Yes	Yes, for the host and every client	The host is a server AND a player, so it does both jobs at once.
Dedicated server	The server	Yes	Yes, for every client	The server has no local player, so it never writes a Profile of its own.
Splitscreen / couch co-op	The one machine	Yes	Yes, one set per local player	Each local player gets its own profile id from the local store, keyed by controller id.

What a client is allowed to write

Exactly one thing: its own Profile. A profile belongs to the machine it is on, so a client saving its own character writes nothing the host owns. Everything else - world state, and that player's progression inside the host's slot - is written by the authority, because that is the only machine that has the authoritative copy to write.

Not supported by design

Clients cannot save world or player state; those calls are refused and logged, not silently ignored. There is no shared backend database and no MMO-scale player count. A profile does not follow a player between machines unless they are signed in to a real platform account - an offline profile id lives on the machine that created it. If you need a service API behind any of this, that is a storage provider, not a change to the save system.

Testing each shape in PIE

The editor can reproduce three of the four directly. Test the shape you actually ship - a bug that only appears once a second player connects will not show up in Play Standalone.

PIE mode	Reproduces	Worth checking
Play Standalone	Single player	One profile id, reused on every relaunch.
Play as Listen Server	Listen server	Host and client get different profile ids and separate Player folders.
Play as Client	Dedicated server	The client's data lands under its own profile id, not the server's.
Number of Players > 1, no net mode	Splitscreen	One profile id per local player index.

PIE and a packaged build address saves identically

Both resolve a profile id out of the same local store; only the index differs (PIE instance in the editor, controller id in a build). A save made in PIE is addressed the same way it would be in a shipping build, so what you test is what you ship.