Game Dev · July 6, 2026
Cloud Saves and Cross-Platform Sync for Indie Games: What Breaks and Why
Cloud save sync is one of those features that looks trivial in a design doc and turns out to have a genuinely hard distributed-systems problem hiding inside it: what happens when two devices both have unsynced progress.
Published July 6, 2026
The pitch for cloud saves is simple: play on a desktop, pick up the same save on a laptop or a Steam Deck, progress carries over. The implementation is not simple, because the naive version — upload the save file on close, download the newest one on open — has an obvious failure mode. A player closes the game on device A without full network connectivity, plays a session on device B, and then reopens device A later with connectivity restored. Whichever device syncs last silently overwrites real, unrecoverable progress from the other one, and the player finds out only after it is too late to recover it.
Timestamps alone are not enough
A common first attempt at conflict resolution compares the local and cloud save's last-modified timestamps and keeps the newer one. This works for the common case but fails silently for the scenario above, and it also breaks entirely if a player's system clock is wrong, which happens more often than developers expect, particularly on handheld devices that sometimes lose clock sync during sleep. A more robust approach tracks a monotonic save version counter inside the save file itself, incremented on every write regardless of wall-clock time, so version comparison never depends on the local device's clock being correct.
When conflict resolution should ask the player
Automatic resolution works fine when one save is a strict superset of the other — same stage progress, one just has more score or more recent unlocks. It does not work when the two saves have genuinely diverged, for example if a player unlocked a different set of achievements or reached a different stage on each device during the disconnected period. In that case, silently picking one save and discarding the other is a worse outcome than surfacing a simple choice to the player: "Cloud save and local save have diverged, choose which to keep," with a short summary of what each contains (stage reached, playtime, last played date). This is more honest than a fully automatic resolution and costs one UI screen that most players will see rarely, if ever.
How this interacts with local save/continue systems
Cloud sync sits on top of, not instead of, the local save and continue mechanics covered in save states and continue systems in shmups. The local save remains the source of truth during an active play session; cloud sync only reads from and writes to it at session boundaries — game launch and game close, plus periodic background syncs if the platform supports them. Treating cloud storage as a live, continuously-written store rather than a periodic snapshot of the local save invites far more conflict scenarios than it prevents, since every intermediate write becomes a potential sync point that needs its own conflict handling.
What platform APIs actually promise
It is worth reading platform cloud save documentation closely rather than assuming behavior, since guarantees vary meaningfully: some platforms handle conflict detection and expose it to your game, others silently pick the most recently modified file with no hooks for custom resolution at all. This variance is the same category of surprise covered in porting an indie shmup to consoles, where a feature that works one way on one platform behaves completely differently on another despite an apparently similar API surface. The Steam Cloud documentation is a reasonable starting reference for the PC side of this problem, though console platforms each have their own separate guarantees worth checking individually before assuming parity.
File size and sync frequency limits
Most platform cloud storage quotas per title are modest, often in the low tens of megabytes, which is rarely a problem for a save file consisting of progress flags, high scores, and settings, but becomes a real constraint the moment a project adds anything heavier, such as stored replay data for the deterministic playback system discussed elsewhere on this site. A save file that grows without bound — appending a new replay entry every run instead of capping the stored history — will eventually hit the platform's quota and start failing silently unless the failure is explicitly surfaced to the player. Capping stored history to a fixed number of entries, and pruning the oldest first, keeps the save file bounded regardless of how long a player has owned the game.
Testing sync behavior deliberately
Cloud sync bugs are notoriously hard to catch in normal development, since a single developer testing on one machine rarely reproduces the multi-device conditions that trigger conflicts. Deliberately testing with two devices, artificially disconnecting one mid-session, making progress on the other, then reconnecting the first, should be a standard pre-release test case rather than something discovered through player bug reports after launch. A short, repeatable manual test script covering disconnect-then-diverge, simultaneous launch on two devices, and a forced quota-exceeded scenario catches the overwhelming majority of real-world sync failures before they reach players.