CSCI 1321 (Principles of Algorithm Design II), Fall 2003:
Homework 3

Credit:

Design 20 points; code 40 points.

Overview

In this assignment you will begin to construct your implementation of Dr. Lewis's 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 do two things:

• Respond to keyboard or mouse input.

• Interact in a meaningful way with the other things you have implemented so far -- in particular, it should interact with your block classes in whatever way is right for your game, such as not going through walls.

You should try to take the design a little further and also think about what will be needed in your player for other aspects of the game (e.g., interacting with other game entities). You probably won't get it completely right at this point, but thinking now about all the functionality you eventually need will probably help you spot potential problems earlier.

Design

The design for this assignment will include a description of the player class you will write and its methods, plus a UML diagram showing how all your classes fit together. As before, for the design step you can write a ``skeleton'' version of the new class. 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. Writing these comments before writing the code encourages you to ``think first, then code''. They also help human readers of your code understand how everything fits together.

Code

Like the previous homework, this one will have you writing and editing a fair bit of code. The class for your player 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. Notice that the Player interface extends the GameEntity interface, so your player class will need all the methods of both interfaces. (Remember that these methods are how the game framework interacts with your classes.) Over time you will probably also wind up writing other private and public methods for your player that help it get things done as well as allow it to interact with other parts of your game. Some of the key things you will write are the following.

• getUpdateTime and update methods: Your player is a game entity and as such will be added to the event queue used by the game to make sure that things get updated as the game is played. Currently this is done in GameSetup using the game framework's implementation of a priority queue. As you write additional game entities, you will add them to the priority queue as well. Later in the semester we will talk more about priority queues, and you will write your own implementation. The game framework uses this queue to move things around, as follows. The queue is kept in order by the time (in game ticks) at which the entities next want to be updated, which is based on what they return from their getUpdateTime methods, At each game tick, the framework finds every entity on the queue that wants to be updated at that tick and calls its update method, passing it the current time (in game ticks). This update method is where the game entity's state, including position, should be altered. Positions are represented using the game framework Location class and include a reference to a Screen and coordinates of a block within that screen. This allows your player to figure out what kind of block it currently occupies and what kinds of blocks are nearby.

• Methods for processing user input: Your player also needs to be able to accept and deal with inputs from the user. The game framework makes sure that when the user does something (with the keyboard or mouse) it will be passed to your player class. How it does this is something that we will discuss in more depth later. For now what you need to know is that if you want your player to respond to keyboard input you need to implement the interface java.awt.event.KeyListener, and if you want your player to respond to mouse input you need to implement java.awt.event.MouseListener and/or java.awt.event.MouseMotionListener. Look at the Java library API documentation to see what methods you need for these interfaces and what information you have to work with. For keyboard input, you probably should use keyPressed and keyReleased rather than keyTyped because this gives you more control over what is happening. For mouse input, the game framework class MainDisplay provides a nice method getClickLocation to help you convert the position as known to the Java library classes into a game-framework Location. (See me for more details if this sounds like something you want to use.) You will need to think a bit about the interaction between these methods and update, because the listener methods are called when the user does the appropriate thing with the keyboard or mouse, but you probably want all changes to the actual player to be made in update. I recommend that you have the listener methods just set variables in your player class and have update determine how to move by looking at these values. (E.g., for keyboard input, you might want a boolean for each key you want to use, representing whether it has been pressed.)

The combination of update and listener methods should give you a player class that takes input from the keyboard or mouse 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, if you have wall blocks or other obstacles, the player should not be able to move through them. In a side-view game the player should also fall if not supported by something, and you might want to implement some way for the user to make the player jump. If you have blocks that are supposed to change when the player moves onto them, you should implement that as well in this homework.

As mentioned above, the player's position is represented as a Location (a class in the game framework). Notice that this class is immutable. The value passed to setPartialsInWhole determines whether entities move around in whole-block units or in smaller steps. A value of 1 makes things such as collision detection easier, but a larger value gives you smoother motion. The partialMove method is useful for moving entities around without having to keep track of whether you are about to run off the edge of your screen.

Details

What files do I need?

You will need

• The JAR file for this assignment, PAD2Assn3.jar.

As before, you will probably find the project API and the Java 1.4 API (linked from the course ``Useful links'' page) useful.

You can use the Together project you set up for Homework 2, but I recommend setting up a new project for each homework assignment (so that if something goes wrong you have a previous project to fall back on). You should copy your Java source files (*.java) from the old project, but I recommend that you not copy the project files (*.tpr, *.tws, and default.*) but instead create a new project from scratch.

Completing the design step

Once you have your project set up and your classes outlined (i.e., defined in at least the skeleton form described earlier), use the ``generate HTML documentation'' feature of Together to generate documentation, putting it in the proper directory as described in the overall ``Project Description'' document. Turn in your design as described in the ``Project Description'' document.

Completing the code step

For this step, fill in the bodies of the methods in your player class and make any changes needed to the classes you wrote for Homework 2 (including fixing any problems). Make sure your code compiles and your player moves around and interacts with blocks in the way that's right for your game.

When you're happy with how your code works, generate a final version of your documentation and turn in the code as described in the ``Project Description'' document. For this assignment, you will be turning in all your source-code (.java) files, plus possibly a file saved from the screen editor -- basically, everything I need to recompile and run your game. You do not need to send me .class files or the files that contain your Together project (*.tpr, etc.).