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:
-
its creation, which is a function of a game strategy;
-
a function or method for informing the player of the number of
participants and of handing over a collection of six tiles;
-
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 |
|---|
| Turn | is |
<turn>
Board
<player> Score Tile Tile Tile Tile Tile Tile </player>
<administrator> Tile ... </administrator>
<actions> Placement 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 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 |
|---|
| Results | is |
<results>
ScoreOrBad
</results>
|
| SocreOrIll | is 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.