Save + multiplayer
Persist interaction state without breaking server authority.
Save/load and multiplayer should be designed together. In Interaction Engine, interaction results are server-authoritative, while prompts and prediction can run locally for responsiveness. This page is a production checklist for projects that need both persistence and replicated gameplay state.
Recommended authority model
| Stage | Recommended owner | Reason |
|---|---|---|
| Focus and prompt display | Local client | Keeps UI responsive and avoids unnecessary server work for purely presentational state. |
| Interaction prediction | Local client | Allows immediate feedback while waiting for the authoritative result. |
| Validation and completion | Server | Prevents clients from granting themselves rewards, consuming resources, or modifying shared world state. |
| Snapshot capture | Server or trusted single-player authority | Save data should represent authoritative state, not a predicted or stale client view. |
| Snapshot restore | Server | The restored state can then replicate normally to connected clients. |
Recommended multiplayer save flow
- Pause or gate gameplay actions if your game allows saving during active interactions.
- On the authority side, create or load your
InteractionEngineSaveGameobject. - Call
Store All Interactable Snapshotsto capture registered interactable actors. - Call
Store All Foliage Proxy Snapshotsto capture world-level foliage proxy and hidden source state. - Write the save object using your project save system.
- On load, restore world/streaming state first when applicable.
- Call
Restore All Interactable Snapshots. - Call
Restore All Foliage Proxy Snapshots. - Let replicated runtime state update clients instead of manually replaying client-only UI events.
Do not save predicted client state
Predicted local events are useful for responsiveness, but they are not authoritative. Do not persist data from OnInteractionPredicted_LocalOnly or from local-only UI state. Persist state after the server has accepted and confirmed the interaction.
| Event or state | Persist? | Recommended use |
|---|---|---|
OnInteractionPredicted_LocalOnly | No | Play local animation, sound, UI highlight, or other temporary feedback. |
OnInteractionStarted_Confirmed | Usually no | Start confirmed gameplay presentation if needed. |
OnInteractionCompleted_Confirmed | Yes, if it changes world state | Unlock, consume, harvest, open, reward, or mark persistent completion. |
OnHitConfirmed | Yes, if the damage changes persistent state | Persist damaged or depleted resource state through the interactable snapshot path. |
SlotRuntimeStates | Captured through snapshots | Use the plugin snapshot API instead of manually copying replicated runtime arrays. |
Foliage in multiplayer save games
Foliage persistence should use the world-level proxy snapshot path. The per-interactor foliage snapshot functions are kept for compatibility and specialized cases, but they are not the recommended primary path for shared multiplayer worlds.
Store All Foliage Proxy Snapshots and Restore All Foliage Proxy Snapshots for networked projects.
Common networked persistence cases
| Case | Recommended handling |
|---|---|
| Door opened by a client | Client may predict feedback, but the server confirms the interaction and the opened/completed state is saved through the interactable snapshot. |
| Two players try to use the same exclusive target | Server validation decides the winner. Only the confirmed result should affect persistent state. |
| Hold interaction interrupted before completion | Do not save predicted progress unless your game intentionally supports persistent partial progress. Most projects should save only confirmed runtime state. |
| Button mash progress | Use server-confirmed mash state for gameplay. Treat local mash UI as presentation. |
| Foliage harvested through a proxy | Save both the proxy/interactable state and source foliage hidden/restored state through world-level foliage proxy snapshots. |
| Respawning resource | Persist remaining respawn/regrowth timing if the design requires it, then restore on the server. |
Listen server and dedicated server notes
In a listen server session, the host is both a player and the authority. Avoid testing only as the host, because local host behavior can hide client prediction and replication issues. Always test the save/restore path from a remote client and verify that the server remains the only side that mutates persistent world state.
On a dedicated server, UI and prompt widgets do not exist. Save and restore logic should not depend on widget events, local focus state, or client-only notification widgets.
Validation checklist
Useful debug commands
ie.Debug.Net 1
ie.Debug.Transaction 1
ie.Debug.Validation 1
ie.Debug.SaveLoad 1
ie.Debug.Foliage.EventTrace 1
ie.Debug.FoliageProxy 1