8 --- The Observer

8.15.0.2

8 — The Observer🔗

Due Thursday, 07 November 2024, 11:59:59pm

Purpose This milestone has two distinct learning goals:

T to develop a “non functional” but helpful component; and
T to ensure that the core system can cope with components that violate the “business logic.”. These components act in a well-behaved manner in all other ways.

Composing the already-existing visualization pieces into a complete observer is a good investment for every software system that deals with geometric ideas. While it does not enhance the functionality of the system per se (allowing players to connect and play refereed games) the observer will help you understand how games proceed and how games may go wrong. It is essentially a problem-specific debugging aid.

Delivery Place the product of this week’s milestone into your git repo as follows:

for the Programming Task, place observer.PP into Bazaar/Referee/;
for the Design Task, place remote.md into Planning/
for the Testing task, place xgames-blogic and Tests/ into a top-level repo directory named 8

Programming Task Implement an observer component with which dev ops can watch and inspect a game from a referee’s perspective.

Look into the Observer design pattern.

The observer has two different but related purposes:

it saves the states it receives as PNG files in a directory called Tmp/, using the names "0.png", "1.png", and so on.
The Tmp/ directory should be created at the place where the program is run.
it displays the states it receives as images in a graphical user interface (GUI). This GUI must support at least three interaction capabilities:
1. A next functionality shows the next state of the game, if it is available.
2. A previous functionality shows the previous state of the game, if it is available.
3. A save functionality saves the current state as an instance of Game in a file of the user’s choice.

Protocol The observer must support at least two pieces of functionality: (1) a receive-a-state functionality, which consumes a state; and (2) a game-over functionality, which alerts the observer that no more states will become available. The referee will use the first method to inform the observer of a change in state is completed and at the very end of the game (why?). The second piece of functionality is used as the referee shuts down.

The observer is wired into the referee only when a devop requests it. See below for how such a request is specified on the command line.

Design Task The time has come to prepare for turning your monolithic software system into a distributed one. Imagine your referee managing a game with all the players from your peers in class or your player participating in a game that one of your peers organizes.

Then design a protocol for gathering players, launching a game, and reporting the result. Use Logical Interactions as a starting point. Your document should combine English, schematic JSON data definitions (if needed), and sequence diagrams (if needed) to specify a protocol that you and your peers can implement.

Keep in mind our Bazaar.Com, a Plan while you work on a design task.

Testing Task Create a test harness named xgames-blogic. The harness consumes its JSON input from STDIN and produces its results to STDOUT. Create ten tests ([0-9]-{in,out}.json) and place them in the specified Tests/ folder.

A test case always consists of given inputs and expected outputs. For this course, a test consists of a pair of files: n-in.json, the input file, and n-out.json, the expected output file, where n is an integer between 0 and the requested number of tests (exclusive).—Constraint No test file may exceed the size limit of 40Kb.

The inputs of xgames-blogic consist of three JSON values:

*ActorsA, representing the actual players;
the (maximally useful) *Equations; and
a Game state.

Think of these values as a description of an interrupted game.

Functionally, xgames-blogic performs the same computation as the test harness of 7 — The Clean Up, though with actors that misbehave in different ways.

The output format is the same as for 7 — The Clean Up.

Here are the specifications for the inputs:

*ActorsA is a JSON array of Actors: [ActorA, ..., ActorA]

CONSTRAINT A *ActorsA array contains at most 6 items.

CONSTRAINT The names of any two different ActorAs must be distinct.

A ActorA is one of:

- a JSON array of two elements: [ActorName, Policy]

- a JSON array of three elements: [ActorName, Policy, Exn]

- a JSON array of four elements: [ActorName, Policy, "a cheat", Cheat]

A Cheat is one of:

- "use-non-existent-equation"