MCS-178: Introduction to Computer Science II
Due November 23, 2009
In this lab you will use object-oriented programming to extend an adventure game, the Land of Gack. This game is explained in section 14.5 of Concrete Abstractions and we will spend a couple class days discussing the Python version you'll be working with.
I am providing a document that summarizes the classes. In brief, the changes from the book's versions are
Use of a GUI
Clean-ups of capitalization, spelling, and punctuation
Elimination of methods that just retrieve or set an attribute
Elimination of the named-object class
Making the registry a class attribute within AutoPerson
Endowing each Witch and Wizard with
its own favorite pond or chamber
To download and run the game:
Download gack.zip.
Unzip that file, so as to produce a directory called gack.
To run the program, open Game.py in Idle and choose "Run Module" from the Run menu (or press F5).
If at some point you close the game window, you
can use the interactive Python prompt to probe more
deeply the state of the various objects. (I'll demonstrate this in
class.) If you then want to restart the GUI, you can tell Python to play().
The code for the game has been divided into a collection of
individual
files, most of which which are named for the class they contain. For
example, Person.py contains the Person
class. There are only four exceptions to this general rule:
Gack.py creates the specific people/places/things
that
constitute the Land of Gack.
Game.py provides all of the user interface except
for displaying output.
Interface.py provides the procedures for displaying
output.
Utilities.py defines some minor utility procedures.
Once you have a copy of the game, you are to do exercises 14.33, 14.34, and 14.35. In coming up with ideas for the open-ended exercise 14.35, you may also want to look at exercise 14.42. All four of these exercises are reproduced below with minor editing to suit the current Python context. Be sure in the open-ended exercise to make changes which require all three of the following: some change or addition to the class hierarchy, some additional method, and some additional attribute (instance variable). This is a grading criterion for your project report.
Exercise 14.33: First you'll need to familiarize yourself with the game. Run it as described above. Try to get from the dormitory to the computer lab without getting turned into a frog along the way. To make it more challenging, try to get to the lab possessing the scroll of enlightenment. If you want, you can make the other characters move several times after each move of yours (rather than just once) by using the "Pace" control. Be sure to get familiar with the game's other features too.
Exercise 14.34: Modify the Land of Gack so that
there is a new scroll, called "late lab report", in the dormitory. Now
you can play the game with a new goal: Pick up the late lab report, go
catch up with Max, wherever he may have wandered to, and try to give
Max the report even though it's late. You'll need to add some
additional mechanisms to the Person class and to
the give procedure within Game.py. Verify
that at the end the lab report thinks Max is its owner, Max thinks the
lab report is one of his possessions, and Gack.player no
longer thinks the lab report is one of its
possessions.
Exercise 14.35: Of course, you can make the game much more interesting by adding additional twists. Implement some that interest you. We give a list of suggestions below but feel free to come up with some of your own. Be sure to describe in English whatever new ideas you introduce.
Add Chocolate as a kind of Thing
with a method to beEaten. When a chocolate is eaten, the
owner loses it and it is gone from the place where the owner is
located. You can optionally add cute sound effects or make a wrapper or
some crumbs appear at the place. Make some chocolates appear at food
service.
Modify the Person class so people have an eat
method that causes a chocolate they own to be eaten, much like the read
method.
Now that we have chocolates, we can modify
the Witch class to reflect a little-known property of
witches: They can be bought off with chocolates. Change the act method
so that if Barbara's victim has any chocolates, Barbara will take and
eat one rather than turning the victim into a frog. Only victims who
possess no chocolates will become frogs. This makes the game more
interesting in that you have to decide whether to take the extra time
to make a detour to food service for chocolates or go for speed but
risk being caught unprepared by Barbara.
If you want to make the game harder yet, you can make it difficult to hoard protective chocolates by creating a troll who wanders around eating chocolates. Perhaps you should change Max from being a normal person to being the troll--it was probably just the fact that he wrote this section that kept him from being cast as a troll in the first place.
Introduce a general class, MagicScroll, into the
game as a class that inherits from Scroll and that has a
limited number of charges (let's say n) and when read the
first n
times invokes the doMagic method of self,
i.e., of the particular magic scroll. However, there shouldn't be an
actual defintion of doMagic in MagicScroll;
instead the definition should only appear in more specific subclasses
that inherit from MagicScroll. Define one or more
specific kinds of magic scrolls as subclasses with interesting doMagic
methods; for example, you might make a ScrollOfTeleportation
class. Only these specific subclasses will have instances created in Gack.py.
It makes the game rather easy if the title of a magic scroll
tells what it does. You could add a feature so that initially the name
of any magic scroll is just "a mysterious scroll", but when you read
the scroll the first time the name changes to the actual title. This
feature is particularly effective if you
include scrolls with undesirable effects as well as desirable ones. Of
course, you could counter by including a ScrollOfIdentification
that can be used to decode the titles.
Currently Elvee, the wizard, always takes the first scroll at a place. Because some scrolls are more valuable than others, this action can make the game boring. Change the definition of the wizard class so wizards choose a scroll to take at random.
Feel free to add you own interesting kinds of people, places and things. While you are at it, you can also update any of the out-of-date game elements. Remember, though, changing some names or locations isn't as interesting as changing the overall patterns of behavior.
Exercise 14.42: When a person says something in the Land of Gack, it is "heard" only by the player, in that whatever is said gets displayed. It would be more interesting if other objects within the Land of Gack itself could also hear--and potentially respond to--what was said. That way you could have characters who behaved differently if you said "please," magic portals that opened when you said "open sesame," etc. Note that this is just a suggestion; you don't need to do this.
Add a method in the Person class called hear
that takes two arguments: the person speaking and what was said. The
implementation in the Person class
should do nothing because ordinary persons ignore what they hear.
Change the Person class's say method
so that it invokes the hear
method of each other person in the place where the person is speaking.
Now have fun introducing special classes of person that respond to what they hear.
In order for magic portals and the other magical objects to
respond to spoken commands, they will need to hear as well. In Concrete
Abstraction's version of the Land of Gack, this would be achieved
by putting the hear method in a general named-object
class, from which the person, place, and thing classes all inherit.
However, in the Python version, this superclass was eliminated.
Therefore, you have a choice of either independently adding hear
to other classes, such as Thing, or reintroducing a NamedObject
class after all.
Your audience for this report is a fellow programmer (or team of programmers) who will be extending your game. You can assume the audience knows Python but is not familiar with The Land of Gack. All aspects of your report, including the introduction, should be addressed to this audience. (If there are comments that you wish to make to the grader, you can put those in an appendix.) As always, your report should focus on what the final product is, and not on the assigment. Sentences starting, "We were asked to..." and "The first thing we did in lab is..." should not appear in your project report.
You'll want to briefly describe your game to the audience (with emphasis placed on those parts that differ from the original version.) One thing I'll be looking for is a clear description of your final class hierarchy early in the report. (A diagram helps!) As always, emphasize the final product rather than each incremental change you made. Make sure that your English text provides context for the Python code rather than echoing it; after all, the reader can read Python code.
Suggest one or two specific further improvement(s) to the audience. Clearly explain how components of the program will need to be adapted to incorporate these improvements. I'd rather you explain one suggested improvement in detail than explain several vague ideas. For instance, the programmer may need to
One way to sketch your idea is to list the attributes any new class would have (along with the type of value each would refer to, if that isn't obvious) and the methods that would be defined. You should specify the arguments and return values for new methods.
Although you need not provide explicit testing information in this report, you are expected to adequately test the code you wrote. If your program has bugs, provide a bug report.
The gradesheet for the project is available in PDF format. (If you print a copy out, you can staple it to the front of your project report to save paper.)
.py files from your project directory as attachments.
Please print out your project report and submit it in class. Your project report should not include all your code.