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.
For your game entity classes, try to think of all the things in your game that should be entities. This might include both things that move (e.g., enemies) and things that don't move (e.g., objects you pick up), though the latter could also possibly be blocks that change appearance. For each such kind of thing, you will write a class that implements your general entity interface. You already know about the methods of this interface; you implemented them for your player. One difference is that entities that don't move don't need complex update methods. Notice that an entity can tell the game framework not to call its update method again by returning -1 from its getUpdateTime method.
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.
You don't have to completely implement all your game entity classes for this assignment, and you don't have to make any of them move, but the more of them you start writing now, the less you will have to do later.
You also need to figure out how to add entities to your game. This would probably be a good time to think in general about how to create the overall layout (screens, blocks, and game entities) you want, if you haven't already done so. It probably doesn't make sense to invest time right now producing something elaborate, but you need something close enough to your eventual goal that you can test functionality.
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.)
Finally, you need to write a replacement for the GameEntityList class. Since you are presumably using this class to implement addEntity, removeEntity, and createEntityIterator in your screen class, your replacement class should include methods that make it easy to do this. Implement this class using a linked list (unsorted and singly-linked is fine), as discussed in class. Do not use any of the data-structure classes from the java.util package -- they would make the job simpler, and in Java programs you write in the future you should consider using them, but one of the objectives of this assignment is write your own.
This class can be a generic class, as GameEntityList is, but it does not really need 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.