Project 3

Project:  Write an adventure game.  We'll provide most of the program.  You will mostly make modification and some additions.

This project is designed to be done by two people working in parallel, then combining your results into one finished product.  (Hereafter the two partners are called Person A and Person B.)  But you will combine your work to hand in a single report for your group.

The project begins with two exercises that everyone should do; these exercises do not require new programming, but rather familiarize you with the overall structure of the program as we've provided it.  After that, each person has separate exercises.  There is one final exercise for everyone that requires the two partners' work to be combined. (Therefore, you should probably keep notes about all of the procedures that you've modified during the project, so you can notice the ones that both partners modified independently.)

This is a two-week project.  Each week, your group should hand in one paper (not one per person) including a listing of your modified adv.scm program with the modifications highlighted, and a transcript of the testing of your work.  Indicate on the paper which of you is person A and which is person B.

In the printed version of your code, please highlight the parts that you change/add. Highlight only parts that you have changed for the project that you are submitting, i.e. don't highlight proj3 part1 code if you didn't change them for proj3 part 2. The penalty for not highlighting is one point.

Scoring:  Each person works on nine problems.  Three of these (numbers 1, 2, and 9) are common to the two partners; the others are separate. You hand in a single solution to each problem.  Both partners get the points awarded to the group for problems 1, 2, and 9; each
person gets the points for his or her own problems 3 through 8.  This means that your score for the project is mostly based on your individual work but also relies partly on the other member of your group.  For the first two problems, you could get away with letting your partner do the work, but you shouldn't because those problems are necessary to help you understand the structure of the entire project.  Problem 9 requires that both partners have already done their separate work, and meet together to understand each other's solutions, so probably nobody will get credit for it unless both have done their jobs.

(Acknowledgement: This assignment is loosely based on an MIT homework assignment in their version of this course. But instead of killing each other, the characters go around eating gourmet food all the time.)

In this laboratory assignment, we will be exploring two key ideas: the simulation of a world in which objects are characterized by a set of state variables, and the use of message passing as a programming technique for modularizing worlds in which objects interact.

OBJECT-ORIENTED PROGRAMMING is becoming an extremely popular methodology for any application that involves interactions among computational entities.

        -- operating systems (processes as objects)
        -- window systems (windows as objects)
        -- games (asteroids, spaceships, gorillas as objects)
        -- drawing programs (shapes as objects)

To start, copy the following five files into your directory:
  ~cs61a/lib/obj.scm           The object-oriented system
  ~cs61a/lib/adv.scm           The adventure game program
  ~cs61a/lib/tables.scm        An ADT you'll need for parts A5 and B4
  ~cs61a/lib/adv-world.scm     The specific people, places, and things
  ~cs61a/lib/small-world.scm   A smaller world you can use for debugging

To work on this project, you must load these files into Scheme in the correct order: obj.scm first, then adv.scm and tables.scm when you're using that, and finally the particular world you're using, either adv-world.scm or small-world.scm.  The work you are asked to do refers to adv-world.scm; small-world.scm is provided in case you'd prefer to debug some of your procedures in a smaller world that may be less complicated to remember and also faster to load.

The reason the adventure game is divided into adv.scm (containing the definitions of the object classes) and adv-world.scm (containing the specific instances of those objects in Berkeley) is that when you change something in adv.scm you may need to reload the entire world in order for your changed version to take effect.  Having two files means that you don't
also have to reload the first batch of procedures.

In this program there are three classes: THING, PLACE, and PERSON.

Here are some examples selected from adv-world.scm:

;;; construct the places in the world
(define Soda (instantiate place 'Soda))
(define BH-Office (instantiate place 'BH-Office))
(define art-gallery (instantiate place 'art-gallery))
(define Pimentel (instantiate place 'Pimentel))
(define 61A-Lab (instantiate place '61A-Lab))
(define Sproul-Plaza (instantiate place 'Sproul-Plaza))
(define Telegraph-Ave (instantiate place 'Telegraph-Ave))
(define Noahs (instantiate place 'Noahs))
(define Intermezzo (instantiate place 'Intermezzo))
(define s-h (instantiate place 'sproul-hall))

;;; make some things and put them at places
(define bagel (instantiate thing 'bagel))
(ask Noahs 'appear bagel)

(define coffee (instantiate thing 'coffee))
(ask Intermezzo 'appear coffee)

;;; make some people
(define Brian (instantiate person 'Brian BH-Office))
(define hacker (instantiate person 'hacker Pimentel))

;;; connect places in the world

(can-go Soda 'up art-gallery)
(can-go art-gallery 'west BH-Office)
(can-go Soda 'south Pimentel)

Having constructed this world, we can now interact with it by sending
messages to objects.  Here is a short example.

; We start with the hacker in Pimentel.

> (ask Pimentel 'exits)
> (ask hacker 'go 'north)

We can put objects in the different places, and the people can then take the

> (define Jolt (instantiate thing 'Jolt))
> (ask Soda 'appear Jolt)
> (ask hacker 'take Jolt)

You can take objects away from other people, but the management is not responsible for the consequences...  (Too bad this is a fantasy game, and there aren't really vending machines in Soda that stock Jolt.)

PART I: DUE 7/18/2011 11:59PM

The first two exercises in this part should be done by everyone -- that is, everyone should actually sit in front of a terminal and do it!  It's okay to work in pairs as long as you all really know what's going on by the time you're finished.  (Nevertheless, you should only hand in one solution, that both agree about.)  The remaining exercises have numbers like "A3"
which means exercise 3 for Person A.

After you've done the work separately, you should meet together to make sure that you each understands what the other person did, because the second week's work depends on all of the first week's work.  You can do the explaining while you're merging the two sets of modifications into one adv.scm file to hand in.

1.  Create a new person to represent yourself.  Put yourself in a new place called Dormitory (or wherever you live) and connect it to campus so that you can get there from here.  Create a place called Kirin, north of Soda. (It's actually on Solano Avenue.)  Put a thing called Potstickers there. Then give the necessary commands to move your character to Kirin, take the Potstickers, then move yourself to where Brian is, put down the Potstickers, and have Brian take them. Then go back to the lab and get back to work. (There is no truth to the rumor that you'll get an A in the course for doing this in real life!)  All this is just to ensure that you know how to speak the language of the adventure program.

LIST ALL THE MESSAGES THAT ARE SENT DURING THIS EPISODE.  It's a good idea to see if you can work this out in your head, at least for some of the actions that take place, but you can also trace the ASK procedure to get a complete list.  You don't have to hand in this listing of messages.  (Do hand in a transcript of the episode without the tracing.)  The point is that you should have a good sense of the ways in which the different objects send messages back and forth as they do their work.

[Tip:  we have provided a MOVE-LOOP procedure that you may find useful as an aid in debugging your work.  You can use it to move a person repeatedly.]

2.  It is very important that you think about and understand the kinds of objects involved in the adventure game.  Please answer the following questions:

2A.  What kind of thing is the value of variable BRIAN?

Hint:  What is returned by scheme in the following situation:
     You type:     > BRIAN

2B.   List all the messages that a PLACE understands.  (You might want to maintain such a list for your own use, for every type of object, to help in the debugging effort.)

2C.   We have been defining a variable to hold each object in our world. For example, we defined bagel by saying:

     (define bagel (instantiate thing 'bagel))

This is just for convenience.  Every object does not have to have a top-level definition.  Every object DOES have to be constructed and connected to the world.  For instance, suppose we did this:

> (can-go Telegraph-Ave 'east (instantiate place 'Peoples-Park))

;;; assume BRIAN is at Telegraph
> (ask Brian 'go 'east)

What is returned by the following expressions and WHY?

> (ask Brian 'place)

> (let ((where (ask Brian 'place)))
      (ask where 'name))

>  (ask Peoples-park 'appear bagel)

2D.  The implication of all this is that there can be multiple names for objects.  One name is the value of the object's internal NAME variable. In addition, we can define a variable at the top-level to refer to an object. Moreover, one object can have a private name for another object.  For example, BRIAN has a variable PLACE which is currently bound to the object that represents People's Park.  Some examples to think about:

      > (eq? (ask Telegraph-Ave 'look-in 'east) (ask Brian 'place))

     > (eq? (ask Brian 'place) 'Peoples-Park)

     > (eq? (ask (ask Brian 'place) 'name) 'Peoples-Park)

OK.  Suppose we type the following into scheme:

>  (define computer (instantiate thing 'Durer))

Which of the following is correct?  Why?

(ask 61a-lab 'appear computer)


(ask 61a-lab 'appear Durer)


(ask 61a-lab 'appear 'Durer)

What is returned by
(computer 'name)?  Why?

2E.  We have provided a definition of the THING class that does not use the object-oriented programming syntax described in the handout.  
[CHANGED] Compare it to the code below. Add the code below your your file. Your “Answer” for 2E should be the code below, which just involves copying and pasting it.

(define-class (thing name)

 (instance-vars (possessor 'no-one))

 (method (type) 'thing)

 (method (change-possessor new-possessor)

   (set! possessor new-possessor)) )

2F.  Sometimes it's inconvenient to debug an object interactively because its methods return objects and we want to see the names of the objects.  You can create auxiliary procedures for interactive use (as opposed to use inside object methods) that provide the desired information in printable form.  For example:

(define (name obj) (ask obj 'name))
(define (inventory obj)
 (if (person? obj)
     (map name (ask obj 'possessions))
     (map name (ask obj 'things))))

Write a procedure
WHEREIS that takes a person as its argument and returns the name of the place where that person is.

Write a procedure OWNER that takes a thing as its argument and returns the name of the person who owns it.  (Make sure it works for things that aren't owned by anyone.)

Procedures like this can be very helpful in debugging the later parts of the project, so feel free to write more of them for your own use.

Now it's time for you to make your first modifications to the adventure game.  This is where you split the work individually.


A3.  You will notice that whenever a person goes to a new place, the place gets an 'ENTER message.  In addition, the place the person previously inhabited gets an 'EXIT message.  When the place gets the message, it calls each procedure on its list of ENTRY-PROCEDURES or EXIT-PROCEDURES as appropriate.  Places have the following methods defined for manipulating these lists of procedures:  




You can read their definitions in the code.

Sproul Hall has a particularly obnoxious exit procedure attached to it.  Fix SPROUL-HALL-EXIT so that it counts how many times it gets called, and stops being obnoxious after the third time.

Remember that the EXIT-PROCS list contains procedures, not names of procedures!  It's not good enough to redefine SPROUL-HALL-EXIT, since Sproul Hall's list of exit procedures still contains the old procedure.  The best thing to do is just to load adv-world.scm again, which will define a new sproul hall and add the new exit procedure.

A4a.  We've provided people with the ability to say something using the messages 'TALK and 'SET-TALK.  As you may have noticed, some people around this campus start talking whenever anyone walks by.  We want to simulate this behavior.  In any such interaction there are two people involved: the one who was already at the place (hereafter called the TALKER) and the one who is just entering the place (the LISTENER).  We have already provided a
mechanism so that the listener sends an ENTER message to the place when entering.  Also, each person is ready to accept a NOTICE message, meaning that the person should notice that someone new has come.  The talker should get a NOTICE message, and will then talk, because we've made a person's NOTICE method send itself a TALK message.  (Later we'll see that some special kinds of people have different NOTICE methods.)

Your job is to modify the ENTER method for places, so that in addition to what that method already does, it sends a NOTICE message to each person in that place other than the person who is entering.  The NOTICE message should have the newly-entered person as an argument.  (You won't do anything with that argument now, but you'll need it later.)

Test your implementation with the following:

(define singer (instantiate person 'rick sproul-plaza))

(ask singer 'set-talk "My funny valentine, sweet comic valentine")

(define preacher (instantiate person 'preacher sproul-plaza))

(ask preacher 'set-talk "Praise the Lord")

(define street-person (instantiate person 'harry telegraph-ave))

(ask street-person 'set-talk "Brother, can you spare a buck")


A4b.  So far the program assumes that anyone can go anywhere they want. In real life, many places have locked doors.

Invent a
MAY-ENTER? message for places that takes a person as an argument and always returns #T.  Then invent a LOCKED-PLACE class in which the MAY-ENTER? method returns #T if the place is unlocked, or #F if it's locked.  (It should initially be locked.)  The LOCKED-PLACE class must also have an UNLOCK message.  For simplicity, write this method with no arguments and have it always succeed.  In a real game, we would also invent keys, and a mechanism requiring that the person have the correct key in order to unlock the door.
(That's why MAY-ENTER? takes the person as an argument.)

Modify the person class so that it checks for permission to enter before moving from one place to another.  Then create a locked place and test it out.

A5.  Walking around is great, but some people commute from far away, so they need to park their cars in garages.  A car is just a THING, but you'll have to invent a special kind of place called a GARAGE.  Garages have two methods (besides the ones all places have): PARK and UNPARK.  You'll also need a special kind of THING called a TICKET; what's special about it is that it has a NUMBER as an instantiation variable.

The PARK method takes a car (a THING) as its argument.  First check to be sure that the car is actually in the garage.  (The person who possesses the car will enter the garage, then ask to park it, so the car should have entered the garage along with the person before the PARK message is sent.)  Then generate a TICKET with a unique serial number.  (The counter for serial numbers should be shared among all garages, so that we don't get in trouble later trying to UNPARK a car from one garage that was parked in a different garage.)  Every ticket should have the name TICKET.

You'll associate the ticket number with the car in a key-value table like the one that we used with GET and PUT in 2.3.3.  However, GET and PUT refer to a single, fixed table for all operations; in this situation we need a separate table for every garage.  The file tables.scm contains an implementation of the table Abstract Data Type:

constructor: (make-table) returns a new, empty table.

mutator: (insert! key value table) adds a new key-value pair to a table.

selector: (lookup key table) returns the corresponding value, or #F if
                                the key is not in the table.

You'll learn how tables are implemented in 3.3.3 (pp. 266-268).
For now, just take them as primitive.

Make a table entry with the ticket number as the key, and the car as the value.  Then ask the car's owner to lose the car and take the ticket. PARK method should also make sure that no one can steal the car after the person parks the car.

The UNPARK method takes a ticket as argument.  First make sure the object you got is actually a ticket (by checking the name).  Then look up the ticket number in the garage's table.  If you find a car, ask the ticket's owner to lose the ticket and take the car.  Also, insert #F in the table for that ticket number, so that people can't unpark the car twice.

A real-life garage would have a limited capacity, and would charge money for parking, but to simplify the project you don't have to simulate those aspects of garages.

--- End of Part I for Person A


B3.  Define a method TAKE-ALL for people.  If given that message, a person should TAKE all the things at the current location that are not already owned by someone.

B4a.  It's unrealistic that anyone can take anything from anyone.  We want to give our characters a STRENGTH, and then one person can take something from another only if the first has greater STRENGTH than the second.

However, we aren't going to clutter up the person class by adding a local STRENGTH variable.  That's because we can anticipate wanting to add lots more attributes as we develop the program further.  People can have CHARISMA or WISDOM; things can be FOOD or not; places can be INDOORS or not. Therefore, you will create a class called BASIC-OBJECT that keeps a local variable called PROPERTIES containing an attribute-value table like the one that we used with GET and PUT in 2.3.3.  However, GET and PUT refer to a single, fixed table for all operations; in this situation we need a separate table for every object.  The file tables.scm contains an implementation of the table Abstract Data Type:

constructor: (make-table) returns a new, empty table.

mutator: (insert! key value table) adds a new key-value pair to a table.

selector: (lookup key table) returns the corresponding value, or #F if
                                the key is not in the table.

You'll learn how tables are implemented in 3.3.3 (pp. 266-268).
For now, just take them as primitive.

You'll modify the person, place and thing classes so that they will inherit from basic-object.  This object will accept a message PUT so that
        > (ask Brian 'put 'strength 100)
does the right thing.  Also, the basic-object should treat any message not otherwise recognized as a request for the attribute of that name, so
        > (ask Brian 'strength)
should work WITHOUT having to write an explicit STRENGTH method in the class definition.

Don't forget that the property list mechanism in 3.3.3 returns #F if you ask for a property that isn't in the list.  This means that
        > (ask Brian 'charisma)
should never give an error message, even if we haven't PUT that property in that object.  This is important for true-or-false properties, which will automatically be #F (but not an error) unless we explicitly PUT a #T value for them.

Give people some reasonable (same for everyone) initial strength.  Next week they'll be able to get stronger by eating.

B4b.  You'll notice that the type predicate PERSON? checks to see if the type of the argument is a member of the list '(person police thief).  This means that the PERSON? procedure has to keep a list of all the classes that inherit from PERSON, which is a pain if we make a new subclass.

We'll take advantage of the property list to implement a better system for type checking.  If we add a method named PERSON? to the person class, and have it always return #T, then any object that's a type of person will automatically inherit this method.  Objects that don't inherit from person won't find a PERSON? method and won't find an entry for person? in their
property table, so they'll return #F.

Similarly, places should have a PLACE? method, and things a THING? method.

Add these type methods and change the implementation of the type predicate procedures to this new implementation.

B5.  In the modern era, many places allow you to get connected to the net. Define a HOTSPOT as a kind of place that allows network connectivity.  Each hotspot should have a PASSWORD (an instantiation variable) that you must know to connect.  (Note: We're envisioning a per-network password, not a per-person password as you use with AirBears.)  The hotspot has a CONNECT method with two arguments, a LAPTOP (a kind of thing, to be invented in a moment) and a password.  If the password is correct, and the laptop is in the hotspot, add it to a list of connected laptops.  When the laptop leaves the hotspot, remove
it from the list.

Hotspots also have a SURF method with two arguments, a laptop and a text string, such as


If the laptop is connected to the network, then the surf method should

        (system (string-append "lynx " url))

where URL is the text string argument.

Now invent laptops.  A laptop is a thing that has two extra methods:  CONNECT, with a password as argument, sends a CONNECT message to the place where the laptop is.  SURF, with a URL text string as argument, sends a SURF message to the place where it is.  Thus, whenever a laptop enters a new hotspot, the user must ask to CONNECT to that hotspot's network; when the laptop leaves the hotspot, it must automatically be disconnected from the network.  (If it's in a place other than a hotspot, the SURF message won't be understood; if it's in a hotspot but not connected, the hotspot won't do anything.)

--- End of Part I, PERSON B.

PART II: DUE 7/23/2011 11:59PM

This part of the project includes three exercises for each person, but YOU HAVE TO READ EACH OTHER'S CODE midweek, because one partner's exercises 7 and 8 build on the other partner's exercise 6.  Finally, exercise 9 requires the two partners' work to be combined.  You will have to create a version of adv.scm that has both partners' changes.  This may take some thinking!  If both parners modify the same method in the same object class, you'll have to write a version of the method that incorporates both modifications.


Adv.scm includes a definition of the class THIEF, a subclass of person. A thief is a character who tries to steal food from other people.  Of course, Berkeley can not tolerate this behavior for long.  Your job is to define a POLICE class; police objects catch thieves and send them directly to jail.  To do this you will need to understand how theives work.

Since a thief is a kind of person, whenever another person enters the place where the thief is, the thief gets a NOTICE message from the place.  When the thief notices a new person, he does one of two things, depending on the state of his internal BEHAVIOR variable.  If this variable is set to STEAL, the thief looks around to see if there is any food at the place.  If there
is food, the thief takes the food from its current possessor and sets his behavior to RUN.  When the thief's behavior is RUN, he moves to a new random place whenever he NOTICEs someone entering his current location.  The RUN behavior makes it hard to catch a thief.

Notice that a thief object delegates many messages to its person object.

A6a.  To help the police do their work, you will need to create a place called jail.  Jail has no exits.  Moreover, you will need to create a method for persons and thieves called GO-DIRECTLY-TO.  Go-directly-to does not require that the new-place be adjacent to the current-place.  So by calling (ASK THIEF 'GO-DIRECTLY-TO JAIL) the police can send the thief to jail no matter where the thief currently is located, assuming the variable thief is bound
to the thief being apprehended.

A6b.  Thieves sometimes try to leave their place in a randomly chosen direction.  This, it turns out, won't work if there are no exits from that place -- for example, the jail.  Modify the THIEF class so that a thief won't try to leave a place with no exits.

** Now get your partner to explain problem B6 and its solution. **

A7a.  We are now going to invent restaurant objects.  People will interact with the restaurants by buying food there.  First we have to make it possible for people to buy stuff.  Give PERSON objects a MONEY property, which is a number, saying how many dollars they have.  Note that money is not an object.  We implement it as a number because, unlike the case of objects such as chairs and potstickers, a person needs to be able to spend SOME money without giving up all of it.  In principle we could have objects like QUARTER and DOLLAR-BILL, but this would make the change-making process complicated for no good reason.

To make life simple, we'll have every PERSON start out with $100.  (We should really start people with no money, and invent banks and jobs and so on, but we won't.)  Create two methods for people, GET-MONEY and PAY-MONEY, each of which takes a number as argument and updates the person's money value appropriately.  PAY-MONEY must return true or false depending on whether the person had enough money.

A7b.  Another problem with the adventure game is that Noah's only has one bagel.  Once someone has taken that bagel, they're out of business.

To fix this, we're going to invent a new kind of place, called a RESTAURANT. (That is, RESTAURANT is a subclass of PLACE.)  Each restaurant serves only one kind of food.  (This is a simplification, of course, and it's easy to see how we might extend the project to allow lists of kinds of food.)  When a restaurant is instantiated, it should have two extra arguments, besides the ones that all places have: the class of food objects that this restaurant
sells,  and the price of one item of this type:

   > (define-class (bagel) (parent (food ...)) ...)

  > (define Noahs (instantiate restaurant 'Noahs bagel 0.50))

Notice that the argument to the restaurant is a CLASS, not a particular bagel (instance).

Restaurants should have two methods.  The MENU method returns a list containing the name and price of the food that the restaurant sells. The SELL method takes two arguments, the person who wants to buy something and the name of the food that the person wants.  The SELL method must first check that the restaurant actually sells the right kind of food.  If so, it should ASK the buyer to PAY-MONEY in the appropriate amount.  If that succeeds, the method should instantiate the food class and return the new food object.  The method should return #F if the person can't buy the food.

A8.  Now we need a BUY method for people.  It should take as argument the name of the food we want to buy:  (ask Brian 'buy 'bagel).  The method must send a SELL message to the restaurant.  If this succeeds (that is, if the value returned from the SELL method is an object rather than #F) the new food should be added to the person's possessions.

--- Person A skip to question 9 below.


B6.  The way we're having people take food from restaurants is unrealistic in several ways.  Our overall goal this week is to fix that.  As a first step, you are going to create a FOOD class.
We will give things that are food two properties, an EDIBLE? property and a CALORIES property.  EDIBLE?  will have the value #T if the object is a food.  If a PERSON eats some food, the food's CALORIES are added to the person's STRENGTH.

(Remember that the EDIBLE? property will automatically be false for objects other than food, because of the way properties were implemented in question B4. You don't have to go around telling all the other stuff not to be edible explicitly.)

Write a definition of the FOOD class that uses THING as the parent class. It should return #T when you send it an EDBILE? message, and it should correctly respond to a CALORIES message.

Replace the procedure named EDIBLE? in the original adv.scm with a new version that takes advantage of the mechanism you've created, instead of relying on a built-in list of types of food.

Now that you have the FOOD class, invent some child classes for particular kinds of food.  For example, make a bagel class that inherits from FOOD. Give the bagel class a class-variable called NAME whose value is the word bagel.  (We'll need this later when we invent RESTAURANT objects.)

Make an EAT method for people.  Your EAT method should look at your possessions and filter for all the ones that are edible.  It should then add the calorie value of the foods to your strength.  Then it should make the foods disappear (no longer be your possessions and no longer be at your location).

** Now get your partner to explain problem A6 and its solution. **

B7.  Your job is to define the police class.  A policeperson is to have the following behavior:

The police stays at one location.  When the police notices a new person entering the location, the police checks to see if that person is a thief. If the person is a thief the police says "Crime Does Not Pay," then takes away all the thief's possessions and sends the thief directly to jail.

Give thieves and police default strengths.  Thieves should start out stronger than persons, but police should be stronger than thieves.  Of course, if you eat lots you should be able to build up enough STRENGTH (mass?) to take food away from a thief.  (Only a character with a lot of CHUTZPAH would take food away from the police. :-)

Please test your code and turn in a transcript that shows the thief stealing your food, you chasing the thief and the police catching the thief.  In case you haven't noticed, we've put a thief in Sproul Plaza.

B8.  Now we want to reorganize TAKE so that it looks to see who previously possesses the desired object.  If its possessor is 'NO-ONE, go ahead and take it as always.  Otherwise, invoke
        (ask thing 'MAY-TAKE? receiver)
The MAY-TAKE? method for a thing that belongs to someone should compare the strength of its owner with the strength of the requesting person to decide whether or not it can be taken.  The method should return #F if the person may not take the thing, or the thing itself if the person may take it.  This is a little more complicated than necessary right now, but we are planning ahead for a situation in which, for example, an object might want to make a clone of itself for a person to take.

Note the flurry of message-passing going on here.  We send a message to the taker.  It sends a message to the thing, which sends messages to two people to find out their strengths.

--- End of Part II, Person B (but both partners do question 8 below).

9.  Combine the two partners' work.  For example, both partners have created new methods for the PERSON class.  Both partners have done work involving strengths of kinds of people; make sure they work together.

Now make it so that when a POLICE person asks to BUY some food the restaurant doesn't charge him or her any money.  (This makes the game more realistic...)

******** OPTIONAL **********
As you can imagine, this is a truly open-ended project.  If you have the time and inclination, you can populate your world with new kinds of people (e.g., punk-rockers), places (Gilman-St), and especially things (magic wands, beer, gold pieces, cars looking for parking places...).

For your enjoyment we have developed a procedure that creates a labyrinth (a maze) that you can explore.  To do so, load the file ~cs61a/lib/labyrinth.scm. [Note: labyrinth.scm may need some modification to work with the procedures you developed in part two of the project.]

Legend has it that there is a vast series of rooms underneath Sproul Plaza. These rooms are littered with food of bygone days and quite a few theives. You can find the secret passage down in Sproul Plaza.

You may want to modify FANCY-MOVE-LOOP so that you can look around in nearby rooms before entering so that you can avoid thieves.  You might also want your character to maintain a list of rooms visited on its property list so you can find your way back to the earth's surface.