Assignment 5: Inheritance, Abstract Classes, and Final
Objective: Create a small game and practice writing child classes.
Due: Tuesday at 11:59 p.m.
Recommendation: Complete at least through part of part 3-4 before Monday, for timely completion of the assignment and to identify any issues/questions/comments you may have.
Set Up
Cloning the Repository
In your terminal, go to the directory where you are keeping your repositories for CSCI209. Clone the repository for this assignment. Add your name to the README file.
Part 1: Compiling and Running the Code
- Compile the code using javac *.java or javac Game.java.
- Run the game by executing java Game
You should see a black pop-up window with a little dude--the professor--in the bottom right corner of the screen, walking. - Using the arrow keys, move the professor around the screen. Use the space bar to stop him.
- To stop the program, close the window.
- To see what I'm hoping to see when you're done (if you also do
the extra credit), go into the
demoClassesdirectory and run java -cp Game.jar Game Your Goblin's movement may not be as aggressive as mine.
Part 2: Understanding the Code
To help you with understanding the code, here are the Javadocs for the game code. Refer back to them while completing the assignment, as it may help you to figure out what is inherited and who can do what.
- Start by looking at
Game.java. There is a lot of code that you don't need to worry about. Focus on themainandanimatemethods as well as the instance variables.The
mainmethod creates a new Game object, including setting up the window.mainalso calls theanimatemethod, which starts the game running.The
animatemethod creates the professor and moves the professor. The professor's direction is determined by pressing keys. - Then, look at
GamePiece.java. (This class contains some less-than-ideal coding practices; bear with me--we haven't seen the techniques to fix them yet.)Note the instance variables, the constructor, and the available methods--especially the
move(Game game)method. - Now, look at
Human.java. Look at the class's constructor and themovemethod. Hopefully, you're now seeing how the pieces fit together.
Part 3: Creating Child Classes (60 pts)
There should be a lot more thinking than there is coding for this part. The amount of code you need to write is not huge. Think about the behavior of each class and how that should be implemented.
~~~ FAQ ~~~ Don't look at this until after you've attempted to solve this part.
- Create a
Goblinclass, which inherits fromGamePiece. There are several animated gifs to choose from. A Goblin should "chase" the professor instead of just standing there, which is what the inheritedGamePiece'smovemethod does. Since you are overriding the move method, the method should have the same signature (e.g., the same parameters) as the parent's move method. How can you make the compiler help enforce that the child class's method has the same signature as the parent?Some slides to help frame your thinking. To test your implementation, you can jump to Part 5 and do the Goblin-relevant steps.
The implementation of
Goblin'smovemethod should look completely different from theHuman'smovemethod. They do not move in the same ways. Consider this hypothetical: if theGoblinwas so much likeHuman, why wouldn't I have told you to make theGoblina child ofHuman? I probably would have. So, their implementations are probably pretty different.If you are tempted to change the method signature or write code that violates encapsulation, stop and think about what objects are available to you and if they have any methods that could be useful.
- Create a
Treasureclass, whose image is the gem. The gem will move around the window, periodically and randomly. Note that theTreasureshould not change positions during every iteration of theanimateloop. So, sometimes, the Treasure's move method is called, but it doesn't move. Also, note that the top 20 pixels of the window (indicated byYMIN_DISPLAY) are covered by the menu bar. - Clean up your classes. Is there irrelevant code?
Part 4: Updating the Game Class (20 pts)
- Edit
Game'sanimatemethod. Create a Goblin object and a Treasure object. Start the Goblin in the upper left corner. The Treasure should be at a random spot in the window. - Call the Treasure and Goblin's
movemethods to make them move. - Call the Treasure and Goblin's
drawmethods to display them. The window "refreshes" each frame, so you'll need to draw each object, even if you don't move it.
Part 5: Using Abstract Class in the Game Application (35)
Cannot be completed until after Friday's class.
Refactoring
This assignment is an example of a typical design/implementation process. Start with the original code design: inheritance from GamePiece class. You realize it could be designed better, so you change the design/implementation. With the revision, it is now easier to add new functionality to Game. This is called refactoring. You are not adding functionalityl, but you are changing the code to improve its design/readability/maintainability in some way.
Now for the refactoring of your code:
- First, clean up your code. If you did not use
the
@Overrideannotation on themovemethods of your child classes, you should add that. If you get errors, fix the errors (most likely caused by not using the appropriate parameters). - Modify the
GamePiececlass so that it is anabstractclass with anabstractmovemethod. - Modify the
Gameclass'sanimatemethod to have an array ofGamePieceobjects, which contains theGamePieceobjects that you just created. Iterate through the objects, calling themoveanddrawmethod on each object. (If you're getting errors, you likely didn't override themovemethod correctly.) Is there any other way you can make the code more concise? - Make all appropriate methods in the
GamePiececlass befinalmethods. - Test your new code.
The coding for this part of the assignment should be straightforward. The explanations described below are more important.
Documenting Design Decisions
You are going to document your design decisions in
the README.md file, under "Design Decisions".
- In the section labeled "Making GamePiece Abstract", discuss
why making
GamePieceabstractis a better approach to the code's design - In the section labeled "Calling an Abstract Method", explain
why we can call the
movemethod on aGamePieceobject--a method that is abstract on an object of an abstract class--and the application does the "right" thing - In the section labeled "Choices of Final Methods", justify
your choices of making methods
final. - In the section labeled "Adding a New Goblin", describe all the steps a programmer would need to take to add a new bad guy that has a different movement behavior (e.g., zig-zags across the screen) to the game. Be clear, concise, and explicit. Don't talk about the zig-zag behavior in particular--I am just giving you a concrete idea of a different behavior. It should be clear to a programmer how to add a new bad guy to the game. (You can make an ordered list in Markdown to make the steps easily read.
- After you push your code to GitHub, look at how the README is displayed in your browser to make sure it looks as you expect--with headings and paragraphs under those headings.
Extra Credit (up to 15 points)
Complete all of the above requirements before doing extra credit.
Add the overlap method to
the GamePiece class. The signature
for overlap will look something like
public boolean overlaps( GamePiece gp ). It will
return true iff the GamePiece overlaps the GamePiece passed to
the overlap method as a parameter. Note that, if you
haven't done so already, you'll need to adjust the value of the
img_width or char_width variables
of the respective child classes, depending on the size of animated
gif you chose. Try a value of 15 to start.
There is a lot more that can be done on this assignment--actually making the game stop, implementing winning or losing, adding goblins (with different types of movements), ... Be creative, but keep the code neat.
Submission
As usual, put all of your code in your GitHub repository that you and I can access.
Grading (115 pts)
You will be evaluated based on the following criteria:
- (80 pts) correctness and OO style of your classes, including use of abstract, final
- (15 pts) adding abstraction
- (20 pts) Documentation of design decisions