Teaching
6515 S '11
 
Projects
Presentations
 
Ingenious
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 7

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

Objective: to implement a player for Ingenious that is parametrized over a game strategy


The Ingenious Player: You have designed and implemented a data representation for the board and a turn proxy. It is now time to design a player. At this point, the use case for the player consists of two different kind of interactions. First, we assume that a player registers with the central game administrator and that after setting up a game, the administrator informs the player of the number of participants and hands the player a bundle of six tiles. Second, when there are enough players around, the administrator asks players to take turns in a round-robin fashion. (Yes, there are additional use cases, and you should be prepared to implement some more in the future.)

Task 0: Describe two distinct game strategies. For now a game strategy corresponds to a mathematical function from the player's state to a tile placement. That is, a strategy computes the next tile placement from the player's current state, i.e., knowledge about the state of the world. Given our current game design and use cases, it does not have any access to the state of other players, neither their scores nor their tiles.

Task 1: Design and implement a player component that comes with these pieces of functionality:

  1. its creation, which is a function of a game strategy;

  2. a function or method for informing the player of the number of participants and of handing over a collection of six tiles;

  3. a function or method for handing a player a proxy turn object and the list of board placements that have taken place so far.

In addition, your player representation should keep track of its own current score in such a way that the test harness can set and reference.

Task 2: Your second task is to design a suite of up to 10 "integration" tests. The purpose of the test cases is to determine that your player can execute a manually determined strategy and that the turn's contracts catch flawed strategies.

As in projects 4, 5 and 6, the tests are formulated in XML. The input XML describes everything needed to create and simulate a turn:

Input
Turnis
<turn> 
    Board 
    <player> Score Tile Tile Tile Tile Tile Tile </player>
    <administrator> Tile ... </administrator>
    <actions> Placement Placement ... </actions>
</turn>
Boardis
<board players=PlayerNumber> 
   Placement ...
</board> 
Placementis
<placement c0=Color d0=Nat a0=Nat c1=Color d1=Nat a1=Nat /> 
Scoreis
<score orange=Nat red=Nat green=Nat yellow=Nat purple=Nat blue=Nat /> 
Tileis
<tile c0=Color c1=Color /> 
The intention of a turn here differs from the one in project 6. Specifically, the action sequence represents the player's strategy for one turn, given the state of the board and his own score. Since a player must perform at least one placement per turn, the sequence of actions is guaranteed to be non-empty.

The output XML reports the player's score after the turn or it signals that the player's strategy is faulty:

Output
Resultsis
<results> 
  ScoreOrBad
</results> 
SocreOrIllis one of
-- Score
-- <strategy />
-- <bad reason=FreeShapedString />
For the test harness, you need to implement a "function" that consumes lists of placements and produces a strategy. It then creates a player that executes this strategy. If the strategy is too short for the turn, it is the player's responsibility to signal a strategy problem; for any other problem, your turn must catch the player's bad behavior with a message that explains the contract violation. Put differently, it is not the task of the player to check the strategy's validity; it just executes whatever actions the strategy dictates. (If you really were not to trust your strategies, you may wish to place contracts between the player and the strategies so that you know where to start debugging.)

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

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

Source/
  ... source files for the turn implementation ... 
  ... with references to "../06/Board" as appropriate ...
  you may change the board; that is why we use svn

Tests/
  in0.xml ... in9.xml
  ex0.xml ... ex9.xml
xbuild 
xrun 
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 player 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.


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