First a disclaimer: I’m feeling a bit poorly at the moment, so I can only hope this post will be coherent. That said, on to my question.
I’m currently trying to channel categories of actions during specific scenes. During those scenes I want to restrict the player from acting on nonessential things and people.
For instance, we might have a duel between two naval officers, deadly swordsmen both. Now, during this duel, a wavering attention should be discouraged, but even the smallest detail of the enemy could be vital. In other words, I want to block off most actions having to do with the surrounding environment, while keeping the player and the enemy and anything they enclose remain valid options.
In other words, I’d love for a general definition similar to “if x encloses y”, but one that also applies if x is y, so that one could write
If the noun pertains to Sir John
and have it evaluate as true for Sir John, Sir John’s pitiless blue eyes, and Sir John’s deadly gleaming sword of stabby-stabby-kill.
Now. What’s the best, most general way of doing this? I can see how you do it through “to decide whether…” statements, but those tend to become pretty specific in their wording, which I’d prefer to avoid if possible.
Here’s how to do this with the basic parameters you mentioned and using a decide phrase:
To decide if (X - an object) pertains to (Y - an object):
if Y is X, decide yes;
if Y is part of X, decide yes;
if Y encloses X, decide yes;
decide no.
I’m not sure exactly what you mean by decide phrases being overly specific in their phrasing. This one doesn’t mention any specific objects at all and can also be used with any game object (including rooms), so hopefully it fits the bill!
Yeah, that would do it. I wrote some similar code, although yours was better thought-out.
I suppose my confusion stems from the fact that phrases like “enclosed by” is a lot more flexible than the result of the “to decide if…” phrase. I mean, if you were to write
say the list of things enclosed by Sir John
this would work, but
say the list of things pertaining to Sir John
wouldn’t work at all because the expression “pertaining” isn’t semantically recognized.
By the way, any reason we don’t write
To decide if (X - an object) pertains to (Y - an object):
if Y is X, decide yes;
if Y is enclosed by X, decide yes;
if Y encloses X, decide yes;
decide no.
? As far as I know incorporation is enclosure, or was there something about your logic that I overlooked?
Ah, I see. If you want that capability, you can use a relation instead:
[code]Pertainment relates an object (called X) to an object (called Y) when X is Y or X encloses Y or Y encloses X. The verb to pertain to (he pertains to, they pertain to, he pertained to, he pertains to) implies the pertainment relation.
When play begins: say the list of things that pertain to the player.[/code]
See 13.12 in the manual for more on this type of relation.
No, that’s better, and of course you can add other relationships as you need them.
EDIT: By the way, if you use the relation, you might want to consider whether you need it to apply to objects other than things (such as rooms). Setting up a relation such as this one between objects is more expensive than doing so between things.
Is it? I thought conditional relations weren’t expensive at all. Perhaps they take extra time, though. In that case, you can make it even faster by defining it as a relation between things and people.
Hm, could be–I’d assumed that they function as do other relations. But it would make sense too if they were really just more flexible conditions, and thus evaluated only when needed. In that case, using objects wouldn’t be more expensive except, as you say, in terms of speed–Inform would need to iterate over all objects in the game rather than just things or people. The speed probably isn’t too much too worry about unless you have tons of objects, though. Testing this kind of thing in Quixe or Parchment is a good way to see whether the speed hit is significant.
The calculated relation isn’t expensive at all – it’s just a plain function like the decide-if function shown up-thread, only its syntax is that of relations. Asking if “steely eyes pertain to John” is quick as the decide-if. But “the list of things pertaining to John” is, of course, a single loop.
It’s the storage relations that one might be careful of defining on the root Object, but even then, if it’s Glulx it’s likely not a problem anyway.
Very useful discussion, and a big thank-you to all (three) participants. As for glulx, I love that it exists, but I generally start out striving for code that would work on the z-machine.
(This isn’t because I necessarily want my game to be z8. Part of it may well be snobbery, but I have noticed that if I start out writing code in glulx, the result is often wasteful and, worse, incoherent. To me, the benefit of the z-machine restriction is that it counters the impulse to simply brute-force a solution.)
I’m still writing my WIP as if I had z-machine constraints, even though it’s too big for z8 already. I have a vague idea that I’ll trim it down later (after all, if Curses fits in z5, my tiny little thing OUGHT to fit!), but even if I don’t, I like having clean code.