Define the function create-cave, which creates caves from a name (symbol), and an item.
Optional: allow for some caves to have an optional snapshot ¹.

When in room cave1, we don't want a tunnel to cave2 to be the same as cave2 itself: e.g. from 'Lovett-Hall, a player saw the tunnel 'west-door, but didn't know (w/o trying) that it leads to the cave 'main-quad.

All tunnels are one-way. If you want a two-way connection between two caves, use two one-way tunnels. (To consider: does your implementation preclude a tunnel leading from a cave to itself, or several different tunnels between the same pair of caves? It shouldn't.)

So a tunnel consists of a label (describing it), and a destination. Define the function connect-caves!, which accepts two caves, c1 and c2, and a label lbl (symbol), and adds (make-tunnel lbl c2) to c1's exits. (We can have the starting-end of a tunnel impicitly correspond to the room which contains that tunnel, if we like; or, you can include both ends of a tunnel.)

As the player walks through the maze, she can carry one item in her pocket. When the player enters a cave, she may exchange her carried item with the item in the current cave. Once the player is happy with the state of the items, she moves on by choosing one of the exits out of the cave.

Define the function create-player, which accepts a cave and creates a player who is in that cave and with nothing in their pocket (Consider: how to represent no item?). Write the function swap-item (Consider: what is a reasonable contract for this?).

The walk is simulated with a simple generative recursive program. It repeatedly: prompts the user, reads a typed response from the keyboard, and reacts accordingly. The user's response is one of a pre-determined set of symbols:

• inventory, which prints the contents of the player's pocket.
• swap, which swaps the room's item (if any) with the player's item (if any);
• leave, which asks the player which exit they'd like to leave through (perhaps a number), and moves the player as indicated. (A better dialogue than the example given might number the exits for you, though that's not required.) If the player doesn't respond with a valid exit, do something reasonable.
• 'quit, to exit the game.
  (You might implement this by setting the player's cave field to the flag 'done, and your generative recursion checks for this flag. Alternately, you can make this the only place in your program where you use set!: set a local flag variable.)
• Implement one more command of your choice, which is useful when playing the game.

Implement the dialogue.
You do not need to re-create the exact behavior of the example dialogue, (Though you do need to use the same command names mentioned here.)

You may use read and printf as mentioned in lab (or, helpdesk). For simplicity, you may implement each command as a one-symbol command. Note that the example dialogue's first line can be produced with

(printf "You are in ~s.  It contains ~s.~n" 'Lovett-Hall 'a-file-cabinet)

Hint: one approach would be to have a big function which takes in a symbol, and (via a large cond) calls a particular helper function (passing it any arguments needed). Adding a new command means adding a new cond branch. This is fine.

A more flexible approach would be: Keep a list of symbol/function entries; instead of a large cond, you can just lookup the appropriate function in the list. Adding a new command means adding a new symbol/function entry to the list. This allows more things -- for instance, it's easy now for a help command to tell the user a list of all legal commands. (If you augment commands to be not just a function but also a help-string, it's easy to make use of that info.)

For this second approach, recall the directory/entry problem from an early homework -- that's virtually the same thing. See assoc in help-desk.

In either approach, you might want to have several different commands map to the same function (i.e. s and swap might both cause your internal function swap-item to be called on the current player).