Assignment 6: Inheritance, Abstract Classes, and Final

Objective: Create a small game and practice writing child classes.

Due: Before Wednesday's Class

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

1. Compile the code using javac *.java or javac Game.java.
2. 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.
3. Using the arrow keys, move the professor around the screen. Use the space bar to stop him.
4. To stop the program, close the window.
5. To see what I'm hoping to see when you're done (if you also do the extra credit), go into the demoClasses directory 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.

1. Start by looking at Game.java. There is a lot of code that you don't need to worry about. Focus on the main and animate methods as well as the instance variables.

   The main method creates a new Game object, including setting up the window. main also calls the animate method, which starts the game running.

   The animate method creates the professor and moves the professor. The professor's direction is determined by pressing keys.

2. 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.

3. Now, look at Human.java. Look at the class's constructor and the move method. 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.

1. Create a Goblin class, which inherits from GamePiece. There are several animated gifs to choose from. A Goblin should "chase" the professor instead of just standing there, which is what the inherited GamePiece's move method 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?

   The implementation of Goblin's move method should look completely different from the Human's move method. They do not move in the same ways.

   If you are tempted to change the method signature or write code that violates encapsulation, stop and think about what is available to you and if they have any methods that could be useful.

   Your Goblin may look like it's "bouncing" around the professor when they get close to each other. Why is that happening? (Add print statements with good labels if it's not clear as to why it's happening. The print statements will come flying, so be ready.) How can you fix that? A little bounce may be okay but some bouncing may indicate that something wasn't coded as well as it should be. Once you understand the problem, it should be a relatively easy fix to get rid of the bounce completely. (You may want to return to this issue with a clear head after you have gotten more comfortable with the code.)

2. Create a Treasure class, whose image is the gem. The gem will move around the window, periodically and randomly. Note that the Treasure should not change positions during every iteration of the animate loop. 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 by YMIN_DISPLAY) are covered by the menu bar.
3. Clean up your classes. Is there irrelevant code?

Part 4: Updating the Game Class (20 pts)

1. Edit Game's animate method. 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.
2. Call the Treasure and Goblin's move methods to make them move.
3. Call the Treasure and Goblin's draw methods 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 Monday'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 @Override annotation on the move methods 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 GamePiece class so that it is an abstract class with an abstract move method.
• Modify the Game class's animate method to have an array of GamePiece objects, which contains the GamePiece objects that you just created. Iterate through the objects, calling the move and draw method on each object. (If you're getting errors, you likely didn't override the move method correctly.) Is there any other way you can make the code more concise?
• Make all appropriate methods in the GamePiece class be final methods.
• Test your new code.

The coding part of 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 GamePiece abstract is a better approach to the code's design
• In the section labeled "Calling an Abstract Method", explain why we can call the move method on a GamePiece object--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 Baddie", 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) Documentations of design decisions)