Assignment 4 – Go:   the rule checker
1 Design, Build and Test

Assignment 4 – Go: the rule checker

Due Friday 10/18 11:59pm for the tests and Tuesday 10/15 11:59pm for the final deliverables

1 Design, Build and Test

Take a look back at the component you built for assignment 3. If it doesn’t consist of (i) a separate library for GO boards and (ii) a test driver with plumbing code for marshaling/unmarshaling JSON values into the library’s data representation of boards refactor your code from last week.

When you have a separate library for boards, re-use it to implement a rule checker for the basic rules of GO. In particular, we will follow all ten basic rules described in the above link with (i) the addition of the optional 7A rule that disallows suicide, and (ii) the ko rule instead of the positional superko rule for rule 8.

It is up to you to decide what specific interface your component should implement and how. However, your code should come with a clear description of the interface you pick that includes an account of all operations the component is supposed to provide and all their constraints. You should also enhance your implementation with code that enforces as many of these constraints as possible and produces appropriate errors if it discovers that the constraints are violated. At the very least, your rule-checker should provide (i) a way to decide whether a move is legal and (ii) a way to calculate the final score of the two players at the end of a game.

If, while implementing the rule-checker, you realize that your board component does not provide all the operations you need, feel free to revisit its design and implementation. However, do record these changes so that we can discuss them during the code walks.

After you implement the rule checker, wrap it in a test driver that reads JSON from STDIN and outputs JSON to stdout like you did for the board in assignment 3.

In particular the test driver should read from STDIN JSON values of the form:

[Stone, Move] or Board where

Move is either a Play or a "pass";

a Play is a JSON array of the form [Point, Boards];

Boards is a JSON array of Board of length 1 to 3;

Board, Stone and Point are the same as for assignment 3.

In a value [Stone, Move], Stone represents the color of the stones of the player who is about to make the move.

If Move is a Play, the array [Point, Boards] represents the point on the current board where the player would like to place one of their stones, and Boards is a list containing the current board and the boards right before the last two moves ordered from the most recent to the oldest.

When the test driver consumes:

a [Stone, Move], it should reply with the literal true if the Move is legal for the player whose stones are Stone based on the information provided in Move, or the literal false otherwise;

a Board, it should reply with a JSON object with two keys "B" and "W" whose values are numbers representing the scores of the players with the corresponding stones in a game where the final board is Board.

Your test driver should output its replies to STDOUT for a sequence of the above JSON values as a JSON array.

Deliverables: In your team’s dev GitHub repository, create a directory "Deliverables/4/4.1/" and deposit there a Makefile for your test driver. In your team’s testing GitHub repository, create a directory "4/4.1/" and deposit there five input files for the test driver and their expected output files. The input files should have at least five valid JSON values as described above. Name the input files "input1", "input2", etc. and the corresponding output files "output1", "output2", etc.