# Save & Load

!!! note "Summary"
    **Save & Load** collects selected state from registered objects and assets, then writes that snapshot to disk. It restores only declared state rather than capturing the entire scene.

## How it fits together

![Remember component](assets/remember.jpg)

1. A **[Remember](remember.md)** component marks a game object as having state, and its **[Memories](memories.md)** select which aspects to capture.
2. Saving gathers subscriber data into a **snapshot** and writes it.
3. Loading reads the snapshot and returns each stored value to its subscriber.

!!! info "Global Variables register automatically"
    Visual Script subscribes **[Global Variables](../variables/global-variables.md)** to the save/load system at startup. The asset provides the same options as the **[Remember](remember.md)** component.

## Choosing what gets saved

Use **Remember** to select the state each game object contributes to a save.

Add it with `Add Component` → `Visual Script` → `Remember`, then select the aspects that matter. The options include position, name, destruction, and Local Variable contents.

For a chest whose open state is stored in a Local Variable, select the **Local Variable** Memory. For a movable crate, select **Transform**.

The full list is in [Memories](memories.md).

!!! tip "Only remember what matters"
    Each remembered object adds data to the save and work during loading. Scenery that never changes doesn't need a **Remember** component.

For Global Variables, enable saving in the asset itself; they don't need a **Remember** component.

## Profiles and shared data

Choose where each subscriber stores its data:

| Location | Holds |
| :--- | :--- |
| **Profile** | Belongs to one numbered save slot. Most game state goes here. |
| **Shared** | The same across every slot. Settings, unlocks, high scores. |

Profiles use numeric identifiers such as `0`, `1`, and `2`, with no fixed limit. A single-save game can use profile `0` throughout. See [Profiles](profiles.md).

## The Instructions

| Instruction | Does |
| :--- | :--- |
| **Save Profile** | Collects everything profile-scoped and writes it to a slot. |
| **Save Shared** | Writes only the shared data. |
| **Load Profile** | Restores a slot, loading the right scene first. |
| **Unload Profile** | Discards the loaded state and returns to a fresh game. |
| **Delete Profile** | Deletes the save file. |

These Conditions report save state:

| Condition | Asks |
| :--- | :--- |
| **Has Any Saved Game** | Is there any save at all? |
| **Has Saved Game** | Is there a save in this particular slot? |
| **Is Save Loaded** | Has a save been loaded this session? |

!!! info "Delete from the main menu"
    Deleting the loaded profile leaves the game running in a scene whose save no longer exists, and doesn't load another profile. Put **Delete Profile** on a screen where no profile is loaded, such as the main menu.

![Event with a check if a saved game exists and displays the Continue button](assets/event-continue.jpg)

Use these Conditions to gray out **Continue** when no saved game exists.

## Loading is more than reading

**Load Profile** does several things in order:

1. Reads the stored snapshot for that profile.
2. Loads the scene or scenes the save recorded, according to the [load policy](settings.md).
3. Restores every persistent subscriber, in priority order.
4. Restores the scene-bound objects as the scene comes up.

Because each step depends on the previous one, **Load Profile** exposes the process as one Instruction.

!!! warning "Loading can destroy the Event that started it"
    **Load Profile** waits for the asynchronous load before continuing. If loading destroys the Event's game object with the old scene, don't rely on that Event to run subsequent Instructions.

!!! warning "Scene Triggers can fire before saved state is restored"
    Loading first creates the scene in its authored state, then applies saved positions and values. During that interval, objects occupy their authored positions.

    That moment is long enough to fire a Trigger. A character whose authored position sits inside a trigger volume raises **On Trigger Enter** during loading, even when its saved position is elsewhere.

    Check the authored position when a physics Trigger fires during loading without visible movement.

## Ordering

Subscribers can declare a priority so that some are restored before others. This matters when one system's restore depends on another's already being in place.

For example, a system can restore a character's attributes before restoring the equipment that modifies them.

## Getting it right

!!! tip "Test saving when state is introduced"
    Add a **Remember** component when an object gains state that must persist. Verify a save across a full editor restart so missing state and unstable IDs are found before other systems depend on them.

Check these cases early:

- Does the state survive a **full editor restart**, rather than only a load within one session?
- Does a **duplicated** object still save correctly? See the note on IDs in [Remember](remember.md).
- Does anything **shared** remain unchanged when the player switches profiles?

## Try it

1. Add a **Remember** component with the **Transform** Memory to a cube.
2. Create one Event that saves to profile `0` on a key press, and another that loads it.
3. Enter Play mode, move the cube, and save. Move it again, then load and check that it returns to the saved position.
4. Exit Play mode, restart, and load again to check that the saved position survives between sessions.

The **Save & Load** [example scenes](../installation.md#installing-the-examples) provide a worked version.

## Where to go next

<div class="grid cards" markdown>

- **[Remember](remember.md)** — mark a game object as a save subscriber and assign its identity.
- **[Memories](memories.md)** — choose which aspects of the object are captured.
- **[Profiles](profiles.md)** — separate save slots from shared data.
- **[Save settings](settings.md)** — configure storage, serialization, encryption, and load policy.

</div>