506.srt

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:00.506 --> 00:00:09.516 A:middle
[ Silence ]

00:00:10.016 --> 00:00:15.000 A:middle
[ Applause ]

00:00:15.866 --> 00:00:16.346 A:middle
>> Good morning.

00:00:17.016 --> 00:00:18.036 A:middle
I'm Nathan Taylor.

00:00:18.226 --> 00:00:21.186 A:middle
I manage the iOS Game Center
team and today, I want to talk

00:00:21.186 --> 00:00:23.676 A:middle
to you about Turn-Based
Gaming in Game Center.

00:00:24.926 --> 00:00:28.496 A:middle
So, here are the things
I'm going to cover today.

00:00:28.496 --> 00:00:29.966 A:middle
I'm going to talk
about turn-based gaming

00:00:29.966 --> 00:00:30.826 A:middle
for the most part of this talk.

00:00:30.826 --> 00:00:32.906 A:middle
I'm going to start with a
brief overview, you know,

00:00:33.036 --> 00:00:35.646 A:middle
what is turn-based gaming and
what other multiplayer types

00:00:35.826 --> 00:00:37.126 A:middle
of gaming does Game
Center provide?

00:00:38.186 --> 00:00:39.576 A:middle
Throughout the talk, I'm going

00:00:39.576 --> 00:00:41.466 A:middle
to cover some new features,
will be interspersed.

00:00:41.946 --> 00:00:44.016 A:middle
Let me give you a little load
on what they are in a bit.

00:00:45.026 --> 00:00:46.496 A:middle
Then I'm going to cover
the basic scenarios

00:00:46.496 --> 00:00:49.116 A:middle
of turn-based gaming and this
is sort of all the scenarios

00:00:49.456 --> 00:00:51.986 A:middle
that you need to cover to
make a good turn-based game.

00:00:52.986 --> 00:00:55.846 A:middle
And in doing this, you know, I'm
going to show a lot of code and,

00:00:55.846 --> 00:00:57.806 A:middle
you know, kind of go over some
of the decisions that you have

00:00:57.806 --> 00:00:59.436 A:middle
to make when you're handling
some of the events you get.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:01:00.406 --> 00:01:01.156 A:middle
And then I'm going to go

00:01:01.156 --> 00:01:03.376 A:middle
into advance scenarios
of turn-based gaming.

00:01:03.756 --> 00:01:06.226 A:middle
These are some of the things
that are difficult to do

00:01:06.456 --> 00:01:09.966 A:middle
with turn-based gaming today
and show you a solution

00:01:09.966 --> 00:01:14.566 A:middle
that we're offering in iOS
7 to help you solve this.

00:01:14.726 --> 00:01:18.346 A:middle
Game Center has three ways
to do multiplayer and play

00:01:18.346 --> 00:01:19.366 A:middle
with your friends, all right.

00:01:19.786 --> 00:01:22.746 A:middle
The first that we offered
is peer-to-peer multiplayer,

00:01:23.416 --> 00:01:25.006 A:middle
you know, and this
is, you know, device--

00:01:25.006 --> 00:01:27.246 A:middle
a device multiplayer
up to four players,

00:01:27.576 --> 00:01:29.426 A:middle
Game Center provides
auto-matching

00:01:29.426 --> 00:01:31.936 A:middle
and invitations and, you
know, we connect the devices

00:01:31.936 --> 00:01:34.126 A:middle
and provide the networking
layer and allow players

00:01:34.126 --> 00:01:35.256 A:middle
to play a synchronous game.

00:01:36.476 --> 00:01:37.736 A:middle
Similarly, we offer, you know,

00:01:37.736 --> 00:01:40.936 A:middle
through the same auto-matching
invitation mechanism a

00:01:40.936 --> 00:01:42.716 A:middle
server-hosted multiplayer.

00:01:42.836 --> 00:01:44.996 A:middle
And this is where you use
Game Center's auto-matching

00:01:44.996 --> 00:01:47.216 A:middle
and invitations you
bring your own server

00:01:47.216 --> 00:01:49.546 A:middle
into your own networking through
your server between the devices.

00:01:49.856 --> 00:01:51.626 A:middle
And this will allow
up to 16 players.

00:01:52.416 --> 00:01:54.146 A:middle
And the topic of
today's session,

00:01:54.306 --> 00:01:56.786 A:middle
turn-based multiplayers
relatively new compared

00:01:56.786 --> 00:01:58.026 A:middle
to this others in Game Center.

00:01:58.026 --> 00:02:00.436 A:middle
And we think it's going
to be ideal solution

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:01:58.026 --> 00:02:00.436 A:middle
And we think it's going
to be ideal solution

00:02:00.526 --> 00:02:04.076 A:middle
in multiplayer allows, you know,
up to 16 players to take turns

00:02:04.336 --> 00:02:05.836 A:middle
and passing the turn, you know,

00:02:06.356 --> 00:02:08.856 A:middle
device in a fully
asynchronous manner.

00:02:09.656 --> 00:02:12.006 A:middle
And this is sort of how
turn-based gaming works,

00:02:12.006 --> 00:02:14.476 A:middle
you know, so we sort of have
this table and people see it

00:02:14.476 --> 00:02:17.036 A:middle
around the table and its kind
of like a board game, right?

00:02:17.386 --> 00:02:19.106 A:middle
Everybody's going to take their
turn and the turn will move

00:02:19.106 --> 00:02:19.966 A:middle
on to the next person.

00:02:20.376 --> 00:02:23.586 A:middle
So, you'll take your turn,
indicate to Game Center

00:02:23.586 --> 00:02:27.486 A:middle
to pass it turn to Sue, Sue will
take her turn, pass it to Bob,

00:02:28.146 --> 00:02:30.306 A:middle
and then we've got an empty
seat here and this is kind

00:02:30.306 --> 00:02:31.976 A:middle
of represents the seat that
we're going to auto-match

00:02:31.976 --> 00:02:33.706 A:middle
and fill with somebody else
who wants to play with us.

00:02:34.186 --> 00:02:37.036 A:middle
So, when the turn passes to the
empty seat we will auto-match

00:02:37.036 --> 00:02:39.816 A:middle
in a new player Meg here,
Meg will take her turn.

00:02:40.396 --> 00:02:43.296 A:middle
And then, the other thing
about turn-based gaming is

00:02:43.296 --> 00:02:45.546 A:middle
that the turn sequence is
entirely determined by you.

00:02:45.546 --> 00:02:47.386 A:middle
It's not purely sequential.

00:02:47.786 --> 00:02:49.516 A:middle
So, you can send the
turn to whoever you need

00:02:49.516 --> 00:02:50.596 A:middle
to base on your game rules.

00:02:50.966 --> 00:02:53.616 A:middle
So, here, you know, Meg
will then turn to Sam, Sam--

00:02:53.616 --> 00:02:55.456 A:middle
sorry, let me start that over.

00:02:55.456 --> 00:02:57.856 A:middle
Sam will send it back to Meg,

00:02:57.856 --> 00:03:00.966 A:middle
and then Meg can
send it back to you.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:02:57.856 --> 00:03:00.966 A:middle
and then Meg can
send it back to you.

00:03:02.176 --> 00:03:05.226 A:middle
And this will proceed however
your game [inaudible] needs

00:03:05.226 --> 00:03:05.576 A:middle
to go.

00:03:05.576 --> 00:03:09.086 A:middle
You can implement, you know,
skips, reverses, whatever type--

00:03:09.456 --> 00:03:10.416 A:middle
whatever your game needs.

00:03:10.416 --> 00:03:15.076 A:middle
So, Game Center turn-based
multiplayer provides all the

00:03:15.076 --> 00:03:16.596 A:middle
matchmaking in invitation
services.

00:03:16.596 --> 00:03:19.736 A:middle
Your users can invite their
friends to play or they can pick

00:03:19.736 --> 00:03:21.486 A:middle
up and play an auto-match game

00:03:21.486 --> 00:03:22.976 A:middle
with other players
around the world.

00:03:23.846 --> 00:03:25.926 A:middle
The important part to
remember is the matching

00:03:25.926 --> 00:03:27.536 A:middle
and invites are asynchronous.

00:03:27.806 --> 00:03:30.636 A:middle
You know, invites do not
go out until the turn moves

00:03:31.226 --> 00:03:33.326 A:middle
to the participant that had--

00:03:33.326 --> 00:03:34.446 A:middle
you know, that's
waiting to be invited,

00:03:34.776 --> 00:03:36.696 A:middle
and then when they get the
invitations immediately

00:03:36.696 --> 00:03:37.276 A:middle
their turn.

00:03:38.636 --> 00:03:41.286 A:middle
Game Center, also, provides all
the storage of the game save,

00:03:42.126 --> 00:03:44.266 A:middle
you know, we also do
the synchronization

00:03:44.266 --> 00:03:45.316 A:middle
and the updating of clients.

00:03:45.316 --> 00:03:46.536 A:middle
So, we use push notifications

00:03:46.536 --> 00:03:48.816 A:middle
when you pass the turn
to the next player.

00:03:49.406 --> 00:03:52.446 A:middle
They get notified on their
devices and then they can pull

00:03:52.446 --> 00:03:54.236 A:middle
down the game state and take
their turn and upload it.

00:03:55.126 --> 00:03:56.366 A:middle
The turn-based game scenario

00:03:57.266 --> 00:03:59.626 A:middle
in Game Center also
covers player status.

00:03:59.986 --> 00:04:01.756 A:middle
So, this is where you know,
if hey, this person is

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:03:59.986 --> 00:04:01.756 A:middle
So, this is where you know,
if hey, this person is

00:04:01.756 --> 00:04:04.736 A:middle
on auto-match, he's invited,
he's actively playing,

00:04:05.226 --> 00:04:07.776 A:middle
has quit the game, or
when the game is over.

00:04:10.026 --> 00:04:11.836 A:middle
With all this, you
know, we kind of feel

00:04:11.836 --> 00:04:14.686 A:middle
that turn-based game is
really the ideal solution

00:04:14.686 --> 00:04:17.136 A:middle
for multiplayer gaming
on a mobile platform.

00:04:17.315 --> 00:04:20.086 A:middle
Users can play whenever
they have spare time.

00:04:20.086 --> 00:04:22.516 A:middle
You know, we always have
our iPhones with us,

00:04:22.516 --> 00:04:23.636 A:middle
our devices in our pocket.

00:04:24.236 --> 00:04:27.116 A:middle
And, you know, we don't
actually have, you know,

00:04:27.116 --> 00:04:30.836 A:middle
10 minutes to sit together with
somebody and play and, you know,

00:04:31.346 --> 00:04:34.166 A:middle
be involved for a real time
game but we have a spare

00:04:34.166 --> 00:04:36.236 A:middle
of minute here, we're
online, we're on the bus

00:04:36.236 --> 00:04:38.806 A:middle
and we can take a couple of
turns then get on with our life.

00:04:40.216 --> 00:04:42.116 A:middle
So, here's a breakdown

00:04:42.116 --> 00:04:43.636 A:middle
of the capabilities
of turn-based gaming.

00:04:44.676 --> 00:04:47.196 A:middle
Users can have up to
30 simultaneous matches

00:04:47.326 --> 00:04:49.806 A:middle
for your game, so they can
be playing with, you know,

00:04:49.856 --> 00:04:52.736 A:middle
30 different games with
however many game friends

00:04:52.836 --> 00:04:53.656 A:middle
that your game allows.

00:04:55.466 --> 00:04:57.446 A:middle
There's up to 16
players per game.

00:04:59.446 --> 00:05:01.926 A:middle
Gameplay as well as invitations

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:04:59.446 --> 00:05:01.926 A:middle
Gameplay as well as invitations

00:05:01.926 --> 00:05:04.266 A:middle
in auto-matching is fully
asynchronous, right?

00:05:05.396 --> 00:05:08.846 A:middle
Player one is taking their turn,
the other players two, three,

00:05:08.846 --> 00:05:11.526 A:middle
four don't know anything
about it until it's completed.

00:05:12.936 --> 00:05:15.836 A:middle
The game data can be
up to 64 kilobytes.

00:05:15.836 --> 00:05:18.286 A:middle
You know, a little a while
ago we increased this

00:05:18.286 --> 00:05:19.426 A:middle
from the initial 4 kilobyte.

00:05:19.426 --> 00:05:21.076 A:middle
We offer 64 kilobytes
of storage.

00:05:22.716 --> 00:05:25.026 A:middle
Seats are filled as I
said through invitations

00:05:25.026 --> 00:05:27.196 A:middle
and auto-matching and
it's fully asynchronous.

00:05:29.116 --> 00:05:31.306 A:middle
The turn order is
entirely up to you.

00:05:32.126 --> 00:05:35.056 A:middle
Game Center doesn't take
any part in the turn order.

00:05:35.056 --> 00:05:37.786 A:middle
You specify who the turn
goes to and you can tell us

00:05:37.786 --> 00:05:39.716 A:middle
who it should we go to next
if that person is unavailable.

00:05:42.096 --> 00:05:44.846 A:middle
And to that effect we
have this fallback list

00:05:44.846 --> 00:05:46.276 A:middle
so you can specify
a complete list;

00:05:46.276 --> 00:05:48.896 A:middle
it could be all the players in
the game of who we should go

00:05:48.896 --> 00:05:52.446 A:middle
to in case the next person is
not available and the person

00:05:52.446 --> 00:05:53.436 A:middle
after that's not available.

00:05:53.846 --> 00:05:56.236 A:middle
So, it provides a recovery
mechanism for games

00:05:56.586 --> 00:05:59.016 A:middle
or people are away or
forget about their game.

00:05:59.016 --> 00:06:03.156 A:middle
And finally, we give time outs.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:05:59.016 --> 00:06:03.156 A:middle
And finally, we give time outs.

00:06:03.226 --> 00:06:06.196 A:middle
You can specify a time
out but the default time

00:06:06.196 --> 00:06:07.916 A:middle
of the game center
uses these two weeks.

00:06:10.726 --> 00:06:13.086 A:middle
So, let's take a look
at what actually happens

00:06:13.416 --> 00:06:14.096 A:middle
with the game data.

00:06:14.536 --> 00:06:16.836 A:middle
The way game center
does synchronization

00:06:16.836 --> 00:06:17.816 A:middle
of term based game data is

00:06:17.816 --> 00:06:20.446 A:middle
that the person whose turn
it is is the only person

00:06:20.446 --> 00:06:21.486 A:middle
who can write the game data.

00:06:22.076 --> 00:06:24.746 A:middle
All other players can, you
know, download from the server,

00:06:24.976 --> 00:06:27.276 A:middle
read from it and view the
game state but only the person

00:06:27.276 --> 00:06:29.956 A:middle
who knows the term can write
new data to the servers.

00:06:30.496 --> 00:06:32.276 A:middle
So, you have to turn
here and you're going

00:06:32.276 --> 00:06:34.486 A:middle
to write the data send it up
to the Game Center servers

00:06:34.866 --> 00:06:35.906 A:middle
and pass to turn to Sue.

00:06:36.576 --> 00:06:37.756 A:middle
Sue gets notified.

00:06:38.216 --> 00:06:40.256 A:middle
We badge your application
on Sue's devices,

00:06:40.646 --> 00:06:43.096 A:middle
and then when Sue decides to
launch a game and play it,

00:06:43.096 --> 00:06:46.766 A:middle
he will pull down the game data
and then Sue can take her turn,

00:06:47.976 --> 00:06:50.746 A:middle
move it, pass the turn to
Bob and Bob gets notified.

00:06:51.746 --> 00:06:53.206 A:middle
But Bob is on vacation
and can't play.

00:06:54.006 --> 00:06:55.626 A:middle
So, your time out
comes into effect.

00:06:56.226 --> 00:06:58.366 A:middle
You fallbacks fall
and also take place

00:06:59.216 --> 00:07:02.366 A:middle
and we automatically will
notify Meg who can then pull

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:06:59.216 --> 00:07:02.366 A:middle
and we automatically will
notify Meg who can then pull

00:07:02.366 --> 00:07:04.096 A:middle
down the turn data
and take her turn.

00:07:04.256 --> 00:07:05.356 A:middle
And then, it's up to you.

00:07:05.566 --> 00:07:06.736 A:middle
Do you want to let Meg choose?

00:07:06.736 --> 00:07:09.726 A:middle
Do you want to give Bob another
chance to take his turn later?

00:07:10.356 --> 00:07:12.006 A:middle
Or, do you drop Bob
from the match?

00:07:12.566 --> 00:07:14.166 A:middle
It's up to you and your users

00:07:14.166 --> 00:07:15.726 A:middle
on how your game should
proceed in the state.

00:07:17.826 --> 00:07:22.126 A:middle
So, let's take a quick look at
what the match data is, right?

00:07:22.296 --> 00:07:23.986 A:middle
This is basically
an NSData object.

00:07:24.066 --> 00:07:25.796 A:middle
It's completely opaque
to Game Center.

00:07:25.866 --> 00:07:27.036 A:middle
We don't write anything to it.

00:07:27.096 --> 00:07:27.896 A:middle
We don't read it.

00:07:28.326 --> 00:07:31.596 A:middle
It's just a blob that we pass
it to servers, store for you

00:07:31.796 --> 00:07:33.996 A:middle
and it will let you
download onto--

00:07:33.996 --> 00:07:35.436 A:middle
into the game so you
can show your data.

00:07:36.216 --> 00:07:38.386 A:middle
You completely define
the contents.

00:07:38.386 --> 00:07:40.416 A:middle
Only the current player
can upload new data.

00:07:40.416 --> 00:07:43.576 A:middle
And they can upload new data
with an intermediate upload

00:07:43.576 --> 00:07:45.906 A:middle
and they upload new data
when they finish their turn

00:07:45.906 --> 00:07:47.746 A:middle
and at the end of the game,
you upload the final state.

00:07:48.966 --> 00:07:51.346 A:middle
All other players can read
this data at any time.

00:07:51.436 --> 00:07:53.696 A:middle
The can pull down,
view the current state.

00:07:53.736 --> 00:07:56.276 A:middle
So, if there's stuff you want
them ask in there about turn,

00:07:56.276 --> 00:07:58.936 A:middle
well, you know, sets some flags
in the data so they can see,

00:07:59.236 --> 00:08:01.026 A:middle
hey, you know, this
guy is taking his turn.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:07:59.236 --> 00:08:01.026 A:middle
hey, you know, this
guy is taking his turn.

00:08:01.026 --> 00:08:02.236 A:middle
I don't want to show you
what he's done, you know,

00:08:02.236 --> 00:08:05.426 A:middle
fog of war type of stuff.

00:08:05.426 --> 00:08:08.696 A:middle
Remember that it's
limited size, 64 kilobytes.

00:08:08.696 --> 00:08:10.716 A:middle
It's not a whole lot, you know.

00:08:11.516 --> 00:08:15.966 A:middle
But you can do a quite a bit
with it as long as you are smart

00:08:15.966 --> 00:08:17.376 A:middle
and you use and, you know,

00:08:17.376 --> 00:08:18.916 A:middle
efficient data packing
strategies.

00:08:19.806 --> 00:08:21.686 A:middle
You know, small games
might be able to get away

00:08:21.686 --> 00:08:23.996 A:middle
with encoding a P-list
or, you know,

00:08:23.996 --> 00:08:26.656 A:middle
serializing our objects
directly into this.

00:08:27.026 --> 00:08:30.476 A:middle
But if you got a more complex
game, you going to want to think

00:08:30.476 --> 00:08:33.746 A:middle
about this, you know, turn your
games into some [inaudible],

00:08:33.885 --> 00:08:36.696 A:middle
use some bit fields, do what you
need to to pack data tightly.

00:08:37.296 --> 00:08:40.395 A:middle
If you need more,
you can always point

00:08:40.816 --> 00:08:43.336 A:middle
to data stored on
your own servers.

00:08:43.936 --> 00:08:46.946 A:middle
And to do this you can either
store reference inside the match

00:08:46.946 --> 00:08:49.916 A:middle
data, or you can
just use the match--

00:08:50.116 --> 00:08:51.996 A:middle
session ID to reference it.

00:08:54.786 --> 00:08:56.616 A:middle
So, users have some
interesting expectations

00:08:56.616 --> 00:08:58.116 A:middle
of turn-based games, right?

00:08:58.676 --> 00:08:59.556 A:middle
It's a little bit different

00:08:59.556 --> 00:09:01.196 A:middle
when they're playing
peer-to-peer game,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:08:59.556 --> 00:09:01.196 A:middle
when they're playing
peer-to-peer game,

00:09:01.196 --> 00:09:03.286 A:middle
you're playing one game
and that's all there is.

00:09:04.126 --> 00:09:05.076 A:middle
You know, you can't
really do anything else.

00:09:05.076 --> 00:09:07.126 A:middle
But with turn-based games
it's always asynchronous,

00:09:07.126 --> 00:09:08.326 A:middle
they can come and
go as they want.

00:09:09.596 --> 00:09:11.076 A:middle
So, to get this, they
expect to be able

00:09:11.076 --> 00:09:12.566 A:middle
to have multiple
simultaneous matches.

00:09:12.566 --> 00:09:16.786 A:middle
So, your game needs to be
able to handle the scenario.

00:09:17.016 --> 00:09:18.386 A:middle
You now, you don't want to be
in this case with the user,

00:09:18.386 --> 00:09:20.686 A:middle
you can just have one match
but somehow get a second

00:09:20.686 --> 00:09:23.096 A:middle
and there's no way to
manage it in your game,

00:09:23.096 --> 00:09:24.706 A:middle
that's a problem, right?

00:09:24.706 --> 00:09:26.076 A:middle
How do they find the match

00:09:26.076 --> 00:09:27.236 A:middle
with the other friend
if they're playing?

00:09:28.206 --> 00:09:31.476 A:middle
Each game has its own
state, its own players,

00:09:31.636 --> 00:09:33.536 A:middle
and in the end, its own outcome.

00:09:34.066 --> 00:09:36.616 A:middle
And some users like to keep
the match around and be able

00:09:36.616 --> 00:09:38.366 A:middle
to show it to their
friends when they've won.

00:09:38.586 --> 00:09:40.776 A:middle
You know, when they got all the
work, all the titles filled,

00:09:41.346 --> 00:09:42.566 A:middle
they can show off
to their friends.

00:09:44.716 --> 00:09:45.996 A:middle
One player at a time, right?

00:09:46.426 --> 00:09:47.306 A:middle
It's turn-based.

00:09:47.526 --> 00:09:48.966 A:middle
There's only one
person taking the turn

00:09:49.756 --> 00:09:51.536 A:middle
and they're the only person
who can upload the game state.

00:09:51.976 --> 00:09:54.496 A:middle
Other players are observers
until it becomes their turn.

00:09:54.816 --> 00:09:58.966 A:middle
And the other thing in
your mind is your game

00:09:58.966 --> 00:09:59.976 A:middle
on the other device
is not running, right?

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:01.066 --> 00:10:02.716 A:middle
These things are handled
through notifications

00:10:02.716 --> 00:10:03.906 A:middle
that game center handles.

00:10:04.336 --> 00:10:07.316 A:middle
We will tell you-- your game
will launch when we needed to

00:10:07.466 --> 00:10:09.816 A:middle
and the user going to take,
you know, choose a match,

00:10:10.346 --> 00:10:15.906 A:middle
take their turn, exit, go back
to, you know, doing work and,

00:10:16.076 --> 00:10:17.986 A:middle
you know, whenever they get
a notification they'll take

00:10:17.986 --> 00:10:18.576 A:middle
another turn.

00:10:19.826 --> 00:10:21.576 A:middle
And the tricky part with
turn-based gaming is

00:10:21.576 --> 00:10:24.006 A:middle
because it is asynchronous.

00:10:24.006 --> 00:10:27.136 A:middle
You can get notified about
any of these other 30 matches

00:10:27.136 --> 00:10:29.886 A:middle
that the user might have in
their game at any time, right?

00:10:30.126 --> 00:10:31.316 A:middle
User's playing one match

00:10:31.936 --> 00:10:33.916 A:middle
and gets a new turn
in another match.

00:10:34.836 --> 00:10:36.996 A:middle
Sometimes the right
answer here is take them

00:10:36.996 --> 00:10:37.866 A:middle
to that other match.

00:10:38.026 --> 00:10:39.886 A:middle
Sometimes it's not.

00:10:40.496 --> 00:10:43.816 A:middle
You know, and you often want to
give the user the choice but do

00:10:43.816 --> 00:10:46.226 A:middle
so in as non-disruptive
way of possible.

00:10:46.866 --> 00:10:49.596 A:middle
You also may have
user-viewing the game and one

00:10:49.596 --> 00:10:52.786 A:middle
of the players is not their turn
when someone takes their turn,

00:10:52.916 --> 00:10:54.816 A:middle
you know, and passes it to,
you know, the third player.

00:10:55.516 --> 00:10:56.986 A:middle
And there you might want

00:10:56.986 --> 00:10:59.006 A:middle
to immediately update the state
'cause they're looking at it

00:10:59.006 --> 00:11:00.946 A:middle
and show the live updates.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:59.006 --> 00:11:00.946 A:middle
and show the live updates.

00:11:00.946 --> 00:11:03.846 A:middle
You can make it feel
like it's a live game.

00:11:05.036 --> 00:11:08.076 A:middle
And I'm going to go into the
decisions you have to make

00:11:08.076 --> 00:11:10.296 A:middle
when handling these kind of
events, so that it can give sort

00:11:10.296 --> 00:11:13.286 A:middle
of the correct and ideal
user experience here.

00:11:15.896 --> 00:11:18.406 A:middle
So, before I start
looking at some scenarios,

00:11:18.406 --> 00:11:19.686 A:middle
let me give an overview of some

00:11:19.686 --> 00:11:22.236 A:middle
of the new features
we have in iOS 7.

00:11:23.336 --> 00:11:27.406 A:middle
One, the first here is that we
allow you to report the scores

00:11:27.406 --> 00:11:30.726 A:middle
and achievements for all
the players of the match

00:11:30.726 --> 00:11:33.586 A:middle
from the one device that
the takes the final turn.

00:11:33.586 --> 00:11:36.656 A:middle
This was a request
and it was a good one.

00:11:36.656 --> 00:11:39.116 A:middle
It was really hard to get the
right scores and achievements

00:11:39.116 --> 00:11:41.856 A:middle
up when actually the last
term can change all that.

00:11:42.576 --> 00:11:44.576 A:middle
So, one player with
the final submission

00:11:44.576 --> 00:11:49.406 A:middle
of the match can report all the
scores, because now this is,

00:11:49.546 --> 00:11:51.316 A:middle
you know, an internet
world and people play

00:11:51.316 --> 00:11:52.836 A:middle
in multiple different
countries and have, you know,

00:11:52.836 --> 00:11:53.796 A:middle
speak different languages.

00:11:54.716 --> 00:11:57.726 A:middle
We now allow for you to
specify turn messages

00:11:57.726 --> 00:11:59.976 A:middle
that will be localized
on the receiver's device.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:12:00.596 --> 00:12:03.856 A:middle
So, with a little extra work,
you can specify, you know,

00:12:03.856 --> 00:12:07.886 A:middle
when you send the turn, you
know, the message, you know,

00:12:08.006 --> 00:12:11.836 A:middle
key and we will localize it
for the user that receives it.

00:12:12.236 --> 00:12:15.926 A:middle
We also have a new feature to
be able to easily remind people

00:12:16.106 --> 00:12:18.596 A:middle
that have forgotten to take the
turn this is now their turn.

00:12:18.596 --> 00:12:20.066 A:middle
So, there's an API to do this

00:12:20.066 --> 00:12:21.956 A:middle
and you can give
your users buttons

00:12:21.956 --> 00:12:23.426 A:middle
to remind their friend
to take turns.

00:12:24.746 --> 00:12:26.536 A:middle
As alluded to in
the earlier games

00:12:26.536 --> 00:12:28.656 A:middle
in our talk there's an
improved event handling model

00:12:28.656 --> 00:12:31.116 A:middle
and I'm going to go into
some depth on this on how

00:12:31.116 --> 00:12:33.846 A:middle
to use this event handling
model for turn-based games.

00:12:35.286 --> 00:12:37.296 A:middle
And then, we have
a big new feature

00:12:37.296 --> 00:12:40.276 A:middle
and this is what will help us
all in the advance scenarios

00:12:40.276 --> 00:12:42.436 A:middle
in turn-based gaming and we
call turn-based exchanges.

00:12:42.976 --> 00:12:45.056 A:middle
I'm going to talk about
more-- that more at the end.

00:12:46.286 --> 00:12:49.756 A:middle
And lastly, you know, game
center its little tricky debug

00:12:49.756 --> 00:12:51.096 A:middle
at times with turn-based gaming.

00:12:51.346 --> 00:12:53.986 A:middle
And so, we've done a little
bit better parameter checking

00:12:54.366 --> 00:12:55.166 A:middle
in error handling.

00:12:55.166 --> 00:12:58.366 A:middle
So, hopefully, you know, with
iOS 7 you'll get notified

00:12:58.366 --> 00:13:00.926 A:middle
of mistakes that you may making
your code and catch those

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:12:58.366 --> 00:13:00.926 A:middle
of mistakes that you may making
your code and catch those

00:13:00.926 --> 00:13:03.846 A:middle
in sandbox before you go
live and I hopefully be able

00:13:03.846 --> 00:13:04.636 A:middle
to figure them out easier.

00:13:06.846 --> 00:13:10.476 A:middle
So, let's take a quick look
at the primary classes you use

00:13:10.476 --> 00:13:12.496 A:middle
in doing turn-based gaming
and the principle class

00:13:12.496 --> 00:13:14.466 A:middle
of all is the turn based match.

00:13:15.456 --> 00:13:16.996 A:middle
This represents the
game instance

00:13:16.996 --> 00:13:18.886 A:middle
and you might have 30 of them.

00:13:19.346 --> 00:13:21.096 A:middle
It includes the list
of participants.

00:13:21.096 --> 00:13:23.876 A:middle
You know, these are the
empty seats or the players

00:13:23.876 --> 00:13:25.476 A:middle
that are filled in
and playing the game.

00:13:26.256 --> 00:13:27.906 A:middle
It includes the current
game state.

00:13:27.906 --> 00:13:29.766 A:middle
You know, this is the
NSData that you provided us.

00:13:29.916 --> 00:13:32.376 A:middle
We also let you know who
currently has the turn

00:13:32.376 --> 00:13:33.756 A:middle
so you know if it's your player

00:13:34.686 --> 00:13:37.696 A:middle
on the current device
or someone else.

00:13:37.696 --> 00:13:40.366 A:middle
And with turn-based
exchanges, all exchanges

00:13:40.366 --> 00:13:42.476 A:middle
that have been made
are also listed

00:13:42.476 --> 00:13:43.736 A:middle
and accessible from the match.

00:13:44.986 --> 00:13:48.186 A:middle
The next class, the participant,
you know, this is the seat.

00:13:48.756 --> 00:13:50.526 A:middle
This is how many people
are playing the game

00:13:50.816 --> 00:13:52.086 A:middle
and who they are if you know.

00:13:52.736 --> 00:13:55.956 A:middle
Alright so, if we know who they
are it's a player ID but you got

00:13:55.956 --> 00:13:57.856 A:middle
to keep in mind that
maybe an open seat

00:13:57.856 --> 00:13:59.376 A:middle
and maybe waiting to auto-match.

00:13:59.846 --> 00:14:01.926 A:middle
It may be an invitation
that your player sent,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:13:59.846 --> 00:14:01.926 A:middle
It may be an invitation
that your player sent,

00:14:02.336 --> 00:14:04.466 A:middle
you'll know who it is but
they haven't actually gotten

00:14:04.466 --> 00:14:04.996 A:middle
to take the turn yet.

00:14:05.986 --> 00:14:07.866 A:middle
This also then includes
the status,

00:14:07.936 --> 00:14:09.056 A:middle
so that you can know
this, right?

00:14:09.246 --> 00:14:09.896 A:middle
Are they invited?

00:14:09.896 --> 00:14:10.696 A:middle
Are they matching?

00:14:11.316 --> 00:14:12.946 A:middle
Are they currently
playing the game?

00:14:13.816 --> 00:14:14.566 A:middle
Or are they done?

00:14:15.766 --> 00:14:18.296 A:middle
And lastly and it's a little bit
often forgotten is the outcome.

00:14:18.896 --> 00:14:20.426 A:middle
For each participant of the game

00:14:20.426 --> 00:14:22.966 A:middle
when you end the game we've
[inaudible] a mechanism

00:14:22.966 --> 00:14:25.826 A:middle
to set the outcome and we
provide you a basic enum

00:14:25.826 --> 00:14:28.336 A:middle
so you can set this
to, you know one lost,

00:14:28.336 --> 00:14:29.746 A:middle
first, second third place.

00:14:29.896 --> 00:14:32.376 A:middle
And there's also a range
in this [inaudible]

00:14:32.376 --> 00:14:34.466 A:middle
that you can use
for custom outcomes.

00:14:34.466 --> 00:14:36.926 A:middle
So, you can use this to
display state in your game.

00:14:37.706 --> 00:14:40.806 A:middle
And you need to fill this
in when you end the game

00:14:41.586 --> 00:14:43.356 A:middle
or when a player
quits on their turn.

00:14:45.996 --> 00:14:49.856 A:middle
So, the other class, you
know, that you often use this

00:14:49.856 --> 00:14:53.216 A:middle
that the Game Center GK
turn-based match maker

00:14:53.216 --> 00:14:53.686 A:middle
view control.

00:14:53.796 --> 00:14:56.236 A:middle
This is the Game Center
interface for turn-based games.

00:14:56.786 --> 00:14:58.866 A:middle
Now, if you want easy access

00:14:58.866 --> 00:15:01.536 A:middle
to creating matches
inviting friends

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:14:58.866 --> 00:15:01.536 A:middle
to creating matches
inviting friends

00:15:01.596 --> 00:15:04.376 A:middle
and listening available matches
and allowing management of this,

00:15:04.706 --> 00:15:05.876 A:middle
you can use the view controller.

00:15:06.626 --> 00:15:08.586 A:middle
It per basically provides
management from matches.

00:15:13.186 --> 00:15:15.766 A:middle
So, let's look at
the basic scenarios

00:15:15.766 --> 00:15:18.496 A:middle
that all turn-based games kind
of has to be able to handle.

00:15:19.026 --> 00:15:21.266 A:middle
And I'd like to say, you know,
that is only three items,

00:15:21.496 --> 00:15:23.146 A:middle
but I've got seven on the slide.

00:15:23.776 --> 00:15:24.856 A:middle
You know, and the
kind of a grouped

00:15:24.856 --> 00:15:25.806 A:middle
into sort of three things.

00:15:25.806 --> 00:15:30.276 A:middle
Creating a match, dealing with
the turns and then dealing with,

00:15:30.276 --> 00:15:31.856 A:middle
you know, and managing
multiple matches.

00:15:31.856 --> 00:15:33.786 A:middle
So, the first thing
you're going to want

00:15:33.786 --> 00:15:36.236 A:middle
to build is make sure a way--
there's a way that in your app

00:15:36.236 --> 00:15:39.226 A:middle
for user to create a match
and invite their friends.

00:15:39.926 --> 00:15:41.816 A:middle
Then the thing you're
going to do most often

00:15:42.766 --> 00:15:43.776 A:middle
and most important thing

00:15:43.776 --> 00:15:45.586 A:middle
to get absolutely right
is playing a turn, right?

00:15:45.586 --> 00:15:48.436 A:middle
This is your game logic and then
how you communicate that turn

00:15:48.436 --> 00:15:49.386 A:middle
to the Game Center server.

00:15:49.386 --> 00:15:54.716 A:middle
At the end of the match, when
all the turns are taken you need

00:15:54.716 --> 00:15:55.886 A:middle
to end the match appropriately.

00:15:56.386 --> 00:15:58.386 A:middle
This will notify all the
users that the game is over

00:15:59.116 --> 00:16:01.506 A:middle
and just put it into
the completed section

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:15:59.116 --> 00:16:01.506 A:middle
and just put it into
the completed section

00:16:01.506 --> 00:16:03.896 A:middle
of the other list and make it so
they can remove it if they want.

00:16:04.726 --> 00:16:07.246 A:middle
And then in managing
matches, you need to be able

00:16:07.246 --> 00:16:12.106 A:middle
to list all the open matches,
remove a match and quit a match.

00:16:12.296 --> 00:16:14.006 A:middle
In quitting, there're
two ways, you know,

00:16:14.006 --> 00:16:17.936 A:middle
in turn or out of turn.

00:16:18.146 --> 00:16:21.626 A:middle
So, creating a match can be
done with the view controller.

00:16:21.626 --> 00:16:23.186 A:middle
If you want to use our UI,

00:16:23.796 --> 00:16:25.616 A:middle
you can use the turn-based
matchmaker view controller,

00:16:26.166 --> 00:16:27.526 A:middle
provides all the
management you need,

00:16:28.066 --> 00:16:31.226 A:middle
list the matches allows users to
remove them with a little help

00:16:31.226 --> 00:16:33.126 A:middle
from you, they can quit in turn

00:16:33.856 --> 00:16:36.186 A:middle
and it provides auto-matching
invitations.

00:16:36.856 --> 00:16:40.866 A:middle
And you create this by
specifying a match request.

00:16:41.676 --> 00:16:44.286 A:middle
However, if you want to do it
programmatically and you want

00:16:44.286 --> 00:16:47.666 A:middle
to provide your own UI for this
and we encourage this, you know,

00:16:47.666 --> 00:16:49.166 A:middle
nothing kind of fits
better in your app

00:16:49.536 --> 00:16:51.186 A:middle
than your own, UI design.

00:16:51.766 --> 00:16:53.806 A:middle
We provide a mechanism so
you can do auto-matching

00:16:53.806 --> 00:16:54.986 A:middle
and invitations
programmatically.

00:16:54.986 --> 00:16:57.146 A:middle
And that's what I'm
going to show you next.

00:16:57.146 --> 00:16:59.316 A:middle
It's really not too difficult.

00:16:59.316 --> 00:17:03.286 A:middle
This is how to create a
match and allows someone

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:16:59.316 --> 00:17:03.286 A:middle
This is how to create a
match and allows someone

00:17:03.286 --> 00:17:04.695 A:middle
to invite their friends
at the same time.

00:17:05.266 --> 00:17:07.796 A:middle
So, you provide a mechanism
what the user choose,

00:17:07.876 --> 00:17:09.836 A:middle
which friends they want
to invite, you know,

00:17:09.836 --> 00:17:11.376 A:middle
get the player ID's
of these friends.

00:17:11.376 --> 00:17:13.776 A:middle
Set up a match request.

00:17:14.636 --> 00:17:16.626 A:middle
We'll just specify the
minimum and maximum number

00:17:16.626 --> 00:17:17.996 A:middle
of players here, four and four.

00:17:19.415 --> 00:17:22.026 A:middle
And then we'll set the
players to invite on a--

00:17:22.316 --> 00:17:23.236 A:middle
on the match request, right?

00:17:23.236 --> 00:17:24.616 A:middle
So, players to invite
as a property

00:17:24.616 --> 00:17:29.216 A:middle
that you put your friend ID's
in and set the invite message.

00:17:29.776 --> 00:17:33.146 A:middle
Usually this is something we've
recommend you'll have the user

00:17:33.146 --> 00:17:34.626 A:middle
type in 'cause this is kind

00:17:34.626 --> 00:17:36.086 A:middle
of a personal message that's
[inaudible] to the friends

00:17:36.086 --> 00:17:36.806 A:middle
that you're going to invite.

00:17:38.126 --> 00:17:41.496 A:middle
And then one API call,
it's a class method

00:17:41.496 --> 00:17:44.636 A:middle
on GK turn-based matching you
can call, find match for request

00:17:45.386 --> 00:17:48.136 A:middle
with your request and
then a completion handler.

00:17:48.456 --> 00:17:52.366 A:middle
On completion, you
either get a match,

00:17:52.456 --> 00:17:54.576 A:middle
it will immediately be your
players turn in that match.

00:17:54.576 --> 00:17:57.266 A:middle
They'll need to take some
action or you'll get an error

00:17:57.336 --> 00:17:58.876 A:middle
if we were unable to
create that match for you.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:18:02.556 --> 00:18:05.486 A:middle
So, said users can
enable to matches

00:18:05.486 --> 00:18:09.036 A:middle
and you can see matches here
can be in various states.

00:18:09.036 --> 00:18:10.456 A:middle
It might be your players turn.

00:18:10.456 --> 00:18:11.766 A:middle
It might be someone else's turn.

00:18:12.316 --> 00:18:14.776 A:middle
You know, so, how
do you handle this?

00:18:15.256 --> 00:18:16.536 A:middle
Well, it's really simple.

00:18:16.776 --> 00:18:19.596 A:middle
There's pretty much two
APIs and you do and sort

00:18:19.596 --> 00:18:22.146 A:middle
of two actions you need to take.

00:18:22.296 --> 00:18:25.296 A:middle
If you want to list matches,
build your own UI around this.

00:18:25.466 --> 00:18:27.796 A:middle
You can use the class
method, load matches

00:18:27.796 --> 00:18:28.706 A:middle
with completion handler.

00:18:28.706 --> 00:18:33.046 A:middle
And this will give you an
array of the existing matches.

00:18:33.096 --> 00:18:35.226 A:middle
All the active matches,
all the completed matches

00:18:35.226 --> 00:18:36.856 A:middle
and then you can sort
this as you'd like

00:18:36.856 --> 00:18:37.846 A:middle
and display it to the user.

00:18:39.316 --> 00:18:41.096 A:middle
When the user's done
with the match, you know,

00:18:41.096 --> 00:18:42.356 A:middle
you want to implement
some way for them

00:18:42.356 --> 00:18:44.326 A:middle
to remove this match
from their list.

00:18:44.396 --> 00:18:48.116 A:middle
You know, some matches will
get auto removed overtime

00:18:48.116 --> 00:18:50.366 A:middle
as new matches are
created, but users want

00:18:50.366 --> 00:18:51.066 A:middle
to keep their list clean.

00:18:51.066 --> 00:18:53.186 A:middle
So, provide a mechanism
when you remove a match

00:18:53.186 --> 00:18:54.466 A:middle
and it's quite simple.

00:18:54.726 --> 00:18:57.656 A:middle
It's an instance method on the
turn-based match called Remove

00:18:57.656 --> 00:18:59.866 A:middle
with Completion Handler and
this will simply remove it

00:18:59.866 --> 00:19:01.576 A:middle
from the users match list.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:18:59.866 --> 00:19:01.576 A:middle
from the users match list.

00:19:02.866 --> 00:19:04.946 A:middle
And then alternatively you
can use the view controller.

00:19:06.756 --> 00:19:08.276 A:middle
So, most important
thing you can do

00:19:08.276 --> 00:19:10.226 A:middle
in any turn-based
game is take turns.

00:19:10.426 --> 00:19:12.376 A:middle
Every player in the
game presumably is going

00:19:12.376 --> 00:19:15.076 A:middle
to take a turn, multiple
turns and this is going

00:19:15.076 --> 00:19:16.926 A:middle
to be the most common
thing and there's a lot

00:19:16.926 --> 00:19:18.086 A:middle
of stuff you want to do here.

00:19:19.866 --> 00:19:23.006 A:middle
So, essentially taking a turn
involves making the match data,

00:19:23.006 --> 00:19:26.216 A:middle
passing it up to the server,
setting who the player is next.

00:19:28.056 --> 00:19:30.316 A:middle
And so, let's take a look
at the actual full sequence.

00:19:30.526 --> 00:19:33.116 A:middle
First, you're going to
unload the current state

00:19:33.116 --> 00:19:33.636 A:middle
from the server.

00:19:33.636 --> 00:19:36.736 A:middle
So, this is the effect, pulling
down the most recent match data,

00:19:36.876 --> 00:19:39.626 A:middle
so that you have current stuff--
most current data to operate on.

00:19:40.486 --> 00:19:42.406 A:middle
You will then apply
your game logic to it

00:19:42.646 --> 00:19:44.316 A:middle
to both allow the user
to take their turn.

00:19:45.516 --> 00:19:47.986 A:middle
You will then be able to save
the enemy, hit save if you want.

00:19:47.986 --> 00:19:50.416 A:middle
So, if the users in the middle
of the turn, it's really nice

00:19:50.456 --> 00:19:52.876 A:middle
to let them save their state
so that if they want to resume

00:19:52.876 --> 00:19:55.626 A:middle
on another device, but they
happen to put the device away

00:19:56.056 --> 00:19:58.686 A:middle
and your app gets jetsam to be
able to come back and come back

00:19:58.686 --> 00:20:00.086 A:middle
to where they were in
the middle of their turn.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:19:58.686 --> 00:20:00.086 A:middle
to where they were in
the middle of their turn.

00:20:00.086 --> 00:20:00.976 A:middle
You can save the enemy at state.

00:20:01.056 --> 00:20:05.106 A:middle
And in doing this, you have to
keep in mind that other players

00:20:05.106 --> 00:20:08.806 A:middle
in the game can see that state
unless you explicitly kind

00:20:08.806 --> 00:20:10.576 A:middle
of hide it through flags
in the match state.

00:20:12.136 --> 00:20:14.766 A:middle
Next, when the user is done,
they've taken their turn,

00:20:14.766 --> 00:20:16.066 A:middle
you know, kind of the results.

00:20:16.586 --> 00:20:18.766 A:middle
You need to choose the next
player sequence, right?

00:20:19.196 --> 00:20:21.966 A:middle
Who should the turn go to
next and specify the fallback

00:20:21.966 --> 00:20:24.086 A:middle
so that we can recover
gracefully

00:20:24.086 --> 00:20:25.646 A:middle
if that person is unable
to take their turn.

00:20:26.816 --> 00:20:29.016 A:middle
And then finally, you're
going to submit the turn

00:20:29.016 --> 00:20:32.106 A:middle
to Game Center and Game Center
will then notify the next player

00:20:32.666 --> 00:20:33.806 A:middle
and this will repeat.

00:20:34.986 --> 00:20:37.046 A:middle
So, to load the current state,

00:20:37.366 --> 00:20:39.306 A:middle
there's basically a
single API to do this.

00:20:39.506 --> 00:20:42.956 A:middle
It's an instance method on
the match, load match data

00:20:42.956 --> 00:20:43.846 A:middle
with completion handler.

00:20:44.546 --> 00:20:46.626 A:middle
This will return to you,
your latest match data

00:20:46.626 --> 00:20:50.196 A:middle
and then usually what you'll
do is take the match data,

00:20:50.686 --> 00:20:52.786 A:middle
you know, and apply it
to your view controller

00:20:52.786 --> 00:20:53.726 A:middle
and show it to the user.

00:20:57.226 --> 00:20:59.486 A:middle
After that, you know,
you've let your user play

00:20:59.486 --> 00:21:00.186 A:middle
with the match there, right.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:20:59.486 --> 00:21:00.186 A:middle
with the match there, right.

00:21:00.186 --> 00:21:01.036 A:middle
They've taken their turn.

00:21:01.036 --> 00:21:02.256 A:middle
They manipulated
the data, they've--

00:21:02.396 --> 00:21:05.836 A:middle
you know, drawn some cards,
moved their token, roll the die.

00:21:06.696 --> 00:21:08.536 A:middle
You'll want to, you
know, update the match

00:21:08.536 --> 00:21:10.656 A:middle
or generate the new match
data for the user actions.

00:21:12.086 --> 00:21:15.686 A:middle
Now, because I said,
you know, your device

00:21:15.686 --> 00:21:17.966 A:middle
and user make want to-- you
need to put your app away,

00:21:18.266 --> 00:21:20.256 A:middle
your app is in the
background and make it jetsam.

00:21:21.096 --> 00:21:24.556 A:middle
The user might want to
switch to another device

00:21:25.226 --> 00:21:26.176 A:middle
and pick this up later.

00:21:26.616 --> 00:21:29.336 A:middle
Save the enemy that
state to server, right?

00:21:29.416 --> 00:21:32.606 A:middle
And to do this, there's an
API called save current turn

00:21:32.606 --> 00:21:34.996 A:middle
with match data with
completion handler.

00:21:35.546 --> 00:21:38.236 A:middle
This doesn't move who
the current turn is.

00:21:38.266 --> 00:21:40.736 A:middle
This only uploads the new
data or into the server

00:21:40.736 --> 00:21:42.126 A:middle
so that's available
to all the players.

00:21:43.626 --> 00:21:45.066 A:middle
And then, we're going
to continue,

00:21:45.356 --> 00:21:46.566 A:middle
you know, taking the turn.

00:21:47.156 --> 00:21:50.546 A:middle
So, the next step as I
mentioned was to choose

00:21:50.996 --> 00:21:52.236 A:middle
who which you go to next.

00:21:54.666 --> 00:21:57.336 A:middle
This is entirely based
on your game rules.

00:21:57.626 --> 00:21:59.196 A:middle
Game Center doesn't
really take any part

00:21:59.196 --> 00:22:00.556 A:middle
in who the turn goes to next.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:21:59.196 --> 00:22:00.556 A:middle
in who the turn goes to next.

00:22:01.646 --> 00:22:03.136 A:middle
The things you keep
mind though is you need

00:22:03.136 --> 00:22:06.806 A:middle
to select active players
or players that you want

00:22:06.806 --> 00:22:08.906 A:middle
to become active,
remember auto-matching

00:22:08.906 --> 00:22:10.286 A:middle
and invitation is asynchronous.

00:22:10.986 --> 00:22:13.416 A:middle
To get those people into the
game, to get send invites

00:22:13.416 --> 00:22:15.966 A:middle
to auto-matching when--
they need to get the turn.

00:22:15.966 --> 00:22:20.106 A:middle
And when they do, it will
be that persons turn.

00:22:20.266 --> 00:22:23.786 A:middle
You also want to be able to
guard against missed turns.

00:22:23.886 --> 00:22:27.216 A:middle
So, you can check to see
if a player has timed

00:22:27.216 --> 00:22:29.846 A:middle
out in the past, right?

00:22:29.846 --> 00:22:31.326 A:middle
And you can also provide--

00:22:31.326 --> 00:22:33.456 A:middle
you provided us the list of
the multiple participants.

00:22:33.456 --> 00:22:34.666 A:middle
You're not picking
just the next person.

00:22:34.666 --> 00:22:35.646 A:middle
You're going to give
us everybody.

00:22:36.316 --> 00:22:37.836 A:middle
You can find out who timed out.

00:22:38.596 --> 00:22:40.876 A:middle
Make the decision or look if the
user choose whether they should,

00:22:40.876 --> 00:22:43.966 A:middle
you know, still be in the game,
you know, if they time out,

00:22:43.966 --> 00:22:45.836 A:middle
did they forfeit or did
they get three tries.

00:22:46.656 --> 00:22:47.836 A:middle
That's up to you, right?

00:22:50.136 --> 00:22:52.486 A:middle
You then, you know, just specify
this list of participants.

00:22:52.836 --> 00:22:56.926 A:middle
You're going to use time outs so
that if someone takes too long

00:22:56.926 --> 00:22:58.836 A:middle
or it's not available to
move on to the next person.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:23:00.036 --> 00:23:03.106 A:middle
The last person on this list
because after that games

00:23:03.106 --> 00:23:05.316 A:middle
and doesn't know what
to do won't time out.

00:23:05.316 --> 00:23:09.536 A:middle
And what we actually recommend
you do here is basically specify

00:23:09.536 --> 00:23:11.706 A:middle
the full turn cycle
and put the last person

00:23:11.706 --> 00:23:13.566 A:middle
on the list is the person who
is currently taking the turn.

00:23:14.236 --> 00:23:17.076 A:middle
This way if everything
goes wrong,

00:23:17.766 --> 00:23:19.326 A:middle
the person who took
the turn last played

00:23:19.326 --> 00:23:22.026 A:middle
in the game can make a decision
of, all right, if I want to give

00:23:22.026 --> 00:23:24.696 A:middle
up on this game, I want to
go play with someone else

00:23:24.696 --> 00:23:26.846 A:middle
or do I try again, right?

00:23:29.466 --> 00:23:32.426 A:middle
So, this is the work
that you need to do here.

00:23:32.536 --> 00:23:34.816 A:middle
There aren't really an API's
on this slide but you're going

00:23:34.816 --> 00:23:38.146 A:middle
to again update your match
data with the latest state.

00:23:39.216 --> 00:23:44.266 A:middle
You're going to determine
the next participant list

00:23:44.266 --> 00:23:46.606 A:middle
and then you're going
set up a turn message.

00:23:46.706 --> 00:23:49.186 A:middle
And this gets us into
the next new feature,

00:23:50.056 --> 00:23:52.906 A:middle
localizable message.

00:23:52.906 --> 00:23:53.546 A:middle
You're essentially going

00:23:53.546 --> 00:23:56.406 A:middle
to be providing us localizable
strings in your bundle.

00:23:57.246 --> 00:24:01.356 A:middle
Game Center will use the strings
on the recipient's device

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:23:57.246 --> 00:24:01.356 A:middle
Game Center will use the strings
on the recipient's device

00:24:01.736 --> 00:24:04.146 A:middle
to generate the message that
we show in notification center

00:24:04.146 --> 00:24:07.106 A:middle
on the lock screen and
the message of this show

00:24:07.106 --> 00:24:09.696 A:middle
and the Game Center
user interface both

00:24:09.696 --> 00:24:10.716 A:middle
from the Game Center app.

00:24:11.586 --> 00:24:14.106 A:middle
And in the-- you know, in
game UI in your screen.

00:24:14.106 --> 00:24:18.316 A:middle
So, this allows us to actually
show something, a message here

00:24:18.656 --> 00:24:22.036 A:middle
that is localized to, you
know, the user current device.

00:24:22.356 --> 00:24:24.686 A:middle
And we've seen games that
you, you know, that, you know,

00:24:24.736 --> 00:24:26.606 A:middle
this player played
this word, right?

00:24:26.606 --> 00:24:28.876 A:middle
It would be nice
to be able to make

00:24:28.876 --> 00:24:34.046 A:middle
that appropriately localized
and this can be a format string.

00:24:34.896 --> 00:24:37.366 A:middle
All right, so that you can say
you can specify the player name,

00:24:38.266 --> 00:24:40.396 A:middle
you give us the word
played and with any formats

00:24:40.396 --> 00:24:41.666 A:middle
and with to format parameters.

00:24:42.186 --> 00:24:44.406 A:middle
And then you give us, you know,
the word if you're a word game.

00:24:46.606 --> 00:24:50.406 A:middle
We localize it on the recipients
device, but before we send it,

00:24:50.406 --> 00:24:53.816 A:middle
we also as a fallback localize
it on the senders device

00:24:53.816 --> 00:24:56.616 A:middle
and the senders language,
because there is a chance

00:24:56.716 --> 00:24:59.136 A:middle
that the person, if it's
being invited to play the game

00:24:59.136 --> 00:25:01.466 A:middle
for the first time it may
not have it on the device.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:24:59.136 --> 00:25:01.466 A:middle
for the first time it may
not have it on the device.

00:25:01.466 --> 00:25:02.536 A:middle
Their bundle's not there.

00:25:02.796 --> 00:25:04.096 A:middle
We can't localize the message,

00:25:04.256 --> 00:25:07.466 A:middle
but we will have
something to fallback to.

00:25:07.676 --> 00:25:11.886 A:middle
And then, you know, ideally the
user will quick notification

00:25:11.886 --> 00:25:13.366 A:middle
Game Center will take
them to the store

00:25:13.366 --> 00:25:14.306 A:middle
and they will buy your game.

00:25:15.806 --> 00:25:17.546 A:middle
To do this, we need
two items from you.

00:25:18.326 --> 00:25:21.816 A:middle
The first and most important
is the message string

00:25:22.396 --> 00:25:22.886 A:middle
or format string.

00:25:22.886 --> 00:25:24.936 A:middle
You know, this is works to
the standard, and you know,

00:25:25.146 --> 00:25:26.576 A:middle
localizable strings mechanism.

00:25:26.576 --> 00:25:29.936 A:middle
So, you're going to specify a
string key that will be looked

00:25:29.936 --> 00:25:33.416 A:middle
up in your localizable strings
table inside of the bundle

00:25:33.416 --> 00:25:34.396 A:middle
on the recipient device.

00:25:35.516 --> 00:25:39.026 A:middle
Optionally, if you're using a
format string, you can pass this

00:25:39.086 --> 00:25:40.976 A:middle
to us in array of
format arguments.

00:25:43.836 --> 00:25:45.696 A:middle
So, let's look at how
we do this, right?

00:25:46.236 --> 00:25:48.466 A:middle
This first part is
your job, you know,

00:25:48.786 --> 00:25:51.906 A:middle
giving us the key
and the arguments.

00:25:51.906 --> 00:25:55.246 A:middle
Then on the match, you're going
to set the localizable message

00:25:55.246 --> 00:25:57.566 A:middle
with this key and arguments.

00:25:58.696 --> 00:26:00.236 A:middle
And then, finally
we're to the meat

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:25:58.696 --> 00:26:00.236 A:middle
And then, finally
we're to the meat

00:26:00.236 --> 00:26:01.786 A:middle
of this whole taking
a turn sequence.

00:26:01.786 --> 00:26:03.576 A:middle
This is the last bit.

00:26:04.236 --> 00:26:05.446 A:middle
We're going to end
the turn, right.

00:26:05.716 --> 00:26:07.776 A:middle
Your user has done
everything that you need to do.

00:26:07.776 --> 00:26:09.476 A:middle
It's time for the next
person to take their turn.

00:26:09.936 --> 00:26:11.096 A:middle
So, you will call in turn

00:26:11.096 --> 00:26:13.836 A:middle
with next participants
specifying there's array

00:26:13.836 --> 00:26:15.366 A:middle
of participants that
we determined earlier.

00:26:15.836 --> 00:26:19.246 A:middle
Specifying a time out, here
we use the default time

00:26:19.246 --> 00:26:23.856 A:middle
out using your current match
data that you determined earlier

00:26:24.806 --> 00:26:27.146 A:middle
and then the completion handle
would be called with an error

00:26:27.546 --> 00:26:29.876 A:middle
if there is a problem
submitting this turn, otherwise,

00:26:29.876 --> 00:26:32.476 A:middle
it will move on to the next
player and they will be notified

00:26:32.476 --> 00:26:34.006 A:middle
and the game will proceed.

00:26:36.536 --> 00:26:38.276 A:middle
Reminders, this is
another new feature, right.

00:26:39.726 --> 00:26:42.946 A:middle
Turns-- Turn-based games
is fully asynchronous.

00:26:44.156 --> 00:26:47.426 A:middle
You know, we notify the
user, they download the data

00:26:47.426 --> 00:26:50.046 A:middle
when they're ready to take a
turn but nothing happens if,

00:26:50.046 --> 00:26:52.426 A:middle
you know, until they actually
launched the game and do it.

00:26:52.996 --> 00:26:54.966 A:middle
The games can only
proceed as fast

00:26:54.966 --> 00:26:56.606 A:middle
as their slowest player, right.

00:26:57.176 --> 00:26:58.396 A:middle
Each player gets a turn.

00:26:58.586 --> 00:26:59.866 A:middle
They spend their
time taking up turn.

00:26:59.866 --> 00:27:01.166 A:middle
They forget about it perhaps.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:26:59.866 --> 00:27:01.166 A:middle
They forget about it perhaps.

00:27:01.746 --> 00:27:04.636 A:middle
Time outs and fallbacks help
keep things moving along.

00:27:05.176 --> 00:27:07.126 A:middle
Help us recover from
failure cases.

00:27:07.846 --> 00:27:10.966 A:middle
But it's really nice to be
able to continue in the game

00:27:10.966 --> 00:27:13.666 A:middle
and be able to nudge someone,
"Hey, remember you're playing

00:27:13.666 --> 00:27:14.976 A:middle
with me and take your turn now."

00:27:15.766 --> 00:27:20.386 A:middle
So, sometimes, you need to
remind a player to play.

00:27:21.976 --> 00:27:25.766 A:middle
And we do this through a simple
API and to send a reminder

00:27:25.766 --> 00:27:26.616 A:middle
on the turn-based game.

00:27:26.906 --> 00:27:30.286 A:middle
It's a single one way push
with a localizable message.

00:27:30.286 --> 00:27:33.906 A:middle
Let's take a look at
the code to do this.

00:27:33.906 --> 00:27:37.066 A:middle
Just as before, you're going
to set up a localizable message

00:27:37.906 --> 00:27:41.646 A:middle
with arguments and then call.

00:27:41.646 --> 00:27:42.976 A:middle
Send reminder to participants.

00:27:43.046 --> 00:27:47.376 A:middle
Note that is actually
an array of participants

00:27:47.716 --> 00:27:50.826 A:middle
with the localizable
message key in arguments

00:27:50.826 --> 00:27:51.666 A:middle
and the completion handler.

00:27:52.796 --> 00:27:54.276 A:middle
And you'll see why
the array is kind

00:27:54.276 --> 00:27:55.656 A:middle
of important a little bit later

00:27:56.376 --> 00:27:57.836 A:middle
but the common case
is the sender

00:27:57.836 --> 00:27:59.066 A:middle
to who currently has the turn.

00:27:59.886 --> 00:28:01.966 A:middle
But there are cases
with some new features,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:27:59.886 --> 00:28:01.966 A:middle
But there are cases
with some new features,

00:28:02.006 --> 00:28:05.056 A:middle
turn-based exchanges where you
might be waiting on actions

00:28:05.056 --> 00:28:07.306 A:middle
from multiple people and
you can remind everybody

00:28:07.306 --> 00:28:08.166 A:middle
to take their actions.

00:28:09.966 --> 00:28:12.376 A:middle
So, it's all over, right?

00:28:12.546 --> 00:28:13.776 A:middle
All the turns have been taken.

00:28:14.706 --> 00:28:16.066 A:middle
All the cards are played.

00:28:17.016 --> 00:28:19.166 A:middle
You know, there's no more
property to buy somewhere.

00:28:19.166 --> 00:28:20.146 A:middle
Everybody's gone bankrupt.

00:28:20.386 --> 00:28:21.726 A:middle
Whatever rules determine the end

00:28:21.726 --> 00:28:23.696 A:middle
of your game and
you decide that.

00:28:23.696 --> 00:28:27.016 A:middle
And instead of take-- the
last person taking their turn

00:28:27.016 --> 00:28:28.036 A:middle
and moving on to someone else.

00:28:28.546 --> 00:28:29.986 A:middle
You decide that, all
right the game is over.

00:28:30.456 --> 00:28:31.966 A:middle
And now, I need to end the game.

00:28:32.736 --> 00:28:33.456 A:middle
And what do you need to do?

00:28:33.456 --> 00:28:35.956 A:middle
So, when it's all
over, you know,

00:28:35.956 --> 00:28:36.976 A:middle
there are various
reasons this can happen.

00:28:37.356 --> 00:28:41.976 A:middle
They finish your game
according to the rules, right.

00:28:41.976 --> 00:28:45.366 A:middle
There's nothing left
to do in the game.

00:28:45.366 --> 00:28:47.686 A:middle
And then, there are other cases
where games can end, right?

00:28:48.286 --> 00:28:51.906 A:middle
If everybody quits the game, you
know, and they can quit in turn

00:28:51.946 --> 00:28:55.326 A:middle
or they can forfeit
the game out of turn.

00:28:55.326 --> 00:28:57.276 A:middle
You know, these are things to
think about in winning the game.

00:28:58.636 --> 00:29:01.496 A:middle
But ultimately the game is
ended by the last person

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:28:58.636 --> 00:29:01.496 A:middle
But ultimately the game is
ended by the last person

00:29:01.686 --> 00:29:03.896 A:middle
to play instead of
taking their turn.

00:29:03.896 --> 00:29:05.896 A:middle
And so, instead of
calling in turn

00:29:05.896 --> 00:29:09.026 A:middle
with next participants you're
going to call a different API

00:29:09.026 --> 00:29:10.956 A:middle
and let me get to that.

00:29:11.176 --> 00:29:15.386 A:middle
So, before we end the game,
right, it's usual to be able

00:29:15.386 --> 00:29:16.976 A:middle
to say and let the user
know, who won, who lost.

00:29:17.276 --> 00:29:21.006 A:middle
So, we'd like you
to set the outcomes.

00:29:21.546 --> 00:29:24.246 A:middle
So, we start here by taking
the current match data

00:29:24.776 --> 00:29:27.496 A:middle
and determining your final match
data, this last match data.

00:29:27.956 --> 00:29:30.576 A:middle
You know, this is so that
everybody whose still has the

00:29:30.576 --> 00:29:32.946 A:middle
game in their session list
can download the match data,

00:29:33.326 --> 00:29:36.406 A:middle
can show off how well or poorly
they did to their friends.

00:29:37.796 --> 00:29:41.766 A:middle
Then you're going to walk
over all the participants

00:29:41.766 --> 00:29:45.916 A:middle
in the match and then for each
active participant, you know,

00:29:45.916 --> 00:29:48.126 A:middle
people out still
playing, you know,

00:29:48.126 --> 00:29:50.116 A:middle
we want you to change
their status to done,

00:29:50.116 --> 00:29:51.786 A:middle
because they're not
playing anymore, and then,

00:29:51.786 --> 00:29:52.976 A:middle
determine their outcome and
set the outcome property.

00:29:53.096 --> 00:29:57.466 A:middle
This is entirely
based on you, right?

00:29:57.466 --> 00:29:59.296 A:middle
You're going to look at
the match data, you know,

00:29:59.426 --> 00:30:01.186 A:middle
you know the positions
of the different player,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:29:59.426 --> 00:30:01.186 A:middle
you know the positions
of the different player,

00:30:01.216 --> 00:30:03.286 A:middle
you'll set the outcome,
and you can use our enums

00:30:03.286 --> 00:30:05.506 A:middle
or you can use-- you notice
the reserved bit range

00:30:05.536 --> 00:30:06.976 A:middle
and user custom outcome so
you can pull this down later.

00:30:07.046 --> 00:30:09.736 A:middle
This will be saved in the
match when you end the turn.

00:30:09.736 --> 00:30:11.486 A:middle
And so, when later you
download the match,

00:30:11.616 --> 00:30:13.976 A:middle
you can query this
off to participants.

00:30:14.516 --> 00:30:24.046 A:middle
[ Pause ]

00:30:24.546 --> 00:30:26.946 A:middle
Let's continue on the
ending the game here.

00:30:27.466 --> 00:30:30.766 A:middle
We get to another new feature
and this is what I kind

00:30:30.766 --> 00:30:31.756 A:middle
of start of any features.

00:30:32.066 --> 00:30:35.596 A:middle
At the end of the game,
you now know the scores

00:30:35.596 --> 00:30:38.386 A:middle
that everybody got, the
achievements that everybody got.

00:30:38.626 --> 00:30:40.786 A:middle
And this used to be
a real kind of tricky

00:30:40.786 --> 00:30:42.176 A:middle
in hairy situation, right?

00:30:42.946 --> 00:30:46.986 A:middle
You-- Before now, you would have
to kind of submit a new score

00:30:46.986 --> 00:30:49.006 A:middle
as everybody took a
turn and kind of hope

00:30:49.006 --> 00:30:50.756 A:middle
that that was the final,
you know, representative

00:30:50.756 --> 00:30:52.156 A:middle
of the final score at
the end of the match.

00:30:53.436 --> 00:30:55.016 A:middle
And submit achievements
as their earned

00:30:55.016 --> 00:30:56.686 A:middle
and we still recommend
you to do that.

00:30:57.356 --> 00:31:01.046 A:middle
But at the end of the game
you can now generate scores

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:30:57.356 --> 00:31:01.046 A:middle
But at the end of the game
you can now generate scores

00:31:01.236 --> 00:31:03.516 A:middle
for all the participants
and generate achievements

00:31:03.516 --> 00:31:04.556 A:middle
for all the participants.

00:31:04.876 --> 00:31:08.276 A:middle
There are new APIs for
initialization of scores

00:31:08.276 --> 00:31:09.976 A:middle
as you can meet them
with player IDs.

00:31:09.976 --> 00:31:11.506 A:middle
So, they will be specified

00:31:11.506 --> 00:31:13.566 A:middle
to someone who's not
the local player.

00:31:14.146 --> 00:31:18.636 A:middle
And then, when you're in the
match you can use the new API

00:31:18.636 --> 00:31:22.366 A:middle
to in match and turn
with the new match data.

00:31:22.546 --> 00:31:23.756 A:middle
This is your final match data

00:31:24.446 --> 00:31:27.316 A:middle
and we give us the
scores and achievements.

00:31:27.316 --> 00:31:29.826 A:middle
Games Center then we'll submit
these scores and achievements

00:31:30.236 --> 00:31:32.976 A:middle
in bulk associated
specifically with this match.

00:31:33.226 --> 00:31:34.786 A:middle
So, we know who is
participating.

00:31:35.336 --> 00:31:37.166 A:middle
You can't submit scores
or achievements for people

00:31:37.166 --> 00:31:38.506 A:middle
that weren't members
of this match.

00:31:39.226 --> 00:31:42.426 A:middle
This is really the only way to
submit scores for someone else

00:31:42.426 --> 00:31:44.836 A:middle
and we're using the
match and the match data

00:31:44.836 --> 00:31:48.346 A:middle
and the participants on the
servers as a verification

00:31:48.346 --> 00:31:50.486 A:middle
of this data that things
are being submitted

00:31:50.486 --> 00:31:51.376 A:middle
for the appropriate people.

00:31:51.376 --> 00:31:54.016 A:middle
And then at the end
of the match,

00:31:54.016 --> 00:31:56.136 A:middle
you get a completion handler
an error will tell you

00:31:56.136 --> 00:31:57.486 A:middle
if there're some
problems submitting this.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:32:00.096 --> 00:32:00.676 A:middle
That's it.

00:32:00.826 --> 00:32:02.556 A:middle
When you're done,
that match is over.

00:32:02.556 --> 00:32:04.956 A:middle
Your user can look at it
and view it some other time,

00:32:05.426 --> 00:32:06.866 A:middle
move on to other
matches and play.

00:32:08.746 --> 00:32:10.886 A:middle
But all along this process,

00:32:11.166 --> 00:32:14.736 A:middle
because turn-based gaming is
asynchronous, there were events.

00:32:15.036 --> 00:32:18.016 A:middle
You've got events for invites,
the very start of the match.

00:32:18.406 --> 00:32:21.686 A:middle
You got events whenever it
became your players turn.

00:32:22.206 --> 00:32:25.196 A:middle
And you get events when the
turn move between other players.

00:32:25.916 --> 00:32:32.476 A:middle
We have a new mechanism in
iOS 7 to handle these events.

00:32:32.476 --> 00:32:36.886 A:middle
Previously, we had basically a
singleton GK turn-based event

00:32:36.886 --> 00:32:39.606 A:middle
handler object that you
would set a delegate to.

00:32:40.366 --> 00:32:43.056 A:middle
And it was a singleton and
you can only have one delegate

00:32:43.056 --> 00:32:46.766 A:middle
and you had to kind of process
events all in one place.

00:32:47.216 --> 00:32:50.806 A:middle
We now have this listener
model and you're going to want

00:32:50.806 --> 00:32:52.736 A:middle
to implement the GK
turn-based event listener.

00:32:53.206 --> 00:32:55.626 A:middle
It's a protocol for
turn-based events.

00:32:56.066 --> 00:32:59.726 A:middle
These events include state
changes such as invitations,

00:32:59.726 --> 00:33:03.316 A:middle
new turns, turns getting
passed, match data getting saved

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:32:59.726 --> 00:33:03.316 A:middle
new turns, turns getting
passed, match data getting saved

00:33:03.316 --> 00:33:07.086 A:middle
and updated, as well as match
ended events when you're

00:33:07.506 --> 00:33:10.996 A:middle
in the game and for the
turn-based exchanges,

00:33:11.286 --> 00:33:13.296 A:middle
the various exchange
or events for requests,

00:33:13.586 --> 00:33:15.066 A:middle
cancellations and completions.

00:33:17.176 --> 00:33:19.386 A:middle
As with all the events
these kind of come

00:33:19.386 --> 00:33:20.296 A:middle
from the local player.

00:33:20.296 --> 00:33:22.116 A:middle
The local player is the producer

00:33:22.116 --> 00:33:23.676 A:middle
of these events 'cause
they all sort

00:33:23.746 --> 00:33:24.736 A:middle
of involve the local player.

00:33:25.806 --> 00:33:29.146 A:middle
And this replaces the older
turn-based handler and delegate

00:33:29.146 --> 00:33:31.056 A:middle
which we have deprecated
in iOS 7.

00:33:32.866 --> 00:33:36.126 A:middle
The nice part is you can
have multiple listeners.

00:33:36.606 --> 00:33:38.416 A:middle
All of the protocol
methods are optional.

00:33:39.106 --> 00:33:41.676 A:middle
You can implement the ones
you want, where you want them.

00:33:42.266 --> 00:33:44.686 A:middle
And so, it can simplify the
decisions you have to make.

00:33:44.986 --> 00:33:49.576 A:middle
For example, your app delegate
can remain in responsibility

00:33:49.576 --> 00:33:51.826 A:middle
of receiving new turn
notifications, right?

00:33:51.876 --> 00:33:56.146 A:middle
When the user activates the app
and you've got a turn, you know,

00:33:56.146 --> 00:33:58.776 A:middle
you want to jump right into
that and you're going to start

00:33:58.776 --> 00:33:59.516 A:middle
that with your app again.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:34:00.136 --> 00:34:03.146 A:middle
But, if the users viewing a
match, your view controller

00:34:03.276 --> 00:34:06.816 A:middle
for that game state can listen
for the events for updates.

00:34:07.006 --> 00:34:09.366 A:middle
And it can ignore all
other updates except ones

00:34:09.366 --> 00:34:10.916 A:middle
that affect that match.

00:34:11.216 --> 00:34:13.146 A:middle
And then it can just show
the updates to the user.

00:34:13.606 --> 00:34:15.126 A:middle
It doesn't have to worry
about anything else.

00:34:17.976 --> 00:34:20.065 A:middle
To do this, you know, you're
going to set up for listener.

00:34:20.576 --> 00:34:22.646 A:middle
And you start by
adopting this protocol.

00:34:23.996 --> 00:34:27.056 A:middle
The next thing you do is you're
going to register your listener

00:34:27.056 --> 00:34:30.926 A:middle
or listeners with the local
player using the simple

00:34:30.956 --> 00:34:33.226 A:middle
registered listener method.

00:34:34.616 --> 00:34:37.056 A:middle
And as I've said, you can
register multiple listeners.

00:34:37.056 --> 00:34:39.206 A:middle
You can separate
responsibilities in your app.

00:34:39.636 --> 00:34:41.476 A:middle
And ultimately you
can have simpler code

00:34:41.815 --> 00:34:43.686 A:middle
and less convoluted
decision trees

00:34:43.686 --> 00:34:46.196 A:middle
when you get turn-based events.

00:34:46.626 --> 00:34:48.676 A:middle
So, let's take a look at
what the protocol provides.

00:34:48.966 --> 00:34:50.876 A:middle
These are the basic turn events.

00:34:51.996 --> 00:34:54.636 A:middle
We have, you know, the
generic turn event.

00:34:54.636 --> 00:34:58.776 A:middle
This is when the match state
changes and it's, you know,

00:34:58.776 --> 00:35:02.376 A:middle
player received the turn event
for match, did become active.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:34:58.776 --> 00:35:02.376 A:middle
player received the turn event
for match, did become active.

00:35:03.376 --> 00:35:04.926 A:middle
So, this is you and
get this is on invites.

00:35:04.926 --> 00:35:06.456 A:middle
You can get this one
when it comes your turn

00:35:06.636 --> 00:35:08.016 A:middle
and when the match
state changes.

00:35:09.776 --> 00:35:12.456 A:middle
The next is match
requests from Game Center.

00:35:14.026 --> 00:35:18.156 A:middle
This is relatively uncommon, but
Game Center provides a mechanism

00:35:18.156 --> 00:35:22.126 A:middle
for users to essentially
choose to play your game

00:35:22.126 --> 00:35:23.236 A:middle
with one of their friends.

00:35:24.096 --> 00:35:26.496 A:middle
When this happens,
your game gets launched

00:35:27.146 --> 00:35:30.206 A:middle
and the event you will receive
is player did request match

00:35:30.206 --> 00:35:30.906 A:middle
with players.

00:35:32.436 --> 00:35:35.156 A:middle
The right action here is for
you to create a new match

00:35:35.256 --> 00:35:36.946 A:middle
with these players, so that,

00:35:36.946 --> 00:35:38.916 A:middle
the user can immediately start
playing with their friends.

00:35:40.396 --> 00:35:43.866 A:middle
And finally the last basic
event we have is the match

00:35:43.866 --> 00:35:44.356 A:middle
ended event.

00:35:44.406 --> 00:35:47.346 A:middle
You've ended the
turn and all players.

00:35:47.646 --> 00:35:50.256 A:middle
So, you've ended the match and
all players now get notified

00:35:50.256 --> 00:35:51.106 A:middle
that the match is over.

00:35:52.166 --> 00:35:54.186 A:middle
And this is player match ended.

00:35:59.076 --> 00:36:01.376 A:middle
So, let's take a look
at the new turn event.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:35:59.076 --> 00:36:01.376 A:middle
So, let's take a look
at the new turn event.

00:36:01.466 --> 00:36:04.806 A:middle
As I've said, this is sort of
the most complicated scenario

00:36:04.806 --> 00:36:08.036 A:middle
and I'm going to actually walk
through this with the sort

00:36:08.036 --> 00:36:09.316 A:middle
of the full decision
tree you make.

00:36:09.316 --> 00:36:11.696 A:middle
So, it's going to go over
kind of multiple slides here.

00:36:11.876 --> 00:36:14.216 A:middle
And we're going to start
here with, you know,

00:36:14.216 --> 00:36:16.276 A:middle
the method its player
receive turn event

00:36:16.276 --> 00:36:17.986 A:middle
for match did become active.

00:36:18.646 --> 00:36:20.956 A:middle
And the part focused on
first that did become active.

00:36:21.866 --> 00:36:26.656 A:middle
This flag will be, yes, and
true win the event is the one

00:36:26.656 --> 00:36:28.846 A:middle
that we activated
your application for.

00:36:29.296 --> 00:36:33.406 A:middle
And this happens when the user
taps on a banner for the event

00:36:33.496 --> 00:36:35.406 A:middle
in a notification
center, you know,

00:36:35.406 --> 00:36:37.656 A:middle
they swipe on the lock screen
when we launch their game,

00:36:37.996 --> 00:36:41.416 A:middle
or they select the
turn-based match in Game Center

00:36:41.576 --> 00:36:43.566 A:middle
in the turn, you know the common
turn list that we all have

00:36:44.066 --> 00:36:45.436 A:middle
and select to play this match.

00:36:46.136 --> 00:36:48.876 A:middle
We will launch your game and you
will receive this event as soon

00:36:48.876 --> 00:36:49.796 A:middle
as you set up this listener.

00:36:50.826 --> 00:36:54.206 A:middle
If did become active
is true, what you need

00:36:54.206 --> 00:36:55.816 A:middle
to do is immediately
switch to this match.

00:36:56.516 --> 00:36:59.326 A:middle
The user has already
chosen to play this match.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:37:00.336 --> 00:37:02.096 A:middle
It doesn't make sense
to ask them again.

00:37:02.846 --> 00:37:05.386 A:middle
You want to basically save
off any current state,

00:37:06.296 --> 00:37:07.796 A:middle
allow them to go
to this new match.

00:37:07.836 --> 00:37:09.966 A:middle
And then you're done,
you don't have

00:37:09.966 --> 00:37:11.066 A:middle
to really handle anything else.

00:37:11.066 --> 00:37:12.686 A:middle
You know, you-- they're
ready to play.

00:37:13.986 --> 00:37:17.416 A:middle
But if it's not the one that
activated your app, now you want

00:37:17.416 --> 00:37:18.536 A:middle
to handle it more selectively.

00:37:20.856 --> 00:37:22.416 A:middle
So again, we're going
to continue

00:37:22.416 --> 00:37:24.576 A:middle
with the received
turned event from match.

00:37:25.886 --> 00:37:28.146 A:middle
Here, we want to
look for matches

00:37:28.146 --> 00:37:29.236 A:middle
that are the current match.

00:37:29.876 --> 00:37:31.636 A:middle
So, this is something
that if you were--

00:37:32.226 --> 00:37:33.496 A:middle
you want a separate
responsibilities

00:37:33.496 --> 00:37:35.536 A:middle
that your view controller
for the game can do.

00:37:35.536 --> 00:37:37.696 A:middle
And then you just can
listen for matches

00:37:37.696 --> 00:37:38.896 A:middle
that match the current match.

00:37:38.896 --> 00:37:41.576 A:middle
Now, you can do the easy equal
check between my current match

00:37:41.646 --> 00:37:43.866 A:middle
and the matches passed
on this event.

00:37:44.796 --> 00:37:50.896 A:middle
If it is a match, it's the same
one, you can call refresh match

00:37:51.246 --> 00:37:54.936 A:middle
and update the UI for the user
so they can see the latest turns

00:37:54.936 --> 00:37:58.096 A:middle
that were taken and-- yeah,
you can do simple animations,

00:37:58.206 --> 00:37:59.776 A:middle
whatever is necessary
to make your game fun.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:38:01.246 --> 00:38:02.576 A:middle
If it's not the current match,

00:38:02.756 --> 00:38:06.396 A:middle
there's a little
bit more work to do.

00:38:06.396 --> 00:38:10.016 A:middle
So again, we're going to receive
a turned event, this time,

00:38:10.406 --> 00:38:11.656 A:middle
it's not the current match.

00:38:12.596 --> 00:38:13.826 A:middle
What's the right
thing to do here?

00:38:15.056 --> 00:38:18.956 A:middle
Well, did the player
just get a new turn?

00:38:18.956 --> 00:38:19.906 A:middle
Is it the player's turn?

00:38:20.216 --> 00:38:21.416 A:middle
So here were checking this

00:38:21.456 --> 00:38:24.106 A:middle
by comparing the current
participant's player ID

00:38:24.826 --> 00:38:28.126 A:middle
to the local player's ID-- like
the producer of this event,

00:38:28.986 --> 00:38:30.556 A:middle
the player passing
is the local player.

00:38:30.946 --> 00:38:33.636 A:middle
If these player IDs are
the same, this indicates

00:38:33.736 --> 00:38:37.866 A:middle
that your player now is the
current player in this turn.

00:38:38.876 --> 00:38:40.826 A:middle
That's kind of an
important event.

00:38:41.096 --> 00:38:44.986 A:middle
So, what you want to do
here is consider some way

00:38:44.986 --> 00:38:46.066 A:middle
to notify the user.

00:38:46.776 --> 00:38:50.396 A:middle
They might be busy in having fun
taking a turn so you don't want

00:38:50.396 --> 00:38:53.046 A:middle
to take them immediately
out of that current match.

00:38:53.736 --> 00:38:55.506 A:middle
So, we recommend, you know,
some way to notify them.

00:38:55.506 --> 00:38:58.896 A:middle
You can use Game Centers, you
know, notification banner,

00:38:58.896 --> 00:39:01.156 A:middle
API and show a banner on
the top of your screen.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:38:58.896 --> 00:39:01.156 A:middle
API and show a banner on
the top of your screen.

00:39:01.536 --> 00:39:04.166 A:middle
You can-- put a badge
on your UI somewhere.

00:39:04.566 --> 00:39:07.376 A:middle
You can show an alert
but let the user know

00:39:07.376 --> 00:39:09.476 A:middle
that somebody is waiting
on them somewhere else,

00:39:09.976 --> 00:39:11.186 A:middle
that they have another option--

00:39:12.196 --> 00:39:14.666 A:middle
but don't take them out
of their turned context.

00:39:16.896 --> 00:39:20.186 A:middle
All right, so that wraps up
the turn events and we'll look

00:39:20.186 --> 00:39:21.576 A:middle
at now this match request.

00:39:21.576 --> 00:39:24.616 A:middle
As I said, this is rare but
it's an important scenario.

00:39:25.536 --> 00:39:27.176 A:middle
The user wants to play
with their friends.

00:39:27.296 --> 00:39:30.656 A:middle
In Game Center, the application
has launched your game.

00:39:31.886 --> 00:39:33.756 A:middle
How to handle this is
really quite simple.

00:39:33.756 --> 00:39:35.086 A:middle
It's like creating any match.

00:39:35.086 --> 00:39:38.246 A:middle
So, the first thing you do is
you create a match request.

00:39:38.246 --> 00:39:40.626 A:middle
Here, I create one with,
you know, two players.

00:39:41.456 --> 00:39:44.446 A:middle
I'm going to set the array that
was passing a play ready is

00:39:44.446 --> 00:39:46.926 A:middle
to invite as the players to
invite on this match request.

00:39:47.666 --> 00:39:50.616 A:middle
I'm going to let the user
specify the invite message

00:39:51.906 --> 00:39:53.946 A:middle
and then just like any--

00:39:54.186 --> 00:39:56.646 A:middle
creating a match I showed
you earlier, you're going

00:39:56.646 --> 00:39:59.956 A:middle
to simply call find match for
request with completion handler.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:03.196 --> 00:40:06.926 A:middle
So, that's everything
you need do

00:40:06.926 --> 00:40:08.246 A:middle
for basic turn-based
gaming today.

00:40:09.476 --> 00:40:11.156 A:middle
Now, I'm going to get
into the new stuff.

00:40:11.156 --> 00:40:14.936 A:middle
This is turn-based
exchanges and you might ask,

00:40:15.026 --> 00:40:16.336 A:middle
what is turn-based exchange?

00:40:16.376 --> 00:40:20.506 A:middle
Well, a turn-base exchange
is an out of band exchange

00:40:20.506 --> 00:40:21.576 A:middle
of data between players.

00:40:22.376 --> 00:40:25.776 A:middle
Recall that with the current
turn-base gaming mechanism,

00:40:26.266 --> 00:40:28.696 A:middle
the only person who can,
basically, put new data

00:40:28.696 --> 00:40:29.656 A:middle
into the match is the one

00:40:29.656 --> 00:40:31.376 A:middle
who currently has the
turn, he can upload it.

00:40:31.456 --> 00:40:34.916 A:middle
And when he does that, he
passes the turn to someone else.

00:40:35.626 --> 00:40:37.606 A:middle
Exchanges allow you to
pass a little bit of data

00:40:37.606 --> 00:40:40.486 A:middle
from one player to another,
from any player to another.

00:40:41.666 --> 00:40:43.776 A:middle
And this is done through
basically a single reply,

00:40:44.056 --> 00:40:47.276 A:middle
a single request, and
then a reply, one reply,

00:40:47.276 --> 00:40:51.266 A:middle
from each player that that
request may have been sent to.

00:40:51.486 --> 00:40:55.476 A:middle
What this allows is for you
to do some interesting things,

00:40:55.476 --> 00:40:58.616 A:middle
you can do trading, you can
do auctions, but you also get

00:40:58.616 --> 00:41:01.656 A:middle
to keep the current player
of the game, you player,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:58.616 --> 00:41:01.656 A:middle
to keep the current player
of the game, you player,

00:41:02.086 --> 00:41:04.916 A:middle
in control of the duration
of their term, right?

00:41:04.956 --> 00:41:07.246 A:middle
Other ways to handle some
of these complex scenarios

00:41:07.246 --> 00:41:08.906 A:middle
which I will show
you later, you know,

00:41:08.906 --> 00:41:12.536 A:middle
you're kind of relinquishing
control and-- and the game can,

00:41:12.536 --> 00:41:14.006 A:middle
you know, kind of get messed up.

00:41:14.536 --> 00:41:17.166 A:middle
But we now allow users
to control the duration,

00:41:17.296 --> 00:41:19.826 A:middle
have the communications with
the other players in the match,

00:41:19.976 --> 00:41:23.726 A:middle
and be able to control how
long it takes with time-outs,

00:41:23.726 --> 00:41:26.306 A:middle
and you have the ability
to cancel this at any time.

00:41:27.586 --> 00:41:29.016 A:middle
And as with everything
in turn-base gaming,

00:41:29.016 --> 00:41:31.026 A:middle
this is fully asynchronous.

00:41:31.026 --> 00:41:32.726 A:middle
You know, the user
only has to wait

00:41:32.726 --> 00:41:33.766 A:middle
as long as they want to wait.

00:41:34.476 --> 00:41:36.116 A:middle
You don't have to
wait for a reply.

00:41:36.596 --> 00:41:38.556 A:middle
You can abandon it
and cancel a request.

00:41:41.916 --> 00:41:43.826 A:middle
Why are we giving you exchanges?

00:41:43.826 --> 00:41:46.176 A:middle
Well, we heard a
lot of feedback.

00:41:46.956 --> 00:41:49.086 A:middle
There were kind of-- when we
introduced turn-based gaming,

00:41:49.086 --> 00:41:51.086 A:middle
there were some concerns
about how this would work

00:41:51.086 --> 00:41:52.156 A:middle
with more complex games.

00:41:53.046 --> 00:41:56.006 A:middle
And we believe, exchanges
are the solution

00:41:56.006 --> 00:41:57.616 A:middle
to these difficult scenarios.

00:41:57.906 --> 00:41:59.576 A:middle
Let's take a look at
some of the scenarios

00:41:59.576 --> 00:42:01.526 A:middle
that we think turn-base
exchanges really help solve.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:41:59.576 --> 00:42:01.526 A:middle
that we think turn-base
exchanges really help solve.

00:42:02.106 --> 00:42:04.696 A:middle
And I expect that you, being
as creative as you are,

00:42:04.696 --> 00:42:06.966 A:middle
can find some really cool
usage of-- uses of these.

00:42:07.956 --> 00:42:10.516 A:middle
But the primary one, you know,

00:42:10.516 --> 00:42:12.536 A:middle
one of the first ones here
is trading resources, right?

00:42:12.966 --> 00:42:14.236 A:middle
You're in the middle
of turn-base game

00:42:14.706 --> 00:42:17.026 A:middle
and your player's taking
their turn and they want

00:42:17.026 --> 00:42:19.476 A:middle
to trade some gold to
someone else and get some ore.

00:42:20.976 --> 00:42:23.146 A:middle
Well, it's challenging.

00:42:23.736 --> 00:42:25.056 A:middle
What type of trades are there?

00:42:25.346 --> 00:42:27.396 A:middle
Well, there are trades that are
initiated by the current player.

00:42:28.056 --> 00:42:29.326 A:middle
We could make that happen

00:42:29.596 --> 00:42:31.796 A:middle
with turn-base gaming
before exchanges.

00:42:32.606 --> 00:42:35.026 A:middle
But there are other types of
trades such as trades initiated

00:42:35.026 --> 00:42:37.516 A:middle
by a different player who
doesn't currently have to turn

00:42:38.166 --> 00:42:41.586 A:middle
with your player or
trades between two people

00:42:41.586 --> 00:42:43.586 A:middle
that are unrelated to
the current player.

00:42:43.586 --> 00:42:45.846 A:middle
We also offer things like
auctions of properties

00:42:45.846 --> 00:42:48.296 A:middle
where you're going to
involve one or more

00:42:48.296 --> 00:42:50.516 A:middle
or all the players
in the action.

00:42:50.516 --> 00:42:53.276 A:middle
And then you can do things
like simultaneous turns

00:42:53.276 --> 00:42:54.966 A:middle
or otherwise known as
kind of gated matches,

00:42:55.446 --> 00:42:58.566 A:middle
where you let everybody
take a small action,

00:42:58.596 --> 00:43:01.356 A:middle
you gather the results, you
integrate it into the turn,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:42:58.596 --> 00:43:01.356 A:middle
you gather the results, you
integrate it into the turn,

00:43:01.356 --> 00:43:02.626 A:middle
you move it on, and
you take next turn.

00:43:04.256 --> 00:43:06.856 A:middle
And this also can be used for
like a simple messaging thing

00:43:06.856 --> 00:43:10.606 A:middle
where you can let users send
thoughts, or cubits and kind

00:43:10.606 --> 00:43:14.886 A:middle
of send little hints out of
band and to their partners.

00:43:16.886 --> 00:43:22.506 A:middle
So, before exchanges, how
would you handle these

00:43:22.566 --> 00:43:23.536 A:middle
difficult scenarios?

00:43:24.336 --> 00:43:26.686 A:middle
Well, it all starts
with the turn, right?

00:43:26.686 --> 00:43:30.596 A:middle
You start with the turn, then
you might edit the game state,

00:43:30.596 --> 00:43:32.576 A:middle
put it into some special mode
that says, "Hey, I'm trading."

00:43:32.576 --> 00:43:37.636 A:middle
And then you're going to
pass the turn to the players

00:43:37.676 --> 00:43:39.616 A:middle
that the user wants
to trade with

00:43:39.766 --> 00:43:41.116 A:middle
and you'll give it
a short time-out

00:43:41.116 --> 00:43:44.716 A:middle
so that you can actually
recover and then return the turn

00:43:44.716 --> 00:43:45.496 A:middle
to the original player.

00:43:45.496 --> 00:43:50.036 A:middle
And at the end you'll resolve
a special mode, you know, "Hey,

00:43:50.036 --> 00:43:51.666 A:middle
the user accepted the
trade, but the resources

00:43:51.666 --> 00:43:53.286 A:middle
in their game state let
them finish their turn."

00:43:56.436 --> 00:43:58.176 A:middle
Why is this really hard?

00:43:58.176 --> 00:43:59.086 A:middle
Why is this none ideal?

00:43:59.086 --> 00:44:02.446 A:middle
Well, you've relinquished
the turn and that means

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:43:59.086 --> 00:44:02.446 A:middle
Well, you've relinquished
the turn and that means

00:44:02.446 --> 00:44:04.776 A:middle
that the full duration
of this turn is not

00:44:04.776 --> 00:44:06.766 A:middle
under the player's
control, right?

00:44:06.766 --> 00:44:09.006 A:middle
If the other player that you
gave a turn to that you want

00:44:09.006 --> 00:44:11.336 A:middle
to trade with, answer is
fast, create might work,

00:44:11.916 --> 00:44:13.116 A:middle
but if you have to
wait for that time

00:44:13.116 --> 00:44:15.006 A:middle
out if they're not
available to reply,

00:44:15.666 --> 00:44:17.366 A:middle
they can take a very
long time to resolve

00:44:17.886 --> 00:44:20.006 A:middle
and your player never really
got to finish their turn.

00:44:21.656 --> 00:44:24.456 A:middle
What is this look like
with the exchanges?

00:44:25.726 --> 00:44:27.256 A:middle
Well, it's simpler
here, you know,

00:44:27.256 --> 00:44:29.886 A:middle
we've taken out a
few of the steps.

00:44:29.886 --> 00:44:32.496 A:middle
We start the turn, we
request an exchange,

00:44:32.666 --> 00:44:33.556 A:middle
I want to trade with you.

00:44:34.606 --> 00:44:37.886 A:middle
You receive a reply,
here is my counter offer,

00:44:38.816 --> 00:44:41.606 A:middle
you'll then take this
exchange you'll resolve it

00:44:41.606 --> 00:44:44.356 A:middle
into the matched data, maybe
you'll initiate more exchanges.

00:44:45.696 --> 00:44:47.336 A:middle
But you can leave
this up to the user.

00:44:47.396 --> 00:44:49.116 A:middle
What they're doing
is based on them.

00:44:50.066 --> 00:44:52.606 A:middle
If they don't want to
wait for them for reply,

00:44:52.606 --> 00:44:55.236 A:middle
you can cancel them for them,
then they'll end their turn.

00:44:58.016 --> 00:45:00.106 A:middle
What are-- what are the
classes you use for exchanges?

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:44:58.016 --> 00:45:00.106 A:middle
What are-- what are the
classes you use for exchanges?

00:45:00.176 --> 00:45:02.646 A:middle
Well, we added a
few more for this.

00:45:03.086 --> 00:45:05.836 A:middle
Obviously there's a new class
called GK turn-base exchange.

00:45:06.346 --> 00:45:08.566 A:middle
This represents the requests.

00:45:08.996 --> 00:45:11.596 A:middle
It has the sender, that's
usually your player,

00:45:11.596 --> 00:45:13.706 A:middle
but it can be any of the
people if you're sending them,

00:45:13.706 --> 00:45:14.656 A:middle
you know, the [inaudible]
player.

00:45:15.056 --> 00:45:17.936 A:middle
All the recipients of the
exchanges, this is one or more

00:45:17.936 --> 00:45:19.156 A:middle
of the participants
of the match.

00:45:20.256 --> 00:45:22.576 A:middle
You can send these
to open seats, right,

00:45:22.666 --> 00:45:23.986 A:middle
just like moving a
turn to an open seat.

00:45:23.986 --> 00:45:25.406 A:middle
You send and exchange
to an open seat,

00:45:26.256 --> 00:45:29.166 A:middle
it will trigger the invitation
or trigger auto match to fill

00:45:29.166 --> 00:45:32.206 A:middle
that seat, so someone will come
in and handle that exchange.

00:45:33.956 --> 00:45:37.426 A:middle
Each exchange has its status,
whether it's active, if you--

00:45:37.426 --> 00:45:39.456 A:middle
it's been canceled,
if it's completed,

00:45:39.456 --> 00:45:40.906 A:middle
and then the final
one is resolved.

00:45:41.996 --> 00:45:43.986 A:middle
Each exchange covered
its own message, right,

00:45:43.986 --> 00:45:45.716 A:middle
so you can include
a visible message,

00:45:45.826 --> 00:45:48.386 A:middle
a string for the user
and a small payload.

00:45:49.016 --> 00:45:50.236 A:middle
We allow you to specify data

00:45:50.236 --> 00:45:52.016 A:middle
up to one kilobyte
with each exchange.

00:45:52.686 --> 00:45:54.776 A:middle
And then the exchange
will track its replies.

00:45:55.786 --> 00:45:57.866 A:middle
You might-- if it's only sent
to one person, you get one reply

00:45:58.026 --> 00:46:00.136 A:middle
and then it will be completed
and you need to resolve it.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:45:58.026 --> 00:46:00.136 A:middle
and then it will be completed
and you need to resolve it.

00:46:00.836 --> 00:46:02.426 A:middle
So the next class, obviously,

00:46:02.426 --> 00:46:05.456 A:middle
as it falls from this is the
GK turn-base exchange reply.

00:46:06.586 --> 00:46:07.716 A:middle
This has the recipient.

00:46:07.716 --> 00:46:09.676 A:middle
This is the person who
current exchange was sent

00:46:09.676 --> 00:46:10.606 A:middle
to and who is replying.

00:46:11.096 --> 00:46:14.666 A:middle
It has a message, so you can
have a message in response,

00:46:14.666 --> 00:46:17.136 A:middle
you know, and these generate
banners and notifications,

00:46:17.136 --> 00:46:19.426 A:middle
so that the user can see that
they left-- they left the game,

00:46:19.426 --> 00:46:21.976 A:middle
they can see, you know, that
hey I got a response, you know,

00:46:21.976 --> 00:46:22.986 A:middle
this person like, you know,

00:46:23.636 --> 00:46:25.136 A:middle
will make a counter
offer for my trade.

00:46:26.016 --> 00:46:29.396 A:middle
And then each reply has a small
payload as well, one kilobyte,

00:46:29.396 --> 00:46:32.126 A:middle
so that you can, you know,
take this payloads and request

00:46:32.126 --> 00:46:34.556 A:middle
and reply and then integrate
them into the match data.

00:46:36.836 --> 00:46:38.226 A:middle
So, what does this look like?

00:46:38.336 --> 00:46:39.686 A:middle
We've got our table here.

00:46:40.906 --> 00:46:41.956 A:middle
You have the game data.

00:46:41.956 --> 00:46:42.796 A:middle
It's your turn.

00:46:44.136 --> 00:46:46.146 A:middle
But you want to trade
with Meg and Bob.

00:46:46.536 --> 00:46:48.716 A:middle
So, you'll send one
exchange out to Meg.

00:46:49.386 --> 00:46:51.196 A:middle
We're going out of band
here so the turn goes away,

00:46:51.196 --> 00:46:52.476 A:middle
and we'll send another
exchange to Bob,

00:46:52.476 --> 00:46:55.706 A:middle
both of them will get notified,
now we're waiting for replies.

00:46:56.586 --> 00:46:58.116 A:middle
We get a reply quickly form Meg.

00:46:58.116 --> 00:47:00.216 A:middle
And we like it.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:46:58.116 --> 00:47:00.216 A:middle
And we like it.

00:47:00.216 --> 00:47:01.766 A:middle
You know, the user--
users happy with it.

00:47:01.766 --> 00:47:05.266 A:middle
They accept the trade, so you
can cancel the exchange to Bob.

00:47:06.546 --> 00:47:09.476 A:middle
Integrate the results of
this exchange in reply

00:47:09.956 --> 00:47:11.366 A:middle
into the turn-base-- turn state,

00:47:12.166 --> 00:47:14.516 A:middle
go back to taking the
term and then finish it.

00:47:14.736 --> 00:47:17.016 A:middle
Upload the turn data that has
the results of the exchange,

00:47:17.126 --> 00:47:22.156 A:middle
and then move the turn to Sue.

00:47:22.236 --> 00:47:25.236 A:middle
So, there's sort of a
three Rs to exchanges.

00:47:25.236 --> 00:47:26.886 A:middle
This is what you want to
remember from exchanges.

00:47:26.886 --> 00:47:28.676 A:middle
You're going to request
an exchange,

00:47:28.716 --> 00:47:29.646 A:middle
all right, the first R.

00:47:30.406 --> 00:47:31.516 A:middle
It all starts with this.

00:47:31.716 --> 00:47:33.806 A:middle
It can be started by any
player in that match.

00:47:34.326 --> 00:47:36.036 A:middle
It can be started at any time.

00:47:37.036 --> 00:47:40.126 A:middle
Each exchange can target
one or multiple players,

00:47:40.786 --> 00:47:42.466 A:middle
and they all include
a small payload.

00:47:44.006 --> 00:47:48.806 A:middle
The next R, the second is
to reply to the exchange,

00:47:49.146 --> 00:47:52.446 A:middle
each player that we send the
exchange to, we expect a reply

00:47:52.446 --> 00:47:56.036 A:middle
from or time-out and you
can cancel if you need to.

00:47:56.036 --> 00:47:57.446 A:middle
And then the last

00:47:57.446 --> 00:48:00.166 A:middle
or the important one is
all completed exchanges,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:47:57.446 --> 00:48:00.166 A:middle
or the important one is
all completed exchanges,

00:48:00.166 --> 00:48:02.836 A:middle
that is all the exchanges that
we've got replies for need

00:48:02.836 --> 00:48:06.106 A:middle
to be resolved into the
match date before ending the

00:48:06.106 --> 00:48:06.616 A:middle
current turn.

00:48:06.926 --> 00:48:09.576 A:middle
If you fail to do so, you
will receive an error,

00:48:10.236 --> 00:48:11.556 A:middle
and you'll need to go
back and resolve those

00:48:11.556 --> 00:48:13.276 A:middle
into the state and
then try again.

00:48:14.466 --> 00:48:15.836 A:middle
So what does this look like?

00:48:15.836 --> 00:48:18.786 A:middle
Well, to request an
exchange, you know,

00:48:18.846 --> 00:48:19.886 A:middle
determine the number of players.

00:48:19.886 --> 00:48:22.626 A:middle
You can send it to one of more
people, remember you can send it

00:48:22.626 --> 00:48:24.036 A:middle
to empty seats, so if you--

00:48:24.036 --> 00:48:26.346 A:middle
especially if you're doing
like a gated turn-base match

00:48:26.346 --> 00:48:28.546 A:middle
for simultaneous
turns, you want--

00:48:28.546 --> 00:48:30.056 A:middle
sending it to empty
seats is very important

00:48:30.056 --> 00:48:31.376 A:middle
to be able to fill them in.

00:48:32.616 --> 00:48:34.266 A:middle
For each participant
that we sent it to,

00:48:34.266 --> 00:48:36.076 A:middle
we expect a single reply.

00:48:37.556 --> 00:48:41.586 A:middle
And the API to do is send
exchange to participants

00:48:41.746 --> 00:48:43.956 A:middle
with data, localize
well message,

00:48:44.846 --> 00:48:46.736 A:middle
arguments, and the time out.

00:48:47.086 --> 00:48:50.246 A:middle
And then you'll get a completion
handler that will be callback

00:48:50.246 --> 00:48:52.286 A:middle
with the exchange that
was successfully created.

00:48:54.166 --> 00:48:56.446 A:middle
Replying is essentially
just as simple.

00:48:57.206 --> 00:49:00.656 A:middle
This is an instance method
on the exchange itself.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:48:57.206 --> 00:49:00.656 A:middle
This is an instance method
on the exchange itself.

00:49:01.036 --> 00:49:04.396 A:middle
Each exchange gets a single
reply form each participant

00:49:04.436 --> 00:49:08.546 A:middle
that it was sent to, and the
exchanges marked completed,

00:49:08.976 --> 00:49:11.806 A:middle
once all replies or
time outs are received

00:49:11.806 --> 00:49:12.606 A:middle
from each participants.

00:49:12.606 --> 00:49:15.086 A:middle
And then once completed,
you need to resolve it.

00:49:15.676 --> 00:49:19.516 A:middle
So to reply, you call reply
with localized well message,

00:49:19.976 --> 00:49:23.006 A:middle
given arguments, the data
payload that is all yours,

00:49:23.006 --> 00:49:24.456 A:middle
and the completion handler.

00:49:25.786 --> 00:49:26.746 A:middle
And then that's it.

00:49:26.746 --> 00:49:29.936 A:middle
The reply is sent, the
recipient receives it,

00:49:29.936 --> 00:49:31.656 A:middle
and the game can move on.

00:49:32.626 --> 00:49:36.336 A:middle
Once your user is done
with an exchange, right?

00:49:36.526 --> 00:49:37.776 A:middle
They don't want the results.

00:49:38.496 --> 00:49:39.306 A:middle
They're tired.

00:49:39.306 --> 00:49:40.976 A:middle
You know, they want to get
on and finish their turn.

00:49:41.486 --> 00:49:42.616 A:middle
You can cancel exchanges.

00:49:42.616 --> 00:49:45.976 A:middle
This leaves the control and
the duration of the exchange

00:49:45.976 --> 00:49:48.216 A:middle
and the turn in control
of your player.

00:49:49.326 --> 00:49:50.666 A:middle
And so when you don't
want to wait

00:49:50.666 --> 00:49:52.076 A:middle
for further replies, cancel it.

00:49:52.606 --> 00:49:55.466 A:middle
You can cancel active, once
that you're still waiting

00:49:55.466 --> 00:49:57.356 A:middle
for replies, or even
complete an exchange.

00:49:57.356 --> 00:49:58.446 A:middle
I mean this is going
to essentially say,

00:49:58.446 --> 00:49:59.976 A:middle
I'm discarding the results
from this completed exchange.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:50:00.046 --> 00:50:03.536 A:middle
I don't need to reconcile,
resolve it.

00:50:03.866 --> 00:50:07.246 A:middle
And the act of cancelling
an exchange removes it

00:50:07.246 --> 00:50:07.866 A:middle
from the match.

00:50:09.546 --> 00:50:11.726 A:middle
So, did you saw-- you can
call the instance method

00:50:11.726 --> 00:50:14.606 A:middle
on the exchange; cancel
with localized message,

00:50:15.336 --> 00:50:17.056 A:middle
given some arguments and
a completion handler.

00:50:17.526 --> 00:50:19.596 A:middle
The users that have been waiting
for exchange will be able

00:50:19.596 --> 00:50:21.686 A:middle
to see a notification
that, yes this request

00:50:21.686 --> 00:50:23.236 A:middle
that you've done
previously has been canceled.

00:50:25.116 --> 00:50:30.036 A:middle
And lastly now, the final R
is resolving the exchanges.

00:50:31.456 --> 00:50:35.636 A:middle
Remember that all completed
exchanges needed resolve

00:50:35.636 --> 00:50:39.996 A:middle
and an exchange is complete
once you receive all the replies

00:50:39.996 --> 00:50:42.486 A:middle
for it including time outs.

00:50:44.706 --> 00:50:46.966 A:middle
It's also very important
to remember that you need

00:50:46.966 --> 00:50:49.466 A:middle
to resolve all the
completed exchanges

00:50:49.856 --> 00:50:52.176 A:middle
and that exchanges could
be done between players

00:50:52.176 --> 00:50:54.736 A:middle
that are not the current
player, some of you--

00:50:54.736 --> 00:50:56.346 A:middle
you're going to have to
check and see, you know,

00:50:56.456 --> 00:50:58.526 A:middle
which exchanges have been
completed, handle that

00:50:58.526 --> 00:50:59.966 A:middle
and integrate that
into your match data.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:51:00.306 --> 00:51:02.326 A:middle
You know, how you do
that is all up to you.

00:51:02.486 --> 00:51:05.236 A:middle
You own the payloads and the
requests and the replies.

00:51:05.326 --> 00:51:08.456 A:middle
You own the match data, you
know, but you need to tell us

00:51:08.456 --> 00:51:10.686 A:middle
that you have resolved
this exchange,

00:51:10.686 --> 00:51:13.656 A:middle
and we will remove resolved
exchanges from the match.

00:51:13.846 --> 00:51:18.096 A:middle
So what you do is you gather
the data form the exchange

00:51:18.096 --> 00:51:18.676 A:middle
and reply.

00:51:19.746 --> 00:51:20.906 A:middle
You do what you need
to with that.

00:51:21.726 --> 00:51:25.546 A:middle
You then merge this into
the match state and then

00:51:25.826 --> 00:51:28.576 A:middle
when you resolve it,
we'll remove the match

00:51:28.576 --> 00:51:30.206 A:middle
so that it's no longer there.

00:51:31.546 --> 00:51:32.496 A:middle
Resolving the exchange.

00:51:32.646 --> 00:51:35.376 A:middle
So, we give you a
convenience method

00:51:35.376 --> 00:51:37.166 A:middle
to get all the completed
exchanges on the match.

00:51:37.756 --> 00:51:39.776 A:middle
It's this property,
completed exchanges.

00:51:41.596 --> 00:51:44.396 A:middle
You're going to go-- then
take this completed exchanges

00:51:44.666 --> 00:51:47.346 A:middle
and you're going to gather
the data-- the match, sorry,

00:51:47.346 --> 00:51:50.206 A:middle
the data from each exchange
and each reply and put it

00:51:50.206 --> 00:51:52.706 A:middle
into your new match data,
the merged match data here.

00:51:53.586 --> 00:51:56.526 A:middle
And then just like when we say
saving an intermediate turn,

00:51:57.326 --> 00:52:00.616 A:middle
we have this method where you
can save this new merged data

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:51:57.326 --> 00:52:00.616 A:middle
we have this method where you
can save this new merged data

00:52:00.666 --> 00:52:01.776 A:middle
without passing the turn.

00:52:02.276 --> 00:52:04.056 A:middle
So, you call saved
merged matched data

00:52:04.366 --> 00:52:06.276 A:middle
with resolved exchanges
and completion handler.

00:52:07.036 --> 00:52:08.266 A:middle
And the reason you want
to do this is you want

00:52:08.266 --> 00:52:10.066 A:middle
to resolve exchanges
as they get completed.

00:52:10.586 --> 00:52:14.316 A:middle
But you don't necessarily end
the turn when you do this.

00:52:14.536 --> 00:52:15.866 A:middle
And then usually
continues with the turn.

00:52:16.806 --> 00:52:21.436 A:middle
Exchanges have their own event
handler protocol methods here.

00:52:22.016 --> 00:52:24.076 A:middle
So, as I mentioned
earlier, there are three.

00:52:24.756 --> 00:52:26.626 A:middle
You get to be notified
with an event

00:52:26.696 --> 00:52:29.486 A:middle
when you're player receives
a new exchange request,

00:52:29.556 --> 00:52:31.836 A:middle
that is player received
exchange request from match.

00:52:33.186 --> 00:52:35.416 A:middle
You'll be notified
when exchange request

00:52:35.416 --> 00:52:36.926 A:middle
that your player
has gets canceled.

00:52:36.926 --> 00:52:40.016 A:middle
The player received exchange
cancellation from match.

00:52:41.326 --> 00:52:44.916 A:middle
And you also be notified
when you have in exchange

00:52:44.916 --> 00:52:47.326 A:middle
that you sent out
has been completed,

00:52:47.576 --> 00:52:48.836 A:middle
or any exchange has
been completed.

00:52:49.376 --> 00:52:50.116 A:middle
And this is, you know,

00:52:50.186 --> 00:52:51.556 A:middle
the player received
exchange replies.

00:52:51.556 --> 00:52:53.266 A:middle
We're going to give you
all replies at this time.

00:52:53.916 --> 00:52:56.206 A:middle
For this completed
exchange, for match.

00:52:59.966 --> 00:53:02.866 A:middle
So, let's look at how we, you
know, what kind of we want to do

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:52:59.966 --> 00:53:02.866 A:middle
So, let's look at how we, you
know, what kind of we want to do

00:53:02.866 --> 00:53:03.936 A:middle
when we handle an exchange.

00:53:04.396 --> 00:53:06.696 A:middle
This is sort of similar to
getting a turned event, right?

00:53:07.906 --> 00:53:10.306 A:middle
Exchanges, you know, user
handling exchange, they're going

00:53:10.306 --> 00:53:12.536 A:middle
to be playing your
games like a mini turn.

00:53:13.206 --> 00:53:13.956 A:middle
Right, so you you're
going to want

00:53:13.956 --> 00:53:17.406 A:middle
to determine whether this
exchange, you know, the match is

00:53:17.406 --> 00:53:18.656 A:middle
for is your current
match, right?

00:53:19.046 --> 00:53:20.556 A:middle
If it's the one the
user's currently in,

00:53:21.516 --> 00:53:23.376 A:middle
immediately show them
the data, hey, you know,

00:53:23.376 --> 00:53:25.756 A:middle
there's a trade request
if you want to handle it.

00:53:26.726 --> 00:53:28.256 A:middle
If they're doing
something else in your app,

00:53:28.446 --> 00:53:32.196 A:middle
they're playing another match,
the same logic kind of holds

00:53:32.196 --> 00:53:34.486 A:middle
that we have for
turn state changes.

00:53:34.876 --> 00:53:37.536 A:middle
You don't want them to take this
immediately 'cause this will

00:53:37.536 --> 00:53:38.516 A:middle
interrupt what they're doing.

00:53:39.206 --> 00:53:41.326 A:middle
But you want to, you know,
notify them in some manner.

00:53:42.466 --> 00:53:45.656 A:middle
You know, showing some badge
in your UI, showing an alert,

00:53:45.866 --> 00:53:48.726 A:middle
using Game Center's
notification banners.

00:53:51.916 --> 00:53:54.856 A:middle
When you get in a cancel
exchange, it's pretty similar.

00:53:54.856 --> 00:53:57.836 A:middle
You know, if the users kind of
currently working on that match,

00:53:57.866 --> 00:54:00.136 A:middle
viewing that match,
dealing with that exchange,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:53:57.866 --> 00:54:00.136 A:middle
viewing that match,
dealing with that exchange,

00:54:00.876 --> 00:54:03.626 A:middle
you need to basically, say,
oh sorry we don't need you

00:54:03.626 --> 00:54:06.496 A:middle
to reply anymore,
return them to the match.

00:54:07.726 --> 00:54:10.406 A:middle
If they are, you know,

00:54:10.406 --> 00:54:12.206 A:middle
not dealing with this
exchange right now,

00:54:12.206 --> 00:54:14.296 A:middle
what you do is a little
less important, right?

00:54:14.426 --> 00:54:16.456 A:middle
You know, you've notified
them somehow, you know,

00:54:16.456 --> 00:54:17.366 A:middle
you've got a badge count.

00:54:17.366 --> 00:54:20.516 A:middle
Well, you want to clear
that so you'll, you know,

00:54:20.556 --> 00:54:25.376 A:middle
we use that badge somewhere,
hide your alert if you had one,

00:54:25.376 --> 00:54:26.326 A:middle
you know, clear the banner,

00:54:26.756 --> 00:54:28.786 A:middle
and then they'll be
able to continue.

00:54:31.106 --> 00:54:33.556 A:middle
Finally, you know, when
an exchange is completed,

00:54:33.556 --> 00:54:36.776 A:middle
you've done all the replies you
expect to receive, you know,

00:54:36.776 --> 00:54:37.726 A:middle
what do you want to do here?

00:54:37.726 --> 00:54:41.566 A:middle
Well, you're user that's getting
the reply is probably going

00:54:41.566 --> 00:54:42.556 A:middle
to want to do something with it.

00:54:42.556 --> 00:54:43.406 A:middle
If it's a trade, you know,

00:54:43.406 --> 00:54:46.046 A:middle
you'll see all the
different offers and you want

00:54:46.046 --> 00:54:48.566 A:middle
to let them pick which
one if they want to accept

00:54:48.566 --> 00:54:49.606 A:middle
or maybe make counter.

00:54:50.426 --> 00:54:53.526 A:middle
And so, you know, we check,
this the current match,

00:54:53.526 --> 00:54:54.826 A:middle
is this the current exchange,

00:54:55.586 --> 00:54:57.616 A:middle
immediately show
them the replies

00:54:57.816 --> 00:54:58.986 A:middle
because they're ready
to see that.

00:54:59.686 --> 00:55:02.766 A:middle
If it's not, you know,
show them, you know,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:54:59.686 --> 00:55:02.766 A:middle
If it's not, you know,
show them, you know,

00:55:02.766 --> 00:55:04.866 A:middle
or clear appropriately the
banners that you need to show.

00:55:05.626 --> 00:55:08.176 A:middle
And let them know that something
is waiting for them to finalize

00:55:08.176 --> 00:55:09.676 A:middle
and finish their
match-- their turn.

00:55:11.326 --> 00:55:14.136 A:middle
So, I mentioned that
this also helps also

00:55:14.136 --> 00:55:16.156 A:middle
in difficult scenarios
and I talked about trading

00:55:16.156 --> 00:55:18.266 A:middle
and simultaneous turns,
and auctions of properties.

00:55:19.226 --> 00:55:21.536 A:middle
Let's see how you do this.

00:55:22.706 --> 00:55:23.916 A:middle
Using exchanges for trading,

00:55:24.596 --> 00:55:26.776 A:middle
you let the user decide
what they're going

00:55:26.776 --> 00:55:27.646 A:middle
to offer for trade, right?

00:55:27.646 --> 00:55:28.506 A:middle
It all starts there.

00:55:29.596 --> 00:55:32.656 A:middle
Then they will send
one exchange request

00:55:32.656 --> 00:55:34.706 A:middle
to each potential trade partners
or if it's going to be offered

00:55:34.706 --> 00:55:36.876 A:middle
to everybody, you'll
send out, you know,

00:55:37.326 --> 00:55:40.636 A:middle
one for each participant
in the match.

00:55:40.636 --> 00:55:42.956 A:middle
Once they've decided
they like something,

00:55:43.216 --> 00:55:45.596 A:middle
they can cancel all the
outstanding exchanges,

00:55:46.626 --> 00:55:47.686 A:middle
and then move on.

00:55:47.936 --> 00:55:49.936 A:middle
You know, you resolve the
complete exchange into the match

00:55:50.406 --> 00:55:51.686 A:middle
and let the user go on

00:55:51.686 --> 00:55:53.566 A:middle
and finish their turn maybe
they'll make another trade.

00:55:55.016 --> 00:55:56.486 A:middle
And they could have
multiple trades going

00:55:56.486 --> 00:55:57.166 A:middle
on at the same time.

00:55:57.166 --> 00:55:58.226 A:middle
It's entirely up to your logic.

00:55:58.526 --> 00:55:59.326 A:middle
What does this look like?

00:55:59.516 --> 00:56:01.546 A:middle
Well, you've actually seen
this animation before.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:55:59.516 --> 00:56:01.546 A:middle
Well, you've actually seen
this animation before.

00:56:01.546 --> 00:56:03.446 A:middle
You get the match data, going

00:56:03.446 --> 00:56:06.456 A:middle
to send two requests
to Meg and Bob.

00:56:07.586 --> 00:56:09.036 A:middle
Meg's going to give
me a reply, I like.

00:56:09.426 --> 00:56:13.206 A:middle
I'll cancel the request to
Bob, resolve it into this--

00:56:13.376 --> 00:56:15.856 A:middle
the match state and
finish the turn.

00:56:18.916 --> 00:56:23.206 A:middle
Simultaneous turns, it's
a little more complex but,

00:56:23.496 --> 00:56:25.706 A:middle
you know, it involves
basically a single exchange.

00:56:25.926 --> 00:56:27.256 A:middle
So, you're going to
send one exchange

00:56:27.256 --> 00:56:28.546 A:middle
to all the participants
of the game.

00:56:29.486 --> 00:56:31.926 A:middle
You'll then wait until all
the replies are received

00:56:31.926 --> 00:56:32.536 A:middle
or time out.

00:56:33.786 --> 00:56:35.896 A:middle
You then can resolve
this completed exchange

00:56:35.896 --> 00:56:37.946 A:middle
into the match and
finish the turn.

00:56:40.016 --> 00:56:41.966 A:middle
Auctions, you can do similarly

00:56:41.966 --> 00:56:44.016 A:middle
or you can choose some
other mechanism to do this.

00:56:44.386 --> 00:56:45.736 A:middle
You know, send out an exchange

00:56:45.736 --> 00:56:47.406 A:middle
to all the participants
in the auction.

00:56:47.656 --> 00:56:48.686 A:middle
Give it a shot time out,

00:56:49.516 --> 00:56:51.186 A:middle
wait until all the
replies are received,

00:56:51.726 --> 00:56:54.766 A:middle
determine the high bidder,
you know, reward the item.

00:56:54.766 --> 00:56:56.376 A:middle
You repeat if you've
got some ties.

00:56:56.466 --> 00:57:00.486 A:middle
Send it just to those people let
them handle their tie and then,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:56:56.466 --> 00:57:00.486 A:middle
Send it just to those people let
them handle their tie and then,

00:57:01.206 --> 00:57:04.476 A:middle
you know, continue and resolve
the completely exchanged match

00:57:05.506 --> 00:57:06.236 A:middle
and finish the turn.

00:57:07.146 --> 00:57:09.066 A:middle
This looks a bit
different, right?

00:57:09.786 --> 00:57:12.896 A:middle
We're going to have a lot
of exchanges going or a lot

00:57:12.896 --> 00:57:14.216 A:middle
of lines that's going
to exchange.

00:57:14.896 --> 00:57:16.046 A:middle
I'm going to send
it out to everybody.

00:57:16.116 --> 00:57:18.076 A:middle
We're going to start
getting replies.

00:57:18.076 --> 00:57:18.756 A:middle
They're coming in.

00:57:19.676 --> 00:57:23.286 A:middle
We get all the replies,
exchanges completed.

00:57:23.926 --> 00:57:26.606 A:middle
We resolve it into the match
and we finish our turn.

00:57:29.476 --> 00:57:35.256 A:middle
So, that's how you can use
exchanges to do complex things,

00:57:35.256 --> 00:57:36.166 A:middle
very difficult scenarios.

00:57:36.166 --> 00:57:39.476 A:middle
You can make more complex, more
full featured turn-based games

00:57:39.736 --> 00:57:41.346 A:middle
and use on very interesting
things.

00:57:42.636 --> 00:57:46.216 A:middle
So, it's important to remember
the expectations that users have

00:57:46.216 --> 00:57:48.446 A:middle
of turn-based gaming
on mobile environments.

00:57:48.446 --> 00:57:50.426 A:middle
You have multiple sessions,
they expect to be able

00:57:50.426 --> 00:57:53.416 A:middle
to have matches, be able to
manage to just create new ones,

00:57:53.516 --> 00:57:55.556 A:middle
list them, remove old ones.

00:57:56.646 --> 00:57:58.566 A:middle
Remember, you have
to remember anything,

00:57:58.566 --> 00:57:59.706 A:middle
everything is asynchronous.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:58:00.156 --> 00:58:03.916 A:middle
So, use the new event
listener, separate your code,

00:58:03.916 --> 00:58:07.126 A:middle
make it your code a little
more simpler but, you know,

00:58:07.126 --> 00:58:08.996 A:middle
do the right things,
and don't take users

00:58:08.996 --> 00:58:10.666 A:middle
out of the current context
when it is not appropriate.

00:58:11.276 --> 00:58:14.066 A:middle
And then yes, when you want
to switch the current match.

00:58:14.066 --> 00:58:17.046 A:middle
Well, you have to think about
when these are chose to move

00:58:17.046 --> 00:58:18.906 A:middle
to a new match, when they get
an invite for the new turn.

00:58:22.056 --> 00:58:23.676 A:middle
Wrapping things up, you know,

00:58:24.356 --> 00:58:25.666 A:middle
turn-based games
are great in mobile.

00:58:25.776 --> 00:58:27.926 A:middle
We believe its sort of
optimal solution in mobile,

00:58:27.926 --> 00:58:28.696 A:middle
where people can pick up

00:58:28.696 --> 00:58:30.696 A:middle
and play whenever they
have a spare moment.

00:58:31.716 --> 00:58:34.036 A:middle
We provide multiple
sessions, up to 30 sessions

00:58:34.036 --> 00:58:35.586 A:middle
for your game and your player.

00:58:35.586 --> 00:58:37.806 A:middle
It's a very simple structure

00:58:38.136 --> 00:58:40.166 A:middle
and only one person
can write to the data.

00:58:40.166 --> 00:58:41.966 A:middle
Game Center manages all
the synchronizations

00:58:41.966 --> 00:58:42.576 A:middle
through this model.

00:58:44.406 --> 00:58:47.026 A:middle
And we have exchanges,
a new feature for iOS 7

00:58:47.086 --> 00:58:50.196 A:middle
that make very difficult
scenarios pretty easy,

00:58:50.736 --> 00:58:53.316 A:middle
it opens up new game
modes and the things

00:58:53.316 --> 00:58:55.216 A:middle
to remember are the
three Rs of exchanges,

00:58:55.386 --> 00:58:58.516 A:middle
request, reply and resolve.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:59:00.376 --> 00:59:02.236 A:middle
We want to thank you
for coming today.

00:59:02.236 --> 00:59:03.356 A:middle
If you need more information,

00:59:03.356 --> 00:59:05.066 A:middle
you can contact Allan
Shaffer [phonetic]

00:59:05.066 --> 00:59:06.986 A:middle
or Browser New Documentation.

00:59:08.466 --> 00:59:12.126 A:middle
There were successions earlier
for-- what's new in Game Center

00:59:12.126 --> 00:59:13.506 A:middle
and what's new in
iTunes Connect.

00:59:13.946 --> 00:59:14.356 A:middle
Thank you.

00:59:14.356 --> 00:59:16.016 A:middle
[Applause]

00:59:16.016 --> 00:59:26.306 A:middle
[ Silence ]