[Inform] Ideas for new scope rules
Stuart Allen
>If the player is in a closed cupboard, he can reach anything on the
>floor and even on the shelves on the walls outside the cupboard,
>but nothing inside it. He also gets a full room description.
In this situation I would probably be inclined to make the cupboard a
separate location. You could also have an object that is the cupboard
so it may be manipulated from the room it is in, ie. opened, closed,
examined, having things put in it and taken out of it. When the player
enters it you could transfer any objects from within the object cupboard
to the location cupboard then back into the cupboard when they leave it.
I know it doesn't really get to the heart of the problem but it is a work
around.
>If the player is standing next to a closed and locked (and, I presume,
>transparent) car, he can turn the ignition key or change gears.
I also have all the verbs that involve touching an object check if it
has the attribute OUT_OF_REACH before it does anything else and display a
"You can't reach the blah blah from here." message even if it is in the
current location.
Your solution of new scope routines sounds impressive but I know next to
nothing about Inform so unfortunately I can properly appreciate it. :(
Regards,
Stuart.
Fredrik Ramsberg
> d91f...@ida.liu.se (FReDRiK RaMSBeRG (WILdcARD)) writes:
> > I would like to suggest a new scope system for Inform, where you have
> > "lookscope" and "touchscope".
> >
> > Lookscope would be everything inside the innermost closed,
> > non-transparent container containing the player. If the player is not
> > in such a container, that is the room.
> >
> > Touchscope would be everything inside the innermost closed container
> > containing the player. If the player is not in such a container, it
> > is the outmost open container or supporter. If the player is not in a
> > container or on a supporter, it is the room.
>
> Problem: If an object is out of reach, you really don't want it to be
> out of scope. The game pretends that out-of-scope objects don't exist
> at all. You want errors like
>
> > get ball
> The red bouncy-ball is out of reach.
>
> not "There is no such object here."
I agree.
>
> In other words, it would be bad to have two parallel scope systems.
I disagree. A verb that requires touching will give success if the
object is in touchscope, an out-of-reach-message if it is in lookscope
but not in touchscope, and a no-such-object-message if it is neither.
> You want the usual scope system, in which "scope" is "everything you
> can see", and then an intermediary layer between the parser and the
> object actions, which determines what's "available" for that
> particular verb-type.
>
> Oh, and don't restrict it to just "look" and "touch". The programmer
> should be able to extend it to "smell" or "magic-effect-range" or any
> other set of properties. All you really need is to specify a set of
> attributes to act as "smell-transparent" and "smell-open", or a
> property which computes same.
It's a good point, and I definitely think the programmer should be able
to do that extension, but my point is that the current scope system
works non-satisfactory for 95% of the verbs in the default grammar. The
system I am proposing would work properly for all but one or two of the
verbs in the default grammar, and most of the verbs that a programmer is
likely to add.
I can definitely see your point of view, and I hope my clarification can
help you see mine.
/Fredrik
(and _please_ mail me a copy of replies to this thread, since my news
server is dropping heaps of messages. Thanks.)
-
Andrew C. Plotkin
On Fri, 26 Jul 1996, Fredrik Ramsberg wrote:
> > In other words, it would be bad to have two parallel scope systems.
>
> I disagree. A verb that requires touching will give success if the
> object is in touchscope, an out-of-reach-message if it is in lookscope
> but not in touchscope, and a no-such-object-message if it is neither.
My Elegance Verifier is still flashing a red light. I wish I could be
more specific than that. Oh well.
Hm, the light just downgraded to yellow. This would look something
like
Verb "take"
* touchable -> Take
* noun -> CantReach;
where CantReach is an action that just prints "You can't reach X."
Ok, go write it. :)
> (and _please_ mail me a copy of replies to this thread, since my news
> server is dropping heaps of messages. Thanks.)
I tried to mail you a copy of my first message, but it bounced.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
John Wood
Curiouser and curiouser! I've just been reading Gareth Rees' tutorial,
and sure enough the biggest chunk of non-NPC-related "special-case" code
in "Alice" is to do with avoiding being able to touch things in the room
when on the armchair or mantelpiece. A little of this would have to
remain even with advanced "sense-scope" rules, but it would be
simplified quite a bit.
mbla...@flood.xnet.com (Michael Blaheta) wrote,
>Ach, I just got a flash of insight (not a very big one, but possibly
>useful): "transparent" is really "sight-transparent", while "open" is
>"touch+sight-transparent". An interesting rewrite of the scoping
>system might be as follows:
[snip]
This suggestion (I think) involves some pretty far-reaching changes to
the library; I'm not competent to judge it's worth, but somebody other
than me would certainly have to write it. I'm going to comment on the
simpler suggestion.
Andrew C. Plotkin <erky...@CMU.EDU> wrote,
>All you really need is to specify a set of
>attributes to act as "smell-transparent" and "smell-open", or a
>property which computes same.
and later,
>Hm, the light just downgraded to yellow. This would look something
>like
>
>Verb "take"
> * touchable -> Take
> * noun -> CantReach;
>
>where CantReach is an action that just prints "You can't reach X."
To have the verbs defined as above, you'd need
(a) One attribute for each sense ("touchable", "smellable", etc);
(b) One property to indicate transmission of each sense (e.g.,
"smell_transparent"), or else a single property and a set of defined
bitmasks for the senses;
(c) A routine (maybe "UpdateSenseScope"?) that gets called when the
parent of the player changes, OR anything is opened or closed, OR
probably some other stuff. This would update the sense attributes
according to the sense-transmission property(s) of the intervening
objects.
If you didn't want to use up these attributes you could use another
property instead, but the above verb syntax would have to change to:
Verb "take"
* scope=Touchable -> Take
* noun -> CantReach;
where the scope routine Touchable handles the messy stuff.
This alternative syntax has the advantage of not needing to cope with
all the tricky details of when to call the UpdateSenseScope routine
(which, because of different actors, is even more complicated than I
thought when I wrote the above).
I've been playing about with this last version in my lunchbreak, but
it's not working properly yet - if it does (or even if it doesn't but
I can't figure out why), I'll post the code for comments.
John
Andrew C. Plotkin
John Wood <jo...@elvw.demon.co.uk> writes:
> (c) A routine (maybe "UpdateSenseScope"?) that gets called when the
> parent of the player changes, OR anything is opened or closed, OR
> probably some other stuff. This would update the sense attributes
> according to the sense-transmission property(s) of the intervening
> objects.
I doubt this will work, unless you call it every single turn. Some
objects may undergo scope-altering changes at any time (say, a force
field that flicks on and off every five minutes, controlled by a
daemon.) These changes may be linked to nothing but a game-defined
global variable.
> If you didn't want to use up these attributes you could use another
> property instead, but the above verb syntax would have to change to:
>
> Verb "take"
> * scope=Touchable -> Take
> * noun -> CantReach;
>
> where the scope routine Touchable handles the messy stuff.
>
> This alternative syntax has the advantage of not needing to cope with
> all the tricky details of when to call the UpdateSenseScope routine
> (which, because of different actors, is even more complicated than I
> thought when I wrote the above).
That too.
I think you have to bite the bullet and adapt the library's
scope-iterator to deal with a given sense.
Fredrik Ramsberg
(Long article containing reworked suggestion follows...)
On Mon, 29 Jul 1996, John Wood wrote:
> Curiouser and curiouser! I've just been reading Gareth Rees' tutorial,
> and sure enough the biggest chunk of non-NPC-related "special-case" code
> in "Alice" is to do with avoiding being able to touch things in the room
> when on the armchair or mantelpiece. A little of this would have to
> remain even with advanced "sense-scope" rules, but it would be
> simplified quite a bit.
That's one important part of the concept, yes. I'm not sure how much of
my ideas that were obvious from my original description, but this is
one that was in it anyway; If you are sitting on a blanket on the
bed, you can still touch other things on the bed, but probably not
things on the floor and even more probably not things on the mantel-
piece.
John's and the previous suggestions have all been very interesting and
are definitely useful methods for extending and enhancing the library.
Also, they have indeed inspired and contributed to my suggestion at
the end.
Having said that, I must admit I don't think they should be
included _in_ the library from the start. Maybe they should be
available as a coolscope.h file or as part of a knowledge base on
Inform. And why not in the basic library? Here are my reasons;
My basic intentions with the suggestion of new scope rules, were these;
1. Make the library work better, thus making it sufficient for more
complicated games without major rewrites and extensions on behalf
of the game programmer.
2. Correct "bugs" in the current rules. I'm not sure if they are
conscious simplifications, but they do get strange effects.
3. Make as many verbs as possible work properly with the least
possible effort, thus making it more worth the time writing it.
This, in my experience, makes it _much_ more likely that it
actually gets done.
4. Keep the library and its usage as simple as possible, not building
a wall against non-programmers unless it's really necessary. Inform
is already considered rather programmer-oriented. Maybe the new
programmer's manual can help to make it more accessible, but there
is more to be done.
The suggestions I've seen are working against intention #3 and #4. If
you decide that you don't think they are important, then the following
suggestion may not interest you;
To check if something is in scope, the library always calls TestScope
(I'm not sure if this name is already used in the library, this is
just what I call it for now). Testscope allows a user-defined object
called "scopeobject" to decide if the object can be reached. If
it doesn't make a decision, the library relies on one of the scope-
rules; lookscope, touchscope and thinkscope (yes, this one is new).
(A bit of, untested unreliable possibly-mal-syntaxed, Inform code,
for anyone interested enough to read it. Should be thought of as an
example.)
[ TestScope actor verb object x;
if(scopeobject provides test) { ! Programmer has supplied an object
! for testing scope
x=scopeobject.test(actor verb object);
if(x==1) rtrue; ! The object is in scope;
if(x>1) return x; ! It isn't, and x contains the reason why
}
! If we get this far, the scopeobject didn't want to decide
! whether the object is in scope or not
switch(verb) {
Look, Listen, Smell: return Lookscope(actor object);
Consult, Answer, Ask, AskFor, Tell: Thinkscope(actor object);
default: return Touchscope(actor object);
}
];
As far as I can see, these are the library-defined verbs that may
possibly require different scope rules;
Touch, Look, Consult, Ask and relatives , Smell, Listen, Taste
I think the suggested solution would make the library behave the way
almost all programmers would want it to almost all of the time for
almost all of the verbs, and it would make it very convenient to
change the rules for any verb or group of verbs. All this without
much of a change to the grammar.
Also, you could let the scopeobject supply an "eachturn"-routine
to update lists of objects that should be in some special scope or so.
All of the suggestions that have appeared in this thread would make
useful extensions either in the scopeobject and/or the grammar, for
those that don't think the predefined rules are precise enough.
/Fredrik
(still kindly asking for a mailed copy of replies to the thread, since
my news server skips a lot, thanks)
-----------------------------------------------------------------------------
Fredrik Ramsberg, student at Linkoeping University
Hi-tech-mail: d91f...@und.ida.liu.se
-----------------------------------------------------------------------------
"What happens if a big asteroid hits the Earth? Judging from
realistic simulations involving a sledge hammer and a common
laboratory frog, we can assume it will be pretty bad."
rich...@msi-uk.com
In article <320012...@cosc.canterbury.ac.nz>, Greg says...
>
>Andrew C. Plotkin wrote:
>>
>> I doubt this will work, unless you call it every single turn. Some
>> objects may undergo scope-altering changes at any time (say, a force
>> field that flicks on and off every five minutes, controlled by a
>> daemon.) These changes may be linked to nothing but a game-defined
>> global variable.
>
>methods, so they can test the relevant condition
>dynamically.
>
>The way it's done in WorldClass is that every object
>has three methods for each sense, which determine
>whether the object can pass the sense "in" from
>the containing object, "out" to the containing
>object, and "across" between one contained object
>to another.
>
>There is one very general sensing routine which
>takes two objects and a sense, and works its way
>up and down the hierarchy calling the relevant
>methods to decide whether the given sense can
>get from one to the other.
i was just about to post proposing a similar system for inform, although
without the tri-directional refinement (how often would sense-passing not be
symmetrical?).
any system should be object-oriented (ie you don't want a special `scopeobject'
to handle it), and needs to traverse the hierarchy in a logical order (for
`active' actions like take, from the actor to the object; for `passive'
actions like smell, from the object to the actor).
if it wasn't for the last requirement, i was wondering if `react_before' could
be used (maybe gareth's `alice' example does use this):
react_before
[; Take: if ((self in mantelpiece) && (actor notin chair))
"You can't reach it from there.";
],
other parts of this thread have suggested a `thinkscope' concept for actions
like tell, look up, etc; but i think such actions typically have their own
scope= tokens anyway.
so, a `scope_filter' property in inform would return 0 (false) to indicate that
the object is `scope-transparent' for the action, 1 (true) to indicate that the
object is `scope-opaque' but that the library shouldn't print anything, and
some other value (-1? 2?) to indicate `scope-opaque' and make the library print
a default message.
a function ScopeNeeded(action) might be useful, returning values like TAKE_SCOPE,
SENSE_SCOPE, or refinements (SMELL_SCOPE?).
for example:
Object blanket ...
with scope_filter
[; Take: if ((actor in self) && (noun notin parent(self)))
{ print_ret "You can't reach ", (the) noun, " while sitting on ",
(the) self, "."; }
],
this would of course be fairly expensive at run-time.
-- richard
John Wood
Greg Ewing <gr...@cosc.canterbury.ac.nz> writes:
> The way it's done in WorldClass is that every object
> has three methods for each sense, which determine
> whether the object can pass the sense "in" from
> the containing object, "out" to the containing
> object, and "across" between one contained object
> to another.
Interesting...while I was experimenting with this, I decided I needed
"in" and "out", but assumed it could always pass "across".
It was getting too much work for the individual objects, though, which
rather defeated the purpose - so I gave up before I got it working in
all cases. I think Andrew's right that it needs to be done at the level
of the library's scope-iterator (or something) if it's to actually ease
programming. Unfortunately, that puts it into the "advanced Inform"
category so far as I'm concerned, so I'll wait for somebody else to do
it... 8-b
John
Greg Ewing
Probably not often, but it could happen.
E.g. you're in a cubicle with a window made of half-silvered
glass. The cubicle is dark, the room outside is light.
You can see out, but people outside can't see in.
Greg
Greg Ewing
John Wood wrote:
>
> Interesting...while I was experimenting with this, I decided I needed
> "in" and "out", but assumed it could always pass "across".
Well, you might implement room full of fog as an object which
cannot pass sight "across".
I don't know whether it needs to be as complicated as
the WorldClass system. I'm just citing it as an example
of a system that (presumably) works and could perhaps
be used as a model.
> I think Andrew's right that it needs to be done at the level
> of the library's scope-iterator (or something) if it's to actually ease
> programming.
Another aspect of the WorldClass system that eases
programming is that it first maps actions to senses,
then tests the propagation of senses. So objects
only have to have propagation code for each sense,
rather than for each action.
Perhaps the scope routine for an action wanting sense
propagation tests could call a library routine
Sensable(senses) where senses is a bit mask made
up of SENSE_SIGHT, SENSE_TOUCN, etc. This routine
would walk up and down the object tree from the actor
to the noun calling each object's Passes(sense) method.
This method would return a bit mask made up of
PASS_IN, PASS_OUT and PASS_ACROSS.
Inform isn't my main language, so I'm not sure
if what I just said makes sense or not. If it
does, it would solve the problem without having
to make any major changes to the existing library
code - just the addition of the Senses() routine,
and default Passes() methods for the relevant
classes.
It would also be easily extended to handle new
senses by defining new SENSE_x constants.
Greg