3.1 Introduction

We start this chapter with 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. In what follows, we start with an overview of the General Game Playing environment and the central role of the Game Manager. We then discuss the General Game Playing communication protocol. We see how it is used in a sample game. We conclude with a description of Gamemaster, a repository of games and matches and a source of information about general game players and general game playing tools.

3.2 Game Management

A diagram of a typical general game playing ecosystem is shown below. At the center of the ecosystem is the game manager. The game manager maintains a database of game descriptions and maintains some temporary state for matches while they are running. The game manager communicates with game players. It also provides a user interface for users who want to schedule matches, and it provides graphics for spectators watching matches in progress.

3.3 Game Communication Language

Communication between the Game Manager and game players takes place through HTTP connections. The communication model assumes that each player is running on an Internet-connected host listening on a particular port. HTTP messages sent to players have the standard HTTP header, with content type text/acl.

In the current GGP communication language, there are five types of messages used for communication between the Game Manager and game players.

(1) A ping message is used to confirm that a player is up and running. The general form is shown below.

Upon receipt of a ping message, a player is expected to return ready if it is ready to receive messages. Otherwise, it should return nil.

(2) A start message is used to initialize an instance of a game. The general form of a start message is shown below. The message begins with the keyword start, and this is followed by five arguments, viz. a match identifier (a sequence of alphanumeric characters beginning with a lower case letter), a role for the player to play (chosen from the roles mentioned in the game description), a list of game rules (written as sentences in KIF), a startclock (in seconds), and a playclock(also in seconds).

Upon receipt of a start message, a player should prepare itself to play the match. Once it is done, it should reply ready to tell the Game Manager that it is ready to begin the match. 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 will proceed on the assumption that the player is ready.

(3) A play message is used to request a move from a player. The general form of the play message is shown below. It includes an identifier for the match and a record of the moves of all players on the preceding step. The order of the moves in the record is the same as the order of roles in the game description. On the first request, where there is no preceding move, the move field is nil.

Upon receipt of a play message, a player uses the move information to update its state as necessary. It then computes its next move and returns that as answer. The GGP protocol requires that the player reply before playclock seconds have elapsed. If the Game Manager has not received a reply by this time, it substitute an arbitrary legal move.

(4) A stop message is used to initialize tell a player that a match has reached completion. The general form of the stop message is shown below.

Upon receipt of a stop message, a player can clean up after playing the match. The move is sent along in case the player wants to know the action that terminated the game. After finishing up, the player should return done.

(5) An abort message is used to tell a player that a match is terminating abnormally. It differs from a stop message in that the match need not be in a terminal state.

Upon receipt of an abort message, a player can eliminate any data structures and return to a ready state. Once it is finished, it should return done.

3.4 Game Play

The process of running a game goes as follows. Upon receiving a request to run a match, the Game Manager's first sends a "Start" message to each player to initiate the match. Once game 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. The Manager then sends a Stop message to each player.

Here is a sample of messages for a quick game of Tic-Tac-Toe.

Note that the Game Manager sends slightly different start messages to the different players. Everything is the same except for the role that each player is asked to play. In all other cases, the same messages are sent to all players. In advanced versions of the General Game Playing protocol, this symmetry is broken. The Game Manager can send different game descriptions to different players. And it can tell different players different information in the play and stop messages.

3.5 Gamemaster

Gamemaster is a database of games and developers and players and registered matches. It also links to general game playing tools and the source code for various general game players (including Egghead, the player developed in this book).

Human users can access Gamemaster at http://games.stanford.edu. This site provides browser-based facilities for updating and searching the Gamemaster database and provides access to player source code and GGP tools. There is also an API for use by computer programs to access this information. Details can be found on teh website.

Exercises

1. Connect to Gamemaster. Go to http://games.stanford.edu and click the Gamemaster link. Explore some of the matches recorded there. What is the maximum number of moves in any match in which Cluneplayer and Fluxplayer competed with each other?