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 5

Due date: 2/11, 23:59

Objective 1: to design and implement a data representation for the states of an Acquire game plus an interface for the "rule enforcer"

Objective 2: to create a test harness for the Acquire state representation

Objective 3: to design an interface between an Acquire rule enforcer and an Acquire player

Task 1: Your task is to design and implement a data representation of complete Acquire game states. The design choices are up to you. For a minimal external API, see task 2. Satisfying task 2 may or may not suffice for all other clients of this library.

Task 2: Your second task is to implement and deliver a test harness, dubbed state-tester that responds to requests in the form of XML elements with responses. It should come with a subfolder, state-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 test harness must deal with four distinct kinds of requests. Each grammatically correct, valid, and semantically feasible request receives a State response; for others, the test harness issues an Error response.

   setup = <setup player1=NN player2=NN player3=NN />
	 | <setup player1=NN player2=NN player3=NN player4=NN />
	 | <setup player1=NN player2=NN player3=NN player4=NN player5=NN />
	 | <setup player1=NN player2=NN player3=NN player4=NN player5=NN player6=NN />
   place = <place row=Row column=Column> State </place>
	 | <place row=Row column=Column hotel=Label> State </place>
   buy   = <buy share1=Label> State </buy>
	 | <buy share1=Label share2=Label> State </buy>
	 | <buy share1=Label share2=Label share3=Label> State </buy>
   done  = <done> State </done>
   State = <state> Board Player ... </state>
   Error = <error msg=String />
  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 less than 26
  NN     = String, 20 chars or less
common forms of data

The response to a request is the state of the game that results from the execution of the required action on the specified state:

  1. setup requests a brand new game state, which means an allocating of tiles to the named players;
  2. place requests the placement of the specified tile on behalf of the current player and, if necessary, an action (founding, acquisition) on a specified hotel;
  3. buy requests the acquisition of shares on behalf of the current player;
  4. done requests the allocation of a replacement tile to the current player, if possible, and a switch to the next player in line.
If the state representation rejects a request, the response is an error message with an appropriate explanation. When the test harness receives such an error message from the state representation component, it throws away the remaining requests until STDIN is closed.

A State response specifies two kinds of information: the current state of the board and the current state of the players including the order of turns. The first player in a state representation is the "current player", i.e., the player whose turn it is.

Task 3: Your final task is to design a protocol that governs the interaction between an Acquire rule enforcer and the automated Acquire player participating in a game.

Derive an interface design for the player from the interaction.

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