Skip to main content

Overview

Cloud saves store one payload per slot, per player, per game. The payload is an opaque string — serialize your own state into it. The platform versions each write and applies it inside a server-side transaction.

Write a save

You do not supply a version. The server assigns the next one and returns it.

Read a save

success is false both when the read failed and when the slot has never been written, so treat it as “no save yet”.

Serializing state

Unity’s JsonUtility only handles serializable fields on concrete classes — no dictionaries, no polymorphism. For nested or dynamic state, either flatten it into a serializable class or bring your own JSON library.

Multiple slots

Slots are independent. Use them to separate state that changes at different rates, so a settings write cannot clobber progress.

Concurrency

Two sessions writing the same slot cannot corrupt each other — writes are transactional and the later one wins with a higher version. The SDK has no merge callback. If your game can realistically run in two tabs at once and last-write-wins is not acceptable, read immediately before writing and merge in your own code.

Rules

  • Keep each slot under 500 KB
  • Never store payment details or auth tokens in a save
  • Save at natural checkpoints, not every frame — each write is a network round trip
  • Keep unsaved state in memory when a write fails, and retry rather than dropping progress