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:

   play-one-turn :
         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:

SEQUENCE DIAGRAM

               TESTER      
                |
< - I/O : 1 --->| 
                |  create()
           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 
                |              |              |        ======
                |              |              |        ======
                               |------------->|             end()
                               |            =====
                               |            =====
< - 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
       specified information. 
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 points.

---

Task 3: [POINTS: 5] Your third task is to design and implement a test case administrator. It reads a test case (dubbed esac in 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.