6 —
Due Thursday, 24 October 2024, 11:59:59pm
Purpose T This milestone is about the integration of the logical components of a system. Your unit tests for these components should ensure that the components integrate (meaning: “work together”) properly, perhaps even in “non-cooperative” circumstances.
(The following milestones will come with integration tests that probe all aspects of this logical system.)
Delivery Place the product of this week’s milestone into your git repo as follows:
for the Programming Task, place mechanism.PP and referee.PP into Bazaar/Player/ and Bazaar/Referee, respectively;
for the Design Task, place game-observer.md into Planning/
for the Testing task, place xrules 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 functionality implements a state machine: Look into the State design pattern.
it creates the initial game state;
it then grants players the right to play a turn, one after another;
Each turn consists of at most two player actions:
it asks the active player whether it wants a pebble from the bank or exchange pebbles according to the equations;
assuming the player’s response is legal, it updates the game state so that it can ask the player whether it wants to buy cards; and
assuming the card purchase request is also legal, it updates the game state again and rotates the active player to the back of the line.
when it recognizes that a final state has been reached, it terminates the game. This may happen after a player takes the first action of a turn.
Just like in the world of sports, it is not the task of the referee to collect the players and arrange them in order. See Bazaar.Com, a Plan. It consumes a list of players—sorted in descending order of houseplants owned— and runs a single game to completion according to the rules of The Bazaar Game. Its result is a pair: the winning player(s) and those players that misbehaved (for possible further punishment). 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, this functionality runs the game to completion, starting from this state.
the rule-book component with a way to pick a pebble from the bank in a deterministic manner. Concretely, iterate through the sequence of colors in order (red, white, blue, green, yellow) and, if a pebble of that color is available, pick it.
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.
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.
Note on Misbehavior As Logical Interactions indicates, the referee grants players two actions per turn. Furthermore, if a player’s action-response is legal, the referee executes the request on the player’s behalf on the spot. For example, a player that legally (not strategically, the ref doesn’t know the strategies) requests a pebble receives the pebble on the spot. The very moment, however, a player misbehaves in any way, the referee immediately eliminates it from the game and all its possessions disappear. In addition, the referee never communicates with it again (except for requesting its name).
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 Bazaar.Com, a Plan while you work on a design task.
Testing Task Create a test harness named xrules. The harness consumes its JSON input from STDIN and produces its results to STDOUT. Create five four tests ([0-3]-{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 (maximally useful of the running game) *Equations;
*Rules (representing the chosen pebble exchanges); and
the Turn state given to the active player.
the JSON value false indicating that the proposed trades are illegal;
- or two JSON values indicating that the proposed trades are legal and result in the update bank and the update wallet of the active player:
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.