Multiplayer Invitations

The invitation system for the RTM(Real-Time Multiplayer) and TBM (Turn-Based Multiplayer) is mostly the same with few minor differences which will be also described in this article.

There are 2 scenarios how we can receive / accept invitation and start new multiplayer match:

Receiving invitation when the app is running. 

If you want to be informed when a player gets a new invitation while your app is running, you can subscribe for the ActionInvitationReceived event in GooglePlayInvitationManager class.  ActionInvitationReceived event will be fired only if you have registered the  invitation listener as showed below:


This method will register a listener to intercept incoming invitations for the currently signed-in user. If a listener is registered by this method, the incoming invitation will not generate a status bar notification as long as this client remains connected. You can also unregister it anytime you want using:


Note: Subscribing to this listeners is not necessary, you can always implement only 2-nd offline scenario.

After Invitation listener is registered, you can use ActionInvitationReceived and ActionInvitationRemoved  events as showed below:

GooglePlayInvitationManager.ActionInvitationReceived += ActionInvitationReceived;
GooglePlayInvitationManager.ActionInvitationRemoved += ActionInvitationRemoved;

private void ActionInvitationReceived(GP_Invite invitation) {
	//Hnadeling invitation code

private void ActionInvitationRemoved(string invitationId) {
	//Hnadeling invitation code

ActionInvitationReceived Callback invokes when a new invitation is received. This allows an app to respond to the invitation as appropriate. If the app receives this callback, the system will not display a notification for this invitation. 

ActionInvitationRemoved Callback invokes when a previously received invitation has been removed from the local device. For example, this might occur if the inviting player leaves the match.

Note: For TBM Multiplayer a user will be invited only when he has to do his first turn. User will not be invited right after TBM match is created.

After you was notified about new incoming invitation, you can choose how to handle it. Basically you have two options handle invitation programmatically or use Google Play Inbox UI. To show Inbox UI you, may sue the following code:

//For RTM

//For TBM

Those methods will show user inbox UI and will give user ability to accept / dismiss permission using Google UI. If you want to find out when inbox UI was closed, you can subscribe to the GooglePlayInvitationManager.ActionInvitationInboxClosed event. Handling inbox UI result is the same as Handling offline invitation result.

Receiving invitation when the app is closed

If user gets an invitation while your app is closed, inactive or you are not registered for invitation listener. He will got a clickable status bar invitation. Click on this invitation open's Google Play Service app with the list of user invites. If a user accepts an invitation, it will start the app. 

Real-Time Multiplayer :

Before connection to google play service we should subscribe to the  GooglePlayInvitationManager.ActionInvitationAccepted. See the snippet below:

GooglePlayConnection.ActionPlayerConnected += OnPlayerConnected;
GooglePlayConnection.ActionPlayerDisconnected += OnPlayerDisconnected;
GooglePlayInvitationManager.ActionInvitationAccepted += ActionInvitationAccepted;

GooglePlayConnection.Instance.Connect ();

void ActionInvitationAccepted (GP_Invite invitation) {

	//preparing multiplayer game for start 

If the ActionInvitationAccepted is received, it means that a user has already made a decision to accept the invitation using Google Inbox UI or  Play Service app. So, we need to accept it programmatically as well, no point to ask a user again if he wants to accept this invitation. But before doing that we can prepare our application to start the multiplayer game. For example: load multiplayer scene, subscribe to necessary listeners, initialize models, etc. After everything is done, we should accept the invitation using GooglePlayRTM.instance.AcceptInvitation method. This will join us to the multiplayer room. The result is delivered by the GooglePlayRTM.ActionJoinedRoom event.

Turn-Based Multiplayer

If a user is accepting an invitation for turn-based match unlike RTM invitation, it will be accepted automatically by google API which means we will not get ActionInvitationAccepted event. Instead ActionInvitationAccepted the GooglePlayTBM.ActionMatchInitiated will be fired. Which means we should be prepared to get it after a connection to play service, the same as with the ActionInvitationAccepted for RTM.

Accepting / Declining invitations programmatically

The incoming invitation is represented as GP_Invite object including GP_InvitationType.

Accepting RTM invitation:

GooglePlayInvitationManager.ActionInvitationReceived += OnInvite;

private void OnInvite(GP_Invite invitation) {
	if (invitation.InvitationType != GP_InvitationType.INVITATION_TYPE_REAL_TIME) {



The result is delivered by the GooglePlayRTM.ActionJoinedRoom event. You can also use the following methods for Dismiss / Decline the invitation:


Accepting TBM invitation:

GooglePlayInvitationManager.ActionInvitationReceived += OnInvite;

private void OnInvite(GP_Invite invitation) {
	if (invitation.InvitationType != GP_InvitationType.INVITATION_TYPE_REAL_TIME) {


The result is delivered by the GooglePlayTBM .ActionMatchInitiated event. You can also use the following methods for Dismiss / Decline the invitation:


Warning: Make sure that before you accept the invitation, your game is ready to start a multiplayer game, since accept invitation will result the same as create/join new match.


Google multiplayer exclusiveBitMask and variant

When you are creating TBM and RTM match, you can set exclusive BitMask and variant. Here is a short explanation of use cases for those parametrs.


This is an optional, developer-controlled parameter describing the type of game to play, and is used for auto-matching criteria. Must be either a positive integer or ROOM_VARIANT_DEFAULT (the default) if not desired.

Note that variants must match exactly. Thus, if you do not specify a variant, only other rooms created with ROOM_VARIANT_DEFAULT will be considered potential auto-matches.

Example 1. We have a race game, and, of course, we want our matched player to race the same track. In this case we will use a variant param to make sure that the system will match users with the same track option.  

Example 2. If a skill in our game means a lot, and we do not want to match new buys with the experienced player, we can use a variant as a level representation. For example, for users with level from 1-5 we will set variant 1, for users with level 5-15, variant = 2. 15-30, variant =3, etc.

Exclusive Bit Mask

Your game can also use the exclusiveBitMask parameter to pair auto-matched players who are interested in playing specific exclusive roles in a game. The exclusive bitmask of each pairing of players must equal zero for auto-match.

Example 1. We have different player roles in our game, and match should have 3 players with following roles: FARMER, ARCHER and WIZARD. Let's represend our roles as showed below 

private static int ROLE_FARMER = 0x1; // 001 in binary
private static int ROLE_ARCHER = 0x2; // 010 in binary
private static int ROLE_WIZARD = 0x4; // 100 in binary


In the case only 2 diffrent roles will give us a zero result, same roles will give us a non-zero result




So, we can be sure that only players with diffrent roles can be matched together.