Quality Checklist for Google Play Games Services

The quality of your game influences the long-term success of your game -- in
terms of installs, player rating and reviews, engagement and player retention.
Before publishing your game, it's important to make sure that your game meets
the basic expectations of game players through compelling features and an
intuitive, well-designed UI.

This document helps you focus on key aspects of quality, feature set, and UI
that can have significant impact on your game's success. Each focus area is
presented with a checklist of minimum requirements, best practices, and
good-to-have enhancements. In the interest of delivering the best possible
product to your players, follow the checklist recommendations to the greatest
extent possible.

Caution:

You cannot implement Google Play game services if your game's target
audience is children only.

Note:

To help prioritize your development efforts, take note of the level of
importance indicated for each checklist item.

Required. Minimum requirements that must be
implemented for your game to be considered Google Play games services-compatible.

Best practices. Strongly
recommended implementation guidelines.

Good-to-have. Suggested
guidelines to help you create a distinctive player experience.

1. Sign-in

The following checklist tasks apply to implementing player sign-in functionality
in your game. For code examples of how to implement sign-in on mobile games,
see Implementing Sign-in on Android.

ID

Importance

Description

1.1

Required

Provide players with a sign-in option to
Google Play games services.

Your game must implement one of the following ways for players to sign in:

1.1.1. Automatically prompt the player to sign in when your
game launches

General audience apps 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.

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 and not buried multiple levels deep in your game
menu).

1.1.2. Provide a sign-in option in your game

If not auto-prompted, players must have the option to login via a
sign-in button, or
from a contextually relevant trigger (for example, during multiplayer match initiation,
when submitting a high-score, or when unlocking an achievement). The sign-in button must
incorporate the Play Games icon.

1.2

Required

Do not request unnecessary scopes when creating your sign-in client.

Remove any unneeded scopes from your GoogleSignInOptions
construction along with any APIs you no longer use.

For example, you should not request G+ scopes when creating your Google
sign-in client. This will avoid requiring new users to unnecessarily (1) create
G+ accounts, and (2) review additional consent screens.

// This way you won’t get a consent screen
GoogleSignInOptions signInOption = GoogleSignInOptions.DEFAULT_GAMES_SIGN_IN;

1.3

Required

Allow players to stay signed-in.

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

1.4

Required

Provide players with a sign-out option.

After signing in, the player must always have the option to sign out. The
default Achievements and Leaderboard UIs provided by the Play Games SDK
already include a sign-out option, so you don't need to implement a sign-out
button for these UIs.

Consider providing a sign-out option in other
game screens in your app. For example, your sign-out button can look like
this:

1.5

Required

Remember if players declined signing-in.

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 sign-in flow
automatically. 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, starting a multiplayer
match). In this case, prompt them to sign in before continuing with
gameplay.

1.6

Best practice

Maximize the number of players signed in.

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.

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."

1.9

Good-to-have

Display the 'Connecting' pop-up appropriately during sign-in.

On Android devices, the Google Play Games 'Connecting' pop-up is displayed
by default whenever the sign-in flow is invoked. On Android, verify that
this pop-up is shown when signing the player in automatically at the start
of your game.

If you are signing the player in based on a UI interaction (such as a
sign-in button click), you may optionally suppress display of this pop-up.
To learn how to control the display of the pop-up, see Implementing Sign-in on
Android.

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.

1.10

Good-to-have

Avoid losing player progress information.

If possible, 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.

2. Achievements

The following checklist tasks apply to implementing the
Achievements feature in your game.

ID

Importance

Description

2.1

Required

Ensure that all achievements are attainable.

Players must be able to unlock all achievements you create.

2.2

Best practice

Make achievements distinct.

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

2.3

Best practice

Score achievements proportionately.

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

2.4

Best practice

Design achievements for a variety of difficulty levels.

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.

2.5

Good-to-have

Don't frontload achievements.

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".

2.6

Good-to-have

Define achievements around compelling in-game activities.

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”).

2.7

Good-to-have

Use color achievement icons.

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.

2.8

Good-to-have

Minimize the use of hidden achievements.

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

2.9

Good-to-have

Avoid achievements that are too reliant on chance.

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

2.10

Good-to-have

Think like an 'Achievement Hunter’.

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.

2.11

Good-to-have

Ensure your achievement icon appears correctly.

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.

3. Leaderboards

The following checklist tasks apply to implementing the Leaderboards feature in your game.

ID

Importance

Description

3.1

Best practice

Make leaderboards visible in your main menu and after key
transitions.

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.

3.2

Best practice

Define upper limits for scores that can be submitted.

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

3.3

Best practice

Use custom icons.

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.

3.4

Best practice

Keep the frequency of score submissions appropriate.

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.

3.5

Good-to-have

Make use of scoretags.

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.

3.6

Good-to-have

Creatively design your own leaderboard UI

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.

3.7

Good-to-have

Show players how they stack up against the competition.

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.

4. Multiplayer (General)

Allow players to engage in a multiplayer match if your game
uses invites.

If your game uses the multiplayer APIs to create a room or a turn-based
match but does not allow players to enter into a multiplayer match, this may
be considered an abuse of the service, and can be cause to block access to
Google Play games services.

4.2

Required

Make sure you understand and fully abide by the Google Play games services
terms of service.

You must also have a player's explicit permission to share his or
her personal details to other players in a multiplayer game, beyond the details Google Play games services normally shares.

4.3

Best practice

Provide a 'Quick Match' button that gets players directly
into a competitive match.

Give players an easy way to start playing against randomly selected
opponents via auto-matching. For an example of this in practice, see the
Clumsy Bird game.

4.4

Best practice

Notify players that they have received an invitation in the game.

Developers should implement the invitation callbacks so that they can notify
players while in the game that an invitation has been received.

4.5

Best practice

Take players directly to the action.

When a player clicks to accept an multiplayer match invitation, the player
should be taken directly into the corresponding match. To implement this
behavior, you can use the match information that is included in the
connectionHint parameter that Google Play games services passes to
your game client.

4.6

Best practice

Handle invitations properly when your Android game is brought to the background.

When your game goes to the background, the multiplayer invitation callbacks
in your game will continue to consume any incoming invitations. This prevents invitations from
appearing in the notification shade, keeping players from accepting these incoming invitations.

You are encouraged to unregister your callbacks in your activity's onPause(). If
you fail to do so, the system will release the callbacks automatically and
issue a warning. Once all callbacks are released, notifications will appear
correctly in the shade.

4.7

Best practice

Avoid over-partitioning your player pool when using
bitmasks or variants.

The smaller your potential player pool, the longer it will take
for your players to be auto-matched and to get into a game.

4.8

Best practice

Use variants or bitmasks only if there are no other
alternatives.

Consider if players would leave your game if they did not get to play the
type of game they wanted. If so, provide this type of game as a variant that
players can select while starting a multiplayer match. Otherwise, consider
letting players select the type of game only after they have been matched.

4.9

Good-to-have

Make it easy to play again after a multiplayer match is over.

At the end of a multiplayer match, allow players to
immediately re-engage either by starting a rematch with the same match
opponents or by starting a new match with new opponents.

5. Real-time multiplayer

If you don't leave the room appropriately, Google Play games services
will continue to send event and invitation notifications to the client.
You should leave the active room whenever one of these scenarios occurs:

Gameplay is over (for example, a player has won the match).

When your game goes into the background.

On Android, leave the room when:

The player cancels the game in the waiting room UI.

The response code returned in the onActivityResult()
callback is GamesActivityResultCodes.RESULT_LEFT_ROOM.

The ActivityonStop() is called. This might
indicate that your Activity is being destroyed. In this case,
leave the room and call disconnect().

You can add a small icon or a number next to the Multiplayer option
of your main menu to indicate matches that are waiting for the player to take
a turn or accept an invite. For an example of this in practice, see the
1941 Frozen Front game.

6.2

Good-to-have

Design turns to take more than 15 seconds to play.

Avoid designing your gameplay to have rapid turn transitions. This is to
prevent spam-like behavior that could result in your game going over its API
quota limit or keep players from correctly receiving turn notifications.

7. Gifts and requests

Important:
The Google Play Games game gifts service will be deprecated as of March 31st 2018. Do not
use the Google Play Games game gifts API in new apps. See the
deprecation announcement blog post
for more details.

The following checklist tasks apply if you use the Game Gifts feature in your game.

ID

Importance

Description

7.1

Required

Do not send, request, or accept in-game gifts for players
without their explicit approval

Make sure you understand and fully abide by the Google Play games services
terms of service pertaining to using the
game gifts feature.

7.2

Required

Implement the acceptance of Game Gifts requests.

If your game allows players to send Game Gifts requests but does not allow
players to accept Game Gifts requests, this may be considered an abuse of the
service, and can be cause to block access to Google Play games services.

7.3

Best practice

Implement the listener for accepting a Game Gifts request.

You should implement request listeners so that players are notified when
they receive Game Gifts requests when they are in your game.

8. Quota and rate limiting

The following checklist tasks apply to managing the quota and rate limiting in
your game. To learn how to manage your game's quota and detect when its rate
limit is exceeded, see Managing Quota and Rate Limiting.

ID

Importance

Description

8.1

Best practice

Use the client libraries.

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.

8.2

Good-to-have

Limit your reliable message transmissions.

If you are making reliable calls in your Android app using
RealTimeMultiplayerClient.sendReliableMessage(), keep your message transmission
frequency to 50 messages per second or less.

Tip: If you need
to send data more frequently than this, consider using unreliable message
transmission instead. Unreliable messages do not have a quota.

8.3

Good-to-have

Combine frequent calls to incremental achievements.

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.

8.4

Good-to-have

Be aware of your usage.

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 cloud saves, keep the frequency to once every few
minutes, not on every button click.

9. Events and Quests

Important:
The Google Play Games quests service will be deprecated as of March 31st 2018. Do not
use the Google Play Games quests API in new apps. See the
deprecation announcement blog post
for more details.

The following checklist tasks apply if you use the
Events and Quests features in your
game.

ID

Importance

Description

9.1

Required

Make quests discoverable.

Make sure that quests can be easily discovered by players from the main
menu or primary gameplay view of your game.

9.2

Required

Allow players to accept quests from the Play Games app.

Your game must bring up a view to allow players to accept a quest when they
click on a quest tile in the Play Games app.

9.3

Required

Acknowledge quest acceptance and completion.

Your game must explicitly provide an acknowledgment when players accept or
complete a quest. Display the acknowledgment using a toast or
equivalent form of notification.

9.4

Required

Implement reward claiming.

If your quest description references a reward, your game must provide
that reward when the quest is completed.

Use one of these approaches to allow players to claim
rewards on quest completion:

Implement a claim reward listener which triggers when a user
clicks the Claim Reward button for a completed quest from
the default Quest list UI, or

Automatically claim the reward on quest completion.

9.5

Required

Follow the quest branding guidelines.

When linking to Quests, your game should display the official Quest
iconography. Variations that don’t materially distort the silhouette are
also acceptable, in line with Google Play Games Services branding guidelines.

9.6

Best practice

Describe rewards appropriately.

The reward should be identified in the first 150 characters of the
quest description so that it is visible in the abbreviated quest view in
the Play Games app.

9.7

Best practice

Visually indicate quest progress.

Make sure players can easily view their progress status towards
completing a quest. Your game should display the player's quest
progress (if there is only one quest active), or the quest that is
closest to completion (if there is more than active quest).

Your game can display this visualization in these locations:

In a pop-up dialog on game start-up.

In the main menu.

In the main gameplay screen.

9.8

Best practice

Indicate time remaining to complete a quest.

Giving players a countdown or otherwise making them aware of
impending quest deadlines makes them more motivated to play
aggressively to reach their quest goals before the quest ends.

As time grows close to the quest end, use a toast or other in-game
warning to show a countdown to the end time.

9.9

Best practice

Make quests reusable and/or repeatable.

Reusing quests gives new players a chance to experience them, all
without launching a new binary. Many top games have daily quests for each
specific day of the week that repeat weekly.

Repeating quests on a weekly or monthly basis creates a similar set of
user experiences for all players.

10. Saved Games

The following checklist tasks apply to implementing the Saved Games feature in your game.

ID

Importance

Description

10.1

Required

Add metadata to provide additional context for saved games.

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.

10.2

Required

Allow players to load saved games.

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