Adventures in the Imaginary Land of Gack

Prelab

In lab

The code for the game has been divided into a collection of individual files, but for convenience there is a single "master file" called game.scm which loads all the others in. The first thing you should do is to copy the whole collection of files, so that you will be able to modify any of them as the need arises. If you add any additional files (for example, for newly added classes), you should extend your copy of game.scm to load in the new files as well.

To make a copy of all the files, the simplest approach would be to use the shell to copy the whole directory containing the files. If you are in a shell window, type:

         cp -r ~mc28/labs/gack/gack .

You should open your own copy of game.scm in DrScheme. To play the game, press the Execute button in this window and then evaluate (play) in the associated interaction window.

If you want to edit one of the other files, open it up in its own window in DrScheme, make your changes, and save the file back out. But don't press the Execute button in that window. Instead, press the Execute button back in the window that holds game.scm

Following are links to the various files that comprise the program, together with short descriptions. These links should be useful when you are programming, since you will typically be working on one of the class files, but will need information about various other classes or utility procedures.

• The file that loads all the other files, and should be reloaded each time you modify your program:
  • game.scm

• The various class files in the Land of Gack hierarchy:
  • named-object.scm
    • person.scm
      • auto-person.scm
        • witch.scm
        • wizard.scm
    • place.scm
    • thing.scm
      • scroll.scm
  • registry.scm

• A utility file that contains some procedures used by various classes:
  • utilities.scm

• The gack file creates the specific people/places/things that constitute the Land of Gack:
  • gack.scm

• The interface file provides the play procedure which can be invoked as a normal user's interface to the game, so that you can say (go north) instead of (person/go player 'north):
  • interface.scm

Once you have copies of the files made and loaded in, you are to do exercises 14.33, 14.34, and 14.35, on pages 568 through 570. In coming up with ideas for the open-ended exercise 14.35, you may also want to look at exercise 14.42 on pages 572 and 573.

For the open-ended exercise, be sure to make changes which require some change or addition to the class hierarchy, some additional method, and some additional instance variable.

Our implementation of the object-oriented programming system contains two useful procedures, not mentioned in the text, called oops-display and oops-describe. Calling (oops-describe arg) will give a reasonable representation of arg even if arg recursively contains itself. The procedure oops-display is the one that the object/describe method uses for displaying each of the instance variables values in a summary form -- for example [an object of class witch] or [a 3421 element vector]. The procedure oops-describe, by contrast, will oops-display the first few elements of a 3421 element vector followed by ...

Both procedures are useful when debugging, when you don't know for sure in advance what type of value you are going to encounter (because the bug may be precisely that you have the wrong type, for example the person object rather than the symbolic name of the person).

Postlab

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 Scheme and the OOPS implementation from the book, 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 Scheme code rather than echoing it; after all, the reader can read Scheme 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

1. expand the class hierarchy,
2. adapt the interface,
3. add new instance variables, or
4. change or write new methods.

One way to sketch your idea is to specify the information required by define-class in any new classes, or changes required to define-class in existing classes. You should specify any 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 PostScript or PDF format. (If you print a copy out, you can staple it to the front of your project report to save paper.)

Submitting your code

  ~max/public/178/submit *.scm