CSCI 1321 (Principles of Algorithm Design II), Fall 2005:
Homework 7
60 points.
By now your game should be playable, with all the major functionality
implemented. This homework is something of a tangent;
the goal is to write a second, more efficient priority queue and
compare its performance with your first version.
The needed code breaks down into two categories:
First, you are to write a second priority queue class that uses a heap
(as discussed briefly in class, and also in the textbook,
using an array or Vector to store
elements) rather than a sorted linked list.
Second, you are to add code to your game that will allow you to compare
the performance of the two implementations as the number of game
entities in the queue varies. To do this, you need to do
several things: create a ``dummy'' game entity class so you can
put arbitrarily many entities in the priority queue, change
your main class to accept two command-line arguments that specify
which implementation to use and how many of these dummy entities
to add, and change your player class to print out some information
that will allow you to see how performance varies based on the
choice of priority queue implementation and the number of dummy
entities.
Once you do these two things,
you can run your game with different values of the two command-line
arguments and see how performance changes.
The final part of this assignment is to do this and plot the results.
You need to do the following:
- Write a second priority queue class.
Like your earlier priority queue,
it should implement the framework's PriorityQueue
interface.
You could call it HeapBasedQueue, or something else
that distinguishes it from the previous class.
- Write a ``dummy'' game entity class you can use to put lots
of entries in the priority queue. It will need all the
methods of the GameEntity interface, but the only
ones that have to do anything are update
(store the time passed in) and getUpdateTime
(return the time previously passed to update plus
something nonzero). To fully test your priority queue, the time
between updates should not be the same for all dummy entities.
A simple way to make this happen is for each entity to
have a timeBetweenUpdates variable, passed in via a
constructor; its getUpdateTime method then returns
the time of the last update plus timeBetweenUpdates.
- Add code to your main class so that it accepts two command line
arguments. The first selects which of your priority queue
classes and should be either ``list'' or ``heap''.
The second specifies how many
dummy entities to add to the queue.
- Add code to your game setup class that does the right
thing with these arguments: creates either an instance
of your linked-list priority queue or an instance of your
heap priority queue and then adds to it the specified
number of dummy entities. You can generate values for
the entities' timeBetweenUpdates using a random number
generator (e.g., using nextInt(maximumValue) in Java
library class Random, where maximumValue is
some sensible maximum time between updates, say 10).
Notice that the dummy entities need to be added only to
the priority queue, not to any screens.
Probably the right place to add this code is in the
constructor for the class. There are various options
for passing in the two command-line arguments. One
is to make them parameters to the class's constructor,
write a method makeInstance that takes two parameters
and uses them to create the class's one instance, and call
makeInstance from your game's main class. Or you
may think of a better approach.
- Add code to your player class's update method that
prints out timing information, specifically how much time
it takes for every 100 calls to the method.
System.currentTimeMillis() returns a long
with the current time in milliseconds. Every 100-th call
to update (when time % 100 is 0),
you can call this method to get the
current time, subtract the previous current time, and
print the resulting difference.
Once you have written and tested the above code, I want you to
collect and plot timing information that shows how, for each version of
the priority, performance
(time for 100 calls to player's update
method) changes as the number of dummy entities
increases. You will have to experiment a little to see what
number of entities is needed to get meaningful results. Start
with a small number (say 10), and then increase it by factors
of 2 or 10 until you see performance differences. What you should
see is that for entities the time for the linked-list version
is roughly proportional to , while for the heap version
time is roughly proportional to .
- As with previous assignments, you should probably start
by creating a new Eclipse project, then creating a package
within the project, and then copying over all your code
from previous assignments. You can use the same package
name as in previous assignments.
- Create your two new classes (priority queue and dummy entity)
and add code to existing classes.
Revise and debug until you're happy with how your code
compiles and executes.
- Generate HTML documentation for your project as described
in the
Project Description.
Check that the generated documentation is okay;
point a browser at
http://www.cs.trinity.edu/~yourusername/CSCI1321/HW7/Final
and check that all your classes and documentation comments show up.
- Turn in your code by sending me mail with all of the files I
need to compile and run your game as attachments. This
includes all (.java files), any file(s) created
using the screen editor, and any file(s) containing images.
All of these files will probably be in the same directory
containing your Eclipse project (same name as the project,
in your Eclipse workspace directory), unless you put them
somewhere else.
You don't need to send me .class files or the JAR file,
but if it's simplest for you just to send me all the files
in the directory for your Eclipse project, do that.
It's better to send a bit too much than not enough!
The project description
now contains notes on how to easily send me your whole
project (use tar to create a single file and send
that); it's at the end of the ``Code'' subsection.
Please use a subject line such as ``csci 1321 code 7''.
- Turn in your two plots either in hardcopy form in my mailbox
(outside my office door) or by e-mail. If you choose the
latter option, non-proprietary formats are preferred
(e.g., PDF or GIF rather than Microsoft Excel).
Berna Massingill
2005-12-06