|CIT 594 Assignment
9: Robot, part 2
CIT 594, Spring 2005
In this assignment you will finally have a graphical display of your
and its activities. This will be the final assignment in this sequence.
Supplied files: BoardGame.zip, RobotGui.java, BoardGame.html
To begin, download my
BoardGame.zip file and add the Java files
to your own files. This zip file will include full Javadoc documentation and
a more tutorial introduction on
BoardGame.html. You should begin
public class Robot implements RobotInterface
public class Robot extends Piece implements RobotInterface
Robot will extend
Piece, it will inherit the
Piece. Two methods you should be especially careful
getColumn(); the inherited
versions return the row and column in which the Piece is drawn, but the
overriding methods in your
Robot class return where the robot "actually
is." In the absence of mistakes, these values should be the same.
You will need a
RobotGui class to create a GUI. I'm providing
some starter code, which you can use, modify, or ignore, as you choose. I'm
providing it because (1) most of it is routine stuff you should already be good
at, and (2) it's a lot easier to give an example of using the
than it is to try to explain it. The GUI will look something like this:
The intended meaning of the buttons is as follows:
JFileChooser) and display it on the right side of the GUI.
JFileChooser). Note that the program display area is just a
JTextArea, so it is entirely possible to write and edit programs in this area.
Threads, so you may not want to implement this right away.)
Buttons should be enabled and disabled at appropriate times. For instance, if the robot program is already running, the Run button should be disabled. You can figure out the rest.
You should also provide some means of reporting errors, for instance by adding
TextField to the GUI, or using dialog boxes.
You have a
RobotInterpreter class that executes a program in the
"robot language." The interpreter does all the control logic--the
arithmetic, the if statements and loops, and so on. In some sense, this is the
"brain" of the robot, because it tells the robot what to do.
Robot class is the "body" of the robot: It performs
simple actions when told to do so by the
as moving and picking things up. However, when the program is running, you can't
"see" what the robot is doing.
RobotGui class will provide both input and output to the robot.
Viewed as a Model-View-Controller design, the
Robot together provide the Model (the part that actually
does the work). The
RobotGui class will provide both a View,
an animated display of what the robot is doing; and it will also provide a Controller
(buttons and text area). The buttons will tell the robot to start and stop,
will load and save programs, and a couple other things. Most importantly, the
Controller will have an editable text area containing the program that the
Robot extends the abstract class
it must implement
public abstract void paint(Graphics g, Rectangle r).
This method should draw a picture of the robot on the Graphics object
You do not have to do any computations to figure out where on the board
to draw the robot; just draw it within rectangle
r, and it will
be in the right place. Remember that this rectangle is not a constant, known
size (the user can resize the GUI), so grow or shrink your robot drawing accordingly.
paint method should be able to draw four different
pictures, representing the robot facing in one of four directions (north, east,
south, west). Your drawing should be fairly simple (in case it has to be very
small), but it should be obvious which direction the robot is facing.
You also need to extend the
Piece class with
Beeper classes. Since these aren't "facing" any particular
paint method can be simpler; but remember that the
rectangle they are drawn in can be any size.
The robot will be able to pick up and drop beepers, but not obstacles. It's
a bad idea to hard-wire this information into the
because that would make your robot dependent on these particular kinds of objects;
adding new objects would require modifying your
Robot code. It's
better for the beeper and obstacle classes themselves to indicate whether they
can be moved, possibly with a
boolean isMoveable() method that
the robot can use. If you understand interfaces, you can do this without
Don't modify anything in my
BoardGame classes. If you find a bug
or if you think it's missing some necessary methods, please let me know.
Although there are quite a lot of methods in the
(and it still isn't complete), you only need a few of them. Basically, this
API is used for drawing, not for computation. The
class still decides where the robot moves and what it does. But in addition,
each time the robot does something that should be displayed, it needs to call
an appropriate method of the
For example, to put a piece (robot, beeper, or obstacle) on the board, call
one of the
place methods. When the robot moves, have it call the
moveTo method. When it picks up a piece, it should call one of
remove methods. (There are often similar methods in both the
Board and Piece classes; use whichever is more convenient.) And so on.
Thursday, April 14, before midnight.