10 — Revised!

Due Wednesday 06 07 December, 11:59.59pm (an automatic extension to Thursday, 07 08 December 2022, 11:59.59pm is granted)

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

Programming Task If you haven’t done so, harden the existing remote-proxy player against ill-formed and invalid JSON. This revision is for optional credit.

Clarifications This last milestone may require resolving some corner cases or clarifying some (in the instructor's eyes) obvious terminology. So check this list as soon as you think you have encountered an issue with the spec:

What is a game-terminating player? A player that reaches its home after being told to go home because and there are no extra goals left in the sequence.

What if the last treasure-goal in the extra-goals sequence coincides with the home of the player that is told to go there? Too bad for the player. The goal gets removed from the sequence; it is assigned to the player; but it doesn't count for the player as having collected another treasure. player doesn't get to collect another treasure.

Runnables Task Revise the two executable programs for running distributed Maze game: xserver and xclients. For the last test fest, they should enforce the rules as revised for the programming task of 9 — The Revision.

For some of you, this may mean no work because the implemented revision generalizes the original one and your code fails none of the integration tests. For some others, this may mean linking in existing code because the implementation of the revision perturbs the original one. Regardless, your revised variants should pass the tests for 9 — The Revision when equipped with an empty "goals" array.

Create five tests and place them in the specified Tests/ folder. These new tests essentially use the same format of those in 8 — Remote. The input consists of a JSON array of (instances of) BadPlayerSpec2s followed by an instance of RefereeState2 State2; the output format remains the same. The interpretation of the input is that of 9 — The Revision, meaning the players sign up in the given order and the server hands them to the referee in the specified manner.

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 20Kb.

To facilitate your life, RefereeState is generalized to have an optional "goals" field so that the scripts can readily consume every existing test:

    RefereeState2 is either a RefereeState State or an object with five fields:

      { "board" : Board,

        "spare" : Tile,

        "goals" : Coordinate*,

        "plmt" : [Player, ..., Player],

        "plmt" : [RefereePlayer, ..., RefereePlayer],

        "last"  : Action }


    Coordinate* is an array of Coordinates:

      [Coordinate, ..., Coordinate]


    INTERPRETATION Specifies a sequence of treasure goals, each handed out when a

      player has reached a goal and needs another one.

Well-formed and Valid You may assume that all inputs to your test harnesses from STDIN are well-formed and valid. A well-formed piece of JSON satisfies the grammar; such a piece is valid if it also satisfies all the side constraints of a schema specification.
At this point, you understand that the test inputs represent the system-configuration aspect of your software system.