Assignment 4 – Santorini:   the rule checker and a first stub at designing players
1 Build and test
2 Design

Assignment 4 – Santorini: the rule checker and a first stub at designing players

Due Wednesday 10/24 11:59pm

1 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 Santorini boards and (ii) test harness plumbing code for unmarshaling JSON values into the library’s data representation of boards after reading them from STDIN and marshaling the results of the library’s operations back to JSON values before writing them to STDOUT, refactor your code from last week.

When you have a separate library for boards, re-use it to implement a rule checker for Santorini’s base game. Your rule-checker should provide an operation that decides if a play is valid according to the rules of the game given a board. A play refers to the choices a player makes during a turn, i.e., selecting a worker, where to move it and where to build.

After you implement the rule checker, wrap it in a test harness that reads JSON from STDIN and outputs JSON to stdout.

Your test harness should expect as input JSON values of the shape

[Board, Worker, Directions]

where

Directions is a JSON array of Direction of length 1 or 2, Board is a valid Board from assignment 3 and same for Worker and Direction.

Your test harness should output either "yes" or "no".

Deliverables: In your team’s GitHub repository, create a directory "Deliverables/4/4.1/" and deposit there your executable called “rule-checker-test-harness”, and input and expected output files for five tests.

2 Design

Design a Santorini player component and its strategy component. The player has to be able to register with the game engine, send to the game engine its next play and receive a notification upon the end of the game about which player won. The strategy component should decide a player’s next play given information from the player.

For each component your design document should include three parts (i) its interface that describes the operations the component provides together with their contracts and purpose statements, (ii) its dependencies that describe which operations of other components in your implementation the component intents to use and (iii) its knowledge that describes what information it needs to possess and maintain about the game.

As before describe the design in a mix of your programming language of choice and English comments. Also be careful to define every term that you introduce even if you use it in the English language parts of the design.

Deliverables: In your team’s GitHub repository, create a directory "Deliverables/4/4.2/" and deposit there a “design.my-language’s-extension" file.