Due date: 2/23 : 11:59pm
Running a Turn
Task 1: [POINTS: 40] Your first task is to design (as in "design
recipe") a function that plays one turn of Squadron Scramble:
player/c deck/c stack/c (listof discard/c)
boolean? ;; is the battle over?
(or/c card? boolean?) ;; the return card (if any)
(listof discard/c) ;; the discarded squadrons
(listof attack?) ;; the attacks
(or/c from-deck? from-stack?) ;; where were the cards taken from?
;; play one turn with the given player, using the current deck, the current
;; stack, and the list of discarded squadron from all other players
The ->* notation means that the function returns several results
simultaneouesly. Some languages support this concept, some don't.
If yours doesn't, you will need to create a "record" that bundles
all the results first and then you need to unbundle them on return.
If you're using an OOD approach, consider this function a method of the
game administrator that eventually ends up being a private method. If
you're using a module-oriented approach, create a module with just this
one public function.
Task 2: Your second task is to implement a test harness for your
"administrator." The test harness interacts with our test case
administrator (you, or see below) a via standard input and output. Each
input and output message is an XML message, some simple, some complex. The
following diagram demonstrates how the harness works:
< - I/O : 1 --->|
pp = |-----------------------------------> ProxyPlayer
| 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 a _xtrn_ with all the necessary items
for the Administrator from standard input.
I/O 2: ProxyPlayer reads one _mesg_ from standard input and one _done_.
The _mesg_ is turned into an appropriate method call. After
it reads _done_, the ProxyPlayer finishes its turn and returns the
I/O 3: TESTER writes to
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
to standard output, then closes the port.
Read the auxiliary file for the old XML data definitions and the
additional XML data definitions.
Task 2a: The second part of this task is to develop test cases
for your administrator. Create a file for each test case. Remember that
due to the somewhat random nature of the player, writing test cases is
non-trivial and, for some things that you might imagine,
impossible. For now, you must assume that the
specification is for a player that plays by the rules.
POINTS: The base score for Task 2 is 15 points. We will run our own test
administrator for all test harnesses on our test cases. We will
also run all submitted test cases on our test harness.
(1) You will receive an additional point for each test case that discovers
an error in our interaction module. (2) You will lose one point for each
test case that contains an error. (3) You will not receive fewer than 15
Task 3: [POINTS: 5] Your third task is to design and implement a
test case administrator. It reads a test case (dubbed
MESSAGES2.txt, starts up your test harness,
and writes XML messages to standard output and listens for transmissions on
standard input. Finally, it reads off the final done sent and determines
whether this is the expected result according to the test case.