CSE 143

Spring 1999

Homework #5

"Impress Me"

Due dates: Thursday, May 13; Tuesday, May 18; Monday, May 24 extended to Wednesday, May 26(see below)

The quarter's almost over.  You would rather play than work.  Who wouldn't?  But now you know about objects and inheritance, and you can play in the Big Leagues.  Impress your roommate!  Impress that significant other (or would-be significant other).  Most of all, impress your TA...

For this project, find a partner and work together on a solution.  Except for the first part (May 13), all the parts should be done together.

Getting Started

What you have to start with is a version of the popular old video game Pac-Man.   This version is rather thoroughly object-oriented.  Part of the problem is simply to dig through the code and figure out how it works.  You will find that it is not really complicated, but it is organized somewhat differently from the programs we have seen so far.

Once you have it figured out, you and your partner should decide how to improve it.   Do something that a person (not a programmer) would find interesting. (We may offer some suggestions later on what would be "interesting", but don't wait for that to get started).  The final version of the program is due May 24th.  Sometime after that, you will show up for an appointment with a TA to demonstrate the program in the IPL and be graded on the basis of that demo.  If you do not show up for your scheduled appointment, you won't get a grade for the assigment.  (Details on signing up, etc. will be given later).

Note on Windows code:  The program as we give it to you has direct calls to some Window-specific functions.  (Sad note for non-Windows users: This means you will need to find a Windows machine to work on.)  All of this code is encapsulated in the Display class.  It works as given.  We don't intend for you to have to learn how or why it works (you can look up the functions via the MSCV help facility.)  Try NOT to change this class, unless you really, really want to.   Some of the TAs and consultants might be up on this stuff, but the instructor certainly isn't!  You may find yourself out on a limb if you try to get too fancy with it.

For May 13 (due in quiz section.) 

Each person should do this individually.  Staple the parts together.  Make sure your name, etc. is on each part. These should all be originals in your own hand (no xeroxed copies).

  1. Partner statement.  Each person should turn in a statement of who their partner is: name, ID number, section, etc.  If you are working alone, state that fact.  Partner selection is final! You will not be able to change your mind later.  That is, you can't drop your partner, or change to a different one, or add one later if you first said you wouldn't have one.  This statement can be written freehand on a piece of paper (no need to word-process).
  2. Object hierarchy.  Turn in a simple object hierarchy diagram for the program as we give it to you originally.  All it has to show is the names of the classes, and their relationships.  Indicate this by drawing a rectangle for each class, with bases classes toward the top of the page, and derived classes below them, connected by a line.  For simple examples, see slide 17 of the 5/10 lecture, or p. 362 of the textbook.  You do not have to word-process this chart or make it beautiful.  Freehand but legible is fine.
  3. Main () analysis.  Locate the main() function for the program and print it off.  Notice that the function contains 6 statements.  Each one of them involves some kind of function call (in some cases, it might be a constructor).  For each of the 6 lines, identify where the function is that is being called (that is, what is the name of the file where the function is implemented).   You can provide this information by writing directly on the printout, or by modifying the function with brief comments on each line.

For Tuesday May 18 (due in quiz section). 

Each team should hand in only ONE copy, but both partners' names, IDs, and sections must be on every part.

  1. Improvements proposal.  Write a statement describing what improvements you plan to make to the game.  This statement should not discuss the programming.  Rather, it should describe what the user (the game-player) would see as different between your game and the one you had to start with.  This statement should be typed or word-processed.
  2. Object hierarchy (revisited).  Turn in the object hierarchy again, but with more detail this time.  Inside each class box, show the names of the members.  You can omit constructors and destructors.  Use () to indicate the methods.  You do not have to give the types, just names.  If you expect to have additional classes, show them on the hierarchy, too, but use a different color for the box.  For your new classes, you might not yet know the names of the members, so you can should show what you know or think will be there.  As before, this diagram may be done freehand, as long as it is legible.
  3. Static call graph.  This is an extension of the the main() analysis you did earlier.  Create a static call graph for the functions in the program (as given).  Start with main() at the top and below that show the functions called by main.  Draw a rectangle for each function and a line down to each function called.  Continue the diagram downward, showing all functions that are called in the original program (whether or not they are defined in the original program.   Take srand() for example. Should should you show it?  Ask yourself, is it called in the original program? is it defined in the original program?  You should be able to decide from this whether or not to show it on the call graph.)
  4. [Optional] You may find there are some programming features of the original program which are hard to understand.  Try to figure them out.  If you still have questions at this point, write a list of them and turn it in.  Some of the questions may get answered in quiz section or via e-mail, and you can always go to office hours or to consultants to get additional help.

For Monday, May 24 26 (electronic turn-in by 8:00 pm.)

Please give hard-copy to TAs on Tuesday in quiz section).  Each team should turn in only ONE copy of the material, with BOTH partner's names on all parts.  Only one partner need do the electronic turn-in.

  1. The turn-in receipt, as usual.
  2. A statement describing what improvements you actually made to the game.  This might be identical to what you turned in the previous week, or might be different, depending on how things turned out.
  3. The final version of the object hierarchy.  This should accurately reflect what you actually turned in.
  4. The final version of the static call graph.
  5. Statement of acknowledgements.  If you got help from other groups or from individuals outside the class, state how much help you got and who gave it to you.   If you took any code from other sources (the Internet, etc.) you must acknowledge the source and how you used it.

Internal requirements. 

In addition to "doing something interesting," your program needs to do it in an object-oriented way.  Preserve the original object hierarchy and add it to, by inheriting to new subclasses, or defining new inheritance hierarchies if appropriate.   What you may not do is tear out the object stuff and substitute your own, non-object oriented design -- no matter how interesting the result might be from the user's point of view.