[Inform] Ideas for new scope rules
FReDRiK RaMSBeRG (WILdcARD)
Scope rules in Inform
---------------------
I am programming in Inform 6, using the library. Generally I find the
parser and its surrounding routines to be very competent and easy to
program, but have found a problem that seems rather difficult to work
around; the scope rules.
To get an illustration, try implementing a normal car properly.
As it is now, you can always reach exactly the things that you could
see if you were standing on your own feet in the room.
Problems imposed by this:
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.
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.
If the player is in a closed coffin in a dark chamber, it is light in
the coffin only if there is a lamp of some kind _outside_ the coffin.
Most of the time you can work around these problems by making
enterable containers into locations of their own instead, but that
causes new problems.
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.
Note: By "innermost" I mean the one closest to the player, in the case
that he is in nested containers.
In both cases, the delimiting container or supporter itself will also
be in scope.
Lookscope would be used by Look, Examine and Search, touchscope by the
other verbs. When putting extra objects into scope, you could choose
to put them into lookscope, touchscope or both.
How does this sound to you? If anyone cares to discuss this, please
mail me a copy of your follow-up, since my news-server is dropping a
lot of articles.
/Fredrik Ramsberg
--
-----------------------------------------------------------------------------
Fredrik Ramsberg, student at Linkoeping University
Hi-tech-mail: d91f...@und.ida.liu.se
-----------------------------------------------------------------------------
Fredrik Ramsberg
Andrew C. Plotkin
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."
In other words, it would be bad to have two parallel scope systems.
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.
I haven't looked at the TADS WorldClass library, but I suspect it has
worked out these sorts of ideas.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
Julian Arnold
In article <Pine.SOL.3.91.96072...@astmatix.ida.liu.se>,
Fredrik Ramsberg <mailto:d91f...@astmatix.ida.liu.se> wrote:
>
> To get an illustration, try implementing a normal car properly.
I tried this a while ago. Although it is a lot of trouble, it is
possible with the current scope rules. Basically you have two objects
for the vehicle. The first, veh_obj, is a static object, and represents
the vehicle which is referred to by the player (as in "ENTER VEHICLE").
The second, veh_loc, is a location and represents the inside of the
vehicle. Entering veh_obj moves the player to veh_loc, writes veh_obj's
location to veh_loc.number, and moves veh_obj to veh_loc as well (giving
it concealed and scenery). Now, veh_obj has an add_to_scope routine
which, when the player is in veh_loc puts everything in scope in the
outside location (which is held in veh_loc.number). veh_loc has a
before routine which says something like
before
[;
if ( noun in veh_loc.number )
Examine: rfalse;
default: "You can't reach things outside.";
],
Using the LookRoutine() entry point you can make look print the veh_loc
descfription followed by the veh_loc.number description (ie, describe
inside car, describe outside location.
That's basically it, although there are various other tweaks you have to
make.
Jools
Michael Blaheta
Quoth Andrew C. Plotkin:
> 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.
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:
Each game must note each of the senses it uses. By "sense" in this case
I mean anything which will require separate scoping. A conservative
game would just have sight and touch; a magical game might also include
the "magic" sense; a truly elaborate game could have tons of senses,
including sight, smell, sound, reach, grasp, telepathic, and maybe
others. (In the library, reach would always be a synonym of touch, and
if grasp was not noted/requested as a separate sense, then it would also
be aliased to touch.)
Each sense then has its own is-this-in-scope routine.
Each and every verb would have to identify the senses it normally
accesses. If that sense is not noted as in use, then the verb's
subroutine would switch to a more "stupid" behaviour. For example:
[ SmellSub ;
if (IsSense(#s$smell))
{
print noun.smell;
}
else
{
print "A perfectly normal smelling "; PrintShortName(noun);
}
];
In addition, ##Smell would have as its fundamental sense #s$smell. The
fundamental sense of a verb would be the one which would be used when
the parser was running; if a verb requires secondary senses, it must
test them within its subroutine, such as the following verb whose
fundamental sense is sight.
[ PressSub ;
if (IsSense(#s$touch) && ~ InScope(noun, #s$touch))
{
print "You can't reach "; DefArt(noun);
}
else !Whether touch is a sense or not, it's in scope
{
print "Pressing "; DefArt(noun); print " does nothing.";
}
];
There would also be a default sense--*usually* sight--which would be
used to check scope on verbs whose fundamental sense is not used. Some
verbs can declare their fundamental sense to be whatever the default
sense is. If the InScope function is invoked without a sense, it uses
the default sense. By doing it this way, implementing a blind player is
not that difficult.
Don