Last time, on let’s make IF…
When we finished up yesterday, I said I wanted to work on the following things:
- Printing portable items when looking into remote rooms.
- Implement a “look [direction]” command.
- Deal with whatever comes up in the course of #1 and #2 (something usually comes up).
Printing portable items in remote rooms.
With our current code, examining a distant room (e.g., “examine center stage” when the protagonist is in the spotlight booth) will print whatever room description we’ve defined for that room. As I mentioned last time, this probably commits us to writing two different room descriptions. Things look different as they grow more distant, after all. So let’s commit to finding a way to do that.
Staying on topic: If you’ve followed my Inform 7 content on tumblr at all, then you’ve probably encountered the term “locale description” before. If not, the locale description is a complex activity by which Inform 7 automatically prints items in the location after printing the room description. The only time this happens automatically is by looking (which happens either via command or else after entering a room). The grammar for manually firing this activity is a little different from normal action processing grammar:
after examining a room:
carry out the printing the locale description activity with the noun.Differences between this and action processing grammar:
- “carry out” (activity) vs “try” (action).
- the word “activity” must be specified.
- instead of “to the noun” (action) vs “with the noun” (activity).
This will get us a room description, followed by the hoped-for locale description.
>examine spotlight booth zork. In Spotlight Booth you can see a turtle and a box (in which is a snail).
“Zork” is a placeholder I use, a room description will replace it in the near future. Problem: would I really see a snail in a box onstage, at the other end of the theater? This wouldn’t make sense. We can tinker with what gets printed. Perhaps omitting the contents of remote containers makes sense. When omitting one thing at a time, I tend to use “rule for writing a paragraph about” constructions. Since we’re dealing with big picture, automated processes, I think we’ll have to intervene when Inform 7 builds its list of in-room items. If we take a look at the documentation, then have a look at the standard rules, “listing the contents of a room” seems to be the relevant point of entry.
This usage seems a bit off book, so we might have to experiment before getting it right. We’re going to start with “rule for printing the name of something.” That’s a big deal. We’re touching Inform 7’s process for printing every room description! We’ll want to be very specific with our conditions, and make sure we don’t break anything. How about this:
Rule for printing the name of something (called the mysterious item) that is not in the location while listing contents of a room:
if the mysterious item is in a container:
do nothing.That doesn’t sound bad, right? It will only affect looking into other rooms, which is what we want. And we are trying to omit container contents, right? Here are the results.
>examine spotlight booth zork. In Spotlight Booth you can see a and a (in which is a ).
Hm. That doesn’t look so good. We don’t have any names printing. Hm. [some time passes] OK, I see. This isn’t action processing, where actions just continue by default. We’ve shut the process down altogether. I’ll tell Inform 7 to keep going:
Rule for printing the name of something (called the mysterious item) that is not in the location while listing contents of a room:
if the mysterious item is in a container:
do nothing;
otherwise:
continue the activity.That yields this:
>examine spotlight booth zork. In Spotlight Booth you can see a turtle and a box (in which is a ).
That’s better, at least. I think I’ve got it, now. I’m looking at it the wrong way. I should be thinking about modifying the way “box” prints, not the things in the box. In other words, we should omit the contents of containers.
Rule for printing the name of something (called the mysterious item) that is not in the location while listing contents of a room:
if the mysterious item is a container:
omit contents in listing;
continue the activity;
otherwise:
continue the activity.And, at long last, we have what we’re looking for.
>examine spotlight booth zork. In Spotlight Booth you can see a turtle and a box.
From a mechanical standpoint, this is pretty great. I’ve never done anything like this before, and it seems nice and clean. Still… perhaps we are missing something important. Printing the locale description of a remote room may not be a slam dunk. The protagonist might see a basketball, but not a credit card. Even if we came up with a visibility check–it wouldn’t be hard–there’s the question of what someone would notice. Not see, but notice. I’m going to leave this as-is, but I expect that we aren’t finished with this element of our design.
UPDATE: I made a thread about this subject at the Interactive Fiction Community Forum.
looking into the distance
The next thing on our list is looking in a direction. If we “look north,” we want Inform to print a room description of the room to the north. If there isn’t a room to the north, we’ll need a message to handle that. Inform 7 is great about readability, so I’ll try to emphasize that feature here.
First, I’ve decided that I want to make our scope rule more restrictive. I’ll specifically designate verbs that will work. This is easy in inform. The language is “[action] is [whatever I want to call it].” We know we’ll be examining rooms and things in rooms, so we can start with that.
examining is possible from a distance.That’s pretty easy. We can prevent all other actions with a rule. Since the default “reaching into rooms” message is an “instead” rule, let’s jump in line with a “before” rule. That way, Inform will print only our custom messages.
before doing anything other than possible from a distance when the noun is not in the location:
if the noun is a room:
say "I'm just a small cat. I can't mess with a whole room all at once.";
otherwise:
say "I have to get closer to [the noun] before I can do that." instead.These texts will need some more work. Right now, we’re just trying to get things ready for describing things and places.
Now we can turn back to looking in a direction.
looking into the distance is an action applying to one visible thing.
understand "look [direction]" as looking into the distance.
looking into the distance is possible from a distance.We have an action and a command, but no action processing yet. What do we want this to do? We’ve already done a lot of work with examining rooms and printing locale descriptions. It seems like the best thing would be to redirect the command “look [direction]” to “examine [room]”. But those commands don’t seem very similar, do they? How to get from “[direction]” to “[room].”
This is something Inform 7 handles very well, actually. This is because there’s language for describing adjacent rooms. Also… to Inform 7, directions are nouns/things! Considering these two factors, we can put something like this together:
instead of looking into the distance:
let the scrutinized area be the room noun of the location;
if the scrutinized area is a room:
try examining the scrutinized area;
otherwise:
say "zork.".What just happened? In this construction, “noun” is the direction specified. The command “look north” would be parsed as “let the scrutinized area be the room north of the location.” But what if there’s no room? Our “otherwise” condition will handle that (again, “zork” is a placeholder). We’ll handle “examine [direction]” the same way. Now, I’ll put everything together in the examining rule:
carry out examining a room:
if the noun is the location:
try looking instead;
otherwise:
say "[description of the noun]";
say line break;
carry out the printing the locale description activity with the noun;
rule succeeds.I think we have everything in place to start building out rooms, so this is a good place for us to take a break. We’re going to have to make some design decisions about how to manage our room descriptions, because I see them changing more than once as the story progresses. Coupled with the descriptions for viewing rooms remotely, which may also change, things are going to get very complicated if we don’t have a good plan. I have some ideas, but I’m also open to the possibility that I might need a few attempts to get it right.
next
Next time, I’ll try to write at least one room description. Hopefully I can find a method that will make it easy (or easier, maybe) to manage multiple passages for the same locations and things.
Here’s a link to the folder where I’m storing source code for this project.
Here’s a link to today’s update. For best results, copy/paste into an Inform 7 IDE.
top expert 