In this assignment you will finally have a graphical display of your Robot 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 by reading BoardGame.html.

Next, replace:

public class Robot implements RobotInterface

with:

public class Robot extends Piece implements RobotInterface

Since Robot will extend Piece, it will inherit the methods from Piece. Two methods you should be especially careful about are getRow() and 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.

The RobotGui class

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 BoardGame than it is to try to explain it. The GUI will look something like this:

The intended meaning of the buttons is as follows:

Load

Load in a program from a text file (use JFileChooser) and display it on the right side of the GUI.

Save

Save the program on the right side of the GUI into a text file (chosen with JFileChooser). Note that the program display area is just a JTextArea, so it is entirely possible to write and edit programs in this area.

Initialize

Put the robot in the top left corner, facing east, and randomly place some obstacles and beepers in the rest of the array.

Run

Start interpreting the robot program; or, if the program is paused, continue interpreting from where you left off.

Pause

Temporarily stop the robot from executing. (This requires some knowledge of Threads, so you may not want to implement this right away.)

Stop

Stops the robot, not the entire program. This is mostly so you can stop the robot's program in case of an infinite loop. You should still be able to edit the program and use the other buttons. (Closing the window will terminate the program.)

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 a TextField to the GUI, or using dialog boxes.

The big picture

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.

The Robot class is the "body" of the robot: It performs simple actions when told to do so by the RobotInterpreter, such as moving and picking things up. However, when the program is running, you can't "see" what the robot is doing.

The RobotGui class will provide both input and output to the robot. Viewed as a Model-View-Controller design, the RobotInterpreter and 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 RobotInterpreter interprets.

Extending the Piece class

Since your Robot extends the abstract class Piece, it must implement public abstract void paint(Graphics g, Rectangle r). This method should draw a picture of the robot on the Graphics object g. 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.

Your Robot's 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 Obstacle and Beeper classes. Since these aren't "facing" any particular direction, the 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 Robot class, 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 modifying the Piece class.

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.

Using the BoardGame API

Although there are quite a lot of methods in the BoardGame API (and it still isn't complete), you only need a few of them. Basically, this API is used for drawing, not for computation. The Robot 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 Piece or Board class.

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 the remove methods. (There are often similar methods in both the Board and Piece classes; use whichever is more convenient.) And so on.

Due date

Thursday, April 14, before midnight.