CS 2

Igel Ärgern

Winter 2012

Objectives

Provide experience managing a moderately large project
Provide experience with the semester's key topics, including
- Two-dimensional arrays
- Exceptions
- Interfaces
- Inheritance
- Stacks
- Good design
- Good documentation
- Testing

Due Dates:

Final submission: 16 April, 2012

Problem Statement

Design, implement, and test the game engine for a Java application to play the board game Igel Ärgern (commonly translated as "Hedgehogs in a Hurry").

Rules are very easy to find on the web (begin by reading this document as well as others at boardgamegeek.com); and we will demonstrate the game in class. Therefore, we provide only a very brief overview here:

The standard game is played on a grid with 6 rows and 9 columns. Each player has four tokens (representing hedgehogs) that he or she must move from the left column to the right column. Hedgehogs sharing a square stack on top of each other. Only the hedgehog on the top of a stack may move.

On his turn a player:

rolls the die,
optionally moves one of his hedgehogs up or down one row (we call this a "sideways" move, because the hedgehog is moved sideways relative to the direction of travel toward the finish line), and
chooses one hedgehog (either his or another player's) in the row indicated by the die roll and moves it one space to the right (i.e., "forward").

The game is interesting because:

Some squares are obstacles and can "block" or "trap" hedgehogs.
The sideways movement allows players to
1. move one of their hedgehogs into the row indicated by the die,
2. move their hedgehogs out of a row where they could become trapped in an obstacle, or
3. simply sit on another player's hedgehog and prevent it from moving.
There are many rule variants, including many different possible behaviors for the obstacles (concrete blocks, deep pits, shallow pits, worm holes, etc.).

This document contains a long list of variants. You will be required to implement some of them.

This jar file contains an example completed project. Use it to learn how to play the game. To run the demo, download the jar file, then run java -jar igelArgern.jar from the command line.

Project Requirements

Implement and test the game logic for Igel Ärgern. (We will provide the the GUI and the controller/presenter. More on that later.) In addition to playing a basic game of Igel Ärgern, your program must meet the following requirements:

Each obstacle may have a different behavior. (This is the inheritance/polymorphism part of the project.)
By default, obstacles are deep pits. A hedgehog that falls into a pit is stuck there until every other hedgehog has caught up. In addition to deep pits, you must implement "Concrete Blocks" and at least two other obstacle behaviors. When the obstacles are concrete blocks, hedgehogs simply cannot enter that square. (This is variant 37). You may choose your other two behaviors from the rule variants, or invent one of your own. Here are some ideas:
- Black hole (variant 39): Hedgehogs go in, but they don't come out. Ever.
- Shallow pit (variant 36): Only the first hedgehog gets trapped.
- Slightly deeper pit: Only the most recent hedgehogs are trapped. When a new hedgehog falls in, the hedgehog who has been in the pit the longest (and has regained his senses) climbs up the other hedgehogs (who are still dazed) and escapes.
- Worm hole: Hedgehogs who fall in reappear somewhere else (e.g., back in the start column).
You must have some automated mechanism for testing the game engine. This need not be JUnit.

Required Design Elements

Your implementation of different obstacle behaviors must use interfaces and inheritance.
Your model (i.e., the main game engine) must implement the IIgelGame interface. In addition, your model must implement this constructor
- public MyIgelGame(IgelGameParameters)
This requirement allows the instructor to run your model against his or her tests. The constructor should place obstacles in the same location as the standard Igel Ärgern board. IgelGameParameters.obstacleType specifies the the type for all obstacles for this game. Please make sure your model recognizes the strings "ConcreteBlock" and "DeepPit". You may also have it recognize other strings if you prefer.

Suggested Approach

Create a project in your favorite IDE.
Download igelArgern.jar and import it into your project.
Create a package named model.
Create a new class in the model package that implements both IIgelGame and IGameState.
Create a new class in the model package that implements ICellState.
Download and import this class into your project. Then make the changes indicated by the comments.

At this point, if you run the main method in MyIgelArgern, you should see a configuration dialog box appear. If you press the start button, the program will crash. This is because many methods in your model are returning null. When you implement enough of your model to have removed all the default return null; statements, you should be able to see the GUI.

Model-generated Events

If you look at the IIgelGame documentation, you will see it contains a GameEventListener. This interface allows the model to report events back to the presenter. Your model must support a GameEventListener. The presenter (which we provide) is responsible for implementing a GameEventListener object and passing it to the model using the method addGameEventListener. Your model is responsible for calling methods on the GameEventListener object at the apporpriate times. For example, your model must call the GameEventListener's roll method whenever the die value changes. Because the model uses a listener, the presenter does not have to "poll" the model for events. For example, if there was no GameEventListener, then the presenter would have to call currentDieValue after every method call.

Artists (Optional)

IgelViewKurmas uses objects called Artists to draw each cell. The provided GUI comes with Artists to draw Deep Pits and Concrete Blocks. In some cases, you may be able to re-use or subclass these artists for your own obstacles. Read these instructions if you decide you want your new obstacles to have a different look.

An Artist is simply an object that implements a draw method. The type() method in ICellState tells the view which artist to use. The IIgelViewKurmas constructor takes an optional Map<String, Artist> parameter maps the strings returned by ICellState.type() to the Artist object used to render the cell. Notice that all cells of a given type share the same Artist object. This means that the Artist shouldn't store any state. The view of any given cell should be determined solely by it's state (i.e., the ICellState object).

To add another obstacle type, do the following:

Optionally, create a new Artist. This step is optional because one of the existing Artists may work for the new obstacle type. For example, if the new obstacle doesn't allow hedgehogs inside, then you can simply use the existing ConcreteBlockArtist.
Call IgelViewKurmas.defaultArtistMap() to obtain the default map.
Add an entry to this map for your new obstacle:
Pass the updated map as the second parameter to the IgelViewKurmas constructor.

      Map<String, Artist> artistMap = IgelViewKurmas.defaultArtistMap();
      artistMap.put("FinishCell", new SmileyArtist());

      // Create a view configured for the specified game.
      final IIgelView view = new IgelViewKurmas(model.getState(), artistMap);

IgelViewKurmas comes with the following artists: "Cell Type" is the string that is mapped to that artist.

Name	Cell Type	Description
`CellPanelArtist`	"Cell"	Draws a "regular" cell: A cell containing a stack of hedgehogs.
`FinishCellArtist`	"FinishCell"	Draws the cells in the rightmost column (i.e., the "finish" column). Works just like a `CellPanelArtist`, except it draws the finish line on the left side of the cell.
`DeepPitArtist`	"DeepPit"	Draws "deep pit" obstacles. These cells can contain a stack of hedgehogs. The artist draws a "regular" cell with a black background and a red border.
`ConcreteBlockArtist`	"ConcreteBlock"	Simply draws a solid black rectangle.

Hints and Reminders

Make sure each ICellState object correctly implements the type() method. Unless you have added your own Artists or artist map, the type method should return only those values listed in the "Cell Type" column of this table.

Grading / Rubric

Here is the grading rubric.

Academic Honesty

You may not under any circumstances look at the source of another person's Igel Ärgern game. In particular, you may not download implementations of Igel Ärgern from the web and look at the source code (whether original or decompiled). High-level help from classmates is allowed and encouraged, but looking at their specific implementation is not.

Deliverables / Submission

You must demonstrate your program. It is your responsibility to find a time for the demonstration. Programs that are not personally demonstrated may not be graded.

Electronically submit:

all necessary source code and support files, including tests (from your electronic submission, we must be able to compile and run your program and tests),
a single, neatly formatted pdf containing all the source code you wrote for this project (we recommend using enscript to properly format source code) and
a bug report. We should not be able to find any bugs in your project that you have not detailed in your report.

Instructor Supplied Resources

igelArgern.jar: All necessary demo and support code.
Documentation for provided code.
Full Documentation for those who want to write their own Artists or do other, optional fancy stuff.