Due date: 3/17 : 11PM

Objective: (1) to implement graphical rendering methods; (2) to rigorously specify the strategy interface

---

Visualizing Ingenious: Now that you have a working "Ingenious player farm" for automated strategies, it is time to implement some rendering methods so that you can watch a game unfold.

Task 1: Design and implement graphical rendering methods so that your implementation can visualize a mechanized player. A player's state consists of three major pieces that your implementation should be able to visualize:

1. the player's view of the board;

2. the player's score;

3. the player's hand (currently available tiles).

Implement visualization methods for these three data representation and create a harness that can use these three methods to visualize a player's state. The harness must consume specifications of the following form:

Input
Player	is	<player> Board Score Tile Tile ... </player>
Board	is	<board players=PlayerNumber> Placement ... </board>
Placement	is	<placement c0=Color d0=Nat a0=Nat c1=Color d1=Nat a1=Nat />
Score	is	<score orange=Nat red=Nat green=Nat yellow=Nat purple=Nat blue=Nat />
Tile	is	<tile c0=Color c1=Color />

Its output is a graphical (GUI) visualization of this state.

TestFest: Since it is basically impossible to compare the GUI outputs of programs in different languages, we will not conduct a test fest. Instead we will post take a screenshot per implementation and post it.

API Design: The second task is an exercise concerning API design, a situation with which all good programmers are confronted sooner or later. You have had two chances to work with the 'strategy' API in your system. This experience should enable you to define an API in the common sense, namely something that you publish so that others can program against it. The problem with APIs is of course that once in place, people program to it and it becomes increasingly difficult to change it.

Task 2: Design and implement a strategy API. For our purposes, an API consists of three pieces:

1. a listing of all publicly available identifiers of the interface, possibly including their type signatures (if you are working in an explicitly statically typed language or an implicitly statically typed language that allows explicit annotations);
2. an informal description of each "service" provided via these identifiers;
3. contracts for each identifier either via a contract system in your language or a simulated contract implementation.

As you formulate your strategy API, imagine programmers such as the other students in class who may be asked to implement a strategy for Ingenious.

Deliverables: Your SVN directory must contain a subdirectory labeled "09" with the following pieces:

 Visuals/
  ... source files for the modified board implementation ...
  ... source files for the modified score implementation ...
  ... source files for the modified player hand implementation ...
 xbuild ... builds an executable (if needed)
 xrun   ... consumes a player configuration and displays it 

The Linux (Ubuntu) shell script xbuild should create an executable (if necessary). The xrun script should consists of at most two or three lines; its purpose is to execute one gui program, with its input coming from STDIN.