Teaching
6515 S '13
 
Projects
Presentations
SVN
 
Acquire
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 7

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, random).

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 blog).

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
  1. all hotels on the board are safe after a player completes a turn
  2. any of the hotels on the board consists of 41 tiles after a turn
  3. a player cannot place a tile on the current board
  4. 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 one point.

The specifications for the test harness will not be released until Friday or Saturday.

  Run   = <run rounds=Nat> Named Named Named ... </run>
  Named = <player name=NN />
  NN    = String, 20 chars or less
requests
  Game  = <exhausted> State</exhausted>
	| <done> State</done>
	| <score> State</score>
	| <impossible> State</impossible>
responses
  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:

  1. done means the game ended after the specified number of rounds played without any incident and without reaching a final state;
  2. exhausted means the game administrator ran out of tiles;
  3. impossible means the player could not find a legitimate place for all of its tiles; and
  4. 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 more tiles.


Task 3: Your final task is to design two interfaces for components that are to be outsourced for improvement to the capable engineers in Bulramistan:

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


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