An object used to implement turn-based matches between sets of players on Game Center.
- iOS 5.0+
- macOS 10.8+
- Mac Catalyst 13.0+Beta
- tvOS 9.0+
- watchOS 3.0+
A turn-based match uses a store-and-forward approach to share data between the participants. When a player participating in the match performs actions that advance the state of the match, your game describes the new state of the match and decides which player acts next. The next player to act is notified by a push notification. Later, when the next player launches your game, you download the match data from Game Center and continue the match. Players take turns acting (based on whatever internal logic your game implements) until the match ends. One advantage of turn-based matches is that a player may participate in multiple matches simultaneously.
Your game never directly creates
GKTurn objects, because a match always represents an existing match that is stored by Game Center. Instead, match objects are created for your game by Game Kit. A match object may hold a newly created match (for a match that has not started yet) or a match that is already under way. Here are ways your game acquires match objects:
To allow the player to see a standard user interface for turn-based matches, use the
Based Matchmaker View Controller
To programmatically find a new match for the player to join, call the
Match For Request: with Completion Handler:
To programmatically load a collection of match objects for matches the local player is already participating in, call the
Matches With Completion Handler:
To receive notifications when it is the local player’s turn in a match, use
Based Event Listener
A match object contains a few essential properties:
matchproperty holds binary data that describes the current state of the match. The format of the data contained in this object is something you design when you create your game; Game Kit only manages storing and forwarding of this data.
When a player views a particular match, your game should take the match object and call its
load method to retrieve the match data. After the match data is downloaded from Game Center, your game parses the data and displays the game’s user interface. A player may want to view the match even when it is another player’s turn to act; your game should expect this and allow the player to view the state of the match without allowing them to act. When the current player views the match, your game should both show them the state of the match and provide a user interface to allow the player to take a turn. The current player is expected to perform actions that change the state of the match. These actions are based on the internal logic of your game’s rules. The player continues to act until he or she takes an action that requires another person in the match to act in order to advance the match. For example, in a game like Chess, moving a piece on the board and passing control to the other participant happen simultaneously. A more complex game might allow the current player to take multiple actions before the match reaches a state in which control is ceded to another player.
If the player takes an action that is irrevocable (but control is not yet passed to another player), you update the match data by calling the
Once the player takes an action that requires another player to act, your game should determine which player needs to act next. Then, it should encode the state of the match into an
NSData object and call the match object’s
end method to set the next player to act. The next player is automatically informed that the match is waiting on his or her actions in order to continue the match.
As the match progresses, players may leave the match. For example, this situation might occur if your game determines that this player has been eliminated from the match. Or your game might offer a user interface to allow players to resign from matches. If the local player resigns from the match and is also the match’s current player, your game must call the match object’s
participant method. As it does when the player takes a turn, your game passes in the state of the match and the next player to act. Your game also provides a match outcome — essentially, a numerical value that indicates the reason why that player left the match. If your game allows players to resign from matches when it is not that player’s turn, your game calls the match object’s
participant method to allow the player to leave the match.
Eventually, a match ends. When your game logic dictates that a match should end, your game calls the match object’s
end method. Your game must ensure that all participants in the match have a valid match outcome before ending the match.
Even after a match ends, its data is still stored on Game Center; this allows players to view previous victories and defeats. A player may choose to delete the match using the standard user interface, but your game can also programmatically remove a match by calling the match object’s
remove method. In all cases, the decision to delete a match should be made by a player; the
remove method exists to allow your game to present a custom user interface for viewing and working with matches.
GKTurn class may not be subclassed.