8 — Tournament and Game Observers

Due Thursday, 07 November 2019, midnight

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

• for the Design Task, place WELCOME.md in Planning/.

• for the Programming Task, place

  • game-observer.PP and

  • tournament-observer.PP

  in the Admin/

• for the Testing Task, place xadmin and admin-tests in a directory named 8

Describe in a WELCOME.md document (1) how you found the corresponding components starting at the README.md file and (2) how easily the dynamic description helped you relate these three pieces. Finally, (3) investigate how you would implement the following change via these three pieces. If a player places a tile that causes a collision, the tile is placed and the acting player is eliminated. In particular, consider whether you have to change any other components in the repository to get all unit tests to pass again. How easily would you be able to accomplish this task? What is missing from the available project/file descriptions and purpose statements for classes, modules, functions, and methods?

Keep this memo to at most one page.

Programming Task

• Implement a graphical game observer.

  The purpose of the game observer is to enable human observers, dubbed humobs, to watch a game of Tsuro as it is played out by some AI players. At any moment, the humobs must be able to understand which players are still in the game, which player is the acting player, and which action the player has chosen to take given the current state.

• Implement a graphical tournament observer.

  The purpose of the tournament observer is to enable humobs to watch a tournament of at most 20 players. At any point in time, the humobs should be able to understand which players are active, which round of the tournament is being played, and which group of players is currently engaged in a game. Represent the players via their age, with the oldest one assigned the highest number and the youngest one the lowest.

Pedagogy These tasks should require small changes to the referee and administrator so that you get to know these components. At the same time, the emphasis is on creating new components. Many companies use such an introduction to a code base to familiarize you with the repository and the company’s software practices. (Of course if they are run by former EE/CEs they don’t have any.)

Testing Task Develop a test harness for the administrator. The harness should dynamically load a strategy component and combine it with the mechanical player. For now load the first-s strategy.

The input is an array of at least three and at most NNN JSON objects:

The output uses the same format as the test harness in 7 — The Administrator.

Create two tests and place them in admin-tests.