Which manager should I pick?

Start on Prototype and move when a concrete need appears: the choice is data on the asset, so switching later is a dropdown change, not a refactor. Each local manager is detailed in Local Saving, the two remote ones in Cloud & Remote.

ManagerWhere it savesBest for
Prototype One save file per object, managed for you. Starting out and prototyping: zero setup, works on desktop, mobile and WebGL.
Local File A file you configure: name, compression, encryption, backups. The usual choice for a shipped game: every option is there when a need appears.
Player Prefs Unity's PlayerPrefs. Small data: settings, a high score.
Session (Memory) Memory only; everything is gone when the game closes. State you want within a play session but never across them.
Server (HTTP) Your own server, through three simple HTTP routes. Saves that follow the player across devices, on a backend you control.
Cloud Save (UGS) Unity Gaming Services Cloud Save, per signed-in player. Cross-device saves without running a backend of your own.
Test Nowhere: every operation's outcome is forced by you. Rehearsing failed or slow persistence, temporarily.
None Nowhere: persistence is off. An object that should behave like a plain ScriptableObject.

With their default settings, the local managers have the data loaded before your code can touch the object, so you just read and write it. The two remote managers reach a server, so their data arrives asynchronously: gate once on await WhenReady in your boot flow. Some settings shift a local manager toward the remote behavior too (turning Auto Load off, an Async Only read mode, or Local File's Runtime Secret lock); when the data is ready explains the whole spectrum.

Consoles gate saving behind their platform SDK, so no built-in manager covers them: there you write a small custom manager against your console's SDK (see Extending).

Common surprises

  • My asset shows its default values again after I stop playing. Intentional: the editor restores your authored defaults at play-exit; the save still exists and reloads next launch. See Editor safety.
  • A field never saves. Only fields Unity serializes are persisted, the same rules as the inspector: public fields or [SerializeField] ones, with custom classes marked [Serializable]. A property, a static field, or a [NonSerialized] field is never saved. The rule of thumb: if it does not show in the inspector, it does not save.
  • A save is being ignored. A no-op result means one of: no slot selected (a multi-slot object without a slot), the object is IDirtyTracked and not dirty, the manager has not loaded yet (not ready), or a block hook vetoed it. The result's Message says which.
  • Data does not load, or loads as defaults. The read returned Invalid (no save yet, or unreadable, so the object kept its defaults) or Failure (temporarily unavailable, so it is still retrying). The manager's log shows which.
  • I changed a manager setting and an existing save is gone. Settings like the file name, compression, encryption or the serializer decide where and how the save is stored, so changing one points the manager at a fresh location. Nothing is deleted; the old save is stranded. Locking & migrating saves is the protection: lock the manager once players have it, and migrate through an import copy.
  • An error says two managers share a storage location. They would silently overwrite each other's saves there, so the editor refuses it and a build fails at start. It only happens with overridden names (Local File's File Name, the HTTP URL and Id, the Cloud Save Key): two managers ended up with the same one, so change one of them. See Identity & portability.
  • A manager or component does not appear (Cloud Save, a No-Code Input/Localization component). Each needs its Unity package installed: see optional modules.
  • A remote save never lands. The player is likely not authenticated yet or offline; IsReady stays false and the load keeps retrying. See Cloud & Remote.

Digging deeper

When the answers above do not settle it, the package tells you what actually happened:

  • The manager's Status section in the inspector: live state, the last operation's result, and a running log of every load, save and clear with its outcome and messages. See Debugging.
  • The In Game Logs Viewer: the same logs as an overlay in a running build or on a device.
  • The Unity console: warnings and errors carry a [Persistent Asset] prefix, so real problems surface even with no inspector open.

The deeper behavior questions (crash safety, concurrency, security, performance) are answered in the Technical Q&A. And if you are genuinely stuck, email justetools@gmail.com; a clear repro description gets a fast answer.