6 —
Due Thursday, 26 October 2023, 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 Q/Player/ and Q/Referee/, respectively;
for the Design Task, place game-observer.md into Planning/
for the Testing task, place xstrategy and Tests/ into a top-level repo directory named 6
The player mechanism should support the pieces of functionality of the protocol. Keep in mind that the mechanics is abstracted over a strategy.
The referee is a function. It Like in an actual sports game, it is not the task of the referee to collect the players and arrange them in order. See Q.Com, a Plan. accepts a list of players—
sorted in ascendingdescending order of “age”— and runs a single game to completion according to the rules of The Q Game. Its result is a pair: the names of the winning player(s) and the names those players that misbehaved (for possible further punishment, in addition for being eliminated from the game on the spot). You may assume that the players have distinct names. For testing purposes, equip the referee component with an additional piece of functionality, namely, the capability to accept a list of players plus a game state. Given these pieces of data, this functionality runs the game to completion, starting from this state.
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 game-observer mechanism. The design
should describe the interface of the component; how it interacts with the
existing system; and how a single person may wish to interact with the
observer’s view.—
Pedagogy The point of this request is to indicate how a system design may combine several architectural elements.
Keep in mind our Q.Com, a Plan while you work on a design task.
Testing Task Create a test harness named xstrategy. The harness consumes its JSON input from STDIN and produces its results to STDOUT. Create five tests ([0-4]-{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).—
The inputs of xstrategy consist of a JPub object followed by a JStrategy designation: JStrategy designation followed by a JPub object:
INTERPRETATION Designated one of the strategies from 5 — |
A JAction is one of: "pass", "replace", or a 1Placement. |
INTERPRETATION Denotes an action that a strategy may suggest. |
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.