►Software Development
▼—Project Milestones
•6 — The Observer
8.7.0.3
    contents  ← prev  up  next → 

6 — The Observer

Due Thursday, 03 November 2022, 11:59:59pm

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

  • for the Programming Task, place observer.PP into Maze/Referee/ and xgames-with-observer in 6;

  • for the Design Task, place remote.md into Planning/

  • for the Testing task, place xgames and Tests/ into a top-level repo directory named 6

All previous comments on code files apply.

Programming Task Design and implement a GUI observer component, called observer.PP, that can also generate JSON representations of intermediate RefereeStates.

The observer component must display a given state. The graphical user interface should provide two pieces of user functionality via buttons:

  1. A next functionality shows the next state of the game, if it is available.

  2. A save functionality saves the current state in a file of the user’s choice. Your GUI toolkit should come with a file-chooser.

Protocol The observer component supports two internal 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 after a turn is completed and the second one when a game is over.

Naturally, this observer should be wired up with the referee only on demand. To make this component truly useful for this milestone and the following ones, create a harness xgames-with-observer that consumes the same inputs as xgames with the same interpretation and then runs the referee with the observer turned on.

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.

Read up on the remote-proxy design pattern.

Then design a protocol for gathering players, launch 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 remote-proxy protocol that you and your peers can implement.

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

Testing Task Create a test harness named xgames. The harness consumes its JSON input from STDIN and produces its results to STDOUT. Create three tests 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 20Kb.

Its inputs consists of a PlayerSpec followed by a RefereeState. The test harness creates a series of players that are going to use the specified strategies. It then hands these players and the given state to the referee, which runs the game to the end and computes the winner(s). (The details will depend on your referee interface and data representations.)

The output is an array of alphabetically sorted (string<?) Names, denoting the winners.

Here are the relevant data definitions:

    A PlayerSpec is a JSON array of PS arrays.

    

    A PS is a JSON array of two (2) elements:

      [Name, Strategy]

    

    INTERPRETATION Specifies which strategy the named player of the given

      name employs.

    

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

    

    A Name is a string of at least one and at most 20 alpha-numeric

      characters, i.e., it also matches the regular expression "^[a-zA-Z0-9]+$".

    

    A Strategy is one of: "Riemann", "Euclid".

    

    A RefereeState is like a State, except that its

      "plmt" field contains an array of RefereePlayers.

    

    INTERPRETATION The state data-represents the knowledge of the referee

     at the beginning of a round and before any player has reached any assigned goal.

     Remember that a state's "plmt" field specifies

     the order in which players take turns.

    

    RefereePlayer is an object with four fields:

      { "current" : Coordinate,

        "home"    : Coordinate,

        "goto"    : Coordinate,

        "color"   : Color }

    

    INTERPRETATION Describes a player's current location, its home,

      its current goal, and the Color of its avatar.

    

    CONSTRAINT These coordinates satisfy the conditions of the game,

      meaning the values of the "home" and "goto"

      fields are on fixed tiles. Furthermore all these tiles are distinct from each other.

    

    GLOBAL CONSTRAINT The array of RefereePlayers (in RefereeState)

      contains as many players as the PlayerSpec. The order of players in

      PlayerSpec is the same as the order in RefereeState.

CONSTRAINT Keep in mind that the instructors' test harness framework forces the tiles to live up to the specification of The Game: Labyrinth: the gems on each tile are distinct and all pairs of tiles display distinct sets of gems.

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.

    contents  ← prev  up  next →