Design 20 points; code 40 points.
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 a replacement for the ListBasedPriorityQueue class in the framework. 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 the replacement for ListBasedPriorityQueue) 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 or modify 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 5''.
For this assignment the coding job consists of two main pieces -- writing or modifying game-entity classes and possibly modifying your player class, and writing your PriorityQueue class.
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 game's priority queue. This will happen automatically if you create the initial configuration with the screen editor. Otherwise, or for entities that are created during execution of the game, you can add them to the priority queue using methods in your game setup 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 your game setup class. 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.
Implement this class using a linked list, as discussed in class. Probably the best approach is to maintain the list in sorted order, sorted by what's returned from getUpdateTime. 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 either be a generic class, as the ListBasedPriorityQueue in the framework 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. To do this, you will probably need 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.)