Assignment 6 – GO: the referee (oh ... and also time to switch partners!)

.

Due Friday 11/1 11:59pm for the first task and the initial tests submission, Sunday 11/3 11:59pm for submitting valid tests and Tuesday 11/5 11:59pm for the final deliverables. The valid tests that we will use for the testfest, and will count towards your score, will be those that pass the validity checks when the Sunday deadline expires.

1 Partner Switch and Essay

Your first task is to send us an email with the information of your new team in the same format as for assignment 1. Then you should write a short essay (maximum one page long) to justify the selection of the code base your team will work with for the rest of the quarter. Your essay should argue that your code base selection is preferable to the other option based on: (i) your knowledge of the language and libraries used in each code base; (ii) the features each code base implements and your confidence of the correctness of their implementation; (iii) the design of each code base. The title of the memo should be "TeamX commits to this code base!" where X is the number of your new team (we will assign those as soon as we receive your email).

Deliverables: In your team’s GitHub repository, create a directory "Deliverables/6/6.1/" and deposit there a PDF called "switch-essay.pdf".

2 Design, Build and Test

Implement a a GO referee. The referee has to be able to receive two instances of your player components (that implement the same interface interface) and manage a game of GO between these two players following the rules of the game. If the referee detects that a player is attempting to violate the rules of the game it should abort the game and notify the cheating player that they lost and the other player that they won.

After you implement the referee, wrap it in a test driver that reads JSON from STDIN and outputs JSON to stdout. Here, as in previous assignments, in order to test a component, we are faking parts of the rest of the system. However, what is new in this case is that the referee interacts with two player components that use the inputs from the STDIN as a source of canned anwsers to the referee’s messages (and output to STDOUT information received from the referee). Such testing devices are called stubs and they are a common technique in unit testing.

Your test driver should expect as input a sequence of messages encoded in JSON values of the shape:

Name

or

Action

where

Name is a string denoting the name of the player, and Action is either "pass" or Point (as described in assignment 4).

Your component should assume that every sequence of commands consists of two Name inputs, followed by a a number of Action inputs. The inputs correspond to alternating interactions with the two players of a GO game. Your component is not responsible to reply to invalid messages including sequences of messages that do not follow the above pattern.

After receiving both Name inputs, the test driver should produce the arguments the referee provides to the players’ operation that determines the color of the stones of a player, i.e., "W" or "B". The referee should assign the black stones to the player that registers first.

Right before reading an Action input, the test driver should produce the argument Boards of a call to the player operation that asks from a player to make a move. Put differently, the Action input corresponds to the answer of the player for such an operation and Boards reflects the most recent history (the last three boards) of the game’s state when the call takes place. If the action corresponds to an end of the game or illegal move the test driver should produce the names of the winners as a JSON array of strings in lexicographic order. Any messages after deciding on the winner(s) of a game should be ignored. Now you should have all the pieces for a complete game. It is time to put them together and try it out... And don’t forget to do some system testing (in the following weeks we will do more of that).

Your test driver should collect all the values it produces for a sequence of the above JSON inputs in a JSON array and output the array to STDOUT.

Deliverables: In your team’s dev GitHub repository, create a directory "Deliverables/6/6.2/" and deposit there a Makefile for your test driver. In your team’s testing GitHub repository, create a directory "6/6.2/" and deposit there five input files for the test driver with at least 5 inputs each and their expected output files. As usual name the input files "input1", "input2", etc. and the corresponding output files "output1", "output2", etc.