Due date: 3/23 : NOON
Running a Turn, Enforcing the Rules of the Game
PROBLEM: a player may wish to discard a squadron with aircraft (A,1) plus
two wildcards even though some other player has already discarded (A,2)
(A,3) plus a wildcard as a squadron. This is not allowed. BUT players
don't know what others have discarded, so how can they check?
The goal of this Project is to implement a rule checker for Squadron
Scramble. The rule checker is called by
consumes a player's representation and the result of playing one turn. It
determines whether the actions during the turn and the results of the turn
are consistent with the rules of the game.
Your rule checker is not to enforce the rule that a player cannot
discard/attack with a squadron if the same airplane type has been used to
form a squadron before. Since the player doesn't receive all the necessary
information, it is unfair to enforce the rule.
A player shouldn't use the same aircraft in two separate turns with
different wildcards for this purpose, and the player does have enough
information to play by this portion of the rule. For simplicity though, we
ignore this part, too.
Task 1: [POINTS: 10] Design the rule checking function.
< - I/O : 1 --->|
pp = |-----------------------------------> ProxyPlayer
| first-hand(hand) |
| create / run-one-turn() |
|----------> Administrator |
| | |
| | create() |
| t = |----------> Turn |
| | | |
| |------------------------->| take-turn(t)
| | | |
| | | | < --- I/O : 2 --->
| | | |
| | |<----------| get-a-card-from-deck()
| | |<----------| get-cards-from-stack(n)
| | | |
| |<=========================| done
| | | ======
| | | ======
< - I/O : 3 --->|
I/O 1: TESTER reads an _xtrn_ and a _hand_ with all the necessary items
for the Administrator from standard input.
I/O 2: ProxyPlayer reads as many _mesg_ from standard input as there are
and then one _done_.
The _mesg_s are turned into appropriate method calls. After
it reads _done_, the ProxyPlayer finishes its turn and returns the
specified information to
I/O 3: TESTER writes one of the following to standard output and then
closes the port:
-- a CONTRACT _resp_, if a contract is violated;
-- a TIMING _resp_, if a timing contract is violated;
-- a CHEATING _resp_, if a rule of the game is violated;
-- or the following five XML elements if the turn worked out okay:
bool %% is this the end of the battle?
borc %% the return card (or false)
slst %% the discards
from %% did the player take the cards from the stack or the deck?
atta %% (possibly empty) series of attacks
For your convenience, the message formats and the formats of test cases are
collected in one file (MESSAGES4).
Task 2: [POINTS: 10-50] The above diagram modifies the
interaction protocol of Projects 6 and 7 so that your test harness first
calls the proxy-players's
first-hand method (basically a
non-empty list of cards) and then plays one turn.
Modify your test harness so that it plays according to the above protocol.
Also develop a test suite for your rule checker according to the
specifications. As for Projects 7 and 9 we will run all test cases against
all revisions of
play-one-turn. For each of your tests that
discovers an error in some other rule checker, you will get an extra
point. If two (or more) of your test cases discover the same flaw, you
will receive one extra credit point, not two. You may receive at
most 40 extra credit points this way.
Task 3: [POINTS: 5] Your third task is to design and implement a
test case administrator. It reads a test case, starts up your test
harness, and writes XML messages to standard output and listens for
transmissions on standard input. It compares the received input against
the specified output and decides whether