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. If your game doesn't have something fitting that description then you should come to talk to me about what you need to do for this assignment. For this assignment the player 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 (like not run throuhg walls). 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 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. You should also try to change the things that I mention in the notes on each assignment.
Put the generated HTML in the proper directory and send me an e-mail letting me know it is there.
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 get 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. The code I gave you already handles some of this.
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. For keyboard input you need to implement the interface java.awt.event.KeyListener. For mouse input you would implement java.awt.event.MouseListener and/or java.awt.event.MouseMotionListener. You should go look at the API on the Sun site to see what these interfaces are and what methods are part of them. 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 the appropriate thing with the keyboard, but you probably want all changes to the actual player to be made in the update method. I recommend that you have the event functions simply set variables in your Player class (booleans for whether a key is pressed will work) and have update determine how to move by looking at those values.
The combination of the update and input should give you a player class that takes input from 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 type of 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.
Look at the Location class a bit. That is how the player determines where it is on screen. Note that it is immutable. You should also note that you can set the partialsInWhole value to be whatever fits your game. Large values give you smoother motion, but a value of 1 makes things like collision detection much easier.
JAR file
Here is a new JAR file for this assignment. Remember that you only want one of the jars in your path.
If you want to use graphics from an outside source for your game you can use the java.imageio.ImageIO class. It has simple read methods that you can find in the main Java API.