Quality checklist for Google Play Games Services

1.1.1. Automatically sign players in when your game launches; use manual sign-in as a backup

Games should implement silent sign-in to help players get quickly authenticated and authorized to use the full set of features provided by the Google Play Games Services. If silent sign-in fails, your app should prompt players to sign in interactively. By using interactive sign-in, players can choose to sign into the game and Play Games ensures their profile is correctly configured for use in your game. Combining silent and interactive sign-in results in the highest sign-in rates with minimal user friction.

If the player chooses not to sign in, remember this and do not prompt the player again. Instead, provide a sign-in button. The sign-in button should be easy for players to find; for example, it should be accessible from your main screen or located in the Settings screen. This button should not be buried multiple levels deep in your game menu. Continue to try to automatically sign players in every time they start your game - they may change their preferences and automatically sign in.

If you are already requesting non-Play Games scopes, remove any unneeded scopes from your GoogleSignInOptions construction along with any APIs you no longer use. If you need to request other scopes (for example, if you want to see a user's email for marketing purposes), do so at a relevant time and not as part of the sign-in process.

// This is the proper way to do it
GoogleSignInOptions signInOption = GoogleSignInOptions.DEFAULT_GAMES_SIGN_IN;

After the player signs in successfully to your game, connect them automatically whenever your game starts, until the player explicitly signs out.

On Android devices, the Google Play Games 'Connecting' pop-up must be displayed whenever the sign-in flow is invoked. This requires you to call the setViewForPopups() method of the GamesClient class. Verify that this pop-up is shown when signing the player in automatically at the start of your game. This lets players know that they are signing into your game correctly.

The following example shows how the 'Connecting' pop-up might appear in an Android game during sign-in followed by a brief animation of the Google Play Games Services logo.

After signing in, the player must always have the option to sign out.

Consider providing a sign-out button in a relevant game screen in your app (for example, in your player Settings screen).

If the player declines to sign in when your game initially starts the sign-in flow (for example, if they clicked Cancel in the sign-in UI), you should still allow the player to proceed with gameplay.

When the player launches your game again, don't invoke the interactive sign-in flow automatically. These players can choose to sign in later using the Sign-in button that should be in your Settings system. This saves players from having to repeatedly decline signing in whenever they start your game.

One exception is if players are trying to access a gameplay feature that is dependent on being signed-in (for example, submitting a score to a leaderboard). In this case, prompt them to sign in before continuing with gameplay.

Having more players sign in to Google Play Games Services benefits your players by increasing the opportunities for collaborative and competitive gameplay. To maximize the number of players who are signed-in to Google Play Games Services, you are strongly encouraged to automatically prompt players to sign in, as described above.

Otherwise, direct players into the sign-in flow as early as possible from one of these points (most recommended first):

• Immediately after your game starts.
• Immediately after an introductory experience, such as a cut-scene or tutorial.
• When the player clicks on a Google sign-in button anywhere in your game.

To provide players with an end-to-end experience that is attractive and consistent, implement the Google Play Games Services branding guidelines.

Give signed-in players an appropriate reminder or cue when your game performs some action on their behalf. For example, when a signed-in player finishes a level, you can provide a message like this to indicate that the player's score and achievements are being automatically uploaded: "You are signed-in with Google. Your achievements and scores will be saved automatically."

To ensure players do not lose their progress when switching or resetting devices, or if they play on multiple devices, ensure their progress is backed up to a Cloud Save solution, and use the Play Games Services ID as a key, securely if using your own backend game server. When players sign in with their Play Games Services ID, check whether progress exists for that account and if it does, allow the player to pick up where they left off. You can use your own cloud save solution or Play Games Services Saved Games.

If the user is not signed in, try to maintain the player's progress locally, then sync that progress when the player eventually signs in. This helps to prevent losing any of the player's progress if the player postpones signing in to your game.

Players must be able to unlock all achievements you create.

All images, text, and descriptions should be unique across achievements.

Achievement points should be proportional to the amount of time or skill required to earn that achievement.

Include some easy achievements that a player could earn through casual gameplay, a number of intermediate difficulty achievements that require more skill or player dedication to earn, and one or two very difficult achievements for the most dedicated players.

For example, the following screenshot shows a hard-to-earn achievement that helps to motivate and retain fans of the title.

Avoid awarding more than one achievement in the first 5 minutes of gameplay, since players who are new to your game won't be deeply invested enough to care.

Don't define your achievements such that they are unintentionally granted too early in gameplay. For example, watch out for achievements that are likely to be trivially earned at the start of the game, like "Complete a level without taking damage".

Select metrics to build achievements that make your game more compelling and replayable (for example, "number of zombies killed" is a more interesting metric than "number of miles your character walked”).

Google Play Games Services uses grayscale versions of achievement icons to show if they're earned or unearned. If you are restricted to using all black (or all white) achievement icons, display them on a colored background.

Hidden achievements should only be used to avoid in-game spoilers; they should not be the norm.

"Find 100 treasure chests" is a better achievement than "Find an item that has a 1% chance of appearing in a treasure chest."

Some players will attempt to earn every achievement you create. Try to provide achievements that cater to this category of players. Avoid creating achievements that rely too much on elements beyond the player's control or cannot be earned once the player has made a decision in the game.

When an achievement icon is displayed in an Android toast, the icon is overlaid with a circle and its outer corners are hidden. Make sure that your icon still looks good under these circumstances.

Leaderboards should be readily accessible on the loading of a game. After critical transitions in a game (for example, at the end of a level, or when the player dies), players should immediately see links to the relevant leaderboards.

If possible, add limits when defining your leaderboards so that obviously fake scores are discarded.

Create a custom icon for each leaderboard you define; don't just use your game's icon, as it will display poorly in the Google Play Games app.

Submit scores after critical transitions in the game, such as at the end of a level or when a player's game character dies. For games without critical transitions (for example, an "endless runner" type game), use good judgment on how frequently to submit scores. Scores should not be submitted continuously or every second.

Scoretags are extra bits of data that can be sent with your score submission. For instance, you can implement a scoretag as a flag to confirm that a player's submitted score is valid.

Custom leaderboards can also read this tag data. If the scoretag consisted of an ID for a YouTube video containing that player's gameplay, for instance, your game could create a link to view that video within your leaderboard.

If you have the resources, build your own custom leaderboard view on top of the social leaderboard data. Social leaderboards typically create a more engaging experience than public leaderboards. Check first to determine if there are any entries in the social leaderboard. If not, use the public leaderboard instead.

The leaderboards API supports showing score windows (for example, a player's rank within +/-10 spots). If you are creating a custom view, this can be a powerful way to motivate engagement. This could be shown right after a critical transition in the game (for example, at the end of a level or when a player's game character dies). Avoid putting unnecessary clicks between your players and their ranking information.

This list could be an existing friends list, a recently-played friends list, or other list of friends.

4.1.1. The Play Games icon must be clickable.

If the user presses the icon, the game should call getCompareProfileIntent() or getCompareProfileIntentWithAlternativeNameHints() to show the UI where the user can compare themselves against another player's profile.

4.1.2. Player profiles and friend invitations support, for customizable in-game player names.

If a player sets a different name within the game (and doesn't use their Play Games profile name), use getCompareProfileIntentWithAlternativeNameHints() to provide that alternative in-game name for both the current player and the player they're viewing, as context for the profile view and any friend invitation sent from it. Pass only persistent, global player names for the values and not arbitrary user content. This requirement means that friend invitations sent from within the game will provide context to both players:

• The recipient will see the in-game name of the invitation sender, along with the game name.
• When viewing the friendship, the sender will still see the in-game name of the recipient, as well as the game they initiated it from.

The mobile client libraries employ a number of strategies to reduce the calls you make to the service. For instance, data for achievements and leaderboards is cached, so players can view their achievements as often as they like without requiring the service to make multiple calls.

The Android client library will not to send a player's score to the server if your score isn't as good as one you recently submitted. The Android library also automatically combines frequent achievement increment calls when it detects that you are being rate limited.

If you're making a fighting game and you have a 'Throw 5000 punches' achievement, don't send an achievement increment call every time somebody throws a punch. Wait until the end of the round, and then send one increment(xxx) call (where xxx is the total number of punches thrown that round), or wait until 50 punches are thrown before sending a single increment(50) call.

Be conscious of the number of calls you make to Google Play Games Services. Even if you avoid hitting rate limits, frequent calls can lead to high network traffic, and cause the device's battery to drain more rapidly. To avoid this, you can use these techniques:

• When performing saved games, keep the frequency to once every few minutes, not on every button click.
• Wait until the player's game is over before submitting a high score.
• Review your app's daily quota by going to your project dashboard in the Google Cloud Platform.

At minimum, you must include the following metadata when committing a saved game:

• Cover image - A screenshot that captures game progress and reminds players of where they left the game.
• Description - Short description that provides additional context for the cover image.
• Time stamp - Indicates how long the player has been playing this saved game.

Load the correct saved game when players make a selection from either the Play Games app or the default Saved Games selection UI.