Skip to content

Saved Games Examples

This section demonstrates practical examples of using Google Play Games Services Saved Games (Snapshots) in Unreal Engine projects. All examples assume that the player is already signed in to Google Play Games Services and that Saved Games are enabled for the game in the Google Play Console.

Saved Games allow you to store game progress in the cloud and automatically synchronize it across devices.


Basic Usage Flow

A typical saved games flow in a game looks like this:

  • The player signs in to Google Play Games Services.
  • Game progress is saved to the cloud at key moments.
  • Progress is loaded when the game starts or when the player resumes.
  • Conflicts are resolved if local and cloud versions differ.
  • Optional UI is provided to let the player manage save slots manually.

Important Concepts

SaveGame Object Ownership

All Saved Games operations work with a developer-defined USaveGame class.

  • Save Game uploads an already created and populated USaveGame object to Google Play Games cloud storage.
  • Load Game returns a USaveGame object that must be cast back to your specific save class.
  • The plugin does not create, modify, or interpret save data automatically.

You are fully responsible for defining the save structure and keeping it compatible between versions.

Conflict Resolution Overview

Saved Games conflicts occur when both local and cloud versions of a save exist and cannot be automatically merged.

Google Play Games Services supports automatic and manual conflict resolution.

Automatic Conflict Resolution

Automatic conflict resolution is enabled by selecting a conflict policy other than Manual when calling Save Game or Load Game.

Available automatic policies:

  • Longest Playtime – selects the save with the highest PlayedTimeMillis.
  • Highest Progress – selects the save with the highest ProgressValue.
  • Most Recently Modified – selects the most recently updated snapshot.
  • Last Known Good – selects the last known stable snapshot.

To use automatic conflict resolution correctly:

  • You must explicitly manage and update PlayedTimeMillis and ProgressValue.
  • These values are not updated automatically by the plugin.
  • Incorrect or static values will lead to incorrect conflict resolution.

Automatic resolution is recommended for most games, provided these values are properly maintained.

Manual Conflict Resolution

If Manual conflict policy is selected, conflicts are reported back to the game.

When a conflict occurs:

You must then explicitly resolve the conflict using Resolve Saved Game Conflict.

Resolving Conflicts Manually

To resolve a conflict manually:

  • Decide whether to use the local version, remote version, or custom data.
  • Call Resolve Saved Game Conflict with:
  • ConflictID
  • Selected resolve strategy
  • Optional custom USaveGame object
  • Updated Description, PlayedTimeMillis, and ProgressValue

The result is returned via success or failure callbacks.

Manual resolution gives full control and is useful for complex progression logic, version migrations, or custom merge strategies.

Summary

  • Saved Games always operate on developer-defined USaveGame objects.
  • Automatic conflict resolution is simple but requires correct metadata management.
  • Manual conflict resolution provides full control and must be explicitly handled.
  • Incorrect conflict handling can result in data loss.

Use this module carefully and test all conflict scenarios thoroughly.


Saving Game Progress

Saving a game uploads a serialized USaveGame object to Google Play Games cloud storage.

Example scenario: save progress when the player completes a level.

Typical usage pattern:

  • Create or update a USaveGame object.
  • Call Save Game with a unique SlotName.
  • Provide a human-readable Description for the save.
  • Pass PlayedTimeMillis and ProgressValue for conflict resolution.
  • Choose an appropriate EGooglePlaySavedGameConflictPolicy.

On success, On Success returns FGooglePlaySavedGameMetadata.

Calling Save Game multiple times for the same slot is safe and will overwrite the existing snapshot.


Loading a Saved Game

Loading a saved game retrieves cloud data and deserializes it into a USaveGame object.

Example scenario: load progress when the player starts the game.

Typical usage pattern:

  • Call Load Game with the target SlotName.
  • Select a conflict policy to handle mismatches automatically.
  • Use On Success to receive the loaded USaveGame object.

If a conflict occurs, On Conflict is triggered and returns an FGooglePlaySavedGameConflict structure.


Handling Save Conflicts

Save conflicts occur when the same save slot is modified both locally and in the cloud, for example when a player plays on multiple devices or offline.

Conflicts are reported only when using Manual conflict policy.

Basic Flow

Resolve Strategies

  • Use Local - keep local save.
  • Use Remote - keep cloud save.
  • Use Custom - provide your own merged USaveGame.

For Use Local and Use Remote, Custom Save Game must be empty.

Important Notes

  • You do not work with raw bytes directly.
  • The plugin automatically converts save data to and from USaveGame.
  • When resolving a conflict, always provide valid PlayedTimeMillis and ProgressValue, even if you simply choose local or remote.

This is sufficient for most projects and keeps conflict handling predictable and safe.


Showing the Saved Games UI

Google Play Games Services provides a native UI for managing save slots.

Example scenario: allow the player to manually select or manage saves.

Typical usage pattern:

  • Call Show Saved Games UI from a menu or pause screen.
  • Configure title, maximum saves, and add/delete permissions.
  • Use callbacks to detect selection, creation, cancellation, or failure.

The native UI is fully managed by Google Play Games Services and requires no additional setup.


Loading All Saved Games Metadata

If you need a list of all available save slots, load metadata without downloading full save data.

Example scenario: display a custom save selection screen.

Typical usage pattern:

  • Call Get All Saved Games.
  • Use the returned array of FGooglePlaySavedGameMetadata.
  • Display slot names, descriptions, timestamps, or device names.

Deleting a Saved Game

Saved games can be permanently removed from cloud storage.

Example scenario: delete a save slot from a custom UI.

Typical usage pattern:

  • Call Delete Game with the target SlotName.
  • Use callbacks to confirm success or handle errors.

Deletion is irreversible.


Important Notes and Common Mistakes

  • Saved Games must be enabled in the Google Play Console, or all operations will fail.
  • The player must be signed in before using any Saved Games API.
  • SlotName must be stable and consistent across sessions.
  • PlayedTimeMillis and ProgressValue strongly affect conflict resolution results.
  • Conflicts are normal and should be handled explicitly in production games.
  • Save data size and frequency should be kept reasonable.

These examples cover the most common Saved Games usage patterns and are sufficient for most games that require reliable cloud-based progress synchronization.