6515 S '13
Acquire, Revised
Acquire Plan
Project 1
Project 2
Project 3
Project 4
Project 5
Project 6
Project 7
Project 8
Project 9
Project 10
Project 11
Project 12

Project 6

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 representation

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 basics, board, state, and player may be directories.

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:

  1. 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
  2. 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 one point.

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 =  
     <action> Place</action>
     <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> State </place>
	 | <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:

  1. where the player wishes to place tile and, if needed, which hotel is involved (see project 5);
  2. 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.

last updated on Wed Apr 10 20:51:12 EDT 2013generated with Racket