|CIT 594 Assignment 6: Beeper Hunt, Part II
Spring 2004, David Matuszek
As described earlier, the maze has the form of 16 5x5 "standard mazes" (mazes in which there is exactly one path from any location to any other location), arranged in a 4x4 pattern, with one opening between every pair of adjacent mazes.
The example shown was drawn by hand, so there may be errors. To better show the intended structure, I have used different colors for each "sub-maze," and separated them slightly. I expect that it will be simplest to use a simple 20x20 maze, rather than an array of arrays.
Of course, you do not hard-code these numbers (4, 5, 16, 20) into any program
statements, but rather make them named constants.
Each beeper will have a fixed lifetime, which will be some named constant. This is the maximum time a beeper will remain on the board. All beepers will have the same fixed lifetime (it's not random). Probably the number will be something like 30 or 40. The robot has full knowledge, so it knows when a beeper will disappear.
There will be two beepers on the board at all times. These will be randomly placed at the beginning of the program. Each time the robot collects a beeper, a new one appears; each time a beeper's lifetime expires, it disappears (and a new one appears at some other random location). Beeper placement is completely random over the entire board, but a beeper should not be placed (1) on top of another beeper, (2) on top of the robot, or (3) in the same location as one that just disappeared.
If the robot decides it cannot reach any beeper in time, it does not have to make a futile effort to do so. Time == steps, so time passes when the robot moves. It would probably be a good idea to define "staying in one place" as a possible move, so that the robot can deliberately make time pass without actually having to go anywhere.
I am providing a GUI program (GameBoard.zip) that I wrote some time ago, and have updated to better fit the requirements of this project. Here is a brief description of how to use this code; see the Javadoc for more information, including additional methods.
This class sets up the
Board, puts some
it, and moves them around. You should discard this class, but you can use it
as an example of how to write your own main class.
This class represents the "game board" on which things happen.
is not a complete standalone GUI, but a
Panel which you should
add to your own GUI. See the
Test class for an example of how this
can be done.
public static final int NORTH, SOUTH, EAST, WEST,
public static final int TOP, BOTTOM, RIGHT, LEFT
NORTH==TOP, etc., so you can use whichever set of four directions you prefer.
public Board(int rows, int columns)
public void setWall(int row, int column, int side, boolean wall)
true) or removes (if
false) a wall on the given
side(see above constants) of the board location [
column]. This modifies the display only; if you don't want your Pieces to move through walls, that's up to your program, not my display methods.
public void place(Piece piece, int row, int column)
public void remove(int row, int column)
public Piece getPiece(int row, int column)
Here are some additional methods which you will find useful when you go to paint your robot and beepers on the board.
public int getX(int columnNumber)
public int getY(int rowNumber)
public int getCellWidth()
public int getCellHeight()
public Piece(Board board)
public void place(int row, int column)
public void remove()
public boolean moveTo(int newRow, int newColumn)
public boolean move(int deltaRow, int deltaColumn)
public abstract void paint(Graphics g)
remove methods. They are equivalent (in fact, each calls the other),
and you can use whichever is more convenient.
These are example subclasses of
Piece. You can use them as examples,
but replace them with your own subclasses for drawing the robot and the beepers.
Please turn in a complete design for this assignment. By a "complete design"
I mean that you should specify all public classes, interfaces,
constructors, methods, and variables. Specify the signature for each method,
including the return type. Include a brief description of what each method does,
unless it is obvious from the signature (for example, if you have getters and
setters, you probably don't need to describe what they do). Please name your
"main class" (the one containing the
I am not asking for Javadoc at this point, but I am asking for the sort of information that you would find in the Javadoc API for your program. It should be clear what each method does, not how it does it.
The design should be in either plain text or HTML format. If you need to include pictures (such as UML diagrams), then GIFs are strongly preferred, JPGs or PNGs are acceptable.
Please one copy of your design for each team, if possible, with the names of your team members. I asked for these by Monday night (March 22), but really I just need them when I get in to my office Tuesday morning.
Other people will see your design. I will remove names so it will be anonymous, but still, you should try to make your design presentable and appealing; clear specifications are a part of that. We will have a kind of "popularity contest" for the best design (contest details to be revealed on Tuesday). You will receive some points--I haven't decided yet just how many--based on how much the rest of the class likes your design.
Don't start coding yet!