Igel Ärgern

Nifty Assignment 2012
Zachary Kurmas
Grand Valley State University

Igel Argern is a German board game, whose name loosely translates as "Hedgehogs in a Hurry". This board game makes for an excellent CS 2 semester project because it is very flexible and utilizes an unusually large number of different CS 2 topics. We present two projects here:

  1. a very large (eight week) semester project where students write everything but the GUI, and
  2. a much smaller 3-to-4 week project where students write only the game engine.

The complete source code is available and instructors may use it as the foundation for smaller projects.

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:

  1. rolls the die,
  2. 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
  3. 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.).

Topics This board game uses an unusually large number of different CS 2 topics including: two-dimensional arrays, exceptions, interfaces, inheritance, File I/O, GUI, Presenter First design, and stacks.
Audience Appropriate for CS 2 or later.
Difficulty This is an advanced project designed to be an eight-week semester project for CS 2; however, it could easily be broken into several smaller projects.
Strengths This project's main strength is its flexibility:
  • The scope of the project can be easily reduced by removing requirements, or providing code.
  • The game has many variants, which provides opportunity for students to be creative.
  • Both the UI and the rule variants can be very simple, or very elegant (thereby providing challenges to advanced students).
We also like the inheritance/polymorphism component of this project: The game board has several black squares (henceforth called "obstacles") that behave differently depending on which rule variant is being used (they can be pillars, pits, worm holes, etc.). Students can explore inheritance and polymorphism by giving each obstacle a different behavior.
Weaknesses It's a big, long project that requires a lot of supervision.
Dependencies This project requires most CS 2 topics. In addition, students need to have been introduced to some basic software design techniques.
Variants: The game rules come with over 40 variants.
Instead of writing the game, students could be given the demo jar file and be asked to:
  • Write an algorithm to play the game. (Then have the students compete to see whose algorithm performs best.)
  • Write a text interface.

The writeup for the large project assumes that instructors and students will follow a design process called Presenter First. We have found Presenter First to be very effective in helping students break a large, overwhelming project down into manageable steps. If you are not familiar with presenter First or the Model-View-Presenter design pattern, you may want to quickly read our motivation for using Presenter First. It is certainly reasonable to assign a Igel Ärgern project that is not based on Presenter First/MVP; however, instructors who choose this option will probably have to make some changes to the provided GUI (or have the students write the GUI themselves.)