NOTE:  The current design is UML documented in the currentDesign.mdl file
           which is there for your viewing pleasure with Rational Rose.

1. PhysicsObject's Removal as a member of Lemming
	It was decided that it would be better for Lemmings to extend
the PhysicsObject rather than contain it as a private data member.  This made
things MUCH simpler when dealing with changing the direction of the animation
as well as makes far more sense as far as actual logic calculations are
concerned.  Primarily, this makes sense when a lemming goes BOOM and breaks up
into tiny, little, high velocity pieces of lemming.  In this case, the lemming
breaks up into Particles and they go SWISH.  This has not been implemented nor
the classes designed (since they are extra credit).
	Finally, we also removed the movementDirection function.  This was 
deemed unnecessary as this can be derived purely by checking the Velocity 
vector of the Lemming, foo.getVector().getI().

2. The File Package and the Level Reader class.
	Once upon a time, the team forgot to think of the fact that levels had
to be loaded from the HDD somehow.  That's where the file package came from 
with its current sole class known to all as the LevelReader class.  This class
will load the necessary files from the HDD and create the necessary Level 
Object or Map Object used by various other classes.  This class has been
added to the Class Diagram described at the top.

3. class LevelData:
Added an id field. The reason for this addition was in order to easily keep 
track of the levels in the directory. When the directory is scanned for levels,
the names of the folders with the level information, or the names of the actual
level files, will become the ids of the levels. Thereafter, we can easily 
access each of the levels by simply using their ids. This also allows us to 
group levels into level-packs, and have several levels have the same name, 
because only the id's have to be unique.

Removed the size field. We thought it applies more to the Map, so that's where 
the field was moved.

Added the points for the level entry and exit portals, as well as 
accessors/modifiers for them. The reason for this addition is because we 
forgot about the entries and exits during the design stage. :)

4. class Map:
Added the texture image. Now, in addition to the background, we can actually 
customize the terrain for a map.

5. class Level:
Added a few fields that we didn't think of during the design: 
lemmingFlow - 
 this will specify how often the lemmings are released from the starting point; 
paused - 
 a boolean value to tell when the game is paused; 
levelPortals - 
 the list of portals on the level, here we would have things like the entrance 
 and the exit.
 
Unfortunately, we forgot to add any portal stuff into our initial designs, and 
so in addition to the things specified above, we had to add some more classes 
to our program. There is the generic Portal class, which is the parent of all 
portals and allows one to basically specify the action to take when a lemming
enters it. Then, there are also the level entry and level exit classes, which 
allow the lemming to enter or exit the level.

6. class LevelLoadingState
To the state machine of the possible states, we also added a LevelLoadingState 
class, which is essnetially a screen shown while a level is being loaded. The 
reason we thought it was important to add this class is because it took some 
time to load a given level, and so the program seemed to have frozen during 
this time. Now, it instead displays a screen that informs the user that the 
game is, in fact, doing something - namely, loading a level.

7. ImageUtilities
We also added the ImageUtilities class into the graphics package, because 
there were certain operations, like getting the color of a pixel of the image, 
and creating a blank image, that were shared among several classes, so we 
abstracted all this functionality into the one utility class. Due to the fact 
that PMD doesn't like utility classes, the ImageUtilities were made a singleton.

We also added the ImageUtilities class into the graphics package, because there were certain operations, like getting the color of a pixel of the image, and creating a blank image, that were shared among several classes, so we abstracted all this functionality into the one utility class. Due to the fact that PMD doesn't like utility classes, the ImageUtilities were made a singleton.

In the GUI package, we have added an AbstractButton class, which abstracts out the functionality for the firing of an ActionEVent when the component is clicked. The reason we did that is because in addition to the regular button, we have some more fancy buttons, like the level selector buttons, which are also clickable and need to fire events, but don't really inherit any functionality from the LButton.
We also added the ImageUtilities class into the graphics package, because there were certain operations, like getting the color of a pixel of the image, and creating a blank image, that were shared among several classes, so we abstracted all this functionality into the one utility class. Due to the fact that PMD doesn't like utility classes, the ImageUtilities were made a singleton.
We also added the ImageUtilities class into the graphics package, because there were certain operations, like getting the color of a pixel of the image, and creating a blank image, that were shared among several classes, so we abstracted all this functionality into the one utility class. Due to the fact that PMD doesn't like utility classes, the ImageUtilities were made a singleton.

In the GUI package, we have added an AbstractButton class, which abstracts out the functionality for the firing of an ActionEVent when the component is clicked. The reason we did that is because in addition to the regular button, we have some more fancy buttons, like the level selector buttons, which are also clickable and need to fire events, but don't really inherit any functionality from the LButton.


In the GUI package, we have added an AbstractButton class, which abstracts out the functionality for the firing of an ActionEVent when the component is clicked. The reason we did that is because in addition to the regular button, we have some more fancy buttons, like the level selector buttons, which are also clickable and need to fire events, but don't really inherit any functionality from the LButton.


8. AbstractButton
In the GUI package, we have added an AbstractButton class, which abstracts out 
the functionality for the firing of an ActionEVent when the component is 
clicked. The reason we did that is because in addition to the regular button, 
we have some more fancy buttons, like the level selector buttons, which are 
also clickable and need to fire events, but don't really inherit any 
functionality from the LButton.

9. Addition and Removal of a few Physics functions
There were a few functions added/removed from the PhysicsEngine.  Documentation
for these changes is not particularly necessary as they are minor changes,
however, actual changes will be detailed:

Added isFalling() which is used by the Engine to change the animation to the
falling animation when the Lemming is falling.

Added gravityUpdates, which is used as a counter for updating gravity effects
when in future implentations.  This is still experimental and in design for
adding advanced features to the engine, so it is not actually used, and 
therefore not JUnit tested, in the submission you have received