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.
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.
|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.2||Required||Do not request unnecessary scopes when creating your sign-in client.
Remove any unneeded scopes from your
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, submitting a score to a leaderboard). 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):
|1.7||Good-to-have||Follow Google branding guidelines.
To provide players with an end-to-end experience that is attractive and consistent, implement the Google Play games services branding guidelines.
|1.8||Good-to-have||Remind players that they are signed-in.
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.
The following checklist tasks apply to implementing the Achievements feature in your game.
|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.
The following checklist tasks apply to implementing the Leaderboards feature in your game.
|3.1||Best practice||Make leaderboards visible in your main menu and after key
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)
|4.1||Required||Allow players to engage in a multiplayer match if your game
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.
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.
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
|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
|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
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
The following checklist tasks apply to implementing the real-time multiplayer feature in your game.
Clean up real-time multiplayer rooms.
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:
6. Turn-based multiplayer
The following checklist tasks apply to implementing the turn-based multiplayer feature in your game.
Alert players to turn-based matches that require their attention.
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.
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. 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.
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.
Limit your reliable message transmissions.
If you are making reliable calls in your Android app using
Tip: If you need to send data more frequently than this, consider using unreliable message transmission instead. Unreliable messages do not have a quota.
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
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:
8. Saved Games
The following checklist tasks apply to implementing the Saved Games feature in your game.
Add metadata to provide additional context for saved games.
At minimum, you must include the following metadata when committing a saved game:
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.