Teaching
6515 S '11
 
Projects
Presentations
 
Ingenious
Project 1
Project 2
Project 3
Project 4
Project 5
Project 6
Project 7
Project 8
Project 9
Project 10
Project 11
Project 12
Project 13

Project 4

Due date: 2/3 : 11PM (code walked next day)

Objective: to implement the bottom layer of Ingenious, to develop another use case


The Ingenious Game Board: We have developed the story of Ingenious. We have recognized that both the administrator and the players rely on the board, and that the board thus belongs to the foundational layer of the software. Hence, this is where we start our implementation effort. At the same time, it remains unclear whether the finished game will be a pure software effort (for testing strategies or for plugging in competing players from different teams), an interactive effort (with human players) and if so, what kind of interactive effort. It is therefore imperative to focus on the model of the board, not its (textual or graphical) view.

Task 0: The game turn is the next layer up from the board implementation. Like with our running example from class, the Squadron Scramble game, our project will make use of a turn object that is handed to the player via a "take your turn" method. Write up a use story for turns. Do so in two steps. First, analyze how a turn works for a game among human participants. Second, synthesize a use case for a software design from that.

Task 1: Design and implement the Ingenious game board. The board must support four pieces of functionality:

  1. its creation, which is a function of the number of players;

    Note: the language "function of" could have raised a red flag as you read this project description. While the first N turns are special, one could argue that it is the role of the administrator to check the legality of turns. So how can the board be a function of the number of players? Well, if you check the original game rules on paper or on line, you will find out that the size of the board is determined by the number of players. Your client has changed his mind, though fortunately not in the last minute and fortunately not in a way that should cause any problems if you followed basic program design principles. See below for details.

  2. detecting whether a tile can be placed;
  3. placing a tile;
  4. and scoring the placement of a tile.
Optionally you may wish to develop some way of displaying the board. I did so to assist with debugging.

The rules governing the placement of tiles are spelled out in project 3.

For our version of Ingenious, this is the shape of the board that we start with:

initial Ingenious board for 3
a game board for three players
Here is one way to understand this board and its organization:
the inner cell the first layer the second layer
innermost cell the first layer the second layer
That is, the innermost cell is the starting point. Around this innermost cell the creator of the board arranged layers of connected hexagons. Each layer is a (large) hexagon that is a bit larger than the one it surrounds. As you can see a board for N players has N + 4 "layers" around the innermost cell, numbered 0 through N + 3.

Terminology: Given that we might wish to create a framework into which others can plug in players, we need to agree on some terminology. First, we fix the six colors that are used:

ORANGE, RED, GREEN, YELLOW, PURPLE, and BLUE.
[The shapes aren't relevant other than for rendering a board.]

Second, we need to fix coordinates for individual hexagons, which we call cells. This way "plug in" players can communicate with the framework about the board. We specify coordinates as a pair of two numbers:

  1. distance, which specifies in which layer a cell is located;
  2. angle, which specifies the exact placement of the cell within the layer, counting in a clockwise fashion starting from the "northern-most" cell (see figures).
For both numbers, we start counting at 0.

Third, a score is a relation between the colors and natural numbers. The placement of any tile scores at least one point for one of the colors. For all those colors that don't receive points a score records a zero.

Task 2: Your second task is to design a suite of up to 10 "integration" tests. Just like a unit test, an integration test consists of two pieces: a specification of an input and a specification of the expected output. In contrast to a unit test, an integration test involves several pieces of functionality at once, similar to tests for imperative methods, which also involve observers.

To accommodate the various language choices, the tests are specified via XML. The input XML determines a board via the number of players and an arbitrarily long sequence of tile placements:
Input
<board players=PlayerNumber> 
 <placement c0=Color d0=Nat a0=Nat c1=Color d1=Nat a1=Nat /> 
 <placement c0=Color d0=Nat a0=Nat c1=Color d1=Nat a1=Nat /> 
 <placement c0=Color d0=Nat a0=Nat c1=Color d1=Nat a1=Nat /> 
 ...
</board> 
The output XML reports the score that each placement receives, meaning the results element contains at most as many score elements as there are placement elements in the input:
Output
<results> 
 <score orange=Nat red=Nat green=Nat yellow=Nat purple=Nat blue=Nat /> 
 <score orange=Nat red=Nat green=Nat yellow=Nat purple=Nat blue=Nat /> 
 <score orange=Nat red=Nat green=Nat yellow=Nat purple=Nat blue=Nat /> 
 ...
 [<bad reason=FreeShapedString />]
</results> 
If any of the placement specifications violates the rules of Ingenious, the tester terminates the sequence of score elements with a bad element that informally explains the rule violation. In this case the sequence of score elements is shorter than the sequence of placement elements. A PlayerNumber attribute is a number between 2 and 6 in the shape of a quoted string; a Nat is any natural number as a quoted string; and Color is string for one of the chosen colors.

Test Fest: We will run all submissions on all test suites, including my own solution and test suite. It is therefore necessary that you strictly stick to the specified XML conventions (see below). -- Jose Falcon will publish an anonymous result matrix of test successes and failures. You can then download the failed test cases and use them to debug your implementation. Ideally you should start by deriving unit tests from the failed integration test cases. For each of your test cases that discovers a true failure in someone else's implementation, you get an extra point.

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

CaseTurn/
  turn.pdf 
  ... plus supportive scanned image files ...
Source/
  ... source files for the board implementation and other pieces ...
Tests/
  in00.xml ... in09.xml
  ex00.xml ... ex09.xml
xrun 
The Linux (Ubuntu) shell script xrun should (compile, link) run your board implementation after consuming an (XML) input from STDIN; it must print its (XML) results to STDOUT. Note: For security reasons, your script will run on a machine that is disconnected from the network.

The testfest scripts will run the script as if it were launched like this:

$ `pwd`/xrun < PathToTest/in3.xml > SomeTmpFile

A Note on XML Remember that XML notation is context-sensitive and that the attributes within elements are unordered while the order matters in sequences of elements. Furthermore, you are not to prefix elements with a prolog (XMLDesc).


last updated on Tue Apr 12 15:14:46 EDT 2011generated with Racket