8.11.1.5

5 — The Strategies 🔗

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

All previous comments on code files apply.

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.

Your first task is to design and implement a strategy interface and two concrete variants. The generic purpose of a strategy component is to make decisions. A Q player requires answers to two questions before it can compute the next action:
  1. which tile(s) should be placed and where;

  2. should it pass or replace its tiles if placing at least one is impossible.

Here are the chosen strategies:
  • 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.

Both are deterministic and thus testable. Both strategies rely on an ordering of tiles:

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.

When a strategy determines that no tile can be placed, it opts for replacement if possible; otherwise it passes.

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—and previously saved—state.

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

The inputs of xscore consist of the two JSON values:
  1. a JMap object, which describes the current state of the game map;

  2. 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.

The expected output is the score that this placement gathers, i.e., a Natural. The script cannot determine whether this placement ends the game, so it must ignore the end-of-game bonus.

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.