Design 20 points; code 40 points.
In this assignment you will begin to construct the entities you want in your game in addition to the player. You should probably sketch out classes for all the entities you intend to have, but you don't have to complete all of them for this assignment. Entities that don't move should be relatively easy to do, and you should be able to complete those; you also need to edit the code for your player so that it interacts with these entities in the way that it should. You will also write a replacement for the GameEntityList class in the framework.
The design for this assignment will include descriptions of the classes you will write (one for each kind of non-player game entity, plus the replacement for GameEntityList) and their methods. As before, for the design step you can write skeleton or stub versions of the new classes. You should also look again at your descriptions of classes you wrote for previous homeworks and see if they need to be improved or updated. Remember that I want at least a short comment about every class and every method. As your project gets bigger and more complex, the comments describing classes will become more important, since they help human readers of your code understand how everything fits together.
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.
The ``General requirements'' section of the Project description has more suggestions about how to send me the needed files.
Please use a subject line such as ``csci 1321 code 4''.
For this assignment you could be writing quite a few classes, but many of them will be similar. The coding job consists of several pieces -- writing your game-entity classes and modifying your player, revising your game setup class so you start out with an acceptable layout of blocks and game entities, and writing your replacement for GameEntityList.
You also need to write code that will handle interactions between your player and the new game entities. This code can go in either the player class or the game-entity classes. For entities that don't move, it probably makes the most sense to put this code in the player class. For entities that move, the code can go either in the player class or the entity class. Which you choose depends on which you think will be easier and more efficient.
One way to do this (set up blocks and entities) is in your code. You could do this in the constructor for your screen class, but it probably makes more sense to have the constructor just create a grid of some type of background block, and then fill in other blocks and entities in the constructor in your game setup class. You already have code in this constructor to create your player and add it to the game; you can use similar code to add other entities. Notice that you need to add each entity both to the screen it should appear in and to the priority queue.
Another way to set up blocks and entities is to use Dr. Lewis's screen editor program. To use this program, you need to be sure your screen class is set up right; the screen editor uses the methods getNumBlockTypes, getBlockOfType, getNumEntityTypes and getEntityOfType to build menus of block and entity types. You also need to modify your game setup class to read in the file you save from the screen editor. There is commented-out code in the constructor showing how to do this. Notice that if you do this, everything in your game needs to be either ``serializable'' or transient. We will talk more about what this means later in the semester. For now, what you need to know is that all your classes need to be declared to implement the Serializable interface (this happens automatically if you implement the Screen, Block, or GameEntity interfaces), and any objects that aren't serializable (e.g., Image objects) need to be declared transient. If you don't do this, you will get a runtime exception when you try to save from the screen editor. Notice also that if you make certain kinds of changes to your screen, block, or entity classes, you will have to recreate the file saved by the screen editor, so I advise not spending too much time creating anything elaborate. (If you're curious about that mysterious variable serialVersionUID found in some of the code you've copied: We'll talk more about this later too, but including it means that there are fewer circumstances in which you'll need to recreate files saved from the screen editor.)
This class can either be a generic class, as GameEntityList is, but it does not have to be. All the things you will store in the list implement your general entity interface (say YourEntity), so you can write the list to store only objects of this type.
This class could even include a main method to do some simple testing -- create a list, fill it with instances of one or more of your entity types, etc. This isn't strictly necessary, but it's good practice and may help you debug your code.