On this page:
2.1 The Rules
2.2 Board Representation
2.3 Game Protocol
2.4 Referee Program
2.5 Handin Procedure

2 Santorini Player

Due: February 12

Santorni is a strategy game that can be played in base mode or with cards that effectively adjust the rules. It works best with 2 players, which is the only configuration that we will consider. At first, we’ll stick to the basic rules, leaving cards as a future addition to the assignment.

2.1 The Rules

The base rules are shown on the first page of the official rules. To recapitulate and to build up some shared notation:

2.2 Board Representation

Your Santorini player can use any representation internally that you find convenient, but to play against other Santorini players, we’ll need to pick a common exchange representation. For that purpose, we’ll represent a board using JSON:

For example, the JSON representation of

image

is

  {"turn":18,

   "players":[[[2,3],[4,4]],[[2,5],[3,5]]],

   "spaces":[[0,0,0,0,2],[1,1,2,0,0],[1,0,0,3,0],[0,0,3,0,0],[0,0,0,1,4]]}

After a turn to produce

image

the JSON representation is

  {"turn":19,

   "players":[[[2,5],[3,5]],[[3,3],[4,4]]],

   "spaces":[[0,0,0,0,2],[1,1,2,0,0],[1,0,0,3,0],[0,0,4,0,0],[0,0,0,1,4]]}

while the alternative, winning turn

image

produces the JSON representation

  {"turn":19,

   "players":[[[2,5],[3,5]],[[3,4],[4,4]]],

   "spaces":[[0,0,0,0,2],[1,1,2,0,0],[1,0,0,3,0],[0,0,3,0,0],[0,0,0,1,4]]}

2.3 Game Protocol

A Santorini player program must read game state as JSON from standard input and write the result of a move as JSON to standard output.

To set up the game, your Santorini player program will first receive a JSON array of one of the following shapes:

Thereafter, your player program should loop: read a JSON board for the current game state, then write a JSON board for the state after your player’s turn.

A referee program that runs the game will check that the JSON board produced by a player program represents a valid turn relative to the given JSON board. Note that it is not necessary for a player program to describe separate move and build steps; only the resulting board. Note also that the board for a winning move should not include an unnecessary build step. A player program will not be sent a board if there are no valid moves or if the other player has already won.

Each player program must be runnable as a exectuable (i.e., runnable by the OS’s execve system call) with no command-line arguments. When one player wins, both player-program processes will be forcibly terminated. “Tournament mode” will include a restriction (to be determined) on how long a player program can take to complete its turn.

The relevant JSON encodings are self-delimiting—bracketed either by { and } or [ and ]and your player program should ideally not rely on any extra whitespace. However, as a convenience, the tournament referee will send player programs JSON input with no newlines except for a newline terminator at the end of each message.

Even if your player writes a newline after JSON output, beware the common mistake of forgetting to flush standard output, especially since the default flushing mode is typically different when writing to a terminal versus writing to an operating-system pipe that is connected to a referee program.

2.4 Referee Program

A referee program and a board-drawing program will become available on January 29. Meanwhile, you should make your own tools, because that’s a good exercise.

2.5 Handin Procedure

Email the instructor an archive or a pointer to an archive (such as a link to Google Drive) that contains your source and a compiled version of your program. The compiled version should run on the CADE lab1-X.eng.utah.edu machines. Include a "README.txt" file that describes the path within your archive for the player executable. You can have multiple player executables in the archive, but choose one to enter into the tournament.