Having a formal description of a game is one thing.
Being able to use that description to
play the game effectively is something else entirely.
In this lesson, we discuss strategies for building general game
players and some of the difficulties that need to be handled.
Since game descriptions are written in logic, it's obviously necessary
for a game player to do some amount of automated reasoning.
Now, there are two extremes here.
One possibility is for the game player
to process the description interpretively throughout a game.
The second possibility is for a player to use the description to
devise a specialized program and then use that program to play the game.
This is effectively automatic programming.
In this lesson, we're going to discuss the first possibility and leave it
to you to think about the second possibil, bility and various hybrid approaches.
We discuss this second approach later in the course.
We begin the lesson by talking about
some infrastructure that frames the problem more precisely.
We then consider a couple of search free uses
of this instra, infrastructure, namely legal players and random players.
In lessons five through eight, we look at complete search strategies which are
appropriate for small game trees and incomplete search strategies which are
necessary for large game trees.
In lessons nine through 12, we examine some game playing techniques based on
the properties of states rather than
properties of states rather than monolithic states.
And finally, in lessons 13 through 16, we show ways that game descriptions can
be used to deduce general properties of
games without enumerating states or properties of those.
Game players typically implement
it as a web service.
As soon as it begins running, the player enters
a loop, listening for messages from the game manager.
Upon receipt of a message, the player calls
an appropriate handler for that type of message.
When the handler is finished, player sends the return value to the game manager.
Given this architecture, building a game player
means writing event handlers for the different types
of messages in the GGP communication protocol.
There's typically one handler for each type of message.
Info, start, play, stop and abort.
So, that means writing five event handlers.
In order to make the implementation of
these message handlers a little easier, the GGP
a code base available in the course
website contains definitions for the subroutines shown here.
there's subroutines for computing the key components of a game.
For example, findrules produces a list of role find
findroles, produces a list of roles in the game.
Findinits gives a list of sentences true in the initial state.
There are also some utility routines to make our job easier.
For example, doesify takes a list of roles and
a list of actions as argument, produces a list of
sentences stating that each role specified in the roles
argument executes the corresponding action specified in the actions argument.
And then undoesify reverses this process.
You'll see how that plays into the definitions a little later.
Now,
your job in building a player as I mentioned earlier is to
use the subroutines provided to write the handlers called by the message handler.
In these next two segments, we're going to look
at a couple of simple approaches for doing this.
Now, we're going to present the definitions in JavaScript.
Yeah, you can use these yourself if
you're building your player directly in JavaScript or
you can adjust them as appropriate to
implement in a Java based version for example.
Alternatively,
you can click the appropriate box in the
parametric player to select from among different approaches.
In the slider case you don't need to type in any code at all, but you'd look
at the code that we present so that you
know what's going on when you make your selections.
[SOUND]