Assignment 3 – Santorini:   the board and its pieces
1 Design
2 Build and test

Assignment 3 – Santorini: the board and its pieces

Due Wednesday 10/17 11:59pm

1 Design

The "Overlord Founder of our Precious Startup" has decided that their card game is too complex. Thus they axed the project and moved your team to project Santorini. You will be building a distributed platform for the base version of the game (without God Powers).

Design an interface for the board of the game. The board is oblivious to the rules of the game. All it "knows" is that it represents a 5x5 square of cells, and that players can place workers and buildings on these cells. Your board component should at least provide operations for (i) moving a worker from the cell it occupies to an adjacent unoccupied one and (ii) building a level in a cell adjacent to a worker given that the cell contains a building without a dome.

The interface must describe all relevant operations and all the information needed to understand what they mean. For example, an operation for moving a worker requires that you explain what is a board, what is a worker, what is a movement, what it means for a worker to occupy a cell, etc.

Describe the interface in your programming language of choice using English comments for information that you cannot describe in the language. Make sure to add purpose statements and contracts. Also be careful to define every term that you introduce even if you use it in the English language parts of the interface.

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

2 Build and test

Implement the above interface as a component. Your component 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 ["neighboring-cell-exists?", Worker, Direction] or ["get-height", Worker, Direction] or ["occupied?", Worker, Direction];

Command is of the form ["build", Worker, Direction] or ["move", Worker, Direction];

Board is of the form [Row, Row, Row, Row, Row];

Row is of the form [Cell, Cell, Cell, Cell, Cell];

Cell is either Height or [Height, Worker];

Height is one of 0, 1, 2, 3, 4;

Worker is one of "blue1", "blue2", "white1" and "white2";

Direction is one of "N", "S", "W", "E", "NW", "NE", "SW" and "SE".

Not all JSON values of the above form are valid input. In particular a Board is valid iff it contains four distinct workers. Your component does not need to handle invalid input.

When your component consumes:

a [Board, ["neighboring-cell-exists?", Worker, Direction]], it should reply true if there is a cell on the Board adjacent to the Worker in this Direction or false otherwise;

a [Board, ["get-height", Worker, Direction]], it should reply with the Height of the cell on the Board adjacent to the Worker in this Direction if a such a cell exists;

a [Board, ["occupied?", Worker, Direction]], it should reply true if a cell on the Board adjacent to the Worker in this Direction exists and the cell is occupied or false if the cell is unoccupied;

a [Board, ["build", Worker, Direction]], it should return a Board that reflects building a level in the cell on the Board adjacent to the Worker in this Direction if it is possible to build there;

a [Board, ["move", Worker, Direction]], it should return a Board that reflects moving the Worker to the cell on the Board adjacent to the Worker in this Direction if it is possible to move there.

Your component should output its replies to STDOUT in all the above scenarios but it is not responsible to reply in any other scenario.

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