WWDC2013 Session 506

Transcript

X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[ Silence ]
[ Applause ]
>> Good morning.
I'm Nathan Taylor.
I manage the iOS Game Center
team and today, I want to talk
to you about Turn-Based
Gaming in Game Center.
So, here are the things
I'm going to cover today.
I'm going to talk
about turn-based gaming
for the most part of this talk.
I'm going to start with a
brief overview, you know,
what is turn-based gaming and
what other multiplayer types
of gaming does Game
Center provide?
Throughout the talk, I'm going
to cover some new features,
will be interspersed.
Let me give you a little load
on what they are in a bit.
Then I'm going to cover
the basic scenarios
of turn-based gaming and this
is sort of all the scenarios
that you need to cover to
make a good turn-based game.
And in doing this, you know, I'm
going to show a lot of code and,
you know, kind of go over some
of the decisions that you have
to make when you're handling
some of the events you get.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And then I'm going to go
into advance scenarios
of turn-based gaming.
These are some of the things
that are difficult to do
with turn-based gaming today
and show you a solution
that we're offering in iOS
7 to help you solve this.
Game Center has three ways
to do multiplayer and play
with your friends, all right.
The first that we offered
is peer-to-peer multiplayer,
you know, and this
is, you know, device--
a device multiplayer
up to four players,
Game Center provides
auto-matching
and invitations and, you
know, we connect the devices
and provide the networking
layer and allow players
to play a synchronous game.
Similarly, we offer, you know,
through the same auto-matching
invitation mechanism a
server-hosted multiplayer.
And this is where you use
Game Center's auto-matching
and invitations you
bring your own server
into your own networking through
your server between the devices.
And this will allow
up to 16 players.
And the topic of
today's session,
turn-based multiplayers
relatively new compared
to this others in Game Center.
And we think it's going
to be ideal solution
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in multiplayer allows, you know,
up to 16 players to take turns
and passing the turn, you know,
device in a fully
asynchronous manner.
And this is sort of how
turn-based gaming works,
you know, so we sort of have
this table and people see it
around the table and its kind
of like a board game, right?
Everybody's going to take their
turn and the turn will move
on to the next person.
So, you'll take your turn,
indicate to Game Center
to pass it turn to Sue, Sue will
take her turn, pass it to Bob,
and then we've got an empty
seat here and this is kind
of represents the seat that
we're going to auto-match
and fill with somebody else
who wants to play with us.
So, when the turn passes to the
empty seat we will auto-match
in a new player Meg here,
Meg will take her turn.
And then, the other thing
about turn-based gaming is
that the turn sequence is
entirely determined by you.
It's not purely sequential.
So, you can send the
turn to whoever you need
to base on your game rules.
So, here, you know, Meg
will then turn to Sam, Sam--
sorry, let me start that over.
Sam will send it back to Meg,
and then Meg can
send it back to you.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And this will proceed however
your game [inaudible] needs
to go.
You can implement, you know,
skips, reverses, whatever type--
whatever your game needs.
So, Game Center turn-based
multiplayer provides all the
matchmaking in invitation
services.
Your users can invite their
friends to play or they can pick
up and play an auto-match game
with other players
around the world.
The important part to
remember is the matching
and invites are asynchronous.
You know, invites do not
go out until the turn moves
to the participant that had--
you know, that's
waiting to be invited,
and then when they get the
invitations immediately
their turn.
Game Center, also, provides all
the storage of the game save,
you know, we also do
the synchronization
and the updating of clients.
So, we use push notifications
when you pass the turn
to the next player.
They get notified on their
devices and then they can pull
down the game state and take
their turn and upload it.
The turn-based game scenario
in Game Center also
covers player status.
So, this is where you know,
if hey, this person is
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
on auto-match, he's invited,
he's actively playing,
has quit the game, or
when the game is over.
With all this, you
know, we kind of feel
that turn-based game is
really the ideal solution
for multiplayer gaming
on a mobile platform.
Users can play whenever
they have spare time.
You know, we always have
our iPhones with us,
our devices in our pocket.
And, you know, we don't
actually have, you know,
10 minutes to sit together with
somebody and play and, you know,
be involved for a real time
game but we have a spare
of minute here, we're
online, we're on the bus
and we can take a couple of
turns then get on with our life.
So, here's a breakdown
of the capabilities
of turn-based gaming.
Users can have up to
30 simultaneous matches
for your game, so they can
be playing with, you know,
30 different games with
however many game friends
that your game allows.
There's up to 16
players per game.
Gameplay as well as invitations
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in auto-matching is fully
asynchronous, right?
Player one is taking their turn,
the other players two, three,
four don't know anything
about it until it's completed.
The game data can be
up to 64 kilobytes.
You know, a little a while
ago we increased this
from the initial 4 kilobyte.
We offer 64 kilobytes
of storage.
Seats are filled as I
said through invitations
and auto-matching and
it's fully asynchronous.
The turn order is
entirely up to you.
Game Center doesn't take
any part in the turn order.
You specify who the turn
goes to and you can tell us
who it should we go to next
if that person is unavailable.
And to that effect we
have this fallback list
so you can specify
a complete list;
it could be all the players in
the game of who we should go
to in case the next person is
not available and the person
after that's not available.
So, it provides a recovery
mechanism for games
or people are away or
forget about their game.
And finally, we give time outs.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You can specify a time
out but the default time
of the game center
uses these two weeks.
So, let's take a look
at what actually happens
with the game data.
The way game center
does synchronization
of term based game data is
that the person whose turn
it is is the only person
who can write the game data.
All other players can, you
know, download from the server,
read from it and view the
game state but only the person
who knows the term can write
new data to the servers.
So, you have to turn
here and you're going
to write the data send it up
to the Game Center servers
and pass to turn to Sue.
Sue gets notified.
We badge your application
on Sue's devices,
and then when Sue decides to
launch a game and play it,
he will pull down the game data
and then Sue can take her turn,
move it, pass the turn to
Bob and Bob gets notified.
But Bob is on vacation
and can't play.
So, your time out
comes into effect.
You fallbacks fall
and also take place
and we automatically will
notify Meg who can then pull
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
down the turn data
and take her turn.
And then, it's up to you.
Do you want to let Meg choose?
Do you want to give Bob another
chance to take his turn later?
Or, do you drop Bob
from the match?
It's up to you and your users
on how your game should
proceed in the state.
So, let's take a quick look at
what the match data is, right?
This is basically
an NSData object.
It's completely opaque
to Game Center.
We don't write anything to it.
We don't read it.
It's just a blob that we pass
it to servers, store for you
and it will let you
download onto--
into the game so you
can show your data.
You completely define
the contents.
Only the current player
can upload new data.
And they can upload new data
with an intermediate upload
and they upload new data
when they finish their turn
and at the end of the game,
you upload the final state.
All other players can read
this data at any time.
The can pull down,
view the current state.
So, if there's stuff you want
them ask in there about turn,
well, you know, sets some flags
in the data so they can see,
hey, you know, this
guy is taking his turn.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
I don't want to show you
what he's done, you know,
fog of war type of stuff.
Remember that it's
limited size, 64 kilobytes.
It's not a whole lot, you know.
But you can do a quite a bit
with it as long as you are smart
and you use and, you know,
efficient data packing
strategies.
You know, small games
might be able to get away
with encoding a P-list
or, you know,
serializing our objects
directly into this.
But if you got a more complex
game, you going to want to think
about this, you know, turn your
games into some [inaudible],
use some bit fields, do what you
need to to pack data tightly.
If you need more,
you can always point
to data stored on
your own servers.
And to do this you can either
store reference inside the match
data, or you can
just use the match--
session ID to reference it.
So, users have some
interesting expectations
of turn-based games, right?
It's a little bit different
when they're playing
peer-to-peer game,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
you're playing one game
and that's all there is.
You know, you can't
really do anything else.
But with turn-based games
it's always asynchronous,
they can come and
go as they want.
So, to get this, they
expect to be able
to have multiple
simultaneous matches.
So, your game needs to be
able to handle the scenario.
You now, you don't want to be
in this case with the user,
you can just have one match
but somehow get a second
and there's no way to
manage it in your game,
that's a problem, right?
How do they find the match
with the other friend
if they're playing?
Each game has its own
state, its own players,
and in the end, its own outcome.
And some users like to keep
the match around and be able
to show it to their
friends when they've won.
You know, when they got all the
work, all the titles filled,
they can show off
to their friends.
One player at a time, right?
It's turn-based.
There's only one
person taking the turn
and they're the only person
who can upload the game state.
Other players are observers
until it becomes their turn.
And the other thing in
your mind is your game
on the other device
is not running, right?
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
These things are handled
through notifications
that game center handles.
We will tell you-- your game
will launch when we needed to
and the user going to take,
you know, choose a match,
take their turn, exit, go back
to, you know, doing work and,
you know, whenever they get
a notification they'll take
another turn.
And the tricky part with
turn-based gaming is
because it is asynchronous.
You can get notified about
any of these other 30 matches
that the user might have in
their game at any time, right?
User's playing one match
and gets a new turn
in another match.
Sometimes the right
answer here is take them
to that other match.
Sometimes it's not.
You know, and you often want to
give the user the choice but do
so in as non-disruptive
way of possible.
You also may have
user-viewing the game and one
of the players is not their turn
when someone takes their turn,
you know, and passes it to,
you know, the third player.
And there you might want
to immediately update the state
'cause they're looking at it
and show the live updates.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You can make it feel
like it's a live game.
And I'm going to go into the
decisions you have to make
when handling these kind of
events, so that it can give sort
of the correct and ideal
user experience here.
So, before I start
looking at some scenarios,
let me give an overview of some
of the new features
we have in iOS 7.
One, the first here is that we
allow you to report the scores
and achievements for all
the players of the match
from the one device that
the takes the final turn.
This was a request
and it was a good one.
It was really hard to get the
right scores and achievements
up when actually the last
term can change all that.
So, one player with
the final submission
of the match can report all the
scores, because now this is,
you know, an internet
world and people play
in multiple different
countries and have, you know,
speak different languages.
We now allow for you to
specify turn messages
that will be localized
on the receiver's device.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, with a little extra work,
you can specify, you know,
when you send the turn, you
know, the message, you know,
key and we will localize it
for the user that receives it.
We also have a new feature to
be able to easily remind people
that have forgotten to take the
turn this is now their turn.
So, there's an API to do this
and you can give
your users buttons
to remind their friend
to take turns.
As alluded to in
the earlier games
in our talk there's an
improved event handling model
and I'm going to go into
some depth on this on how
to use this event handling
model for turn-based games.
And then, we have
a big new feature
and this is what will help us
all in the advance scenarios
in turn-based gaming and we
call turn-based exchanges.
I'm going to talk about
more-- that more at the end.
And lastly, you know, game
center its little tricky debug
at times with turn-based gaming.
And so, we've done a little
bit better parameter checking
in error handling.
So, hopefully, you know, with
iOS 7 you'll get notified
of mistakes that you may making
your code and catch those
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in sandbox before you go
live and I hopefully be able
to figure them out easier.
So, let's take a quick look
at the primary classes you use
in doing turn-based gaming
and the principle class
of all is the turn based match.
This represents the
game instance
and you might have 30 of them.
It includes the list
of participants.
You know, these are the
empty seats or the players
that are filled in
and playing the game.
It includes the current
game state.
You know, this is the
NSData that you provided us.
We also let you know who
currently has the turn
so you know if it's your player
on the current device
or someone else.
And with turn-based
exchanges, all exchanges
that have been made
are also listed
and accessible from the match.
The next class, the participant,
you know, this is the seat.
This is how many people
are playing the game
and who they are if you know.
Alright so, if we know who they
are it's a player ID but you got
to keep in mind that
maybe an open seat
and maybe waiting to auto-match.
It may be an invitation
that your player sent,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
you'll know who it is but
they haven't actually gotten
to take the turn yet.
This also then includes
the status,
so that you can know
this, right?
Are they invited?
Are they matching?
Are they currently
playing the game?
Or are they done?
And lastly and it's a little bit
often forgotten is the outcome.
For each participant of the game
when you end the game we've
[inaudible] a mechanism
to set the outcome and we
provide you a basic enum
so you can set this
to, you know one lost,
first, second third place.
And there's also a range
in this [inaudible]
that you can use
for custom outcomes.
So, you can use this to
display state in your game.
And you need to fill this
in when you end the game
or when a player
quits on their turn.
So, the other class, you
know, that you often use this
that the Game Center GK
turn-based match maker
view control.
This is the Game Center
interface for turn-based games.
Now, if you want easy access
to creating matches
inviting friends
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and listening available matches
and allowing management of this,
you can use the view controller.
It per basically provides
management from matches.
So, let's look at
the basic scenarios
that all turn-based games kind
of has to be able to handle.
And I'd like to say, you know,
that is only three items,
but I've got seven on the slide.
You know, and the
kind of a grouped
into sort of three things.
Creating a match, dealing with
the turns and then dealing with,
you know, and managing
multiple matches.
So, the first thing
you're going to want
to build is make sure a way--
there's a way that in your app
for user to create a match
and invite their friends.
Then the thing you're
going to do most often
and most important thing
to get absolutely right
is playing a turn, right?
This is your game logic and then
how you communicate that turn
to the Game Center server.
At the end of the match, when
all the turns are taken you need
to end the match appropriately.
This will notify all the
users that the game is over
and just put it into
the completed section
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of the other list and make it so
they can remove it if they want.
And then in managing
matches, you need to be able
to list all the open matches,
remove a match and quit a match.
In quitting, there're
two ways, you know,
in turn or out of turn.
So, creating a match can be
done with the view controller.
If you want to use our UI,
you can use the turn-based
matchmaker view controller,
provides all the
management you need,
list the matches allows users to
remove them with a little help
from you, they can quit in turn
and it provides auto-matching
invitations.
And you create this by
specifying a match request.
However, if you want to do it
programmatically and you want
to provide your own UI for this
and we encourage this, you know,
nothing kind of fits
better in your app
than your own, UI design.
We provide a mechanism so
you can do auto-matching
and invitations
programmatically.
And that's what I'm
going to show you next.
It's really not too difficult.
This is how to create a
match and allows someone
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to invite their friends
at the same time.
So, you provide a mechanism
what the user choose,
which friends they want
to invite, you know,
get the player ID's
of these friends.
Set up a match request.
We'll just specify the
minimum and maximum number
of players here, four and four.
And then we'll set the
players to invite on a--
on the match request, right?
So, players to invite
as a property
that you put your friend ID's
in and set the invite message.
Usually this is something we've
recommend you'll have the user
type in 'cause this is kind
of a personal message that's
[inaudible] to the friends
that you're going to invite.
And then one API call,
it's a class method
on GK turn-based matching you
can call, find match for request
with your request and
then a completion handler.
On completion, you
either get a match,
it will immediately be your
players turn in that match.
They'll need to take some
action or you'll get an error
if we were unable to
create that match for you.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, said users can
enable to matches
and you can see matches here
can be in various states.
It might be your players turn.
It might be someone else's turn.
You know, so, how
do you handle this?
Well, it's really simple.
There's pretty much two
APIs and you do and sort
of two actions you need to take.
If you want to list matches,
build your own UI around this.
You can use the class
method, load matches
with completion handler.
And this will give you an
array of the existing matches.
All the active matches,
all the completed matches
and then you can sort
this as you'd like
and display it to the user.
When the user's done
with the match, you know,
you want to implement
some way for them
to remove this match
from their list.
You know, some matches will
get auto removed overtime
as new matches are
created, but users want
to keep their list clean.
So, provide a mechanism
when you remove a match
and it's quite simple.
It's an instance method on the
turn-based match called Remove
with Completion Handler and
this will simply remove it
from the users match list.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And then alternatively you
can use the view controller.
So, most important
thing you can do
in any turn-based
game is take turns.
Every player in the
game presumably is going
to take a turn, multiple
turns and this is going
to be the most common
thing and there's a lot
of stuff you want to do here.
So, essentially taking a turn
involves making the match data,
passing it up to the server,
setting who the player is next.
And so, let's take a look
at the actual full sequence.
First, you're going to
unload the current state
from the server.
So, this is the effect, pulling
down the most recent match data,
so that you have current stuff--
most current data to operate on.
You will then apply
your game logic to it
to both allow the user
to take their turn.
You will then be able to save
the enemy, hit save if you want.
So, if the users in the middle
of the turn, it's really nice
to let them save their state
so that if they want to resume
on another device, but they
happen to put the device away
and your app gets jetsam to be
able to come back and come back
to where they were in
the middle of their turn.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You can save the enemy at state.
And in doing this, you have to
keep in mind that other players
in the game can see that state
unless you explicitly kind
of hide it through flags
in the match state.
Next, when the user is done,
they've taken their turn,
you know, kind of the results.
You need to choose the next
player sequence, right?
Who should the turn go to
next and specify the fallback
so that we can recover
gracefully
if that person is unable
to take their turn.
And then finally, you're
going to submit the turn
to Game Center and Game Center
will then notify the next player
and this will repeat.
So, to load the current state,
there's basically a
single API to do this.
It's an instance method on
the match, load match data
with completion handler.
This will return to you,
your latest match data
and then usually what you'll
do is take the match data,
you know, and apply it
to your view controller
and show it to the user.
After that, you know,
you've let your user play
with the match there, right.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
They've taken their turn.
They manipulated
the data, they've--
you know, drawn some cards,
moved their token, roll the die.
You'll want to, you
know, update the match
or generate the new match
data for the user actions.
Now, because I said,
you know, your device
and user make want to-- you
need to put your app away,
your app is in the
background and make it jetsam.
The user might want to
switch to another device
and pick this up later.
Save the enemy that
state to server, right?
And to do this, there's an
API called save current turn
with match data with
completion handler.
This doesn't move who
the current turn is.
This only uploads the new
data or into the server
so that's available
to all the players.
And then, we're going
to continue,
you know, taking the turn.
So, the next step as I
mentioned was to choose
who which you go to next.
This is entirely based
on your game rules.
Game Center doesn't
really take any part
in who the turn goes to next.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
The things you keep
mind though is you need
to select active players
or players that you want
to become active,
remember auto-matching
and invitation is asynchronous.
To get those people into the
game, to get send invites
to auto-matching when--
they need to get the turn.
And when they do, it will
be that persons turn.
You also want to be able to
guard against missed turns.
So, you can check to see
if a player has timed
out in the past, right?
And you can also provide--
you provided us the list of
the multiple participants.
You're not picking
just the next person.
You're going to give
us everybody.
You can find out who timed out.
Make the decision or look if the
user choose whether they should,
you know, still be in the game,
you know, if they time out,
did they forfeit or did
they get three tries.
That's up to you, right?
You then, you know, just specify
this list of participants.
You're going to use time outs so
that if someone takes too long
or it's not available to
move on to the next person.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
The last person on this list
because after that games
and doesn't know what
to do won't time out.
And what we actually recommend
you do here is basically specify
the full turn cycle
and put the last person
on the list is the person who
is currently taking the turn.
This way if everything
goes wrong,
the person who took
the turn last played
in the game can make a decision
of, all right, if I want to give
up on this game, I want to
go play with someone else
or do I try again, right?
So, this is the work
that you need to do here.
There aren't really an API's
on this slide but you're going
to again update your match
data with the latest state.
You're going to determine
the next participant list
and then you're going
set up a turn message.
And this gets us into
the next new feature,
localizable message.
You're essentially going
to be providing us localizable
strings in your bundle.
Game Center will use the strings
on the recipient's device
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to generate the message that
we show in notification center
on the lock screen and
the message of this show
and the Game Center
user interface both
from the Game Center app.
And in the-- you know, in
game UI in your screen.
So, this allows us to actually
show something, a message here
that is localized to, you
know, the user current device.
And we've seen games that
you, you know, that, you know,
this player played
this word, right?
It would be nice
to be able to make
that appropriately localized
and this can be a format string.
All right, so that you can say
you can specify the player name,
you give us the word
played and with any formats
and with to format parameters.
And then you give us, you know,
the word if you're a word game.
We localize it on the recipients
device, but before we send it,
we also as a fallback localize
it on the senders device
and the senders language,
because there is a chance
that the person, if it's
being invited to play the game
for the first time it may
not have it on the device.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Their bundle's not there.
We can't localize the message,
but we will have
something to fallback to.
And then, you know, ideally the
user will quick notification
Game Center will take
them to the store
and they will buy your game.
To do this, we need
two items from you.
The first and most important
is the message string
or format string.
You know, this is works to
the standard, and you know,
localizable strings mechanism.
So, you're going to specify a
string key that will be looked
up in your localizable strings
table inside of the bundle
on the recipient device.
Optionally, if you're using a
format string, you can pass this
to us in array of
format arguments.
So, let's look at how
we do this, right?
This first part is
your job, you know,
giving us the key
and the arguments.
Then on the match, you're going
to set the localizable message
with this key and arguments.
And then, finally
we're to the meat
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of this whole taking
a turn sequence.
This is the last bit.
We're going to end
the turn, right.
Your user has done
everything that you need to do.
It's time for the next
person to take their turn.
So, you will call in turn
with next participants
specifying there's array
of participants that
we determined earlier.
Specifying a time out, here
we use the default time
out using your current match
data that you determined earlier
and then the completion handle
would be called with an error
if there is a problem
submitting this turn, otherwise,
it will move on to the next
player and they will be notified
and the game will proceed.
Reminders, this is
another new feature, right.
Turns-- Turn-based games
is fully asynchronous.
You know, we notify the
user, they download the data
when they're ready to take a
turn but nothing happens if,
you know, until they actually
launched the game and do it.
The games can only
proceed as fast
as their slowest player, right.
Each player gets a turn.
They spend their
time taking up turn.
They forget about it perhaps.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Time outs and fallbacks help
keep things moving along.
Help us recover from
failure cases.
But it's really nice to be
able to continue in the game
and be able to nudge someone,
"Hey, remember you're playing
with me and take your turn now."
So, sometimes, you need to
remind a player to play.
And we do this through a simple
API and to send a reminder
on the turn-based game.
It's a single one way push
with a localizable message.
Let's take a look at
the code to do this.
Just as before, you're going
to set up a localizable message
with arguments and then call.
Send reminder to participants.
Note that is actually
an array of participants
with the localizable
message key in arguments
and the completion handler.
And you'll see why
the array is kind
of important a little bit later
but the common case
is the sender
to who currently has the turn.
But there are cases
with some new features,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
turn-based exchanges where you
might be waiting on actions
from multiple people and
you can remind everybody
to take their actions.
So, it's all over, right?
All the turns have been taken.
All the cards are played.
You know, there's no more
property to buy somewhere.
Everybody's gone bankrupt.
Whatever rules determine the end
of your game and
you decide that.
And instead of take-- the
last person taking their turn
and moving on to someone else.
You decide that, all
right the game is over.
And now, I need to end the game.
And what do you need to do?
So, when it's all
over, you know,
there are various
reasons this can happen.
They finish your game
according to the rules, right.
There's nothing left
to do in the game.
And then, there are other cases
where games can end, right?
If everybody quits the game, you
know, and they can quit in turn
or they can forfeit
the game out of turn.
You know, these are things to
think about in winning the game.
But ultimately the game is
ended by the last person
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to play instead of
taking their turn.
And so, instead of
calling in turn
with next participants you're
going to call a different API
and let me get to that.
So, before we end the game,
right, it's usual to be able
to say and let the user
know, who won, who lost.
So, we'd like you
to set the outcomes.
So, we start here by taking
the current match data
and determining your final match
data, this last match data.
You know, this is so that
everybody whose still has the
game in their session list
can download the match data,
can show off how well or poorly
they did to their friends.
Then you're going to walk
over all the participants
in the match and then for each
active participant, you know,
people out still
playing, you know,
we want you to change
their status to done,
because they're not
playing anymore, and then,
determine their outcome and
set the outcome property.
This is entirely
based on you, right?
You're going to look at
the match data, you know,
you know the positions
of the different player,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
you'll set the outcome,
and you can use our enums
or you can use-- you notice
the reserved bit range
and user custom outcome so
you can pull this down later.
This will be saved in the
match when you end the turn.
And so, when later you
download the match,
you can query this
off to participants.
[ Pause ]
Let's continue on the
ending the game here.
We get to another new feature
and this is what I kind
of start of any features.
At the end of the game,
you now know the scores
that everybody got, the
achievements that everybody got.
And this used to be
a real kind of tricky
in hairy situation, right?
You-- Before now, you would have
to kind of submit a new score
as everybody took a
turn and kind of hope
that that was the final,
you know, representative
of the final score at
the end of the match.
And submit achievements
as their earned
and we still recommend
you to do that.
But at the end of the game
you can now generate scores
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
for all the participants
and generate achievements
for all the participants.
There are new APIs for
initialization of scores
as you can meet them
with player IDs.
So, they will be specified
to someone who's not
the local player.
And then, when you're in the
match you can use the new API
to in match and turn
with the new match data.
This is your final match data
and we give us the
scores and achievements.
Games Center then we'll submit
these scores and achievements
in bulk associated
specifically with this match.
So, we know who is
participating.
You can't submit scores
or achievements for people
that weren't members
of this match.
This is really the only way to
submit scores for someone else
and we're using the
match and the match data
and the participants on the
servers as a verification
of this data that things
are being submitted
for the appropriate people.
And then at the end
of the match,
you get a completion handler
an error will tell you
if there're some
problems submitting this.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
That's it.
When you're done,
that match is over.
Your user can look at it
and view it some other time,
move on to other
matches and play.
But all along this process,
because turn-based gaming is
asynchronous, there were events.
You've got events for invites,
the very start of the match.
You got events whenever it
became your players turn.
And you get events when the
turn move between other players.
We have a new mechanism in
iOS 7 to handle these events.
Previously, we had basically a
singleton GK turn-based event
handler object that you
would set a delegate to.
And it was a singleton and
you can only have one delegate
and you had to kind of process
events all in one place.
We now have this listener
model and you're going to want
to implement the GK
turn-based event listener.
It's a protocol for
turn-based events.
These events include state
changes such as invitations,
new turns, turns getting
passed, match data getting saved
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and updated, as well as match
ended events when you're
in the game and for the
turn-based exchanges,
the various exchange
or events for requests,
cancellations and completions.
As with all the events
these kind of come
from the local player.
The local player is the producer
of these events 'cause
they all sort
of involve the local player.
And this replaces the older
turn-based handler and delegate
which we have deprecated
in iOS 7.
The nice part is you can
have multiple listeners.
All of the protocol
methods are optional.
You can implement the ones
you want, where you want them.
And so, it can simplify the
decisions you have to make.
For example, your app delegate
can remain in responsibility
of receiving new turn
notifications, right?
When the user activates the app
and you've got a turn, you know,
you want to jump right into
that and you're going to start
that with your app again.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
But, if the users viewing a
match, your view controller
for that game state can listen
for the events for updates.
And it can ignore all
other updates except ones
that affect that match.
And then it can just show
the updates to the user.
It doesn't have to worry
about anything else.
To do this, you know, you're
going to set up for listener.
And you start by
adopting this protocol.
The next thing you do is you're
going to register your listener
or listeners with the local
player using the simple
registered listener method.
And as I've said, you can
register multiple listeners.
You can separate
responsibilities in your app.
And ultimately you
can have simpler code
and less convoluted
decision trees
when you get turn-based events.
So, let's take a look at
what the protocol provides.
These are the basic turn events.
We have, you know, the
generic turn event.
This is when the match state
changes and it's, you know,
player received the turn event
for match, did become active.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, this is you and
get this is on invites.
You can get this one
when it comes your turn
and when the match
state changes.
The next is match
requests from Game Center.
This is relatively uncommon, but
Game Center provides a mechanism
for users to essentially
choose to play your game
with one of their friends.
When this happens,
your game gets launched
and the event you will receive
is player did request match
with players.
The right action here is for
you to create a new match
with these players, so that,
the user can immediately start
playing with their friends.
And finally the last basic
event we have is the match
ended event.
You've ended the
turn and all players.
So, you've ended the match and
all players now get notified
that the match is over.
And this is player match ended.
So, let's take a look
at the new turn event.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
As I've said, this is sort of
the most complicated scenario
and I'm going to actually walk
through this with the sort
of the full decision
tree you make.
So, it's going to go over
kind of multiple slides here.
And we're going to start
here with, you know,
the method its player
receive turn event
for match did become active.
And the part focused on
first that did become active.
This flag will be, yes, and
true win the event is the one
that we activated
your application for.
And this happens when the user
taps on a banner for the event
in a notification
center, you know,
they swipe on the lock screen
when we launch their game,
or they select the
turn-based match in Game Center
in the turn, you know the common
turn list that we all have
and select to play this match.
We will launch your game and you
will receive this event as soon
as you set up this listener.
If did become active
is true, what you need
to do is immediately
switch to this match.
The user has already
chosen to play this match.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
It doesn't make sense
to ask them again.
You want to basically save
off any current state,
allow them to go
to this new match.
And then you're done,
you don't have
to really handle anything else.
You know, you-- they're
ready to play.
But if it's not the one that
activated your app, now you want
to handle it more selectively.
So again, we're going
to continue
with the received
turned event from match.
Here, we want to
look for matches
that are the current match.
So, this is something
that if you were--
you want a separate
responsibilities
that your view controller
for the game can do.
And then you just can
listen for matches
that match the current match.
Now, you can do the easy equal
check between my current match
and the matches passed
on this event.
If it is a match, it's the same
one, you can call refresh match
and update the UI for the user
so they can see the latest turns
that were taken and-- yeah,
you can do simple animations,
whatever is necessary
to make your game fun.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
If it's not the current match,
there's a little
bit more work to do.
So again, we're going to receive
a turned event, this time,
it's not the current match.
What's the right
thing to do here?
Well, did the player
just get a new turn?
Is it the player's turn?
So here were checking this
by comparing the current
participant's player ID
to the local player's ID-- like
the producer of this event,
the player passing
is the local player.
If these player IDs are
the same, this indicates
that your player now is the
current player in this turn.
That's kind of an
important event.
So, what you want to do
here is consider some way
to notify the user.
They might be busy in having fun
taking a turn so you don't want
to take them immediately
out of that current match.
So, we recommend, you know,
some way to notify them.
You can use Game Centers, you
know, notification banner,
API and show a banner on
the top of your screen.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You can-- put a badge
on your UI somewhere.
You can show an alert
but let the user know
that somebody is waiting
on them somewhere else,
that they have another option--
but don't take them out
of their turned context.
All right, so that wraps up
the turn events and we'll look
at now this match request.
As I said, this is rare but
it's an important scenario.
The user wants to play
with their friends.
In Game Center, the application
has launched your game.
How to handle this is
really quite simple.
It's like creating any match.
So, the first thing you do is
you create a match request.
Here, I create one with,
you know, two players.
I'm going to set the array that
was passing a play ready is
to invite as the players to
invite on this match request.
I'm going to let the user
specify the invite message
and then just like any--
creating a match I showed
you earlier, you're going
to simply call find match for
request with completion handler.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, that's everything
you need do
for basic turn-based
gaming today.
Now, I'm going to get
into the new stuff.
This is turn-based
exchanges and you might ask,
what is turn-based exchange?
Well, a turn-base exchange
is an out of band exchange
of data between players.
Recall that with the current
turn-base gaming mechanism,
the only person who can,
basically, put new data
into the match is the one
who currently has the
turn, he can upload it.
And when he does that, he
passes the turn to someone else.
Exchanges allow you to
pass a little bit of data
from one player to another,
from any player to another.
And this is done through
basically a single reply,
a single request, and
then a reply, one reply,
from each player that that
request may have been sent to.
What this allows is for you
to do some interesting things,
you can do trading, you can
do auctions, but you also get
to keep the current player
of the game, you player,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in control of the duration
of their term, right?
Other ways to handle some
of these complex scenarios
which I will show
you later, you know,
you're kind of relinquishing
control and-- and the game can,
you know, kind of get messed up.
But we now allow users
to control the duration,
have the communications with
the other players in the match,
and be able to control how
long it takes with time-outs,
and you have the ability
to cancel this at any time.
And as with everything
in turn-base gaming,
this is fully asynchronous.
You know, the user
only has to wait
as long as they want to wait.
You don't have to
wait for a reply.
You can abandon it
and cancel a request.
Why are we giving you exchanges?
Well, we heard a
lot of feedback.
There were kind of-- when we
introduced turn-based gaming,
there were some concerns
about how this would work
with more complex games.
And we believe, exchanges
are the solution
to these difficult scenarios.
Let's take a look at
some of the scenarios
that we think turn-base
exchanges really help solve.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And I expect that you, being
as creative as you are,
can find some really cool
usage of-- uses of these.
But the primary one, you know,
one of the first ones here
is trading resources, right?
You're in the middle
of turn-base game
and your player's taking
their turn and they want
to trade some gold to
someone else and get some ore.
Well, it's challenging.
What type of trades are there?
Well, there are trades that are
initiated by the current player.
We could make that happen
with turn-base gaming
before exchanges.
But there are other types of
trades such as trades initiated
by a different player who
doesn't currently have to turn
with your player or
trades between two people
that are unrelated to
the current player.
We also offer things like
auctions of properties
where you're going to
involve one or more
or all the players
in the action.
And then you can do things
like simultaneous turns
or otherwise known as
kind of gated matches,
where you let everybody
take a small action,
you gather the results, you
integrate it into the turn,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
you move it on, and
you take next turn.
And this also can be used for
like a simple messaging thing
where you can let users send
thoughts, or cubits and kind
of send little hints out of
band and to their partners.
So, before exchanges, how
would you handle these
difficult scenarios?
Well, it all starts
with the turn, right?
You start with the turn, then
you might edit the game state,
put it into some special mode
that says, "Hey, I'm trading."
And then you're going to
pass the turn to the players
that the user wants
to trade with
and you'll give it
a short time-out
so that you can actually
recover and then return the turn
to the original player.
And at the end you'll resolve
a special mode, you know, "Hey,
the user accepted the
trade, but the resources
in their game state let
them finish their turn."
Why is this really hard?
Why is this none ideal?
Well, you've relinquished
the turn and that means
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that the full duration
of this turn is not
under the player's
control, right?
If the other player that you
gave a turn to that you want
to trade with, answer is
fast, create might work,
but if you have to
wait for that time
out if they're not
available to reply,
they can take a very
long time to resolve
and your player never really
got to finish their turn.
What is this look like
with the exchanges?
Well, it's simpler
here, you know,
we've taken out a
few of the steps.
We start the turn, we
request an exchange,
I want to trade with you.
You receive a reply,
here is my counter offer,
you'll then take this
exchange you'll resolve it
into the matched data, maybe
you'll initiate more exchanges.
But you can leave
this up to the user.
What they're doing
is based on them.
If they don't want to
wait for them for reply,
you can cancel them for them,
then they'll end their turn.
What are-- what are the
classes you use for exchanges?
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Well, we added a
few more for this.
Obviously there's a new class
called GK turn-base exchange.
This represents the requests.
It has the sender, that's
usually your player,
but it can be any of the
people if you're sending them,
you know, the [inaudible]
player.
All the recipients of the
exchanges, this is one or more
of the participants
of the match.
You can send these
to open seats, right,
just like moving a
turn to an open seat.
You send and exchange
to an open seat,
it will trigger the invitation
or trigger auto match to fill
that seat, so someone will come
in and handle that exchange.
Each exchange has its status,
whether it's active, if you--
it's been canceled,
if it's completed,
and then the final
one is resolved.
Each exchange covered
its own message, right,
so you can include
a visible message,
a string for the user
and a small payload.
We allow you to specify data
up to one kilobyte
with each exchange.
And then the exchange
will track its replies.
You might-- if it's only sent
to one person, you get one reply
and then it will be completed
and you need to resolve it.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So the next class, obviously,
as it falls from this is the
GK turn-base exchange reply.
This has the recipient.
This is the person who
current exchange was sent
to and who is replying.
It has a message, so you can
have a message in response,
you know, and these generate
banners and notifications,
so that the user can see that
they left-- they left the game,
they can see, you know, that
hey I got a response, you know,
this person like, you know,
will make a counter
offer for my trade.
And then each reply has a small
payload as well, one kilobyte,
so that you can, you know,
take this payloads and request
and reply and then integrate
them into the match data.
So, what does this look like?
We've got our table here.
You have the game data.
It's your turn.
But you want to trade
with Meg and Bob.
So, you'll send one
exchange out to Meg.
We're going out of band
here so the turn goes away,
and we'll send another
exchange to Bob,
both of them will get notified,
now we're waiting for replies.
We get a reply quickly form Meg.
And we like it.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You know, the user--
users happy with it.
They accept the trade, so you
can cancel the exchange to Bob.
Integrate the results of
this exchange in reply
into the turn-base-- turn state,
go back to taking the
term and then finish it.
Upload the turn data that has
the results of the exchange,
and then move the turn to Sue.
So, there's sort of a
three Rs to exchanges.
This is what you want to
remember from exchanges.
You're going to request
an exchange,
all right, the first R.
It all starts with this.
It can be started by any
player in that match.
It can be started at any time.
Each exchange can target
one or multiple players,
and they all include
a small payload.
The next R, the second is
to reply to the exchange,
each player that we send the
exchange to, we expect a reply
from or time-out and you
can cancel if you need to.
And then the last
or the important one is
all completed exchanges,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that is all the exchanges that
we've got replies for need
to be resolved into the
match date before ending the
current turn.
If you fail to do so, you
will receive an error,
and you'll need to go
back and resolve those
into the state and
then try again.
So what does this look like?
Well, to request an
exchange, you know,
determine the number of players.
You can send it to one of more
people, remember you can send it
to empty seats, so if you--
especially if you're doing
like a gated turn-base match
for simultaneous
turns, you want--
sending it to empty
seats is very important
to be able to fill them in.
For each participant
that we sent it to,
we expect a single reply.
And the API to do is send
exchange to participants
with data, localize
well message,
arguments, and the time out.
And then you'll get a completion
handler that will be callback
with the exchange that
was successfully created.
Replying is essentially
just as simple.
This is an instance method
on the exchange itself.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Each exchange gets a single
reply form each participant
that it was sent to, and the
exchanges marked completed,
once all replies or
time outs are received
from each participants.
And then once completed,
you need to resolve it.
So to reply, you call reply
with localized well message,
given arguments, the data
payload that is all yours,
and the completion handler.
And then that's it.
The reply is sent, the
recipient receives it,
and the game can move on.
Once your user is done
with an exchange, right?
They don't want the results.
They're tired.
You know, they want to get
on and finish their turn.
You can cancel exchanges.
This leaves the control and
the duration of the exchange
and the turn in control
of your player.
And so when you don't
want to wait
for further replies, cancel it.
You can cancel active, once
that you're still waiting
for replies, or even
complete an exchange.
I mean this is going
to essentially say,
I'm discarding the results
from this completed exchange.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
I don't need to reconcile,
resolve it.
And the act of cancelling
an exchange removes it
from the match.
So, did you saw-- you can
call the instance method
on the exchange; cancel
with localized message,
given some arguments and
a completion handler.
The users that have been waiting
for exchange will be able
to see a notification
that, yes this request
that you've done
previously has been canceled.
And lastly now, the final R
is resolving the exchanges.
Remember that all completed
exchanges needed resolve
and an exchange is complete
once you receive all the replies
for it including time outs.
It's also very important
to remember that you need
to resolve all the
completed exchanges
and that exchanges could
be done between players
that are not the current
player, some of you--
you're going to have to
check and see, you know,
which exchanges have been
completed, handle that
and integrate that
into your match data.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You know, how you do
that is all up to you.
You own the payloads and the
requests and the replies.
You own the match data, you
know, but you need to tell us
that you have resolved
this exchange,
and we will remove resolved
exchanges from the match.
So what you do is you gather
the data form the exchange
and reply.
You do what you need
to with that.
You then merge this into
the match state and then
when you resolve it,
we'll remove the match
so that it's no longer there.
Resolving the exchange.
So, we give you a
convenience method
to get all the completed
exchanges on the match.
It's this property,
completed exchanges.
You're going to go-- then
take this completed exchanges
and you're going to gather
the data-- the match, sorry,
the data from each exchange
and each reply and put it
into your new match data,
the merged match data here.
And then just like when we say
saving an intermediate turn,
we have this method where you
can save this new merged data
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
without passing the turn.
So, you call saved
merged matched data
with resolved exchanges
and completion handler.
And the reason you want
to do this is you want
to resolve exchanges
as they get completed.
But you don't necessarily end
the turn when you do this.
And then usually
continues with the turn.
Exchanges have their own event
handler protocol methods here.
So, as I mentioned
earlier, there are three.
You get to be notified
with an event
when you're player receives
a new exchange request,
that is player received
exchange request from match.
You'll be notified
when exchange request
that your player
has gets canceled.
The player received exchange
cancellation from match.
And you also be notified
when you have in exchange
that you sent out
has been completed,
or any exchange has
been completed.
And this is, you know,
the player received
exchange replies.
We're going to give you
all replies at this time.
For this completed
exchange, for match.
So, let's look at how we, you
know, what kind of we want to do
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
when we handle an exchange.
This is sort of similar to
getting a turned event, right?
Exchanges, you know, user
handling exchange, they're going
to be playing your
games like a mini turn.
Right, so you you're
going to want
to determine whether this
exchange, you know, the match is
for is your current
match, right?
If it's the one the
user's currently in,
immediately show them
the data, hey, you know,
there's a trade request
if you want to handle it.
If they're doing
something else in your app,
they're playing another match,
the same logic kind of holds
that we have for
turn state changes.
You don't want them to take this
immediately 'cause this will
interrupt what they're doing.
But you want to, you know,
notify them in some manner.
You know, showing some badge
in your UI, showing an alert,
using Game Center's
notification banners.
When you get in a cancel
exchange, it's pretty similar.
You know, if the users kind of
currently working on that match,
viewing that match,
dealing with that exchange,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
you need to basically, say,
oh sorry we don't need you
to reply anymore,
return them to the match.
If they are, you know,
not dealing with this
exchange right now,
what you do is a little
less important, right?
You know, you've notified
them somehow, you know,
you've got a badge count.
Well, you want to clear
that so you'll, you know,
we use that badge somewhere,
hide your alert if you had one,
you know, clear the banner,
and then they'll be
able to continue.
Finally, you know, when
an exchange is completed,
you've done all the replies you
expect to receive, you know,
what do you want to do here?
Well, you're user that's getting
the reply is probably going
to want to do something with it.
If it's a trade, you know,
you'll see all the
different offers and you want
to let them pick which
one if they want to accept
or maybe make counter.
And so, you know, we check,
this the current match,
is this the current exchange,
immediately show
them the replies
because they're ready
to see that.
If it's not, you know,
show them, you know,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
or clear appropriately the
banners that you need to show.
And let them know that something
is waiting for them to finalize
and finish their
match-- their turn.
So, I mentioned that
this also helps also
in difficult scenarios
and I talked about trading
and simultaneous turns,
and auctions of properties.
Let's see how you do this.
Using exchanges for trading,
you let the user decide
what they're going
to offer for trade, right?
It all starts there.
Then they will send
one exchange request
to each potential trade partners
or if it's going to be offered
to everybody, you'll
send out, you know,
one for each participant
in the match.
Once they've decided
they like something,
they can cancel all the
outstanding exchanges,
and then move on.
You know, you resolve the
complete exchange into the match
and let the user go on
and finish their turn maybe
they'll make another trade.
And they could have
multiple trades going
on at the same time.
It's entirely up to your logic.
What does this look like?
Well, you've actually seen
this animation before.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You get the match data, going
to send two requests
to Meg and Bob.
Meg's going to give
me a reply, I like.
I'll cancel the request to
Bob, resolve it into this--
the match state and
finish the turn.
Simultaneous turns, it's
a little more complex but,
you know, it involves
basically a single exchange.
So, you're going to
send one exchange
to all the participants
of the game.
You'll then wait until all
the replies are received
or time out.
You then can resolve
this completed exchange
into the match and
finish the turn.
Auctions, you can do similarly
or you can choose some
other mechanism to do this.
You know, send out an exchange
to all the participants
in the auction.
Give it a shot time out,
wait until all the
replies are received,
determine the high bidder,
you know, reward the item.
You repeat if you've
got some ties.
Send it just to those people let
them handle their tie and then,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
you know, continue and resolve
the completely exchanged match
and finish the turn.
This looks a bit
different, right?
We're going to have a lot
of exchanges going or a lot
of lines that's going
to exchange.
I'm going to send
it out to everybody.
We're going to start
getting replies.
They're coming in.
We get all the replies,
exchanges completed.
We resolve it into the match
and we finish our turn.
So, that's how you can use
exchanges to do complex things,
very difficult scenarios.
You can make more complex, more
full featured turn-based games
and use on very interesting
things.
So, it's important to remember
the expectations that users have
of turn-based gaming
on mobile environments.
You have multiple sessions,
they expect to be able
to have matches, be able to
manage to just create new ones,
list them, remove old ones.
Remember, you have
to remember anything,
everything is asynchronous.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, use the new event
listener, separate your code,
make it your code a little
more simpler but, you know,
do the right things,
and don't take users
out of the current context
when it is not appropriate.
And then yes, when you want
to switch the current match.
Well, you have to think about
when these are chose to move
to a new match, when they get
an invite for the new turn.
Wrapping things up, you know,
turn-based games
are great in mobile.
We believe its sort of
optimal solution in mobile,
where people can pick up
and play whenever they
have a spare moment.
We provide multiple
sessions, up to 30 sessions
for your game and your player.
It's a very simple structure
and only one person
can write to the data.
Game Center manages all
the synchronizations
through this model.
And we have exchanges,
a new feature for iOS 7
that make very difficult
scenarios pretty easy,
it opens up new game
modes and the things
to remember are the
three Rs of exchanges,
request, reply and resolve.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
We want to thank you
for coming today.
If you need more information,
you can contact Allan
Shaffer [phonetic]
or Browser New Documentation.
There were successions earlier
for-- what's new in Game Center
and what's new in
iTunes Connect.
Thank you.
[Applause]
[ Silence ]