Computer Science II, Lab 09

Tuesday, October 16th and October 23rd

Objectives:


Introduction

This assignment returns you to modification mode. Please download the files for the third version of Budd's pinball construction kit that we made available during Session 22.  

This lab is a little bit different from previous labs because I don't think it is doable in two hours for most students.  In order to adjust for that, this lab will be assigned as a "two week" lab.  It is to be completed IN-LAB on October 16th and October 23rd.  In other words, you are expected to be in Lab for the entire lab period on Tuesday, October 16th.  If you finish and submit all the pieces of this lab prior to the lab period on October 23rd, you are free to skip the lab that day.  Otherwise, you should be in lab on the 23rd.  On the flip side, if you find that you are moving slower than you would like, you should work on this outside of lab as well.  The final code for this lab will be due by Wednesday, October 25th.

As always, feel free to ask questions!

One last hint : I found this lab much easier to work with if I increased the "sleep" between painting the balls so that things moved MUCH slower.  In fact, I changed it by a factor of 10.


Tasks

  1. Get to know the code.
  2. In lab I will hand you a sheet with the following questions.  You should look at the code for this program very carefully and answer the questions on that lab sheet.  Submit this lab sheet along with your final deliverable of code at the end of the entire lab.

  3. Modify the game so that targets can be repositioned.

    It is really annoying to move a target from the pallet and then drop it in the wrong place.  Allow the player to reposition targets after they have been placed in the playing area.  If a mouse 'down' event occurs over a target in the playing area, move the target to the spot of the next mouse 'up' event.

    This is easy in theory, but we want to write good clean code to provide this functionality.  To have clean code, you have to think through the problem.

    One way to do this is to modify the mousePressed() method of the MouseKeeper class.  Notice that the current  mousePressed() method already extracts the x and y coordinates from MouseEvent e .  You can use this to determine if you have pressed on a target that is in the toolkit area or one of the ones that is "in play."    To determine WHICH one of the "in play" targets it was, you should add a method to PinBallTargets so that they can tell us if they contain the point clicked by the user. [Hint:  Look into how you can simply delegate this behavior to super classes and/or composition classes rather than writing the check yourself].

    Once you determine which target it is (regardless of toolkit or in play), you can use the existing element variable to remember which target was pressed on. 

    You will also want to use a flag called something like isInPlay to indicate whether the target is one in play or not.  This is important since what you DO with the target stored in element on mouseRelease() is different depending on where the target came from.

     

  4. Modify the game so that pinballs bounce off of one another when they intersect.

    On the surface, all you have to do is modify PinBall to implement the PinBallTarget interface and store them as targets (instead of balls).

    Test this carefully.  For example, you should first make sure that one ball travelling on its own doesn't do anything "flaky" (it will if you aren't careful).

    The other thing that you will want to look at is what a ball should do when it hits another ball.  How should their motion change?  Where should those new motion directions get set?

    Finally, one side effect of this solution is that a user can reposition a pinball that is in play.  NOT GOOD.  Check out the keyword instanceof  and figure out how you could use this test to prevent this.

     

  5. Modify the game so that, when a pinball bounces off of an object, it moves completely off that target. This will prevent a user from receiving multiple sets of points when it hits a Scorepad but fails to move all the way off when it bounces.

     

  6. Remove the class variable.  Budd's implementation hard-codes the targets that update the score to a class variable named world in class PinBallGame. As you know now from our class discussion, this solution makes it impossible for us to use any of these classes (PinBallGame, ScorePad, and Peg) without using them all.

    Let's correct that situation by creating an association between a ScorePad and the PinBallGame in which it lives.

     

  7. Make multiple games run simultaneously.  A positive side effect of completing Task 5 is that you can now play more than one pinball game at the same time. To demonstrate this, modify the main() method in PinBallGameDriver so that it creates at least two instances of the pinball game for the user to play simultaneously. Play for a while in both to verify that they can have different configurations of targets and different scores!
 

 

 

Deliverables

Treat this like a PA submission.  Submit the files:

Since there are so many of them, go ahead and zip them into a single file

Be sure that your submission follows all homework submission requirements.

ALSO, make sure to submit print-outs of these same classes ( be sure to staple your print-outs in the order listed above!) and include your answer sheet from task1.