This lesson's an overview of Game
Management.
More properly it should be called Match
Management as the issue
is how to manage individual matches of
games, not the games themselves.
We'll start with an overview of the
general game
playing ecosystem, and the central role of
the game manager.
But then discuss the general game playing
communication protocol, and
finally we see how it's used in a simple
game.
Here's a diagram of the typical general
game-playing ecosystem.
At the center is the Game Manager.
The Game Manager maintains the database
of game descriptions, maintains some
temporary
state for matches while they're running
and maintains a database of match results.
The Game Manager communicates with game
players using
the internet's TCP/IP protocol and more
specifically HTTP.
It also provides a user interface for
users who want to
schedule matches and provides graphics for
spectators watching matches in progress.
In the current GGP communication language
there are five types of messages.
that you use strict communication between
the game manager and the game players.
Mainly, info, start, play, stop, and
abort.
Let's look at each one of these in turn.
An info message is used to confirm that a
player is up and running.
The general form is shown here.
Upon receipt of an info message, a player
is expected to return
ready, if it is ready to receive messages
and play a game.
Otherwise, it should return nil or busy.
Of
course, if a player is not running, or not
connected, there'll be no response.
So in practice, info messages sometimes
evoke no reply at all.
A
start message is used to initialize a
match.
The general form of start message is shown
here.
The messages begins with the keyword
start, and that's followed by five
arguments.
namely match identifier is the sequence of
alpha numeric characters beginning with a
lower-case letter.
Uniquely distinguishes the match.
There's a role for the player to play,
chosen from among the roles
mentioned in the game description
a list of game rules, written as sentences
in prefix
gdl, a startclock in seconds, and a
playclock, also in seconds.
Upon receipt of a start message, a player
should prepare itself to play a match.
Once it's done, to reply ready to the game
manager that it's ready to begin.
the ggp protocol requires that the
player reply before startclock seconds
have elapsed.
If the game manager has not received a
reply by this
time, it proceeds on the assumption that
the player is ready.
A
play message is used to request an action
from a player.
The general forms of a play, message are
shown here.
In each case, there's an identifier for
the match.
On the first request, where there's no
preceding move, the second argument is
nil.
In all subsequent requests, the second
argument is a list
of the actions of all the players on the
preceding step.
The order of the deaction in the record is
the same of the order
of the roles in the game description.
Note that if a player fails to reply or
does
not reply in time, the Manager substitutes
a random legal action.
Upon receipt of a play message, a player
uses
the move information to update its state
as necessary.
Then computes its next move and returns
that as answer.
the ggb protocol requires that the player
reply before
playclock seconds have elapsed, if the
Game Manager has
not received a reply by this time, or
receives
an illegal action, it substitutes an
arbitrary legal action.
A stop message is used to tell a player
that a match has reached completion.
General form is shown here, there's a
match ID and a
record of the actions of all the players
on the preceding step.
On receipt of a stop message, player can
clean
up after playing the match move his, the
move
is sent along in case the player wants to
know the action that, the actions that
terminated the game.
Now after finishing up the player should
return done.
Finally, an abort message is used to
tell players that the match has terminated
abnormally.
It differs from a stop message in that the
match not need be in a terminal state.
And upon receipt of an abort message,
player, can eliminate any data
structures that it has set up and return
to a ready state.
And once it's finished, it, should return
done.
Okay, so in summary, a person's running
match goes as follows.
It begins with a receipt of a request to
run a
match from a human who wants to see the
match run.
Game Manager may, at his discretion, send
info messages
to the players to ensure that they're
ready to play.
When it's ready, it sends a start message
with
appropriate arguments to each player to
initiate the match.
Once again, play begins, the manager sends
play messages to each player
to get their plays and it then simulates
the results.
This part of the process repeats until the
game is over.
Manager then sends a stop message to each
player.
Of course, if anything is wrong, the
manager may send
an abort message at any time to terminate
the match.
Okay, now, here's an example of messages
for a quick game of Tic-Tac-Toe.
The game manager initiates the match here
by sending a start
message to all of the players, each with a
different role.
So, Player x is playing white, and Player
y is playing black.
The players then respond with ready.
They can respond immediately, or they can
wait until the startclock's exhausted
before responding.
That's their discretion.
Play begins after all the players have
responded to the
start message, or after the startclock has
expired, whichever comes first.
In this case the manager initiates play by
sending a play message to all of the
players.
Since this is the first step and there are
no
previous moves, move argument in the play
message is nil.
In this case, the first player responds
with the action mark 1 1.
One of its nine legal actions, and a
second player
responds with no operages, its only legal
action.
The Game Manager checks that all of these
actions are legal,
simulates their effects and upstates the
state of the game for itself.
And then sends play messages to the
players to solicit their next actions.
Second argument in the play message, in
this case, is a
list of actions received in response to
the preceding play message.
In this case, the first player responds
with noop, its only
legal action, and the second player
responds with mark 1 2.
Not a particularly good choice.
Again, the Game Manager checks legality,
simulates the move and updates
its state, and sends play messages
requesting the players next actions.
Fir, first player here takes advantage of
the situation and
plays mark 2 2 while the second player
does noop.
[NOISE]
There's not much for the second player
can, that
the second player do at this point to save
itself.
Instead of staving off its immediate loss,
it plays
mark 1 3, while the first player does
noop.
Game manager again simulates updates and
requests a move.
In this case first player goes in for the
kill playing mark 3 3.
With this move, the game's over.
As usual in such cases, the Manager lets
the players know by sending a suitable
stop message, and then stores the results
in the database for future reference, and
terminates.