A single-player save can pretend the local process is the whole truth. A persistent multiplayer game cannot. The moment Ashes of the Unbound gained a dedicated server, every convenient assumption about identity, ownership and saving had to become explicit.
The goal for this phase was not “multiplayer works” in the broad promotional sense. It was narrower and more useful: the server owns durable world state, players have durable identities beyond one connection, and reconnecting does not silently create a different person.
That turned a game feature into a small distributed-systems project.
Server-authoritative saves
The first rule is simple: clients do not decide what becomes history.
They can request actions and present local feedback, but authoritative state belongs to the dedicated server. Save operations therefore run through server-owned persistence. The runtime systems contribute versioned chunks in a defined order, and restoration applies those chunks through the same ownership boundaries.
Ordering matters. A character cannot restore a derived system before the base state it depends on exists. A factory graph cannot safely reappear while its referenced definitions are unavailable. Treating a save as “serialize every object we can find” hides these dependencies until a restore fails.
An ordered chunk protocol makes them part of the format.
Persistent player identity
A network connection is temporary. A session membership is temporary. The player behind both needs a stable identity if progression, appearance and ownership are supposed to survive.
EOS supplied the identity and session layer, but integrating it still required separating several things that are easy to collapse during a prototype: platform identity, authenticated product user identity, the active game session, the live connection and the persistent player record.
They often correlate. They are not interchangeable.
That difference becomes visible immediately on reconnect. If saved state is keyed to a transient connection, the returning player is new. If session presence is treated as identity, moving between sessions can orphan progression. If a display name becomes the durable key, changing it becomes a data migration.
The server needs to resolve the live connection to the stable identity and only then attach durable state.
Authentication, admission and restoration
Connection security was part of the same work. The server and client establish encrypted transport using AES-GCM, and the join path carries enough verified context to associate the connection with the correct player state. The useful part is not the cipher name; it is that authentication, session admission and state restoration happen as distinct stages.
A failure in one stage should not be reported as a vague inability to join. It should be possible to tell whether the client failed to authenticate, could not resolve a session, was rejected during admission or connected successfully but failed during restoration.
Those distinctions are what make a server operable later.
Replicating and saving player appearance
Per-player appearance was a good early test because it crosses nearly every boundary without being the most dangerous data in the game.
The choice begins on one client, travels through server authority, replicates to other players and must return after reconnect. If another client sees the wrong appearance, replication or ownership is wrong. If it looks correct until the server restarts, persistence is wrong. If the owner sees a local choice that nobody else sees, the client has confused prediction with authority.
It is a small feature with excellent diagnostic reach.
Dedicated-server administration
The dedicated server also gained a separate administration application built with Tauri, Vue and Rust. I did not want server operation to depend on opening the Unreal editor or attaching an interactive client with special powers.
That application creates another boundary: operational controls can talk to the server’s administrative surface without being compiled into the game client. It is early infrastructure, but the separation matters. Player capabilities and operator capabilities should never be the same interface with a hidden button.
What was working by 17 April
By 17 April, the server-side arc included authoritative saving, EOS-backed identity and sessions, encrypted connections, per-player appearance and the administration application. That does not mean persistence was finished forever. Later planetary work would expose coordinate data that the first restore payload could not represent durably enough.
It does mean the ownership model was established. The server decides durable truth. Identity outlives the connection. Systems provide explicit save chunks. Administration lives outside the player client.
Those decisions made later failures diagnosable rather than mysterious. When a player eventually restored on another moon and moved in the wrong frame, I could inspect the coordinate contract instead of first asking whether the client had been allowed to invent its own state.
Before reaching space, though, the project needed a visual language for all of these systems. That work became Giving Ashes of the Unbound a Visual Language.