Thoughts on Scope (from the 'Design Pattern' thread)
Lucian Paul Smith
After reading Marnix's 'Design Pattern' post, I looked at the Patterns
Home Page (http://st-www.cs.uiuc.edu/users/patterns/patterns.html) and my
imagination was fired. I got to thinking about scope, and my
dissatisfaction with the way things stand now.
Currently, in Inform (and presumably TADS as well, though I really don't
know), an object is 'in scope' if it is within a 'line-of-sight' of the
player. If you need to manipulate an object that is not in a line of
sight, you need to mess with scope. Conversely, if something _is_ in
your line of sight, but you shouldn't be able to manipulate it, you need
to do other programming tricks.
I think, ultimately, that 'scope' tries to do more than it should. It is
too broad a concept to work consistently well, although it does tend to
work consistently decently.
At one point, I read someone's post proposing a set of six different
'scopes': see_scope, smell_scope, hear_scope, taste_scope, touch_scope,
and think_scope. This, I think, is too far to the other extreme--it is
too complex to easily implement.
Instead, I propose three different 'scopes': a passive scope, an active
scope, and a concept scope.
An object would have 'passive scope' if it could interact with the player
with the player remaining passive. The player could examine, listen to,
smell, or talk to (by default) an object within 'passive scope'.
An object would have 'active scope' if the player could interact with the
object in some active way. The player could manipulate, pick up, etc.
(by default) any object within 'active scope'
An object would be in 'concept scope' if the personna could think about
it, and discuss it with others. The player could as 'What is a ...', or
'Tell so-and-so about the ...' if an object was within concept scope.
Different things would then fit logically and consitently into these
three categories. Any normal object (say, a ball) would, upon being seen
by the player, be put within passive, active, and concept scope. Trees
on a distant mountain, once seen would be put into passive and concept
scope, but not active scope. A telephone could put the person on the
other end into passive scope, but not active scope. If the person was
not already in concept scope to begin with, the player might not be able
to dial their number!
This would help the library with default responses, too. If all objects
were put into concept scope when first encountered, and never removed,
the library could, like TADS, say "I don't know what you're talking
about" to both unknown words and items not in concept scope. It could
say "You left the silver key on the dresser" when the player tried to
'Unlock door with silver key', but forgot to pick it up when they found it.
Items could exist only as concepts, as appropriate to the setting. A
priest might know about 'God', 'life', 'religion', etc. An architect
might know about 'buildings'.
In my 'Comp96' game, all of the game objects have blurbs written on them,
giving the player more information about that game. However, if a player
typed "READ BLURB" I didn't want the game to say "which blurb do you
mean, the blurb on Alien Abduction, the blurb on Aayela, the blurb
on...", etc. ad nauseum. Instead, I implemented the _concept_ of a blurb
as a static concealed object in the room. When refered to, the game
simply responded, "All the games have blurbs on them. I'm afraid you'll
have to be more specific." Had the idea of 'concept space' been a part
of Inform, this would have been easier to implement, and probably more
intuitive, as well.
The nickel in 'Lost New York' would start out, when seen, in 'concept'
and 'passive' scope. In this way, the author wouldn't have to code for
every possible way to interact with the nickle ('Touch nickle', 'Put
nickle in bucket', 'Taste nickle', etc.), but doing the correct series of
actions would put the nickle into active scope.
One could also implement a way to override the standard response, if a
player tried to interact with an item not in active scope--"The trees are
a long ways away", "The nickle is at the bottom of the grate, and you
can't reach it.", "'buildings' are just a concept."
Another concept I would like to add to this discussion is that of
'channels'. I would define a 'channel' as the sense through which a
particular item can interact with a passive player. The normal channels
would be sight, sound, and smell. A bird in a tree would have the sight
and sound channel open, but not the smell (unless, say, the player was a
cat.) A radio in the next room (a la 'Curses') would have the sound
channel open, but not sight or smell.
I think Graham is headed this way with the most recent release of the
Inform library. In it, he allows for the player to be in a container in
a room, and for him to interact reasonably with items still in the room.
If the container is transparent, the player can look at them and listen
to them, but not touch them or interact with them. If you'll notice,
what has happened is that he has differentiated between items in 'active
scope' and items in 'passive scope'.
I want this capability, too! I want to be able to put an item out of
reach of the player, but still examinable, and not have to mess with
kludgy scope rules!
Anyway, this is _way_ too long already, so I'll stop. Any comments?
-Lucian
Andrew Plotkin
Lucian Paul Smith (lps...@rice.edu) wrote:
> Currently, in Inform (and presumably TADS as well, though I really don't
> know), an object is 'in scope' if it is within a 'line-of-sight' of the
> player. If you need to manipulate an object that is not in a line of
> sight, you need to mess with scope. Conversely, if something _is_ in
> your line of sight, but you shouldn't be able to manipulate it, you need
> to do other programming tricks.
> I think, ultimately, that 'scope' tries to do more than it should. It is
> too broad a concept to work consistently well, although it does tend to
> work consistently decently.
> At one point, I read someone's post proposing a set of six different
> 'scopes': see_scope, smell_scope, hear_scope, taste_scope, touch_scope,
> and think_scope. This, I think, is too far to the other extreme--it is
> too complex to easily implement.
> Instead, I propose three different 'scopes': a passive scope, an active
> scope, and a concept scope.
In general, if you can think of three of something, someone will want
more. There must be some way for the author to define more scopes. Then
you can have a fairly minimal library which can easily be twiddled.
(For example, is your idea of concept-scope conflating things *you* know
about with things that the NPC you're talking to knows about? There will
be situations where these have to be different. Or maybe not, but you can
think of something else. Entries in an encyclopedia are the classic
example of a special-use scope.)
[long set of ideas snipped]
These are all good. Some games would make good use of some or all of them.
However, I don't want to see a large library addition which handles 90% of
the cases. We *already* have a system which handles 90% of the cases.
> I think Graham is headed this way with the most recent release of the
> Inform library. In it, he allows for the player to be in a container in
> a room, and for him to interact reasonably with items still in the room.
> If the container is transparent, the player can look at them and listen
> to them, but not touch them or interact with them. If you'll notice,
> what has happened is that he has differentiated between items in 'active
> scope' and items in 'passive scope'.
Right. However, to continue my attitude from above, I am still undecided
whether I like this change. I haven't tried to use it; when I do, I will
decide whether to use it as-is or patch it out (effectively returning to
an earlier library version.) It may not be what I want in my game, and any
library change of this magnitude is going to screw up some of my existing
knowledge of Inform. It may not be worth it. (Or it may be. Like I said, I
haven't tried to use it.)
> I want this capability, too! I want to be able to put an item out of
> reach of the player, but still examinable, and not have to mess with
> kludgy scope rules!
It is convenient that, right now, "examine" is the *only* verb that applies
to out-of-reach objects. (Well, and "ask npc about x", but this is a rare
case and really kind of different from scenery.) 95% of the out-of-reach
scenery objects you want can be done like this:
Class distantthing
with before [;
Examine: rfalse;
default: "That is out of reach.";
],
has scenery;
Object sky
class distantthing,
with description "It's big and blue";
(Or maybe toss in another property for the "That is out of reach" line, so
that it can also be overridden easily.)
I'm not trashing your proposal; I'm pointing out that the existing scope
system, while not super-generalized, handles a great deal of stuff
*without* explicit use of scope rules, and without even requiring a lot of
typing.
I also realized (re-reading) that I'm slightly off-track, because I'm
talking about library additions and you're talking about a conceptual
approach. I think the points apply, though.
And as long as I'm changing my mind: the within-reach change in the new
Inform library really has nothing to do with *scope*; it's more like
*channels* as you described them. Things you can see but not touch, smell
but not see, hear but not take, etc, etc are *all* in scope.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Dan Shiovitz
In article <5kvqhg$olm$2...@joe.rice.edu>,
Lucian Paul Smith <lps...@rice.edu> wrote:
[some good stuff deleted]
>Anyway, this is _way_ too long already, so I'll stop. Any comments?
As far as I know, the definition of scope in an i-f game is "the set
of objects I can manipulate". What we'd really like is for each verb
to have an associated function, and to determine if that object is a
viable choice for that particular verb, we see if that function
returns true for that object. But we don't want to do it that way.
For one thing, we'd be repeating code a lot of the time: most verbs
require the object to be within reach distance of the player, so each
function would have to test that. As a compromise, we divide our
tests into two parts. A "scope" part, to see if the item fills the
general conditions for being the object of the verb, and some other
part that sees if the object's specific situation. As an example, a
rock is takable if it fills both the general condition of being within
reach distance of the player, and the specific condition of being
light enough to pick up.
I'm sure you're probably thinking that these are pretty arbitrary
distinctions. Yeah, I think so too. There's no particular reason why
we can't add a weight_scope, and require that objects be light
enough to fit into that before they can be used by the take verb. The
reason why we *don't* do this (and probably shouldn't) is that most
verbs don't care about the weight of an object. In fact, take is
pretty much the only one that does (and the verbs that require take,
like put). So there's no code reuse benefit from creating a
weight_scope, and you might as well just keep the testing completely a
part of the take verb itself. I also don't think there's any reason
then to distinguish between a "scope" and a "channel".
So what does this mean in terms of actual library interpretations?
Well .. one thing is that you'll want to let players create their own
scopes. This isn't that hard to do, as a "scope" as I've used it is
just a function that takes an object (and perhaps an actor) and
returns true if the player (or the actor) can manipulate it. The
moderately difficult part is making it easy for the author to add a
scope to an verb, once they've created the scope, and automate the
game's checking of the new scope once it's been added. WorldClass
does a good job of this; I'd suggest people look it up if they're
interested. To add a new scope, you just add it as a method to the
object class, and then each verb has a list of scopes it takes,
something like:
scopes = [&seeScope &touchScope &xyzzyScope]
Oh, and it's nice to be able to distinguish between the scope of
direct and indirect objects. To "ASK FOO ABOUT BAR", FOO has to be in
sight and sound scope, but BAR just has to be in concept scope.
The other part is defining default scopes to be distributed in the
main library. Again, scopes exist solely to enable code reuse. The
only scopes I can think of that are useful to several verbs are sight,
touch, concept, and perhaps sound.
If scope is handled mostly automatically and easy to set up, I don't
see any reason why it should be confusing/difficult for novices or
excessively encumbering for advanced programmers. Again, I'd suggest
the WorldClass model as a vague guideline, though it's more
complicated in some respects that I'd like.
>-Lucian
--
dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
slightly lost author/programmer in a world of more creative or more
sensible people ... remember to speak up for freedom because no one else
will do it for you: use it or lose it ... carpe diem -- be proactive.
my web site: http://weber.u.washington.edu/~scythe/home.html some ok stuff.
James Cole
scy...@u.washington.edu (Dan Shiovitz) wrote:
>In article <5kvqhg$olm$2...@joe.rice.edu>,
>Lucian Paul Smith <lps...@rice.edu> wrote:
>[some good stuff deleted]
>>Anyway, this is _way_ too long already, so I'll stop. Any comments?
>
>As far as I know, the definition of scope in an i-f game is "the set
>of objects I can manipulate".
I'd extend this definition to "the set of objects, for each sense, that are
detectable". There is a scope of objects that you can see; a scope of objects
that you can get/touch, and so on for each sense you want to include. You can
look at something if it is in visual scope, but take it only if it's in
get/touch scope. An example of this is an object inside a glass jar. This is
also pretty much the general approch WorldClass takes (as you get into later).
>What we'd really like is for each verb
>to have an associated function, and to determine if that object is a
>viable choice for that particular verb, we see if that function
>returns true for that object. But we don't want to do it that way.
>For one thing, we'd be repeating code a lot of the time: most verbs
>require the object to be within reach distance of the player, so each
>function would have to test that. As a compromise, we divide our
>tests into two parts. A "scope" part, to see if the item fills the
>general conditions for being the object of the verb, and some other
>part that sees if the object's specific situation. As an example, a
>rock is takable if it fills both the general condition of being within
>reach distance of the player, and the specific condition of being
>light enough to pick up.
>
>I'm sure you're probably thinking that these are pretty arbitrary
>distinctions. Yeah, I think so too. There's no particular reason why
>we can't add a weight_scope, and require that objects be light
>enough to fit into that before they can be used by the take verb.
>The reason why we *don't* do this (and probably shouldn't) is that most
>verbs don't care about the weight of an object. In fact, take is
>pretty much the only one that does (and the verbs that require take,
>like put). So there's no code reuse benefit from creating a
>weight_scope, and you might as well just keep the testing completely a
>part of the take verb itself.
I think that's the wrong way to think of it. Something like weight really has
nothing to do with scope; it's more a restriction or condition.
[...]
>The other part is defining default scopes to be distributed in the
>main library. Again, scopes exist solely to enable code reuse.
I know what you're saying, but I think you're thinking of scope in the wrong
way. Everything must have some sort of scope, whether it's determined in an
object's associated function or more generally in a verb. How else could you
tell if the player can see an object?
[...]
---------------
James Cole
jrc...@ozemail.com.au
Dan Shiovitz
In article <3376f382...@news.netspace.net.au>,
James Cole <jrc...@ozemail.com.au> wrote:
>scy...@u.washington.edu (Dan Shiovitz) wrote:
[..]
>>The reason why we *don't* do this (and probably shouldn't) is that most
>>verbs don't care about the weight of an object. In fact, take is
>>pretty much the only one that does (and the verbs that require take,
>>like put). So there's no code reuse benefit from creating a
>>weight_scope, and you might as well just keep the testing completely a
>>part of the take verb itself.
>
>I think that's the wrong way to think of it. Something like weight really has
>nothing to do with scope; it's more a restriction or condition.
>
>[...]
>
>>The other part is defining default scopes to be distributed in the
>>main library. Again, scopes exist solely to enable code reuse.
>
>I know what you're saying, but I think you're thinking of scope in the wrong
>way. Everything must have some sort of scope, whether it's determined in an
>object's associated function or more generally in a verb. How else could you
>tell if the player can see an object?
I agree that it's necessary to tell if a player can see an object in
order for them to use most verbs on it. For instance, they need to be
able to see an object to pick it up (usually). But I disagree that
there's anything *intrinsic* about "can the player see this object?"
as opposed to say, "can the player close this object?". The only
reason to call the first one scope, and handle it generally, and call
the second one internal verb stuff, and handle it specifically for the
close verb, is because many more verbs need to check if the player can
see the object.
You could write a perfectly playable game that had no concept of
scope, as I've defined it. When the player types "TAKE FROG", the
game would check every single object and try and take it. Inside the
take verb would be all the code to see if the object had the noun
'frog' attached to it, to see if the object was within reaching
distance of the player, etc.
(Which suggests that it would be at least possible to have the
question of whether the object's verb matches what the player has
typed be also handled just like all other scopes. But this one is
probably not worth not hard-coding.)
> James Cole
> jrc...@ozemail.com.au
Andrew Plotkin
Dan Shiovitz (scy...@u.washington.edu) wrote:
> I agree that it's necessary to tell if a player can see an object in
> order for them to use most verbs on it. For instance, they need to be
> able to see an object to pick it up (usually). But I disagree that
> there's anything *intrinsic* about "can the player see this object?"
> as opposed to say, "can the player close this object?". The only
> reason to call the first one scope, and handle it generally, and call
> the second one internal verb stuff, and handle it specifically for the
> close verb, is because many more verbs need to check if the player can
> see the object.
But if the player tries to refer to something out-of-scope, the parser
should refuse to recognize it; and this is pretty general. (This may
presume the Inform library's prejudice, which I share, that the parser
should never reveal what out-of-scope objects exist in the game.)
If an object is visible, the parser should recognize it. It's confusing if
"Touch bird" produces a parser-level error like "You can see no such
object here" -- or even "You can touch no such object here." (When the
bird is in a closed, transparent cage.)
I'm trying to get at a clean distinction between the parser and the game
world. That's the intrinsic distinction; the parser understands scope, and
the game world understands touchability and so on. Internal verb/object
code (game world code) can produce errors like "You can't fit your finger
between the bars."
Another example: I think it would get very confusing if other parser
functions, like object name disambiguation, worked within the particular
sense-scope of the verb in question.
> x red
[The red rose, or the red candy?]
> rose
The rose is sealed in a glass box.
> smell red
The candy smells like cinnamon.
> eat red
The candy tastes like cinnamon. All gone.
> smell red
You don't smell any such thing here.
> x red
The rose is sealed in a glass box.
I guess I want to make the parser as transparent as possible -- no pun
intended. Referring to an object should always be easy.
Carl Muckenhoupt
One thing that must be borne in mind is that there are two ways an
action can fail. It can fail because you are not successful at
performing it, or it can fail because you cannot even try. An attempt
to take an object too heavy to lift fits the former criterion. An
attempt to take an object that isn't present fits the latter.
The point I'm trying to make is that scope, properly conceived, only
filters out the latter sort of failure. Scope determines the possible
targets of an action; it's the difference between "I can't take that"
and "There's nothing matching that description that I can take." "Eat
sword" fails, not because the sword is out of the scope of the verb
"eat", but because the sword is unappetizing.
Viewed thus, scope is not merely an optimization. It is a conceptually
clean way of establishing what the player can and cannot attempt. As
for the relationship between scope and disambiguation: Scope is a
starting point, and that is all. When I say "dig", and the game says
"(with shovel)", it does not imply that I can't use other tools for
digging in a pinch.
Now then, suppose we had the system of three scopes mentioned earlier in
this thread. What would the consequences be? The "concept scope" is
just about right: if you don't know about it, you can't even refer to
it. But the active/passive business seems a little strange. If I'm in
a glass box, and there's a hammer right ouside, "Take hammer" shouldn't
produce a reply along the lines of "What hammer?" - it's perfectly clear
what hammer you mean, and the game should tell you that it can't be
taken. Although this could work with some refinement:
I see the "active", "passive", and "concept" scopes as nested.
Everything in active scope is in passive scope, everything in passive
scope is in concept scope. This way, if an object fails one scope test,
we can go to the next wider one for the purpose of determining the
correct error message: "You can't <verb> [the <noun> | any of the
<noun>s]", "[The <noun> isn't | None of the <noun>s are] here", "I don't
know about any <noun>." This is probably more effort than it's worth,
unless you're writing your own libraries from scratch. If you are,
however, it seems like a much more elegant system than many of the
proposed alternatives.
--
Carl Muckenhoupt ca...@earthweb.com
EarthWeb http://www.earthweb.com/
James Cole
scy...@u.washington.edu (Dan Shiovitz) wrote:
>In article <3376f382...@news.netspace.net.au>,
>James Cole <jrc...@ozemail.com.au> wrote:
>>scy...@u.washington.edu (Dan Shiovitz) wrote:
>[..]
[...]
>>
>>[...]
>>
>>>The other part is defining default scopes to be distributed in the
>>>main library. Again, scopes exist solely to enable code reuse.
>>
>>I know what you're saying, but I think you're thinking of scope in the wrong
>>way. Everything must have some sort of scope, whether it's determined in an
>>object's associated function or more generally in a verb. How else could you
>>tell if the player can see an object?
>
>I agree that it's necessary to tell if a player can see an object in
>order for them to use most verbs on it.
Actually, I didn't just mean they'd have to be albe to see an object, but more
generally, be able to sense the object. The sense involved would depend on
the situation.
> For instance, they need to be
>able to see an object to pick it up (usually). But I disagree that
>there's anything *intrinsic* about "can the player see this object?"
>as opposed to say, "can the player close this object?".
But they have to be able to _sense_ it somehow in order to manipulate it. How
can they do this without being able to see, smell, hear, etc., it?
> The only
>reason to call the first one scope, and handle it generally, and call
>the second one internal verb stuff, and handle it specifically for the
>close verb, is because many more verbs need to check if the player can
>see the object.
Scope's not really an implementation issue, it's a concept.
>You could write a perfectly playable game that had no concept of
>scope, as I've defined it.
Your definition was:
As far as I know, the definition of scope in an i-f game is "the set
of objects I can manipulate"
...perfectly playable as long as you don't want to do anything with objects?
> When the player types "TAKE FROG", the
>game would check every single object and try and take it. Inside the
>take verb would be all the code to see if the object had the noun
>'frog' attached to it, to see if the object was within reaching
>distance of the player, etc
that's scope.
>(Which suggests that it would be at least possible to have the
>question of whether the object's verb matches what the player has
>typed be also handled just like all other scopes. But this one is
>probably not worth not hard-coding.)
I don't quiet get what you mean. ...but I think it's confusing scope with
other issues.
---------------
James Cole
jrc...@ozemail.com.au
James Cole
erky...@netcom.com (Andrew Plotkin) wrote:
>Dan Shiovitz (scy...@u.washington.edu) wrote:
>> I agree that it's necessary to tell if a player can see an object in
>> order for them to use most verbs on it. For instance, they need to be
>> able to see an object to pick it up (usually). But I disagree that
>> there's anything *intrinsic* about "can the player see this object?"
>> as opposed to say, "can the player close this object?". The only
>> reason to call the first one scope, and handle it generally, and call
>> the second one internal verb stuff, and handle it specifically for the
>> close verb, is because many more verbs need to check if the player can
>> see the object.
>
>But if the player tries to refer to something out-of-scope, the parser
>should refuse to recognize it; and this is pretty general. (This may
>presume the Inform library's prejudice, which I share, that the parser
>should never reveal what out-of-scope objects exist in the game.)
How come? I find this a real killer of suspension of disbelief; probably
the worst offender.
>If an object is visible, the parser should recognize it. It's confusing if
>"Touch bird" produces a parser-level error like "You can see no such
>object here" -- or even "You can touch no such object here." (When the
>bird is in a closed, transparent cage.)
This is the "parser-level" error WorldClass gives:
>touch bird
You'll have to open the glass case first.
I find this acceptable and not confusing.
>I'm trying to get at a clean distinction between the parser and the game
>world. That's the intrinsic distinction; the parser understands scope, and
>the game world understands touchability and so on.
But touchablitiy is scope and should be considered in the parser just like
sight is. WorldClass does this and provides quite good responses (like the
above).
I'm thinking of it like this: the parser handles all the lower level
checking to see if the required interaction is even possible. The "game
world" actually handles and checks the action.
Here are a few examples:
If you tried to get a key inside a cage the parser would realise that you
can see it but you can't get it. Therefore you get a message to this
effect.
If there was a flower in a cage which you try to smell. The parser knows
that you can see it and that you can smell it. It then passes the handling
to the "game world" to actually go over and try to smell it.
Say there is a locked box sitting up on a high up shelf. You try to open
it. The parser knows that you can't reach it so stops there. The parser
does not care about if the box is locked or not. If the box wasn't on a
shelf, but sitting on the floor, the parser knows that you can reach it so
it passes the action to the "game world". The "game world" then checks to
see if you can open the box. It finds out that the box is closed and gives
you an appropriate message.
Basically, what I'm getting at is that, yes, there are two levels, but the
first, "parser", level just checks to see if the interaction would be
possible. The second, "game world", level checks to see if you can do the
interaction.
> Internal verb/object
>code (game world code) can produce errors like "You can't fit your finger
>between the bars."
>
From what the stuff I said above, I think it would be more appropriate that
the parser level says something like: "you'll have to open the cage first".
It may not be as "nice" sounding, but the other would be a huge task to
undertake.
>Another example: I think it would get very confusing if other parser
>functions, like object name disambiguation, worked within the particular
>sense-scope of the verb in question.
>
>> x red
>[The red rose, or the red candy?]
>> rose
>The rose is sealed in a glass box.
>> smell red
>The candy smells like cinnamon.
>> eat red
>The candy tastes like cinnamon. All gone.
>> smell red
>You don't smell any such thing here.
>> x red
>The rose is sealed in a glass box.
>
But why does examine consider all the objects, but smell doesn't?
Here's the transcript from a WorldClass game I whipped up:
There is a glass case here. A red candy is here. A red rose is in
the glass case.
>x red
Which red do you mean, the red rose, or the red candy?
>rose
It looks like an ordinary red rose.
>smell red
The red candy doesn't smell unusual.
>eat red
That was delicious!
>smell red
You'll have to open the glass case first.
>x red
It looks like an ordinary red rose.
It (WorldClass) uses disambiguation on sense-scope, and doesn't seem
confusing to me.
>I guess I want to make the parser as transparent as possible -- no pun
>intended. Referring to an object should always be easy.
I don't understand what you mean.
---------------
James Cole
jrc...@ozemail.com.au
Joe Mason
-> others are easily added. The "sensibility" attribute is effectively
-> added to the "sensitivity" attribute (the actual formula is a bit
-> more complex since it includes range derating and a skill roll). If
-> the result is greater than or equal to zero, then that aspect of the
-> object is passively sensed. A character's action for actively
-> sensing works the same way, the sensitivity being higher as
-> appropriate.
Interesting. Sounds like this is being geared towards RPG style games -
how general-purpose will it be? Is it to be a complete IF language to
rival TADS or Inform, or is it more of a utility to create a specific
type of game?
Also, how much of this behaviour is going to be hard-wired into the
system? It sounds like the type of thing the author would want to
tinker with in various situations.
-> an appropriate action (read, sense, tell, etc). These items may be
-> tagged with a "lifetime" which will cause them to be forgotten after
-> a period of time. Memory items can also have attributes which do
-> what you
I'd suggest making it a function so that the author can decide when to
forget the memory. That way a certain event (such as discovering more
up-to-date information) could trigger the removal of a memory item.
Joe
Lucian Paul Smith
James P. White (j...@pagesmiths.com) wrote:
: I am developing a game authoring system which implements passive and
: active sensing. For each sense, every object has an attribute for how
: "sensible" it is (another way of thinking of this is how much it absorbs
: or emits). In addition, each character (player or non-player) has an
: attribute for how "sensitive" it is for that sense. The standard senses
: are predefined (see, hear, smell/taste, touch, identity, and magic) and
: others are easily added. The "sensibility" attribute is effectively
: added to the "sensitivity" attribute (the actual formula is a bit more
: complex since it includes range derating and a skill roll). If the
: result is greater than or equal to zero, then that aspect of the object
: is passively sensed. A character's action for actively sensing works
: the same way, the sensitivity being higher as appropriate.
Wow. This is almost exactly what I have been contemplating doing for a
potential adventure with a few different 'main characters', one of whom
was blind. I wanted to have a set of rooms everyone could wander
through, but get different descriptions based on their perceptions. For
example, the blind person walking into a room would get an aural and
limited tactile (if they had their cane) description by default. Someone
else would just get the visual description, but could get the aural text
if they 'listen'ed while in the room. Likewise, closing your eyes or
covering your ears could modify the default descriptions you received.
-Lucian "Lucian" Smith
Lucian Paul Smith
Carl Muckenhoupt (ca...@earthweb.com) wrote:
: I see the "active", "passive", and "concept" scopes as nested.
: Everything in active scope is in passive scope, everything in passive
: scope is in concept scope. This way, if an object fails one scope test,
: we can go to the next wider one for the purpose of determining the
: correct error message: "You can't <verb> [the <noun> | any of the
: <noun>s]", "[The <noun> isn't | None of the <noun>s are] here", "I don't
: know about any <noun>." This is probably more effort than it's worth,
: unless you're writing your own libraries from scratch. If you are,
: however, it seems like a much more elegant system than many of the
: proposed alternatives.
This is exactly what I was trying to get across.
I actually don't think it would take too much modification of the Inform
libraries to accomplish at least a basic form of this, either.
If we redefined (conceptually) Inform's 'scope' as 'active scope', added
a couple attributes ('passive' and 'concept') we could then extend the
grammar of all the verbs, something like (off the top of my head:)
----------------
Extend "touch"
* passive ->PassiveRefuse
* concept ->ConceptRefuse
Extend "eat"
* passive ->PassiveRefuse
* concept ->ConceptRefuse
!!et cetera, et cetera,...
[PassiveRefuseSub;
"You can't touch ", (the) noun, "right now.";
];
[ConceptRefuseSub;
(The) noun, "doesn't seem to be here right now.";
];
----------------
For any given item, you could always add a 'before' rule to it if there
was a specific reason it would usually be refused:
Object freedom "freedom"
with name 'freedom',
before [;
ConceptRefuse: "'Freedom' is a concept, not a thing!";
],
has concept;
You could also expand the 'ConceptRefuseSub' to tell you where you left
something, probably piggybacking on the 'objects' routine.
The net result of all this would be that the default acceptances would
still be maintained, but the default refusal "You don't see any such
thing" would only be displayed if the item in question was not a concept
the player could refer to yet.
I'm not sure how this could tie in to the new library routine
'ObjectIsUntouchable' routine, but it shouldn't be hard.
I might also note that with library version 6/5, an object 'offers light'
if any of the things it "adds to scope" have light. (a quote from the
recent 'errata' from G.Nelson)
As far as I can tell, this means an encyclopedia with an entry about the
sun will glow.
-Lucian "Lucian" Smith
James P. White
Lucian Paul Smith wrote:
>
> James P. White (j...@pagesmiths.com) wrote:
>
> : I am developing a game authoring system which implements passive and
> : active sensing. For each sense, every object has an attribute for how
>
> Wow. This is almost exactly what I have been contemplating doing for a
> potential adventure with a few different 'main characters', one of whom
> was blind. I wanted to have a set of rooms everyone could wander
> through, but get different descriptions based on their perceptions. For
Yep, that's the idea. Two great minds converge! :->
Jim
-----------------------------------------------------------------------
James P. White Netscape DevEdge Champion for IFC
Director of Technology Adventure Online Gaming http://www.gameworld.com
Developers of Gameworld -- Live Action Role-Playing and Strategic Games
j...@pagesmiths.com Pagesmiths' home is http://www.pagesmiths.com
Eric Rossing
On 21 May 1997 20:29:57 GMT, lps...@rice.edu (Lucian Paul Smith) wrote:
: I might also note that with library version 6/5, an object 'offers light'
: if any of the things it "adds to scope" have light. (a quote from the
: recent 'errata' from G.Nelson)
:
: As far as I can tell, this means an encyclopedia with an entry about the
: sun will glow.
No. The encyclopedia doesn't contain the object Sun. It contains the
object SunEntry, a page of text about object Sun. There is a conceptual,
but no programmatic, relationship between SunEntry and Sun, and while Sun
may have light, SunEntry certainly wouldn't(unless, of course, it had a
phosphorescent picture as part of the entry :)
Eric Rossing
ros...@iname.com
http://home.msen.com/~rossing
PGP Public key available on my WWW page
Support the anti-SPAM amendment! Go to http://www.cauce.org!
Big Mad Drongo
: > Wow. This is almost exactly what I have been contemplating doing for a
: > potential adventure with a few different 'main characters', one of whom
: > was blind. I wanted to have a set of rooms everyone could wander
: > through, but get different descriptions based on their perceptions. For
: > ...
: Yep, that's the idea. Two great minds converge! :->
Three, actually. You have played Suspended, haven't you?
Adrian