I’ve been using code adapted from the Beneath the Surface example for modelling the concept of things being underneath other things, and what I like most about it is that I just need to write “Y is in the lab. X is under Y” to place something under something.
However, it also has some disadvantages, most notably that the item is not in any room, which means it gets listed amongst the off-stage items in the index.[1] Of course, that also means asking “if X is in the lab” will not work… which I’m pretty certain will cause problems with my hinting system.
I know there’s also Eric Eve’s Underside extension. Given that it simulates the underside with a container, clearly it solves the issue of the underlying items not being in any room. However, it loses the nice means of specifying where an item is.
Is there a good way to get the advantages of both approaches? It would be nice if there were a way to just declare that “underlying” is a spatial relation like containment et al, but I guess that’s too much to ask for…? A way of using Underside while still being able to use the relation for placement would also be fine.
Note: While it would be nice for the index to list the items as being in the room, it’s not the highest priority. ↩︎
Because the Underside extension represents X being under Y by Y being a subkind of container and X being Y, you just need another alias for (reversed) containment.
The verb to underlie means the reversed containment relation.
The verb to be beneath means the reversed containment relation.
You’ll have to remember that these things aren’t really distinct from containment and make sure yourself that you use these verbs only with undersides and not with plain containers.
Lab is a room.
An underside is a kind of container.
An overlying-supporter is a kind of supporter.
All overlying-supporters incorporate an underside (called its underbelly).
An overlying-container is a kind of container.
All overlying-containers incorporate an underside (called its underbelly).
An overlying-thing is a kind of thing.
All overlying-things incorporate an underside (called its underbelly).
[ repeat as necessary for vehicles, devices, backdrops... ]
The chair is an enterable overlying-supporter in the Lab.
The dust bunny is in the chair's underbelly.
Instead of The dust bunny is in the chair's underbelly. you could do:
overlying relates one thing to various things.
The verb to be over means the overlying relation.
The verb to be beneath means the reversed overlying relation.
After starting the virtual machine:
repeat with item running through things begin;
repeat with thing-underneath running through things that are beneath the item begin;
now the thing-underneath is in a random underside incorporated by the item;
end repeat;
end repeat.
The dust bunny is beneath the chair.
But you’d have to remember that there’s nothing maintaining the overlying relation and you couldn’t rely on is over or is beneath in your rules or phrases: you should use them only in your initial assertions.
What I’d really want is to do it in assertions. This is a workaround because I can’t. So I arrange the closest equivalent I can and get the work done beforewhen play begins is followed. Now we know that anywhen play begins rules are free to use Underside’s to be under verb, even if I declare it with first when play begins, having forgotten about all this. I think I’m less likely to make the equivalent error with after the virtual machine. If it comes at no cost, when I perceive an improved chance of avoiding trouble, I take it.
Hmm… is there any way to arrange for now X is under Y to be an error while still accepting it in structural assertions? If that’s possible, I could define a move X under Y phrase.
Of course, it’s just better if I can’t accidentally use the wrong form to move something under something else.
I’m not sure if I even need to move something under something else though. I’d still need to update the relation when something is put into or taken from an underside, but that doesn’t seem like too much work, as I just need After taking something from an underside and After inserting something into an underside.
For these reason, I would strongly recommend Eric Eve’s Underside as was originally suggested. You seem to be trying to recreate functionality that extension already has, along with other bits that you might need but haven’t discussed here. (For example, the latest version automatically handles situations where the player picks up something that has something beneath it.)
Note that you still can’t assert “X is under Y” at the outset, you have to write "X is in (name of underside of Y). You can write move the ball under the bed. but if you word it incorrectly:
Using this extension, you do indeed get an error.
Problem. You wrote ‘now the ball is under the bed’ : but this is not something I can make true with ‘now’, because it is too vague about the underlying cause which would need to be arranged.
Also, as you can see, light transmission is [sort of] taken care of. [Edit:] Okay, not completely. Once you’ve looked under the bed, it no longer blocks out light, because the underside is now open. Authors dealing with light will still have to fiddle with that depending on their needs.
I think you misunderstood something somewhere along the way. I’m looking for ways that I could use Underside without losing the advantages of my current approach based off the mentioned example from Writing with Inform. One such way (perhaps the only one?) is to use the relation for assertions and conditions, and move the objects to the underside when the game starts. But if I want to use the relation for conditions, it needs to be kept up-to-date as things change, which leads to the two rules mentioned in my previous post.
What about pushing something that has something beneath it to another room? (I might not have the latest version; I’ll go check.)
EDIT: Underside doesn’t handle this. It’s not a problem though – adding a rule for it is easy.
I have something working so I’m going to mark this as solved, though I did add the after taking/inserting rules that I mentioned earlier so that the relation is kept up-to-date during play. I haven’t tested extensively if that works correctly, but I’ll figure it out.
One last note in case someone else finds this page and wonders why After taking something from an underside doesn’t compile, you need to add the following 3 lines of code to make it work:
The taking action has an object called previous locale (matched as "from").
Setting action variables for taking:
now previous locale is the holder of the noun.