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 Dr. Lewis's GameEntityList class.
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, plus a UML diagram showing how all your classes fit together. As before, for the design step you can write ``skeleton'' 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.
For this assignment you could be writing quite a few classes, but many of them will be similar. The coding job consists of three main pieces -- writing your game-entity classes, modifying your player class, 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 Dr. Lewis's GameEntity 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 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 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 also need to figure out how to add entities to your game. One way 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 GameSetup to read in the file you save from the screen editor. There is commented-out code in constructVariables showing how to do this.
The other way to add entities to your game is to add them directly in constructVariables, the same way you add the player. Be sure you add each entity both to the screen it should appear in and to the priority queue.
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). 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.
Note that if you're using the screen editor to lay out your game, 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.
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 3, 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. (If this doesn't work for you, you can use the javadoc command instead, though it won't automatically include your UML diagram. See ``Java Without an IDE'' for details. This page is also linked from the ``Useful links'' page.) Turn in your design as described in the ``Project Description'' document.
For this step, fill in the bodies of the methods in your replacement for GameEntityList and at least one of your game entity classes, and make any changes needed to the classes you wrote for previous homeworks (including fixing any problems). Make sure your code compiles and your player still moves around and interacts with the new entities in the way that's right for your game.
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.).