Game Services | Real-Time Multiplayer: Introduction

IMPORTANT: as of March 31, 2020 Google has discontinued the Play Games Services multiplayer APIs. Therefore the Turn-Based Multiplayer feature is now only available on iOS Game Center platform.

In a real-time match, the players are connected to each other simultaneously in a single game session where they exchange data messages. This form of match is suitable for implementing any type of game that requires live participation. Using the real-time multiplayer API can help to simplify your game development effort because the API handles the following tasks on your behalf:

• Manages network connections to create and maintain a real-time multiplayer room (a virtual construct that enables network communication between multiple players in the same game session and lets players send data directly to one another). In other words, provides a high-level networking interface that lets you ignore many of the problems of the underlying networking layer
• Provides a built-in UI as well as programmatic API to invite players to join a room, look for random players for auto-matching, or a combination of both.
• Stores participant and room state information on the servers of the underlying platform (Game Center or Google Play Games) during the lifecycle of the real-time multiplayer game.
• Sends room invitations and updates to players, notifications appear on all devices on which the player is logged in (unless disabled).

Even though the API solves many of the fundamental problems in developing a real-time multiplayer game, your game design still needs to be prepared to deal with complex issues that arise from real-time networking, including:

• The need for multiple instances of your game (running on different devices) to perform tasks simultaneously or near simultaneously, while synchronizing states between the devices.
• Network reliability.
• Network latency.

Needless to say, implementing a real-time multiplayer game requires extensive work in designing, implementing, and testing.

Game Center and Google Play Games offer all the necessary networking and notification infrastructure for real-time multiplayer games, for free. These platforms expose very different sets of API for accessing their multiplayer infrastructures. Easy Mobile unified these APIs, solve their discrepancies and provide you a common API that works consistently across the two platforms so you only need to write your multiplayer code once for both platforms.

The table below summarizes the specifications of the Real-Time multiplayer services offered by Game Center and Google Play Games.

Real-Time Multiplayer Game Basics

Before you design and implement your game using the real-time multiplayer API, you should familiarize yourself with the following concepts related to the typical lifecycle of a real-time multiplayer game.

Room Initialization

A real-time multiplayer match takes place within a room. Internally, the room sets up a peer-to-peer mesh network between participants where clients can communicate directly with each other, rather than through any central server. When a player initiates a real-time multiplayer match, a room is created with the initiating player automatically joined as a participant in it. Other participants can then join, either by invited or auto-matched. Once all participants have joined, the room is successfully connected and the match can start.

Matchmaker UI vs Programmatic Matchmaking

The real-time multiplayer API provides a built-in matchmaker UI in which the initiating player can invite their friends or select a number of auto-match opponents into a room. It's also possible to create a room programmatically without any UI with all opponents being auto-matched (aka create quick match).

Specifying Number of Players

When initiating a real-time multiplayer match, you must specify the number of players that you want to allow in your room. These players can join via invitations or auto-matching.

The maximum number of players that can join a room on Game Center and Google Play Games platform is 4 and 8, respectively. The minimum number of players is 2. Note that these numbers include the player who is initiating the match.

Variant

Optionally, you might want to ensure that only players who are interested in a specific type of game variant are auto-matched to the room. For example, in a racing game, you can auto-match players who only want to play a specific racing map or difficulty level. Variants can be used to auto-match players who are interested in different play styles, such as player-vs-player (PvP) or 'capture the flag' gameplay. If there are different versions of your app, you can also use variants to ensure that only players who are on compatible versions are auto-matched.

Exclusive BitMask

If your game has various roles and you want to auto-match players who are interested in playing specific exclusive roles in a game, you can specify this using an exclusiveBitMask while setting up the room.

Participants

The participants in a real-time match can fall into one of these categories:

• Initiating player: an initiating player who starts a real-time match can invite other players to join the match, or request to be auto-matched to random users. The initiating player can also request a mix of the two (for example, invite a specific friend, and get two auto-matched players).

• Auto-matched players: auto-matched players do not need to be socially connected to the other players. When auto-matching, the system simply looks for other participants at that time who are also initiating a real-time game and requesting to be auto-matched. Auto-matched players do not receive notifications to join a match; from their perspective, it appears as though they are individually initiating the match.

• Invited players: users who are invited to a match will receive invitation messages/notifications on their device. Once a user accepts a match invitation, that player is joined to the match as a participant.

On Google Play Games platform, auto-matched participants will appear as anonymous players to each other (even if they are known to each other).

Participant Status

The following table lists the possible statuses of a participant in a real-time match:

Participant Connections

As players join or leave the room, the system actively attempts to create a mesh of peer-to-peer connections between all participants. In effect, each participant is fully connected to the other participants in the room. If any player gets disconnected from the room, the connection mesh is reduced to the remaining players who are still fully connected. It is up to your game to determine how to proceed if this happens.

In-game networking

The real-time multiplayer API is flexible enough that your game can use it to implement your own in-game network for participants over the underlying peer-to-peer network created by Game Center or Google Play Games 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 participants through data messaging. 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.

Leaving Participants

Once the required number of participants for a room have been connected, the room is considered to be 'filled' and gameplay can begin. After participants join a room, your game can allow them to leave the room (effectively dropping them out of the game). However, no new players can join a room after it is 'filled' (not even to fill a spot that a participant has vacated).

Sending Game Data

The real-time multiplayer API allows a participant to broadcast data to all participants in a room, or exchange messages with another specific participant. Data messages can be sent using a reliable or unreliable messaging protocol.

• Reliable messaging: with reliable messaging, data delivery, integrity, and ordering are guaranteed. Reliable messaging is suitable for sending non-time-sensitive data. You can also use reliable messaging to send large data sets where the data can be split into smaller segments, sent over the network, and then reassembled by the receiving client. Reliable messaging might have high latency. The maximum size of a reliable message that you can send is 87 kilobytes on Game Center and 1400 bytes on Google Play Games platform.
• Unreliable messaging: with unreliable messaging, the game client sends the data only once ('fire-and-forget') with no guarantee of data delivery or data arriving in order. However, integrity is guaranteed, so there is no need to add a checksum. Unreliable messaging has low latency and is suitable for sending data that is time-sensitive. Your app is responsible for ensuring that the game behaves correctly if messages are dropped in transmission or received out of order. The maximum size for an unreliable message that you can send is 1000 bytes on Game Center and 1168 bytes on Google Play Games platform.

A participant can send messages to participants who are connected to the room. If the participant loses connection to the room or the recipient is not connected, the message will not be delivered.

To conserve message transmissions and avoid exceeding rate limits, follow these best practices for sending data:

• Send messages to only the participants who require that information, rather than broadcasting to all participants. If you are sending a broadcast message, make sure to exclude the sender participant from the list of broadcast recipients.
• If you are sending data using the reliable messaging protocol, try to keep the frequency of your message transmissions to around 50 or fewer messages per second. If you need to send data more frequently than this, we recommend that you use unreliable messaging instead.

Warning

Data that is sent using the real-time multiplayer API (via Game Center or Google Play games services) is unencrypted. Since messages can originate from any peer client connected to the room, you should treat this data as untrusted. We recommend that you implement your own security checking to verify that inbound data does not compromise your app.

Room Closure

When the local player logs out of your game or exits the real-time portion of the game, have the player leave the room. Your game should also handle the scenario where all participants except the local player have left the room. When this happens, your game should disconnect the local player from the room immediately. The room is considered 'closed' when all its participants have left the room.

Demo Scenes

Our multiplayer API demo scenes are located at folder Assets/EasyMobile/Demo/Scenes/Modules and include 5 scenes:

• GameServicesDemo_Multiplayer: the entry point for other multiplayer demo scenes.
• GameServicesDemo_Multiplayer_RacingGame: a 2-player car racing game demonstrating the Real-Time multiplayer API.
• GameServicesDemo_Multiplayer_RealTimeKitchenSink: a kitchen sink demo for the Real-Time multiplayer API.
• GameServicesDemo_Multiplayer_TicTacToe: a 2-player Tic Tac Toe game demonstrating the Turn-Based multiplayer API.
• GameServicesDemo_Multiplayer_TurnBasedKitchenSink: a kitchen sink demo for the Turn-Based multiplayer API.

If you're trying our multiplayer API using the demo app, build these 5 scenes only so that the necessary delegates can be registered and run properly.

Useful Links

• Real-Time Matches, Game Center Programming Guide
• Real-time Multiplayer, Google Play Games Services