Interaction Engine Documentation

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.

Use this page after reading: Save and Persistence and Multiplayer. This chapter does not replace those references; it explains how to combine them safely in a networked project.

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

  1. Pause or gate gameplay actions if your game allows saving during active interactions.
  2. On the authority side, create or load your InteractionEngineSaveGame object.
  3. Call Store All Interactable Snapshots to capture registered interactable actors.
  4. Call Store All Foliage Proxy Snapshots to capture world-level foliage proxy and hidden source state.
  5. Write the save object using your project save system.
  6. On load, restore world/streaming state first when applicable.
  7. Call Restore All Interactable Snapshots.
  8. Call Restore All Foliage Proxy Snapshots.
  9. 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_LocalOnlyNoPlay local animation, sound, UI highlight, or other temporary feedback.
OnInteractionStarted_ConfirmedUsually noStart confirmed gameplay presentation if needed.
OnInteractionCompleted_ConfirmedYes, if it changes world stateUnlock, consume, harvest, open, reward, or mark persistent completion.
OnHitConfirmedYes, if the damage changes persistent statePersist damaged or depleted resource state through the interactable snapshot path.
SlotRuntimeStatesCaptured through snapshotsUse 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.

  • Use world-level foliage snapshots. Prefer Store All Foliage Proxy Snapshots and Restore All Foliage Proxy Snapshots for networked projects.
  • Restore on the server. Let restored proxy/source visibility and interactable state replicate to clients.
  • Account for streaming. If the source foliage component is not loaded yet, restore may need to defer until the relevant level or world partition cell is available.
  • Save after authoritative lifecycle decisions. If a tree fall animation, regrowth timer, or proxy hide/show decision is still pending, save only once the authority-side state is coherent.
  • 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

  • Save from authority. The server should capture final interaction state, especially for contested targets and foliage proxies.
  • Restore before players interact. Restore persistent interaction state before clients can start interacting with the loaded world.
  • Test remote clients. Verify that a client can trigger an interaction, the server confirms it, the state saves, then the restored state appears correctly for all clients.
  • Do not replay confirmed events manually. Restore state through snapshots and let replicated state update clients. Do not fake completion events on clients to simulate loaded state.
  • Separate gameplay from UI. Persistent gameplay state belongs on the interactable/proxy/save data path. Widget rows, progress bars, and glyphs are presentation.
  • 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
    Rule of thumb: if the state affects rewards, inventory, doors, harvested resources, destroyed objects, cooldowns, or respawn timing, it should be confirmed and saved by the authority side.