►Software Development
▼Projects, Specifics
•12 — Integration Time
6.5.0.3
    ← prev  up  next → 

12 — Integration Time

Due Sunday, 10 April, midnight Monday, 11 April midnight

Changed in version 1.5: Thu Apr 7 09:42:42 CEST 2016
more on cheaters,

Changed in version 1.4: Wed Apr 6 18:17:32 CEST 2016
dealing with cheaters, how to hand out cards

Changed in version 1.3: Tue Apr 5 13:16:30 EDT 2016
fixed the definition of Choice

Changed in version 1.2: Mon Apr 4 16:05:19 EDT 2016
clarify the strategy of silly

Changed in version 1.1: Sat Apr 2 19:58:44 EDT 2016
question concerning main

Added in version 1.0.

The time has come to integrate all the pieces. This is called a systems test or an integration test. Often this means bad surprises, long hours, many curses, and lots of despair. In support of this final project step, your architect has designed an interaction Internal Protocol between the dealer and external players (to be supplied in the same language).

To use this protocol for your setting, you will have to choose appropriate data representations for the method calls and returns in your chosen language.

Important As of now, you may no longer assume that external players behave correctly. Programmers make mistakes, and competitors may even try to cheat. Make the API robust so that neither crashing (exceptions, not seg faults) nor cheating players can affect the game. Cheating players are thrown out, including the cards that they own; the game continues regardless of how many players remain.

I protect my dealer also against overly slow players, which might be stuck in an infinite loop. Consider doing so, too.

See "start up" in Internal Protocol.

Task 1 Design the Evolution main program, which combines a dealer with some number of players to run one complete game. It retrieves a natural number n (between 3 and 8) from the command line, creates n external players, hands their references to an instance of the dealer component, and then asks the dealer to run one complete game. When the game is over, the system displays the results of the game on standard out like this:

    1 player id: 3 score: 22

    2 player id: 6 score: 17

    3 player id: 2 score: 16

Delivery Place an executable called main into your main folder. Make sure it can be run from the command line like this:

    ./main n

for some natural number n between 3 and 8.

If possible, supply a compilation script.

Shell scripts A script must start with #!/bin/sh or #!/bin/bash or #!/usr/bin/python17.3 etc. Don’t assume we supply whatever it takes to get it started.

Task 2 Complete the dealer so that it can run a complete game of Evolution. The above-mentioned protocol is the API that it must provide for so-called external players. The latter are written in the same programming language by various competitors who wish to compare their programming and AI building skills.

Assumption You may assume that the plug-in players cannot read from, or (worse) write to, the dealer’s internal state. This assumption is of course false for some programming languages, as is the assumption that plug-in components can only raise known exceptions. To ensure this form of safety and security, we will have to resort to separate processes or, even better, distributed computers.

Note To render the dealer deterministic, it distributes the cards in sorted order:
; Card Card -> Boolean
; lexicographic comparison, traits first according to alphabetical
; spelling, followed by food points on the card
(define (<-card c1 c2)
  (match-define (card f1 t1) c1)
  (match-define (card f2 t2) c2)
  (or (<-trait t1 t2) (and (equal? t1 t2) (< f1 f2))))
 
; Trait Trait -> Boolean
; string comparison after converting traits to strings
(define (<-trait t1 t2)
  (string<? (trait->json t1) (trait->json t2)))
Whenever a player needs to receive n cards (beginning of turn, extinction of species), the dealer hands the player all n cards at once. Finally, the dealer also assigns 1, 2, 3, etc. as player identifications.

Delivery Make sure that we can find the relevant code from the README file.

Task 3 Complete the silly player so that it supports with all the method specified in the Internal Protocol. To remain determinisic, it chooses card actions as follows:

  1. It uses cards in <-card order.

  2. The first card goes toward food.

  3. With the next two cards, it asks for an additional species board with one trait.

  4. If there are cards left:

    1. it grows the population and body of the added species and

    2. replaces the one trait of the new species board

    3. and saves the rest for the next turn.

By the rules of Evolution the player is in possession of at least one board and four cards at the beginning of the turn.

Delivery Make sure that we can find the relevant code from the README file.

Task 4 Develop a test harness for the silly player. The harness consumes a single JSON array from STDIN and delivers a single JSON array to STDOUT.

The input consists of a Choice; the output is a Action4.

A Choice is [Player+,[LOS,...,LOS],[LOS,...,LOS]].

Interpretation A Choice [p,before,after] represents a player p whose choose is then called with the arguments before and after. Recall that the first argument to choose represents the players that take precede p in the current turn order, and the second one are those that follow.

A LOS is [Species+, ..., Species+].

Interpretation An LOS represents the information about a player that the dealer reveals to a player that must choose what actions to take with the cards.

Delivery Place an executable called xsilly into your main folder. Make sure it can be run from the command line like this:

    ./xsilly < some-json-input | diff - some-json-output

The xsilly executable must use the method from task 3. It may assume that all test inputs satisfy the JSON specification above.

If possible, supply a compilation script.

Shell scripts A script must start with #!/bin/sh or #!/bin/bash or #!/usr/bin/python17.3 etc. Don’t assume we supply whatever it takes to get it started.

Task 5 Reformulate the given interaction protocol as a remote-communication protocol between a gaming server and remote players. This change calls for a rather different sign-up procedure because main would no longer be in a position to create players; instead it waits for them to sign up via TCP. The interaction between dealers and players will use JSON to data representations to implement method calls and returns (as needed).

Delivery Create a sub-folder named remote. Place a plain text file remote.txt into the folder. Add whatever images you need as .png files.

The text file explains the revised protocol with "pointers" to the image files and JSON specifications for method calls and returns. If you are good at ASCII art, consider drawing the protocols in ASCII.

    ← prev  up  next →