I7: Familiarity and non-things

Authoring Inform 7
1

I’m working on a game which uses Eric Eve’s Conversation Package (and its constituent extensions). Epistomolgy (which is indirectly included as part of Conversation Package) keeps track of which things are “familiar” (either because the player has seen them or because the author has manually set them to “familiar”).

The game will include a number of liquids; these will be implemented not as things in their own right, but rather as a kind of value which is associated with the container in which they reside. (This idea, and some of the other aspects of liquid handling, are cribbed from Emily Short’s Measured Liquids, although I’m not actually including the extension because in many respects it is far more sophisticated than I need). The main reason I’m implementing liquids in this way is because I want to have two kinds of containers, one of which (what Measured Liquids calls a liquid source) never gets emptied. Thus, to illustrate, I might have a small bottle with a liquid of water; a glass, with a liquid of the null liquid (whch will appear to the player as empty); and a huge cauldron (defined as a liquid source) whose liquid is soup. If the player calls for an action (for example pouring) which transfers the water from the bottle to the glass, the liquid of the glass will be set to “water” and the liquid of the bottle will be set to the null liquid. On the other hand, if the player does something to transfer soup from the cauldron to the glass, the liquid of the glass will be set to soup, and the liquid of the cauldron will still be soup. This is reasonably straightforward to do by implementing liquids as a property of the container, but my sense is that it would be far more complicated – if possible at all – to do it with the liquids implemented as objects in their own right. (I don’t need to keep track of absolute or relative amounts; a given container will either appear to the player as full of a particular liquid or as empty).

All of this is, of course, behind the scenes. From the player’s perspective, liquids need to appear as objects. Although I haven’t yet worked out all the details, I think I can handle most of that with appropriate rules for printing names of the containers, “understand” statements, and rules for carrying out and reporting actions involving manipulation of liquids.

The problem that I’m running into right away, however, is that, as far as I can tell, Epistomology defines the concept of “familiar” only with respect to things – which means that since liquids will not be things, I can’t designate them as potential subjects for conversation. (Actually, the problem may be deeper than just familiarity; I’m not sure if kinds of value (as opposed to things) can be subjects of conversation at all in the system I’m using). I need to be able to have a player “ask the Chef about the soup,” for example.

Any suggestions would be greatly appreciated.

Robert Rothman

2

In obsessing about this some more, I may have come up with the germ of an idea. Before spending a lot of time working out the details, I’d like to toss the idea out and see how more experienced I7 writers react to it (or, alternatively, if somebody can suggest a different – and hopefully simpler – approach).

Basically, the concept would be that for each non-null liquid I create as a kind of value, I would create a corresponding thing. Thus, if I create vodka as a kind of value which could be designated as “the liquid” of a particular container, I would also create a thing called vodka-thing. I might use a table to associate each liquid with its corresponding thing (the same table could also keep track of other attributes, such as appearance, taste and smell, for each liquid). The liquid-things would remain forever off-stage, but their existence means that they could be designated as familiar and be subjects of conversation.

It could get a little complicated. For example, if a player types “pour vodka into glass” I7 would have to understand “vodka” as referring to a container whose liquid is vodka (i.e., from the player’s perspective, the bottle which currently contains the vodka). On the other hand, if he types “Ask bartender about vodka” it would have to understand “vodka” as the off-stage (but nonetheless familiar) vodka-thing.

Is this idea totally off-the-wall?

Thanks.

Robert Rothman

3

That idea is what I was going to suggest.

4

I was trying to think of a clever way to automatically generate the things associated with each kind of value. But I couldn’t come up with something that compiles. Is it possible to make something like this work?

[code]Include Epistemology by Eric Eve.

Liquid is a kind of value. Water, soup, and vodka are liquids.

Abstraction is a kind of subject.

Every liquid has an abstraction.

When play begins: showme the abstraction of water.[/code]

5

If you’re not actually including Measured Liquids, but writing your own version, you might as well make liquids into full-fledged things (or subjects). There’s no reason the contents property of a vessel has to be a kind of value.

6

The problem I have with implementing liquids as things is that it gives me headaches if I want to be able to pour soup from the cauldron into the bowl, with the result that both the bowl and the cauldron then have soup in them. I wouldn’t know where to begin with this approach. Any suggestions as to how to do that are welcome.

Thanks.

Robert Rothman

7

No, no, what I meant is, you have a “contents” property of the vessel, and you set that to the liquid. The liquid is not actually present or in scope (unless you put it there). Just like if you were using a kind of value for the property.

Although you could probably use Conditional Backdrops to do it…

8

Thanks, Capkimee. I had not realized that it was possible to designate a thing as a property of another thing in that way. It sounds like that would make things easier in a number of respects.

Robert Rothman

9

If you go with capmikee’s model, the parsing is then not too hard to set up. You ensure that the cauldron responds to “soup” and “cauldron of soup” when it contains soup. You also ensure that the printed name is “cauldron of soup”.

If the player types “x soup”, Inform’s disambiguator will then be able to print “Which do you mean, the bowl of soup or the cauldron of soup?” without further effort. You have to test this sort of thing a lot, and there’s usually some tuning, but you can make it work.

10

There used to be a Firesign Theater routine called “How Can You be in Two Places at Once When You’re Not Anywhere at All?” It sounds like the approach suggested by Capmikee effectively achieves just that – the soup (or whatever) can be “really” off-stage (i.e., not anywhere at all) and yet, from the player’s perspective, it can be in two places at once (the bowl and the cauldron). Thanks again to all – I think I will try to use that approach.

Robert Rothman

11

I hate to be a pest, and truly appreciate everybody’s generous help, but almost right off the bat I’m running into a problem with implementing this.

[code]“Liquid Assets” by Me

Include Conversation Package by Eric Eve.

A liquid is a kind of thing. The indefinite article of a liquid is “some”. Null liquid is a liquid.
A fluid container is a kind of container.
A fluid container has a liquid called fluid contents. The fluid contents of a fluid container is usually null liquid.

After printing the name of a fluid container:
stop.

Rule for printing room description details of a fluid container (called vessel):
If vessel is dry:
stop;
If vessel is wet:
Say " of [fluid contents of vessel]".

After printing the name a fluid container (called vessel) when taking inventory:
If vessel is dry:
stop;
If vessel is wet:
Say " of [fluid contents of vessel]".

After deciding the scope of the player:
Repeat with Vessel running through the list of visible fluid containers:
If the fluid contents of vessel is not null liquid:
Place the fluid contents of vessel in scope.

Definition: A fluid container is dry if its fluid contents is null liquid.
Definition: A fluid container is wet if it is not dry.
Definition: a fluid container is empty if it is dry and the number of things contained by it is 0.

Kitchen is a room.

Vodka is a liquid. Vodka is familiar. The description of vodka is “It is clear and colorless, to the eye indistinguishable from water.”
The printed name of vodka is “clear colorless liquid”.

A bowl is a fluid container in kitchen. The fluid contents of the bowl is vodka.
A spoon is in kitchen. A glass is a fluid container in kitchen.

[/code]

Everything worked fine (so far) until I added the “After deciding the scope” rule. What I’m trying to do is to set it up so that the player will be able to examine a liquid, independent of the container in which it appears to reside. Since the liquid is “really” offstage, I want to place it in scope manually to allow the player to examine it. (Eventually I’ll have to deal with interacting in ways that require it to be touchable as well as visible, but I’m taking this one step at a time).

It compiles OK, but as soon as I try to do anything I get a “too many activities” run-time error, followed immediately by about a gazillion “memory ran out” errors. My guess is that the routine which determines visiblity (which is called by the second line of the rule) invokes a “deciding the scope” rule; that, in turn, causes my “after the deciding the scope” rule to come into play – which in turn calls the visibility rule – and so the logic winds up chasing its own tail. What I don’t know is how to avoid it. I’m sure its something that’s pretty basic.

Any assistance would be appreciated.

Thanks.

Robert Rothman

12

I don’t know if this is the best way, but I put a flag in the “after deciding the scope” rule to check whether that rule is already running, and changed the header so it doesn’t run when the flag is set:

Fluid-checking is a truth-state that varies. Fluid-checking is usually false. After deciding the scope of the player when fluid-checking is false: Now fluid-checking is true; Repeat with Vessel running through the list of visible fluid containers: If the fluid contents of vessel is not null liquid: Place the fluid contents of vessel in scope; Now fluid-checking is false.

Seemed not to crash. Don’t know if it introduces other bugs.

(For your amusement, here is the transcript of my attempt to test this:

[rant]

[/rant]

You know you aren’t paying attention when you’re having trouble with the nouns while you’re looking at the source text.)

13

There are a few ways to do this. If you don’t need to do any telescopic interactions (such as examining liquids via video monitor), then you can probably get away with doing something like this in your scoping rule: “repeat with Vessel running through the fluid containers enclosed by the location”.

Otherwise, you can just check the visibility of liquids at an appropriate point and cache it in a constant list for use during scoping:

[code]The currently visible liquids is a list of objects variable.

After reading a command:
populate the visibility list;
continue the action.

To populate the visibility list:
now the currently visible liquids are {};
repeat with vessel running through the list of visible fluid containers:
add vessel to the currently visible liquids.

After deciding the scope of the player:
Repeat with Vessel running through the currently visible liquids:
If the fluid contents of vessel is not null liquid:
Place the fluid contents of vessel in scope.[/code]

Edited to add: Caching visible liquids in a constant list might also improve performance if you are often needing to check visibility. As you’ve discovered, each use of the term “visible” causes Inform to retest visibility for all objects of the class you’re interested in.

–Erik

14

Thanks to all. However, as I think about this some more, I realize that I may have a more fundamental problem.

Ultimately, for this to work, I’m going to need a series of “understand” statements which will allow I7 to understand a command which uses the noun “soup” (for example) to refer not only to the soup itself, but to any in-scope fluid container for which soup is the fluid contents. The documentation gives some good examples for “understand” statements which allow things to be referred to by their properties. The examples, however, seem to cover either/or properties and “kind of value” properties; I can’t seem to figure out how to apply the concept where a property of a thing is itself another thing. I’ve played around a little with trying to give the property a name (so that I can use a statement like “Understand the liquidity property as referring to a fluid container”) but either that’s not possible for this type of property or I just haven’t managed to figure out the correct syntax.

The other approach I’ve thought about is trying to set up a relation between the various containers which might hold a liquid and the liquid itself. That approach seems to make things, if anything, more complicated.

I’m beginning to wonder if I’ve bitten off more than I can chew (or, since we’re in the liquid world, sipped more than I can swallow) but if anybody can put me on the right track I will be forever grateful.

Robert Rothman

15

Does this work?

Filling relates a liquid (called filler) to a fluid container (called receptacle) when filler is the fluid contents of receptacle. The verb to be filled with implies the reversed filling relation. Understand "[something related by reversed filling]" as a fluid container.

Add this to your code (with one of the fixes for deciding the scope) and “take vodka” gets the bowl. Unfortunately, now “x vodka” yields the wrong result; “Does the player mean examining a liquid: it is very likely.” seems to fix that in this case, but more bugs may be waiting.

Anyway, I think the trick you’re looking for is to define a relation that expresses a condition (as in 13.12) and then use that in your understand token.

16

Thanks, Matt. I had been struggling (without success) with trying to define this kind of relation manually, and couldn’t figure out how to tie it in to the “fluid contents” property.

I need to do some experimentation to be sure that this works when more than one container holds the same kind of liquid (i.e., that it creates a “one relates to various” type relation when necessary), but it sounds like the right track.

I’m not troubled by the need to use a “does the player mean” statement so that “examine” points to the liquid, and not the container. I had pretty much taken for granted that I will eventually need a series of such statements, which would be action-specific; the whole point is that for some actions I want to point to the container, others to the liquid, but initially I need the noun to be understood as both.

17

Also, make sure you catch attempts to touch a liquid so the player doesn’t get a “you can’t reach into nothing” error.

In my own work, I avoid this using one of two methods:

Make the liquid a conditional backdrop:

[code]Use conditional backdrops by Mike Ciul

Backdrop condition for a liquid (called stuff):
If stuff is the fluid contents of a fluid vessel enclosed by the location, it is present.
[/code]

Make the examining verb work with things that aren’t really there:

[code]Use Remembering by Aaron Reed

Instead of remembering a liquid:
say “[description of the noun]”
[/code]

Neither of these is tested.

18

The route that I 've started to go down was that, except for “examine” (where I want the player to be able to examine a liquid and its container separately), I would set up rules for all other actions so that they work properly when the subject (or object, as the case may be) is the container rather than the liquid itself. A “does the player mean” rule would instruct the parser to interpret the player’s command as referring to the container. (Incidentally, this turned out to be more difficult than expected; the standard “does the player mean” mechanism doesn’t properly handle the case where there are available two containers with the same liquid. I was able – I think, subject to some further testing – to make this work properly using Jon Ingold’s Disambiguation Control).

However, you’re right that “touch” may be a special case. Like “examine,” the player should ideally be able to touch either a liquid or its container, each as a separate item. However, unlike “examine,” it requires that the objects be reachable as well as visible. I need to think about this some more. I may take decide to the lazy man’s way out and allow only the container to be touched (i.e., treat touching the same way as other non-examining actions); while not really defensible from a “realism” perspective, handling it this way wouldn’t really affect the game-play.

Thanks.

Robert Rothman