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:
the player's view of the board;
the player's score;
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
Tile Tile ...
<placement c0=Color d0=Nat a0=Nat c1=Color d1=Nat a1=Nat />
<score orange=Nat red=Nat green=Nat yellow=Nat purple=Nat blue=Nat />
<tile c0=Color c1=Color />
Its output is a graphical (GUI) visualization of this state.
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
Design and implement a
strategy API. For our purposes, an
API consists of three pieces:
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);
an informal description of each "service" provided via these identifiers;
contracts for each identifier either via a contract system in your
language or a simulated contract implementation.
As you formulate your
API, imagine programmers such
as the other students in class who may be asked to implement a strategy
Deliverables: Your SVN directory must contain a
subdirectory labeled "09" with the following pieces:
... 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.