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:
-
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?
-
it must allow a player to place a first tile on the board;
-
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.
-
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:
| Input |
|---|
| Turn | is |
<turn>
Board
<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>
</turn>
|
| Board | is |
<board players=PlayerNumber>
Placement ...
</board>
|
| Placement | is |
<placement c0=Color d0=Nat a0=Nat c1=Color d1=Nat a1=Nat />
|
| Score | is |
<score orange=Nat red=Nat green=Nat
yellow=Nat purple=Nat blue=Nat />
|
| Tile | is |
<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:
| Output |
|---|
| Results | is |
<results>
TileOrFalse ...
[<bad reason=FreeShapedString />]
</results>
|
| TileOrFalse | is |
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:
CasePlayer/
player.pdf
... plus supportive scanned image files ...
Source/
... source files for the turn implementation ...
... with references to "../04/Board" as appropriate ...
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 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