5 —
Due Thursday, 19 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 strategy.PP into Q/Player/;
for the Design Task, place referee-state.md into Planning/
for the Testing task, place xscore and Tests/ into a top-level repo directory named 5
Programming Task Fundamentals I teaches to abstract after you have seen several similar pieces of code. In this situation, you can see ahead of time that the playing mechanics remains the same, that the decision-making changes, and what the decision-making is all about. It is therefore appropriate to abstract immediately. An AI player needs a strategy. Indeed, an ambitious participant in a Q game may wish to experiment with more than one strategy. So a player component should handle the mechanics of playing and should abstract over a strategy component.
which tile(s) should be placed and where;
should it pass or replace its tiles if placing at least one is impossible.
The first one is called dag. It chooses the player’s smallest tile that can extend the current map. If there is more than one place, it breaks the tie using the row-column order for coordinates.
The second is called ldasg. It chooses the player’s smallest tile that can extend the current map. If there is more than one place, it picks the one that has the most existing neighbors, that is, the most constrained one. Ties among those most-constrained places are broken using the row-column order for coordinates.
The lexicographic ordering on tiles says that tile p is less than tile q if p’s shape is less than q’s. If p’s shape is identical to q’s, p is below q iff p’s color is below q’s.
Shapes are ordered from lowest to highest as listed in the definition.
Colors are ordered from lowest to highest as listed in the definition.
Your second task is to equip your strategy component with an iteration functionality. Starting from some game state, the piece of functionality applies a given strategy as far as possible to obtain the longest possible series of placements or a replacement decision or a pass decision.
Design Task The referee components must communicate with the game-state
to run complete games. The referee is a mechanism that manipulates the state
turn by turn and round by round until the game is over. If someone were to
suspect suspend the game for a while, the referee could resume the game from some
given—
Based on your current implementation of the game-state component and your understanding of the referee-player protocol, design a full interface for the game-state component and develop an interaction protocol between the referee and the game-state component. The document, named referee-state.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.
Two pages 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 xscore. 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 JMap object, which describes the current state of the game map;
a JPlacements, which describes the placement that produced this state of affairs.
Added 25 Oct, after the initial grading of xscore: All 1Placements in these JPlacements are expected to be (1) distinct, (2) in one line, and (3) be part of the given JMap.
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.