Matching Players for a Hosted Match

The code you write for hosted matchmaking is similar to the code you write for real-time matches. Before you attempt to create a game that uses hosted matches, you should already be familiar with real-time matchmaking. The critical difference between the two models is that hosted matchmaking returns player identifiers instead of a completed match object. Your game then connects that player to your own server. Your server must match that player’s network address to the player identifier and, similar to a match, perform routing when one device in the match needs to communicate with others.

Table 8-1 lists the most common methods for real-time matchmaking and the corresponding methods or implementation details for hosted matchmaking.

Hosted Matches Overview

By default, when you perform the matchmaking process, Game Kit returns an instance of the GKMatch object on each device connected to the match. Each device then uses its match object to communicate with other participants. For most games, this default behavior is exactly what you want. The GKMatch class abstracts the underlying network topology so that your game can simply focus on sending data to other participants without you having to worry about how the data is transmitted.

However, some games may want to support more players than the maximum number of supported players on Game Center, or may want their own server to arbitrate the match. In these cases, you can still use matchmaking to find players for a hosted match. A hosted match does not use GKMatch objects. Instead, each copy of your game receives the player identifiers for all of the players in the match. Your game then takes additional steps to connect the players to your server.

Creating a hosted match requires your game to implement all of the low-level networking required for your game. In particular, you must do all of the following in your game:

• Design and implement your own networking code to connect each device to your server.

• Design and implement your own networking protocol to inform other devices of the state of any participant in the match.

• Design and implement your own server implementation to map player identifiers to the specific device connected to your server. Thus, your server becomes responsible for routing network data between players.

• If your game uses Game Kit’s standard matchmaking user interface, you must make sure each device informs Game Kit after it connects to your server. This information allows Game Kit to update its user interface.

Creating a Hosted Match Using the Matchmaker View Controller

Create and configure a new match request and then initializes a new GKMatchmakerViewController object using the match request. The presenting view controller makes itself the matchmaking view controller’s delegate and then presents the matchmaking interface over itself. The player interacts with the matchmaking screen until the match is ready to start or an error occurs.

When the view controller is hosted, your delegate implements the matchmakerViewController:hostedPlayerDidAccept: method to process the new player. Your delegate needs to behave differently depending on which device your game is running on:

• When called on the player’s device, the device needs to connect to your own server. When successfully connected, call the setHostedPlayer:connected: method to tell the view controller that the player has connected to the match.

• When called on another player’s device, your game needs to determine that it can talk to the new player’s device through your server. Once it knows it can send messages to the other client, call the setHostedPlayer:connected: method to update the user interface.