5 —
Due Thursday, 27 October 2022, 11:59:59pm
Delivery Place the product of this week’s milestone into your git repo as follows:
for the Programming Task, place player.PP and referee.PP into Maze/Players/ and Maze/Referee/, respectively
Some languages demand a specific organization within the file system. In that case, you may place a link to player.PP and referee.PP into Maze/Players/ and Maze/Referee/, respectively.
for the Design Task, place interactive-player.md into Planning/
for the Testing task, place xchoice and Tests/ into a top-level repo directory named 5
All previous comments on code files apply.
The player mechanism should support the pieces of functionality of the protocol. Note this includes a way to propose an initial board. Keep in mind that the mechanics is abstracted over a strategy.
The referee Like in an actual sports game, it is not the task of the referee to collect the players and arrange them in order. See Maze.Com, a Plan. accepts a list of players—
sorted in ascending order of “age”— and runs a single game to completion according to the rules of The Game: Labyrinth. It returns the winning player(s) and those players that misbehaved (for possible further punishment, in addition for being eliminated from the game on the spot). For testing purposes, equip the referee with an interface that accepts a game state and runs the game to completion starting from this state. Recall that the (referee’s) game state is a data representation of all the information needed to resume a game with some players after an interruption.
This description of the referee demands the definition of two terms: completion and winner.
A game is completed ifa player reaches its home after visiting its designated goal tile;
all players that survive a round opt to pass; or
the referee has run 1000 rounds.
The referee determines the winner(s) as follows. In the first case, the player that reaches its home tile is the winner. In the remaining two cases, the referee uses the following ranking procedure:winners are all those players that are on their way back home and share the same minimal Euclidean distance to their home; or
if no players are on their way back from their assigned goals, winners are all those players that share the same minimal Euclidean distance to their respective goal tile.
Your referee does not yet need to implement the functionality of requesting proposals for boards from the player.
Two different teams may produce the player mechanism and the referee. Indeed, the plan calls for players from people that nobody knows. It is therefore imperative to consider failure modes and to have the referee react to failures in players.
Stop! Why?
Imagine a web server that reacts to a faulty web browser by going down.
In the same spirit, the referee is our “server,” the players are foreign entities connecting to the server. When such “foreign” players misbehave, the referee immediately stops interacting with them so that they don’t bring down the system.
This milestone demands the identification of a player’s dangerous failure modes. In the purpose statement for your referee component, explicitly state what kind of abnormal interactions that referee takes care of now and what kind are left to the project phase that adds in remote communication.
Design Task Design an interactive player mechanism. The design should describe ideas for graphical user interface.
You may also wish to include program design elements. If so, cleanly separate the two. Remember the lessons of Fundamentals III.
Keep in mind our Maze.Com, a Plan while you work on a design task.
Testing Task Create a test harness named xchoice. The harness consumes its JSON input from STDIN and produces its results to STDOUT. Create five 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).—
a State object, which describes what the player knows about the state of the game; and
a Coordinate, which specifies the goal for the active player of the given state.
The output is the Choice the player makes according to the strategy of
4 —
|
-- "PASS" |
-- an array of four JSON values: [Index, Direction, Degree, Coordinate] |
|
INTERPRETATION Spells out the two alternatives of a player's response. |
|
The first option has an immediate interpretation. The second one, |
the array, describes which row or column the player wishes to slide; |
its direction; number of degrees by which the spare tile is rotated |
(counter-clockwise) before it is inserted into the freed-up spot on |
the board; and to which place the player wants to move its avatar. |
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.