In this assignment you will begin to construct your implementation of the Player interface. This will be the little character that goes running around on your screen. For this assignment it needs to begin to interact in a meaningful way with the other things that you have programmed so far, basically that means it need to see the blocks and interact with them in a way that is meaningful. Your design though should try to go further to include what will be needed in your player for other aspects of the game as well. This is significant in a few ways, one of which is that it will show you some of the interplay between design and implementation. What you design for that now will probably be insufficient or outright wrong for what you write later, but thinking about it now will help you discover that earlier.
Design
The design for this assignment will include UML class diagrams for the classes that you will write. It should also include text descriptions of your implementation of Player. It will also include all of the classes that you wrote for the last assignment. Your project is going to continue to get larger over the semester and it should include all your previous work so that someone can see how everything fits together.
Again I recommend that this be submitted by putting the files generated in Together in a new directory that will be visible on the web and send me a link.
Code
This assignment will have you writing and editing a fair bit of code. Your Player subclass could easily be the largest class in your game. However, you don't have to write all of it now, just the beginnings of it. Remember that Player implements GameEntity so your implementation will need all the methods of GameEntity as well as those put just in player. Over time you will probably also wind up writing a fair number of private and public methods for your player that help it gets things done as well as allow it to receive messages from the other parts of your game.
The update method: As an entity, your player will be added to the event queue used by the game to make sure that things get updated as the game is played. We will be talking more about priority queues later in the semester, but for now you will use an existing implementation. The way this works is that at each tick the update methods for the appropriate entities are called and then the entities are placed back on the priority queue using the next update time that they specify. This update method is where the state (including position) or your player should be altered. Note that in the constructor for your GameSetup you need to add the Player to the priority queue. You will have to do this for the other entities in your game as well.
User input: Your player also needs to be able to take and handle inputs from the user. My code makes sure that when the user does something it will be passed to your player class. How it does this is something that we will discuss more in depth later though the simple explanation is that your player class needs to implement whatever event listeners it needs to get input. Since none of you seems to be interested in mouse input, this means that you only need to implement the interface java.awt.event.KeyListener. You should go look at the API on the Sun site to see what this interface is and what methods are part of it. That will also tell you how you will be able to figure out what the user is doing. I recommend that you use the keyPressed and key Released methods instead of keyTyped because they give you more control over what is happening. You will need to think a bit about the interaction between this and the update method because the methods of KeyListener are called when the user does some the appropriate thing with the keyboard but you probably want all changes to the actual player to be made in the update method.
The combination of the update and input should give you a player class that takes input fomr the keyboard and uses it to move around any screens that you have built. The movement should be appropriate for the blocks that are present. For example, in a side view game the player should not go through walls and should fall when not supported by things. In that game you should probably also have code in it for jumping at the end of this assignment. For top view games things are a bit easier because you just have to make sure that the player doesn't go through walls. For any of you who were going to have blocks that could change when the player moves into them, that will need to be implemented in this assignment.
JAR file
Here is a new JAR file for this assignment. Remember that you only want one of the jars in your path. This one also contains the classes for ScreenEditor as well as a new ImageEditor that I'm writing the help file for now.