This page explains how to integrate Play Games Services Sign In with your existing identity or cloud save solution. Even though these recommendations are optional, they can help you complete the cloud save requirements for Google Play Games on PC. Use the continuity requirements and expected behaviors pages to verify that your implementation satisfies these requirements.
Restore player state
In your game’s backend, game accounts are likely represented by some identifier that lets you fetch and update their progress within your game. We will call this your account ID for short. When a player signs in to Play Games Services, you can use that authentication to get a new identifier, the Play Games Services Player ID, which is used to power the cloud save requirement.
When a player logs in with Play Games Services, you should continue as follows:
- Retrieve the OAuth code from the client, and send it to your server.
- Exchange the authentication token and get a verified Play Games Services ID from the Play Games Server. This ensures that the id is trusted and not someone pretending to be another player by using a compromised device.
- Attempt to resolve a game account based on the conditions of the device and any linked identifiers.
Two main new scenarios need to be introduced into your game:
- Storing Play Games Services IDs on your backend and assigning them to
existing account IDs in some way, such as the following:
- For new players, the progress should be automatically linked to Play Games Services at some point. (e.g. at game launch, after the tutorial or some number of levels, etc.).
- For existing players, the current progress should be automatically linked to Play Games Services after the player updates to a version of your game with Play Games Services V2 integrated.
- The Play Games Services ID can be linked with one or more accounts, and Play Games Services can be de-linked from those accounts, but it should be linked to at least one valid account.
- Automatically restoring game progress on a signed out/new device based on the Play Games Services Player ID.
How you store and assign Play Games Services IDs to existing accounts is flexible, as outlined in the examples below. The main requirements to keep in mind are that the player should not have to manually sign in or create a link with another identity system in order to create a link between their Play Games Services ID and game progress, and that player progress should be seamlessly restored across surfaces.
When designing your solution, start by looking at your existing system and how it incorporates different identity providers. Some systems use a single identifier per account, while others use multiple identifiers per account.
If you can only associate each account ID with a single identifier, you’ll need to add support to associate Play Games Services with it. The following solutions demonstrate how to do this.
Example Solutions
The example solutions include binding and recall solutions.
Binding is the process of permanently or semi permanently linking the Play Games Services ID to an account state. In the case of binding, the underlying account that is restored through Play Games Services doesn’t change for the player without their action, even if they log out and log in with another account within your game. We cover this here with account binding.
With recall, you as the game developer store a loose mapping of Play Games Services ID and last seen account(s) for the player to restore when they sign in with Play Games Services on another device. Each time the player logs in to another game account with the same Play Games Services ID, this binding changes. Here’s an example flowchart, which we cover more in the recall recent accounts example below:
More user flow examples are attached to the solutions below.
Account binding
If your game doesn’t have a lot of multi-account players, or if you like to encourage gamers to have a single account within your game, then binding is likely the best solution for your game. In this example, you bind the first account seen while signed in with Play Games Services (whether a guest account or one bound with another identity platform as well) with the Play Games Services Player ID. After this binding, that bound account is restored on new devices automatically. Since we’re doing a strong binding, the player can also switch Play Games Services profiles to change accounts within the game, and you can prompt the player to confirm in this scenario.
If there are conflicting accounts, we recommend that you ask the player to choose an account. These conflicting cases should only happen to players that have multiple accounts in your game, and so they likely have the knowledge and desire to play with a specific account.
Once the account has been resolved, your game should remember the player's choice unless there is a change in sign in identifiers. If the Play Games Services profile is changed, or the player logs in to a different identifier within the game, then the above steps should be repeated as the player has given a strong signal that they desire a change in accounts.
Unbinding
If you’d like to offer the player the ability to completely control their bindings, you can offer the player the ability to unbind their Play Games Services Player ID with a game account. This could be important to some multi-account players, if they accidentally bound their Play Games Services Player ID with an account that isn’t their main account.
Additional account binding examples
This main example shows that a given Play Games Services Player ID (1) is bound to the first in-game account that is seen (A) and not rebound when the player logs out of their game progress to play on another account.
You can optionally allow players to rebind their account, but it is not required.
Switching accounts on device
Here, the player has switched Play Games Services accounts manually, and so has given the game a strong signal that they want to change their in-game account to another account. Reacting to this change is what the player desires; taking this signal into consideration leads to a better player experience.
Existing bound account with another identifier
This example shows that even accounts bound to non Play Games Services identifiers should be bound to Play Games Services and then restored on new devices. Most existing players of your game with accounts will fall into this category.
Recall recent accounts
When thinking about solutions, one thing that will often come up is the multi-account experience. If your game incentivises power users to create many accounts (such as gacha games or choose your own adventure games), then binding the Play Games Services Player ID to a single account might not provide the best player experience when moving across devices.
In the recall solution, you store a loose mapping of a Play Games Services Player ID and in-game account, and the player simply sees the last accounts you’ve stored when switching devices or when logged out.
In this example, a player owns three accounts for a game, and then moves to a new device:
When you prompt the player to restore, you can also offer a “cancel” or “create new” button for players to select to create a new account.
For simplicity, your game could choose to only recall the last seen account. This may be more difficult for the multi-account switching use case, but still meets the continuity requirement.
Additional recall examples
The following section includes additional examples using recall.
Non-Android phones
Here we illustrate both recalling accounts that already exist (3rd party account linked), or that were created from another non Play Games Services signed in device.
A more common flow may be starting from a non Android phone and moving to Google Play Games on PC.
Since the non Android phone does not have Play Games Services, there is no recall active, and the player has to manually type in their credentials from within Google Play Games on PC.
Multiple Play Games Services profiles for one account
Occasionally there might be multiple Play Games Services profiles active that have previously “recalled” a given account. For this case, there are two main solutions that would work equally well:
Save it anyways
We disregard duplicate pointers to a given account in the "Save it anyways" model.
Override it
In the "Override it" model, the developer needs to remember Play Games Services to
Account mappings and clear old mappings in their tables in the "Override it" model. By doing so, they can
keep a clean 1:1 mapping of recalled accounts and Play Games Services
accounts.
Same Device Recall
A multi-account player can use your recall implementation to quickly switch
between their game accounts too.