On this page:
3.1 Revised Board Representation
3.2 Revised Game Protocol
3.3 Test Cases and Turn Checker
3.4 Handin Procedure

3 Santorini Player with Cards

Due: March 15

For this part, you implement a player program and optionally a turn-checking program.

Building on Santorini Player, we’ll add support for the following cards from the “Simple Gods” set:

Note that these choices keep two aspects of the game (almost) the same: none of the cards require information about the game history, and all cards except Pan merely extend the set of possible moves for a player (i.e., they don’t disallow moves that would be allowed without a card). Then again, since a token can be forced by Minotaur to level 3 without winning, and since Pan can win by moving down two or more levels, checking for a winning board may now depend on the immediately preceding board. Also, Pan is special in that it disallows a move that would otherwise be allowed: one where the token moves town two or more levels and then builds (where the build step is not allowed, because Pan has already won by moving down).

In a game, each player will have a distinct card, and a player’s turn is affected only by the player’s own card.

3.1 Revised Board Representation

To accommodate player cards, we redefine players from Board Representation, and we define two new terms:

All other definitions are the same modulo references to the revised term player.

For example, if player 1 has the Artemis card and player 2 has the Prometheus card, the JSON representation of







3.2 Revised Game Protocol

To accommodate player cards in the Game Protocol, we change the setup phase. Your Santorini player program will first receive a JSON array of one of the following shapes:

For example, to start a where player 1 has the Artemis card and player 2 has the Prometheus card, the player 1 program will receive



A suitable response could be the following, which is sent on to the player 2 program:



If so, the player 2 program might reply like this:



3.3 Test Cases and Turn Checker

As part of updating your player program to work with cards, you are likely to implement turn-checking functionality. You can optionally turn that functionality into a turn-checking program to better make use of a shared test suite. The turn-checking program should loop through the following steps until the attempt to read a string in the first step produces an end-of-file:

The same as for the player protocol, a normal turn-checking input will have JSON inputs that each fit on a single, newline-terminated input line.

As a class, we will collect a shared database of tests here:


When you add a test, the server will make sure that it’s a valid test. The server makes tests available in a format that matches the protocol above: you can feed the tests as input to a turn-checking program, and then you can compare its output to the expected output that is provided on the server.

Please don’t upload lots of automatically generated tests. Instead, add hand-crafted tests for interesting cases. Note that your name is associated to any test that you upload (using a password that has been mailed to you).

3.4 Handin Procedure

As usual, 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 player 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.