In this assignment you will continue working on the moving parts of your game, in particular the entities other than your player. You don't have to finish writing them for this assignment, but as before the more you do now the less you will have left to do at the end of the semester. You will also write your own priority queue class to replace Dr. Lewis's ListBasedPriorityQueue class. This class should implement the PriorityQueue interface. (Later in the semester you will write a different implementation of a priority queue and compare the performance of the two implementations.)
The design for this assignment will include descriptions of the classes you will write or modify (one for each kind of non-player game entity, plus one that implements PriorityQueue) 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 the coding job consists of two main pieces -- writing your PriorityQueue class, and then writing or modifying game-entity classes and possibly modifying your player class.
For this assignment, I want you to implement PriorityQueue using a linked list. This isn't the most efficient implementation, but it is easier for now and should be acceptably efficient. Your game needs one priority queue, defined in GameSetup. The game framework uses this queue as follows. During each game tick, the framework removes from the queue one at a time all entities whose getUpdateTime methods indicate that they want to be updated during this tick. For each of these entities, the game framework removes it from the priority queue, calls its update method, and puts it back on the queue. In order for this to work without causing an infinite loop, what the entity returns from getUpdateTime after update is called must either be a number greater than the current tick or -1. A value of -1 causes the framework to not put the entity back into the queue, so it will not be updated again unless something in your code puts it back into the queue. Any time an entity other than the player is removed from the game (killed, e.g.), its getUpdateTime should return -1. It's probably a good idea to test your priority queue class by writing a short main method for it and a DummyEntity class that allows you to test. (For example, this class could be written so that each instance has a ``next update time'' that is always returned from getUpdateTime. You could then create several instances with different times and use them to test your queue.)
The second part of this homework is implementing at least one of your moving entities. To make an entity move, you need to fill in its getUpdateTime and update methods. getUpdateTime can be similar to what you wrote for your player (though perhaps asking to be updated less frequently). update should make the entity move in some way that's right for your game -- chasing the player, moving randomly, etc. You also need to write code that will handle interactions between your player and the moving game entities. This code can go in either the player class or the game-entity classes. For moving entities, this code can go in either the entity's or the player's update method. Choose whichever seems more reasonable to you, but be sure to take into account how often the different kinds of entities are being updated.
Homework 4 describes how to add entities to your game. Since the entities for this assignment move, you need to be sure they get put on the priority queue. This will happen automatically if you create the initial configuration with 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 4, but I recommend setting up a new project for each homework assignment.
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 PriorityQueue 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.).