Local Saving

Saving on the player's device: the built-in managers, and which to choose.

A persistence manager is what saves and loads a persistent object. You pick one from the dropdown at the top of the object's inspector, and can switch at any time without touching code. The package ships several local ones, plus two that save to a server or the cloud (see Cloud & Remote). To compare them all at a glance, see Which manager should I pick?.

Open manager dropdown
Every built-in manager, chosen per object

Prototype

The zero-configuration manager, and the recommended starting point. It is also what new persistent objects are assigned by default (changeable in Settings). It writes one save file per object under the platform's persistent data path, on desktop, mobile and WebGL, with nothing to configure. It is synchronous and dependency-free.

  • No settings: auto load, auto save and the regular save timer are all on and fixed.
  • Editor-safe: in the editor its saves live in the project's UserSettings folder, so play mode never clobbers the saves of an installed build of your game.
  • When to move on: switch to Local File the moment you want compression, encryption, backups, a custom file name, or async saving.
Consoles gate saving behind their platform SDK, so they are not covered by Prototype: there you write a small custom manager (see Extending).

Local File

The full-featured local manager: it saves to files on the player's device and exposes every knob you are likely to want. It supports both synchronous and asynchronous operations.

Local File manager inspector
Local File: the configurable local manager
  • File Name: override the file name and optionally place it in subfolders (no extension).
  • Compression: None, Fast, or Optimal gzip.
  • Encryption: None, Append Hash (readable; a modified save still loads but is permanently marked as tampered, see FilePersistenceManager.IsTampered), or Encrypt (fully encrypted, modifications rejected). See the security guide.
  • Lock Save To: tie protected data to the machine, the file location, and/or a runtime secret your code provides (until it does, the data stays unloaded).
  • Header Text: a free line of text at the top of the file, written as a comment line starting with '#'. Players can edit the text or delete the whole line without breaking the save; leave it empty to write no header line at all.
  • Do Backup: keep a second copy as extra insurance on top of the atomic write, so even an unreadable or undecodable primary still has a fallback.
  • Auto Load / Auto Save / delays: full control over the automatic behavior and timing.
  • Read / Write Execution Mode: prefer synchronous or asynchronous. Under a Prefer mode the safe-point saves (on quit, unload, focus loss) still run synchronously; set Async Only and they run asynchronously too, where a save can fail if it overruns its timeout.

Compression, encryption and the related options also have practical guidance in Securing saves.

Player Prefs

Stores saves through Unity's PlayerPrefs. Synchronous, simple, and a good fit for small amounts of data (settings, a high score). It works on desktop, mobile and WebGL (consoles gate saving behind their platform SDK, so like the file managers it is not supported there). Every key it writes is prefixed so the package can recognize and clear them.

For larger or structured saves, prefer Local File: Player Prefs is not designed for big blobs and offers none of the file manager's protection or backup options.

Session (Memory)

Keeps saves in memory only, for the current session. Nothing is ever written to disk, so all data is gone when the game closes or you leave play mode, and each session starts empty. Saves and loads still go through the normal API.

Use it for state you want within a play session but never across them: a mid-level checkpoint to respawn from, or a run's progress in a game where quitting is meant to forfeit the run.

Test

A fake in-memory manager to test how your game behaves when persistence misbehaves, without touching a real save: force any operation to any outcome (a failed load, a cancelled save, an exception) and inject delays to simulate a slow server, then watch what your title screen, save indicator or error handling does. It is the easiest way to rehearse a slow or failed load before going remote.

Assigning it always keeps a read-only import copy of the setup it replaces, so its inspector restores your real setup in one click once you are done.

None

Selecting None opts the object out of persistence: it behaves like a plain ScriptableObject, with no saving or loading.

Deleting local data

To wipe local saves while developing (to retest the first-launch experience, for example), open Tools > Persistent Asset > Actions > Delete Local Data. It lists every manager that exposes local data and lets you delete one, or all of them.

Delete Local Data window
Tools > Persistent Asset > Actions > Delete Local Data
This deletes developer-side local data. To erase a player's save from your game's own code, use Clear() on the manager (or Persistence.ClearAll(), see Core Concepts).