6.5.0.3

5 — Incremental refinement, a minimal start

Due Sunday, 14 February, midnight

Task 1 Design a data representation for the species of the Evolution game.

Develop a function (method) that determines whether one species is attackable by a carnivore, given the two species and the two neighbors of the "defender" (if any).

Delivery Create a sub-directory called attack and place all necessary files/modules for the data representation and the method into this sub-directory.

Task 2 Develop a test harness for the method that accepts a single JSON expression of its inputs from STDIN and writes its results to STDOUT.

The input consists of a single Situation.

The output is one of:
  • true, if the first species is attackable by the second one;

  • false, if the first species can defend itself against an attack by the second one;

  • nothing, if the input is a Situation that your method considers ill shaped.

You may assume that the inputs are valid JSON and Situations.

A Situation is [Species, Species, OptSpecies, OptSpecies].

A Species is

    [["food",Nat],

     ["body",Nat],

     ["population",Nat+],

     ["traits",LOT]]

A LOT is one of:

An OptSpecies is

A Trait is one of: "carnivore", "ambush", "burrowing", "climbing", "cooperation", "fat-tissue", "fertile", "foraging", "hard-shell", "herding", "horns", "long-neck", "pack-hunting", "scavenger", "symbiosis", or "warning-call".

A Nat is a JSON number interpretable as a natural number between 0 and 7 (inclusive).

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

    ./xattack < some-json-input > some-json-output

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

Task 3 Design the interface of an Evolution player with respect to a dealer. For now assume that
  • the player component is written in the same language as the rest of the system;

  • it is statically linked into the overall system; and

  • the dealer and the player obey the rules of the game.

Be prepared, however, that any of these assumptions might be thrown out in the future. After all, the long term goal is a framework for Evolution software competitions. Even if you assume the above, be prepared for unintentional bugs, e.g., the player component could accidentally read or modify state that the dealer hands it.

Remember that an interface has to include a method for creating instances of the component, method signatures (possibly including behavioral contracts), sequencing constraints, and perhaps even "security" considerations (who can read/modify what).

Delivery Write up a structured English language document mixed with code fragments and possibly diagrams. Write as if you were to ship the document to Foomanistan and expect an implementation back.

Create the document as a plain text file and name it player-interface.txt. If you need supplementary diagrams (as pictures), use the png format and name these files player-interfaceN.png for N a natural number.