6515 S '11
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 13

Project 5

Due date: 2/10 : 11PM (code walked next day)

Objective: to implement turn proxies for Ingenious; to develop the player use cases

The Ingenious Game Turn: You have designed and implemented a board representation, which is the central piece of the software. It is now time to move on to the turn proxy, which controls access to the board and ensures its integrity.

Task 1: Design and implement a proxy object for Ingenious turns. The object must support the following pieces of functionality:

  1. its creation, which is a function of several pieces of data: the current state of the board; the player's current tiles; the player's scores; and the tiles that the administrator will hand the player in return for placing a turn tile.

    Note: some of this information is needed to decide the legality of a player's action; others is necessary to deal with all the actions a player needs to perform. Which is which?

  2. it must allow a player to place a first tile on the board;

  3. it must allow the player to place additional tiles;

    Rule: If placing a tile causes n of the scores to reach 18 (or more), the player not only receives an additional tile; he must place n additional tiles on the board if possible. This rule also applies to the placement of all further tiles.

  4. receive hand out an additional tile for each tile placed (during the extent of the turn) if possible. The administrator may run out of tiles, in which case the player has to play with what tiles are left in his possession.

Task 2: Your second task is to design a suite of up to 10 "integration" tests. As in assignment 5, the tests are formulated in XML. The input XML describes everything needed to create and simulate a turn:

    <player> Score Tile ...  </player>

;; NOTE: there is at least one tile in the <player> 
;;       element and at most six.

    <administrator> Tile ... </administrator>
    <actions> Placement ... </actions>
<board players=PlayerNumber> 
   Placement ...
<placement c0=Color d0=Nat a0=Nat c1=Color d1=Nat a1=Nat /> 
<score orange=Nat red=Nat green=Nat 
       yellow=Nat purple=Nat blue=Nat /> 
<tile c0=Color c1=Color /> 
The output XML reports the tile that the turn handed the player in return for putting down a tile on the game board:
  TileOrFalse ...
  [<bad reason=FreeShapedString />]
Tile or <false />
If there are more specified placement actions than the Administrator has tiles, the sequence contains <false /> instead of tiles. If the specified sequence of placement actions is faulty, the result sequence ends in a <bad ... /> element.

Test Fest: We will run all submissions on all test suites, including my own solution and test suite.

Task 3: Develop all use cases for the player and derive an informal specification of the player's interface from that. Use the following "story" for this step:

Your company wishes to sell a framework for running software competitions. Participants will write player modules that may query human players and/or use an AI to play turns. They will write these modules according to your interface specifications (to be worked out in detail next time); they will upload them through some web server; and your gaming department will then run Ingenious tournaments by linking together an appropriate number of player modules with your company's game administrator.

Deliverables: Your SVN directory must contain a subdirectory labeled "05" with the following pieces:

  ... plus supportive scanned image files ...
  ... source files for the turn implementation ... 
  ... with references to "../04/Board" as appropriate ...
  in0.xml ... in9.xml
  ex0.xml ... ex9.xml
The Linux (Ubuntu) shell script xbuild should create an executable (if necessary). The xrun script should consists of at most two or three lines; its purpose is to execute your turn implementation, consuming an (XML) input from STDIN and printing print its (XML) results to STDOUT. Note: For security reasons, your scripts will run on a machine that is disconnected from the network.

The testfest scripts will run the script as if it were launched like this:

$ `pwd`/xrun < PathToTest/in3.xml > SomeTmpFile

last updated on Tue Apr 12 15:14:46 EDT 2011generated with Racket