In this assignment you will begin to construct your game following the description that you handed in for the last assignment. You will do this by creating at least two new classes that implement Dr. Lewis's interfaces and modifying one of his classes so it uses your new classes. Exactly what type of classes you create will depend on the design of your particular game. What you will be constructing now is the beginning of the ``playing field'' -- the background on which the game is played. To do this, you will write at least one class that implements the Block interface (a ``block class'') and a class that implements the Screen interface (a ``screen class'') that uses your block class(es). You will also edit appropriate methods in the GameSetup class to use your screen and block classes.
The design for this assignment will include descriptions of the block and screen classes you will write and their methods, plus a UML diagram showing how the classes fit together. A good way to approach this is to write ``skeleton'' versions of the block and screen classes -- versions that have just enough code to compile but otherwise are mostly comments. For example, here is a skeleton version of a Circle class:
/** Class for circles. */
public class Circle {
/**
* Constructs a circle with specified radius.
* @param r -- radius
*/
public Circle(int r) { }
/**
* Gets the circle's area.
* @return area
*/
public double getArea() { return 0; }
}
This assignment will have you writing and editing a fair bit of code. as follows.
First you will write a ``screen'' class that implements Dr. Lewis's Screen interface. The name of this class can be anything you want. Something related to your game would be good; for example, if you were writing a version of Pac-Man you might call the class PacManScreen. There are several methods you must write in order to implement the Screen interface; look at the project API to see what methods you need and what they are supposed to do. At this point not all the methods will make sense to you; for those that don't (and the documentation should give you some hints about which ones these are), just write ``skeleton'' versions, with comments that indicates you'll fill them in later. If one of these methods is supposed to return something, have it return 0 or null for now. It's up to you to decide what variables your class will need, but you will almost certainly need a two-dimensional array of blocks and a list of game entities. You should probably use the GameEntityList class from Dr. Lewis's framework for the latter. This class is described in the project API and included in this assignment's JAR file. Later you will write your own replacement for this class.
Next you will write at least one block class, each of which implements Dr. Lewis's Block interface. Most people will write only one screen class but several block classes. Here too I recommend giving these classes names related to your game and their purpose (e.g., PacManWall for a ``wall'' block in a Pac-Man game). Look at the project API to see what methods you need. Block classes are generally fairly simple because they don't do much, and you will have source for a BasicBlock class to use as a model. (See ``What files do I need?'' below.) The only part that might be difficult is defining the appearance of the block (its ``image''). We will talk more about this later in the course; for now, you should be able to do something reasonable by varying the code in BasicBlock.
Finally you will edit Dr. Lewis's GameSetup class (see ``What files do I need?'' below) so that it uses the other classes you have written so far. It has comments that should help you figure out what changes you need to make. By the end of the course you should have replaced any comments telling you what to do with comments that describe how this class works for your game.
For initial testing, you should write GameSetup so that it directly creates a screen and fills it with blocks. Once you're reasonably confident that your screen and block classes are working, you may want to use Dr. Lewis's screen editor (documentation available via the ``Useful links'' page) to actually build screens for your game. This is a nice visual tool that allows you to build screens using your block classes and save them in a binary format that can be read into your game in GameSetup.constructVariables (there is commented-out code you can use as a model for doing this). Warning: Do not put too much effort at this point into creating elaborate screens using the screen editor; almost any change you later make to your screen or block classes will make it necessary to start over (because the saved binary-format representation will no longer be valid -- later in the semester we'll talk about why). However, do try out the screen editor, to make sure the parts of your screen and block classes that interact with it are working right.
You will need
As before, you will probably find the project API and the Java 1.4 API (linked from the course ``Useful links'' page) useful.
You can use the Together project you set up for Homework 1, but I recommend setting up a new project for each homework assignment (so that if something goes wrong you have a previous project to fall back on). You should copy your Java source files (*.java) from the old project, but I recommend that you not copy the project files (*.tpr, *.tws, and default.*) but instead create a new project from scratch.
Once you have your project set up and your classes outlined (i.e., defined in at least the skeleton form described earlier), use the ``generate HTML documentation'' feature of Together to generate documentation, putting it in the proper directory as described in the overall ``Project Description'' document. Turn in your design as described in the ``Project Description'' document.
For this step, fill in the bodies of the methods in your screen and block classes and make the necessary changes in GameSetup. Make sure your code compiles and your game still starts. Also make sure you can start Dr. Lewis's screen editor with your classes. If something goes wrong (which might include the game or screen editor window appearing to freeze), the Message Pane panel should contain error messages telling you the source of the problem.
When you're happy with how your code works, generate a final version of your documentation and turn in the code as described in the ``Project Description'' document. For this assignment, you will be turning in all your source-code (.java) files, plus possibly a file saved from the screen editor -- basically, everything I need to recompile and run your game. You do not need to send me .class files or the files that contain your Together project (*.tpr, etc.).