Assignment 6 – Santorini: implementing a more intelligent player and building a referee (oh ... and also time to switch partners!)
.
Due Wednesday 11/7 11:59pm
1 Essay
Your first task is to write a memo to justify the selection of the code base your team will work with for the rest of the quarter. Your memo 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 "This code base is better!" and should be addressed to the "Overlord Founder of our Precious Startup".
Deliverables: In your team’s GitHub repository, create a directory "Deliverables/6/6.1/" and deposit there a PDF called "memo.pdf".
2 Build and test
Implement a new Santorini player strategy that given a board picks a rule-respecting play for the player such that the other player does not win the game in n moves. Your strategy component should retrieve n at run time from a configuration file "strategy.config" that contains a JSON object of the form {"look-ahead" : n}.
After you implement the strategy link it with your player from assignment 5 and wrap the composition in a test harness that reads JSON from STDIN and outputs JSON to stdout.
Your test harness should expect as input a sequence of commands encoded in JSON values of the shape:
["Place",Color,Initial-Board]
or
["Play",Board]
where
Color is either "blue" or "white;
Initial-Board is a valid Board as described in assignment 5;
Board is a valid Board as described in assignment 3 but with the extra restriction that there can be no workers at levels 3 and 4.
When your component consumes:
A ["Place",Color,Initial-Board], it should reply with a JSON list that contains two pairs of numbers, each between 0 and 4. The pairs correspond to placement positions for the workers 1 and 2 of the player in that order. A worker should be placed in the first unoccupied corner clock-wise starting from the top-leftmost corner of the board.
A ["Play",Board], it should reply with a JSON list of JSON values of the form [Worker,Directions], both as specified in assignment 3. The list should contain all the possible rule-respecting plays that do not allow the other player to win the game in n moves where n is retrieved as above.
Your component should assume that every sequence of commands will consist of a "Place" command followed by a number of "Play" commands. Your component is not responsible to reply to invalid inputs including sequences of commands that do not follow the above pattern.
Deliverables: In your team’s GitHub repository, create a directory "Deliverables/6/6.2/" and deposit there your executable called “player-test-harness”, the strategy configuration file with n equal to 5, and input and expected output files for five tests. Your tests should correspond to sequences of valid commands as described above with well-defined outcomes. Moreover your executable should terminate after the input stream is closed as described in assignment 1. If you made changes to your player interface from assignment 4, deposit in the same directory a revised “design.my-language’s-extension" file.
3 Build and test
Implement a new Santorini referee based on the interface you designed for assignment 5. Feel free to change the interface if you discover it is not suitable, but document these changes.
After you implement the referee, wrap it in a test harness 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 system we are missing. However, what is new in this case is that you have to create a fake player component that returns anwers from STDIN (since the referree expects two instances of components that implement the player interface according to assignment 5) . Such components are called stubs and using stubs is a common technique in unit testing.
Your test harness should expect as input a sequence of messages encoded in JSON values of the shape:
Name
or
[Placement,Placement]
or
[Worker,Directions]
where
Name is a string denoting the name of the player, and Placement and Directions are as described in assignment 3 and assignment 4.
Your component should assume that every sequence of commands consists of two Name messages, followed by two [Placement,Placement], followed by a number of [Worker,Directions]. The messages correspond to alternating interactions with the two players of a Santorini game.Your component is not responsible to reply to invalid messages including sequences of messages that do not follow the above pattern.
When your component consumes:
A Name, it should reply the first time with "blue" and the second with "white". These are the colors of the workers of the two players that are going to play the game.
A [Placement,Placement], it should reply with a Board without any buildings reflecting the placement of the players’ workers on the board so far. If the placement is illegal, i.e. one or both of the target cells are occupied, it should reply with the name of the winner player.
A [Worker,Directions], if the play is legal and not a winning nor losing move according to the rules of the game and given the state of the board for the sequence of messages so far, it should reply with a Board as described in assignment 3 that reflects the board after the play. If the play is a winning or losing or illegal move it should reply with the name of the winner player. Any messages after deciding on the winner of a game should be ignored. Now that you have implemented and tested the board, the rule-checker, the referee and at least two players, 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).
Deliverables: In your team’s GitHub repository, create a directory "Deliverables/6/6.3/" and deposit there your executable called “referee-test-harness”, and input and expected output files for five tests. Your tests should correspond to sequences of valid commands as described above with well-defined outcomes. Moreover your executable should terminate after the input stream is closed as described in assignment 1. If you made changes to your player interface from assignment 5, deposit in the same directory a revised “design.my-language’s-extension" file.