Due date: 2/18, 23:59
Objective 1: to design and implement an automated Acquire player
parametrized over a game strategy
Objective 2: to create a test harness for the Acquire player
Task 0: Organize your svn repository as follows:
basics %% collect basic shared notions such as tiles, shares, etc.
board %% the board component
state %% the internal state component
player %% the external automated player component
Lib/ %% code that you wish your chosen language had
project4/ .. as is ..
project5/ .. as is ..
project6/ %% room for a test harness
player-tester %% we must be able to copy this into a parallel folder and run
auxiliaries %% .. without copying these
project7/ %% like 6
project8/ %% like 6
If your language forces you to create directories for components, then
, and player
Warning For future assignments, we may allow modifications of
certain parts only under certain constraints.
Task 1: Your task is to design and implement an automated Acquire
player. The player's interface must accommodate all phases of an Acquire
game. In addition, you must parametrize the player component over a
strategy that chooses where to place tiles and which shares to buy. Your
solution must include two distinct strategies:
an ordered strategy, which picks the "smallest" tile in the sense
of tile<=? that can be placed on the board and buys
as many shares in hotels possible in alphabetical order
a random strategy, which randomly chooses a tile from the
player's pool and buys a random number of shares (aka stock certificates)
for random hotels. Both requests must satisfy the rules of the game.
Task 2: Your second task is to implement and deliver a test
harness, dubbed player-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
or Saturday. You may assume that each test input specifies the full
knowledge that an automated player needs for the various game actions.
The test harness must deal with one kind of request. Each grammatically
correct and valid request receives an Action response; for others, the test
harness issues an Error response.
Turn = <take-turn cash=Cash> Board Tile ... Share ... XHotel ... </take-turn>
<action hotel1 = Label> Place</action>
<action hotel1 = Label hotel2 = Label> Place</action>
<action hotel1 = Label hotel2 = Label hotel3 = Label> Place</action>
<action hotel1 = Label />
<action hotel1 = Label hotel2 = Label />
<action hotel1 = Label hotel2 = Label hotel3 = Label />
Place = <place row=Row column=Column>
| <place row=Row column=Column hotel=Label> State </place>
Error = <error msg=String />
Board = <board> Tile ... Hotel ... </board>
Hotel = <hotel name=Label>Tile Tile Tile ...</hotel>
XHotel = <hotel label=Label />
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 less than 26
NN = String, 20 chars or less
|common forms of data
A request informs the automated player of the complete state as far as the
player is concerned: the current state of the board, its available tiles,
its available shares, and the available hotel labels (unallocated
hotels). Think of it as a request to the player to take its turn.
The player's response to a request is the actions it wishes to take. An
action specifies two distinct forms of information:
where the player wishes to place tile and, if needed, which hotel is
involved (see project 5);
the hotels the player wishes to buy, if any.
If the player cannot place a tile, it omits the Place
part of the
response. The meaning of such an action is that the game has reached an
unlikely (but not impossible) situation. Since we do not know yet how to
resolve such a situation, the player signals the problem. --
I will issue a rule after the next project.