A legal player, is one of the simplest types of game players.
You need to stay.
A legal player selects an action based solely
on its legality, without consideration of the consequences whatsoever.
Typically, the choice of action is consistent, and selects the
same action every time it finds itself in the same state.
Using the basic sub-routines provided in the GDP
starter pack, building a legal player is simple.
Here we see the entire implementation.
And throughout this course, we use JavaScript
for computer code, as I mentioned earlier.
This is a compromise between Lisp and Java.
Lisp is a powerful language, it's highly efficient
and it's easy to use in building players.
However, it's not very
widely known.
Building programs in Java is slightly more difficult, but
the language is familiar to more people these days.
Java script has a flexibility of Lisp, and
at the same time it's easily converted to Java.
It can also be used directly to implement players,
either in web browsers or in stand alone applications.
Let's walk through this implementation.
We start by setting up some global variables
to maintain state, while a match is in progress.
That's a variable to hold the game rule set, a
variable to hold the player's role in that game, a
variable to hold a list of all the roles in
the game, and a variable to hold the current state.
And now, properly we should create a data structure
for each separate match, and we should attach these values
to this data structure, so the player can
actually play multiple matches at the same time.
However, in this presentation we're striving for simplicity, and so
we'll be treating these as global variables and what follows.
Okay, next we define a handler for each type of message.
The info handler, does nothing at all and simply returns ready.
The start event handler, assigns values to the rule
set and role variables, based on the incoming start message.
It, it initializes roles and the state variable, and then returns ready.
The play event handler, takes a match identifier and a move his arguments.
If the move is not nil, it uses nexts to find nexts, to compute
the state resulting from them preceding state and the action supplied in the move.
Once the player has the latest state, he
uses legalx, findlegalx, to compute a legal move.
The stop event handler for a legal player does nothing.
Ignores the inputs, and simply returns done, as required by the GGP protocol.
And like the stop message handler, the abort message handler
for a player, also does nothing and it simply returns done.
Okay, just to be clear on how this
works, lets work through a short tic-tac-toe match.
When the players initialized, it sets up data structures to hold
the game description, the role, roles, and the state.
These are all initially empty.
Players not retain start clock and play clock, since it does not need to do
extensive computation for those li, how limits are irrelevant.
[BLANK_AUDIO]
Okay, let's assume that player reads the start, receives the
start message from the game manager, as sort shown here.
Match identifiers in 23.
The player is told to be the white player. There are the usual axioms of tic-tac-toe.
The start clock and play clock are both set to ten seconds.
On receipt of the message, the player code calls start handler.
This records the game description and the rule set
variable, and the player's role in the role variable.
Then computes roles from the game description,and the initial state.
Returned values ready, which is then sent back
to the game manager by the listener loop.
Okay, now play begins after all the players have responded,
or after the start clock has expired, whichever comes first.
Once the game manager's ready, it sends a
suitable play message to all of the players.
Here we see a request for the player to choose an action from match m 23.
Excuse me.
The value nil signifies that this is the first step of the match.
On receipt of this message, the player code invokes the play
handler with the arguments passed to it by the game manager.
Since the move argument is nil, no changes are made to the data structures at all.
And using the state together with the role in the role description,
associated with this match, the player then computes the first legal move.
In this case mark (1,1), and it returns that as the answer.
Game manager checks that the actions of all the players are
legal, and simulates their effects, and updates the state of the game.
And then sends play messages to the players to solicit their next actions.
In this case, the player will receive the message shown here.
Mark (1, 1), from the white player, and no
opt the only legal move for the black player.
Again, the player invokes its play handler with
the arguments passed to it by the game manager.
And this time the move is not nil, and so
the player uses find next, to compute the next state.
There are two differences.
There's now an x in cell (1, 1), and control is switched from white to black.
Using this state, the player then computes the first legal action in this state.
Its, its only legal action, there's no up, and returns that as answer.
Okay, this processing repeats until the end of the game.
When the game's over the player receives a message like the one shown here.
While some players are able to make use of the information in a stop message,
our legal player simply ignores this information,
returns done, terminating its activity on this match.
[SOUND]