The Play Games services provides a multiplayer API to allow you to easily create a game that supports multiple simultaneous players. The multiplayer API manages the game client network connections and participant status for your game, so you don’t need to handle this explicitly.
These basic concepts apply to real-time multiplayer games using the Play Games services:
- Room: A virtual meeting space where games take place. Players can be invited to join rooms, or be automatically matched into them. Players that are connected to the same room can exchange game data with each other.
- Participant: Players that can participate in a game. A local player can send invitations to other players from their circles to join a room, or request to be auto-matched to random players. A player who is sent an invitation will see a notification to accept the game invitation. If the player accepts the invitation, they are joined to the room. The state of the participants in a room is managed by Play Games services and is sent to the game clients.
Lifecycle of a real-time multiplayer game
When designing your game using the multiplayer API, it is useful to understand the typical runtime lifecycle for a real-time game:
1. Player sign in phase
Before a multiplayer game can be initiated, the local player must be signed in to your game. For code examples of how to implement player sign in using Google+, see Initializing Your Games Client in Android.
2. Room initialization phase
The signed in local player can initiate a multiplayer game by inviting other players to join, by selecting to be randomly auto-matched, or by a combination of invites and auto-matching. This is described further in Player Invites for Multiplayer.
Your app creates an instance of a room by using the list of
invitees or auto-match criteria specified by the signed in player. You must
when you create the room on behalf of the player who is initating the
multiplayer game. Play Games services notifies your app when a room is
successfully created through the
Play Games services sends notifications to your app as the status of the room, its
participants, or connection status of the participants change. This
information is received by your app through the callback methods of
RoomStatusUpdateListener interface. You can use this information to display details about the joined participants
(for example, while your app is waiting for other participants to join), or to
provide an option to quit the game if there are no other players found for
auto-matching after a long wait.
3. Invitation acceptance phase
The player who initiated the game is automatically joined to the room. Invitees to a multiplayer game will see a notification displayed on mobile devices to prompt them to join the game. If they accept the invitation, your app must issue an API call to join the player to the room corresponding to that invitation.
Play Games services notifies the invitees via the
The callback method is passed a
connectionHint Bundle. Your app can retrieve
object from this Bundle by using the
EXTRA_INVITATION key. From the
object, you can get additional details such as the invitation creation
timestamp, the invitation ID, and the participant who sent the invitation. To
join the player to the room corresponding to the invitation, your app must set
this invitation ID in
For code examples of how to create a room and accept an invitation, see Developing a Real-time Multiplayer Game in Android.
4. Participant connection phase
As players join or leave the room, Play Games services actively attempts to create a mesh of peer-to-peer connections between all participant clients. Play Games services maintains a “connected set” of players in the room. Every player in the set is fully connected to the other players in the set, but this might only be a subset of all players who have joined the room. If a player gets disconnected from even one other player in the connected set, the set is reduced to the remaining players who are still fully connected. It is up to your app to handle how to proceed with the game if this happens.
Play Games services notifies your app when all the participants in a
real-time room are fully connected. This notification is received
callback method. Your app can send messages to the participants who are
connected to your room. This is described further in Data Messaging for Multiplayer.
Note that the multiplayer API gives you flexibility to implement your own in-game networking for participants over the underlying peer-to-peer network created by the Google Play services. For example, in your game, you might want to designate a single client to act as a “host” to establish the authoritative game data first, then transmit this data to the other connected clients through the multiplayer API.
If auto-matching is used to create the room and your game logic relies on the existence of a "host" or "owner" of the game, you are responsible for implementing the logic to determine who the "host" should be.
5. Gameplay phase
Once the required number of participants for a game have been connected, your app can start a gameplay session. After all participants have joined a game and the room is "full", players can leave your game, but no other players can join; not even to fill a spot that another player has vacated.
Your application can run multiple rounds of a multiplayer game for as long as you'd like during this phase, as long as there are participants in the room. Playing another round of a multiplayer game with the same participants doesn't require leaving this phase.
You can optionally choose to start play before all invitations have been accepted. In this case, your app must be prepared to handle players who join the room after gameplay is underway. For example, in a 3-player racing game, you might start the race with two players. During the race, if a third player joins the room, they might be allowed to observe the current race as a spectator but not participate as a racer. Then, after the race is over, all three players can participate as racers in the next round.
6. Room closure phase
Your app is responsible for calling
to leave the room, when a player either exits the game or exits the real-time
portion of the game. Your game is also responsible for handling the situation
where all participants except the local player have left the room. In this
scenario, you should call the API so that the local player leaves the
The room is considered “closed” when all participants have left the room. Your app should shut down any game currently in progress, and make sure to save game data appropriately. To learn more about saving game data to Google Play, see Cloud save for game services.