7.4.0.10

5 — Observing Players

Due Thursday, 17 October 2019, midnight

Delivery Place the product of this week’s project steps into your repo as follows:

Design Task Develop a Tsuro tournament administrators. The task of the administrator is to manage the games for an unbounded number of players that have signed up for a tournament.

Describe an interface for the administrator and a method protocol of how it might run the tournament and interact with the players and the referee.

Two pages should suffice. Less is more.

Programming Task Spectators will wish to watch tournaments at various levels: turns and players, games and referees, tournaments and administrators.

The goal of this “ticket” is to implement graphical observers for players. Do develop an interface that describes how player components may call observer components. An observer must be able to receive the same information as a player per turn (and possibly more).

While you do not have a player component yet, modify your player interface design so that players must accommodate as many observers as desired.

Note An observer is not an interactive player.

Experimentation Task Since it is impossible to specify expected outputs for a graphical rendering task, we cannot write general unit tests and an integration test harness. Instead we write a harness for experimenting with the observer.

Develop an experimentation harness for the observer; think of it as a mock player. The harness takes a server IP address and a port from the command line. It sends the server a string (your names) and receives some JSON input; the harness renders the state and the player’s decision specified via this JSON input.

An input is a JSON array of state-pats followed by a single turn-pats:

    A turn-pat is [action-pat, tile-index, tile-index]

The array of state-pats describes the current state of the board, as outlined in 4 — The Rules. The turn-pat specifies whose player’s turn it was, which tiles the referee allocated, and which action the player chose.