Due date: 2/25, 23:59
We are about to complete stage 1 of the Acquire development plan.
Almost all the pieces are in place to run complete games of Acquire.
Objective 1: design and implement a game supervisor
Objective 2: to design an interface for game-playing strategies
Objective 3: to design an interface for automated players
Task 0: Split the player file from project 6 into two pieces: one
for the player code proper and one for the two strategies (ordered,
Task 1: Your task is to design and implement an Acquire game
testbed. The missing piece is an automated game supervisor that accepts
players and that enforces the rules during the game.
Your automated supervisor is a function/method that consumes between three
and six automated players and the number n of turns to be
played. It then runs at most n turns of a game of Acquire,
enforcing the posted rules subject to the revision concerning mergers (see
A second revision concerns the end-of-game scenario. To determine when a
game has ended, the supervisor checks the following condition.
A game is over if
all hotels on the board are safe after a player completes a turn
any of the hotels on the board consists of 41 tiles after a turn
a player cannot place a tile on the current board
the administrator runs out of tiles to hand out
Note that this revision shifts the burden of recognizing the end of a turn
from the player to the supervisor.
Finally, equip the automated game supervisor with an
optional GUI display for the current state of the
board. The supervisor should display the state of the board at the
beginning of every turn. Insert a delay into your game loop so that human
observers can comprehend the board. I have found that delaying by (/
99 number-of-turns-left) seconds creates a pause of an appropriate
length. -- When the game supervisor is called from the
test suite, the GUI must be turned off.
Task 2: Your second task is to implement and deliver a test
harness, dubbed game-tester that responds to requests in the
form of XML elements with responses. It should come with a subfolder,
player-tests, with up to three test cases specified as a pair of
files: inN.xml and outN.xml for N = 0, ..., 2. Each test
case that exposes a flaw in some other code base gets you a bonus point.
A test case that does not pass my reference implementation means a loss of
The specifications for the test harness will not be released until Friday
Run = <run rounds=Nat> Named Named Named ... </run>
Named = <player name=NN />
NN = String, 20 chars or less
Game = <exhausted> State</exhausted>
| <done> State</done>
| <score> State</score>
| <impossible> State</impossible>
State = <state> Board Player ... </state>
Player = <player name=String cash=Cash> Share ... Tile ... </player>
Board = <board> Tile ... Hotel ... </board>
Hotel = <hotel name=Label>Tile Tile Tile ...</hotel>
Tile = <tile column=Column row=Row />
Share = <share name=Label count=Nat />
Label = "American" | ... | "Worldwide"
Row = "A" | ... | "I"
Column = "1" | ... | "12"
Cash = String, interpretable as a natural number (non-negative integer)
Nat = String, interpretable as a natural number (non-negative integer)
|common forms of data
A request asks the game administrator to run up to the specified rounds
(turns) of an Acquire game with the specified list of three to six
players. All players run the ordered strategy. The game administrator
hands out the tiles according to the tile ordering.
The game administrator response reports the sequence of states that were
played in a tagged element that specifies the outcome:
done means the game ended after the specified number of rounds
played without any incident and without reaching a final state;
exhausted means the game administrator ran out of tiles;
impossible means the player could not find a legitimate place for
all of its tiles; and
score means the game ended because all hotels (and at least one)
on the board were safe or because one of the hotels consisted of 41 or
Task 3: Your final task is to design two interfaces for components
that are to be outsourced for improvement to the capable engineers in
an interface for the game strategies over which you parametrize your
players. When the Bulramistan engineers ship back their implementations of
strategies, you should be able to plug them into your player and launch
the game supervisor to run game simulations without making any other changes.
an interface for automated players. When the engineers return their
players, you should be able to plug your strategies into
their players and launch the game supervisor to run game
simulations without making any other changes.
According to the Acquire development plan, your colleagues in Bulramistan
will build the specified components in your chosen programming language.
Their products will test the architectural qualities of your product.
Note that this time around you have complete though simple implementations
of these components. Consider them prototypes. The task of the engineers
is to simulate "bored programmers" who wish to participate in your
competition by supplying components.