Quick answer: System Save serializes the whole game state, but objects with “No Save” behavior (or on no-save layers) are skipped. For selective saves, write the data to a JSON/dictionary yourself.

After System Load, some enemies’ instance variables are wrong or reset. Those objects had the No Save behavior, or the save approach doesn’t cover runtime-created instances cleanly.

System Save Is All-or-Nothing

The System Save action snapshots the entire layout: every instance, variable, behavior state. System Load restores it exactly. It’s powerful but coarse.

The No Save Behavior

Any object with the No Save behavior is excluded from System Save. If you added it to suppress UI/transient objects, gameplay objects that share that object type get skipped too. Check which objects have it.

Manual Save for Control

For selective, version-tolerant saves, build the data yourself:

For each Enemy:
    Add to JSON: {
      "uid": Enemy.UID,
      "x": Enemy.X, "y": Enemy.Y,
      "hp": Enemy.hp, "state": Enemy.state
    }
→ LocalStorage: Set "save" to JSON.ToString

On load, iterate the JSON, create instances, and set their variables. More work, but you control exactly what persists and it survives layout edits.

Runtime-Created Instances

System Save does capture runtime-created instances — as long as their object type is savable. The manual approach is only needed when you want partial saves or cross-version compatibility.

Verifying

Save mid-level, reload. Every enemy’s position, HP, and state restore correctly. Transient UI doesn’t leak into the save.

“System Save is whole-state. No Save objects are skipped — for selective persistence, serialize JSON yourself.”

For games that patch often, the manual JSON save is worth it — System Save snapshots can break when you change the layout between versions.