4 —
Due Thursday, 12 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 the scoring and rendering functionality into Qwirkle Q/Common/game-state.PP;
for the Design Task, place player-protocol.md into Planning/
for the Testing task, place xlegal and Tests/ into a top-level repo directory named 4
Programming Task Equip your game-state component with the following two pieces:
functionality for rendering the current state, including its map, graphically;
If your TAHBPL comes with images as values, say like Beginning Student Language in Fundamentals I, it suffices to implement a function or method that turns the state into an image. Otherwise you may wish to pop up a separate window and display the current state in this window.
We strongly recommend implementing this functionality before you tackle the second programming task or the testing task.
functionality for scoring a placement.
You may assume that the given placement is legal.
Design Task The player components must communicate with the referee.
This communication involves both function/method calls and orderings of those,
i.e., a protocol. Since outsiders will program to this interface, it must be
spelled out precisely and in detail. Hint To start your
brainstorming—
A protocol supplements an API to explain the calling sequence. Protocols are rarely checked, violations hard to detect, and the resulting errors tend to be obscure.
Design the interaction protocol between the referee and the player(s). The document, named player-protocol.md, should be a well-organized English write-up. If you are familiar with UML sequence diagrams (or you have time to read up on them), illustrate the prose with one of those.
One page should suffice. Less is more.
Keep in mind our Q.Com, a Plan while you work on a design task.
Testing Task Create a test harness named xlegal. 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).—
a JPlacements array and
a JPub object, which describes what the referee knows about the state of the game.
a JPub object, which describes what the referee knows about the state of the game; and
a JPlacements array.
[Entirely Optional but Helpful Your instructors found it extremely helpful to have graphical rendering functions for states around to formulate test cases.]
Here are the relevant JSON specifications:
An alternative data representation could represent states between turns or even in the middle of turns. Stop! Think this through.
{ "map" : JMap, |
"tile*" : Tile#, |
|
INTERPRETATION Describes the current public knowledge of a player about |
the map and all players between two complete rounds of game play. The |
first item in "players" denotes the current player. The |
natural numbers report the scores of the remaining players (and |
implicitly the order of play). The "tile*" informs the |
player how many tiles the referee owns. |
|
{ "score" : Tile#, |
"name" : String, |
|
INTERPRETATION Describes a player's current score and possibly the |
tiles in its possession. |
|
[ 1Placement, ..., 1Placement] |
|
INTERPRETATION Describes the sequence of placements that the active |
player wishes to perform. |
|
{ "coordinate" : JCoordinate, |
"1tile" : JTile } |
|
INTERPRETATION Add the given tile at the specified coordinate to the |
current map. |
Tile# is a Natural no larger than 10000 1000000 the number of tiles available.
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.