8.11.1.5

6 — Games! 🔗

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

All previous comments on code files apply.

Programming Task Co-design implementations for a referee and a player mechanism, which interact according to Logical Interactions:
  • 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.—As always, a mix of prose, code snippets, and diagrams is appropriate. Keep it under two pages.

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).—Constraint No test file may exceed the size limit of 40Kb.

The inputs of xstrategy consist of a JPub object followed by a JStrategy designation: JStrategy designation followed by a JPub object:

    A JStrategy is one of: "dag" or "ldasg".

     INTERPRETATION Designated one of the strategies from 5 — The Strategies.

The output is an JAction and denotes what the specified strategy

    A JAction is one of: "pass", "replace", or a 1Placement.

     INTERPRETATION Denotes an action that a strategy may suggest.

The xstrategy script computes the action that the strategy would recommend in given the current state of the game.

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.