Design 20 points; code 40 points.
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 several new classes and interfaces. 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 what may seem like a lot of classes, but some of them can be very short, and for others you will have access to source code for the equivalent classes in Dr. Lewis's starter game.
Before reading further, review the Project Description, particularly the section ``The game framework''.
The design for this assignment will include descriptions of all the classes and interfaces you will write (for this assignment) and their methods. As in the previous assignment, you will write these descriptions in the form of comments for the classes you need; they will then appear in the HTML documentation generated by Eclipse (or with the javadoc command). As before, what you turn in does not set in stone the code you write for this assignment or later assignments, but you should try to at least plan fairly carefully what you will do for this assignment.
/** 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; }
}
For this assignment, you have to write a number of classes, described in the next section (``Classes for this assignment''). This section describes the overall procedure.
When you get everything right, starting your program (by running its main class, as you did in the previous assignment) will pop up a window much like the starter game, except with a screen and blocks that you created, rather than the starter screen and blocks.
(Read, or at least skim, all of this section before starting your design.)
As you may have noticed from browsing the API for the game framework, many classes and interfaces are generics defined in terms of two basic types, one that extends Block and one that extends GameEntity. These two interfaces are themselves generics defined in terms of Block and GameEntity, and if this sounds to you like infinite recursion -- yes, but this can be avoided by you writing your own class or interface for each of these basic types. I'll call these YourBlock and YourEntity here, but you should give them names related to your game (e.g., PacManBlock and PacManEntity). You will then use these types everywhere the framework wants types that extend Block or GameEntity. YourBlock, and all of your game entity classes will be For example: In Homework 1 you had a MainFrame<BasicBlock,BasicEntity>. In this assignment you will replace that with a MainFrame<YourBlock,YourEntity>.
To make this happen:
Making YourBlock an interface involves much less code; in fact, all you need (other than the usual package and import statements) is the following line:
public interface YourBlock extends Block<YourBlock,YourEntity> { }
The idea is that all of the classes you write to represent
blocks will implement this interface.
So your comment describing this class could be something
like ``this is an interface that all the block classes for
my game will implement.''
The alternative is to make YourBlock a class, possibly an abstract class, and make all of your other block classes subclasses of YourBlock. This is a good choice if you find yourself writing the same code over and over in your block classes, since then you could put that common code into YourBlock and have it inherited by the other block classes. You can model this class on BasicBlock, for which source code is provided as part of this assignment.
public interface YourEntity extends GameEntity<YourBlock,YourEntity> { }
As with YourBlock, the idea is that all the classes you
write to represent entities -- including the player --
will implement this interface.
Once you have definitions for YourBlock and YourEntity, for this assignment you will write the following additional classes. (This is not as overwhelming as it might sound; for most of these classes you have starter code that you just need to modify.)
Once you've written this class, you will need to use it instead of BasicGameSetup in the main method of your main class (the one you wrote for Homework 1).
To find out what methods you need in this class and what they are supposed to do, look at the project API for the Screen interface. 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/stub 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 (i.e., a two-dimensional array of YourBlocks) and a list of game entities. For the list of game entities, for now you should use the GameEntityList class in the framework. (Later you will write your own replacement for this class.) GameEntityList is described in the project API and included in this assignment's JAR file.
For initial testing, you should write your game setup class 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 (see ``Links and files'' below) 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 the constructor of your game setup class. There is commented-out code in the starter version of this class that 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.
If your browser doesn't do a nice job of displaying .java files (flowing the whole file into one big paragraph rather than showing it with separate lines), you should still be able to get the above files by downloading (saving) them rather than trying to display them. (E.g., in Firefox, you right click on the link and then select ``Save link as''.)