Assignment 3 – Go: the board and its pieces
Due Tuesday 10/15 11:59pm
1 Design, Build and Test
Design and implement a component for the board of the strategy game GO. Here is a version of the basic rules of the game.
Your component should be oblivious of the exact rules of the game. All it "knows" is that it represents a 19x19 grid with black or white stones on some of the intersection points of the grid’s lines. Players should be able to query the information the board contains, and place and remove stones from it.
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 apporpriate errors if it discovers that the constraints are violated.
Similarly to the previous assigment, to facilitate testing the component agains other teams’ tests, implement a test driver that reads from STDIN requests for the component and outputs replies to STDOUT. In particular the test driver should read from STDIN JSON values of the form:
[Board, Statement]
where
Statement is either a Query or a Command;
Query is of the form ["occupied?", Point] or ["occupies?", Stone, Point] or ["reachable?", Point, MaybeStone];
Command is of the form ["place", Stone, Point] or ["remove", Stone, Point] or ["get-points", MaybeStone] ;
Board is of the form [Row, ...18 Row] where the ...18 notation means 18 repetitions of the pattern that preceeds it (in this case Row,);
Row is of the form [MaybeStone, ...18 MaybeStone];
MaybeStone is one of Stone or Empty;
Stone is one of "B" or "W";
Empty is " ";
Point is of the form "N-N" where N is a natural number between (and including) 1 and
19 —
When your component consumes:
a [Board, ["occupied?", Point]], it should reply with the literal true if the Board has a Stone at the given Point or the literal false otherwise;
[Board, ["occupies?", Stone, Point]], it should reply with the literal true if the given Stone appears on the Board at the given Point or the literal false otherwise;
[Board, ["reachable?", Point, MaybeStone]], it should reply with the literal true if (i) there is a path of (vertically or horizontally) adjacent points starting at the given Point that have the same kind of Stone as the given Point (or are similarly Empty) and (ii) the path reaches a point of the Board with the given MaybeStone, or the literal false otherwise;
a [Board, ["place", Stone, Point], it should return a Board that reflects placing the given Stone on the given Point if it is possible to do so, or it should return the JSON string "This seat is taken!" ;
a [Board, ["remove", Stone, Point]], it should return a Board that reflects removing Stone from the given Point on the Board if it is possible to do so, or it should return the JSON string "I am just a board! I cannot remove what is not there!";
a [Board, ["get-points", MaybeStone]], it should return a JSON
array of Points
that collects all the Points on the Board
that have the appropriate stone or are empty depending on the given
MaybeStone —
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/3/3.1/" and deposit there a Makefile for your test driver. In your team’s testing GitHub repository, create a directory "3/3.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.