Saving and spawned characters

Most scene authors can use Story Engine history through ordinary Game Creator saving. This page covers the choices that matter when a game has existing saves, renamed content or characters created during play.

Ordinary scene Rules

Each authored Rule has a stable identity stored in the scene or prefab. Its label is the name people see; the identity is what keeps history attached when that label changes.

Game Creator's save system includes Story Engine history. A Rule counts as played when its execution starts, rather than when every instruction finishes.

Previewing, finding no match, rejecting a busy request or stopping a loop does not record a new play. Scene reloads preserve history. Game Creator's Reset Game resets it for a new game.

Renaming published content

Changing a Rule's readable label keeps its identity. Replacing it with a newly created Rule creates different content with different history.

Category history uses category names. The Categories window updates authored references, but it does not migrate saved games that players already have. Before renaming a released category, plan a save migration or keep the old name.

Characters created during play

Two characters spawned from the same prefab start from the same authored Rule definitions. If they need separate, persistent memories, give each actor its own saved identity.

Use Story Engine > History > Set Story Actor Key before that actor can receive a Run Story Director request.

1. Choose the actor's root GameObject.
2. Read a saved, unique actor ID from a string property or variable.
3. Apply the key before any of that actor's Rules can run.
4. Reuse the same key when restoring or respawning the same actor after loading.

The instruction configures Rules below the chosen root, including inactive children. It does not generate or save actor IDs for you. Separate nested actors need their own keys and calls.

If your game does not yet have persistent actor IDs, work with the person responsible for spawning and saving. A temporary Unity instance ID or the actor's current spawn order is not a stable saved identity.

Two active copies need different actor keys

Do not assign the same actor key to two different active characters. Automatic collision repair can prevent an active conflict, but it does not establish a reliable identity for future saves.

Loading and resetting

Configure actor keys before loading history, or keep story requests paused until both actor setup and history loading have finished. Reassigning an actor to a different key changes which history it sees.

Story Insights' Remove Deleted Content keeps actor-keyed history because an actor may simply be unloaded. Reset that entry deliberately if you intend to remove its memory.

For a programmer on the team

The runtime namespace is StorySystem. Rule.SetHistoryInstanceKey(actorKey) provides the actor-key setup in code. StoryDirector.RunAsync returns the selection/execution result; a completed request is not always a played Rule.

The package's Docs/API_AND_PERSISTENCE.md describes the full integration contract, including callbacks, invalidation and asynchronous loop boundaries.