Cloud Saves

Overview

Cloud saves store one payload per slot, per player, per game. The payload is JSON text that you serialize yourself, usually with JsonUtility.ToJson. The platform versions each write and applies it inside a server-side transaction.

Cloud saves need a signed-in player. A guest has no platform session, so a guest’s save and load calls fail. Keep a guest’s progress locally and save it once the player signs in.

Write a save

var payload = JsonUtility.ToJson(new SaveState
{
    level = 12,
    coins = 1200
});

var saved = await SusaPlaySDK.CloudSave.Save("main", payload);

if (saved.Success)
{
    Debug.Log($"Saved as version {saved.Version}");
}

You do not supply a version. The SDK sends the slot’s last version, and the server returns the next one.

Read a save

var loaded = await SusaPlaySDK.CloudSave.Load("main");

if (loaded.Success && !string.IsNullOrEmpty(loaded.Data))
{
    var state = JsonUtility.FromJson<SaveState>(loaded.Data);
    ApplyProgress(state);
}
else if (loaded.Success)
{
    StartFreshGame(); // nothing saved in this slot yet
}
else
{
    Debug.LogWarning($"Load failed: {loaded.Error}");
}

A slot that has never been written is not a failure: Success is true, Data is empty and Version is 0. Success is false only when the read failed.

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. Whatever you use, the payload must be valid JSON.

[System.Serializable]
public class SaveState
{
    public int level;
    public int coins;
    public string[] inventory;
}

Multiple slots

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

await SusaPlaySDK.CloudSave.Save("progress", progressJson);
await SusaPlaySDK.CloudSave.Save("settings", settingsJson);

Concurrency

If another tab or device saved the slot first, the server refuses the write with 409 VERSION_CONFLICT. The SDK reads the slot’s new version and writes again, up to three attempts, so the last write wins. 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,000 characters. The server measures the JSON after re-serializing it, which can add a little, so leave headroom
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

See Saves for the full SaveResult and LoadResult reference.

Getting Started

Integration

SDK

API

Overview

Write a save

Read a save

Serializing state

Multiple slots

Concurrency

Rules

​Overview

​Write a save

​Read a save

​Serializing state

​Multiple slots

​Concurrency

​Rules

Overview

Write a save

Read a save

Serializing state

Multiple slots

Concurrency

Rules