[MUD-Dev] string parsing

[coder at ibm.net]

On 04/11/97 at 08:09 AM, "Felix A. Croes" <felix at xs1.simplex.nl> said:
>coder at ibm.net wrote:

...
>> >If the mud has such object relations as `next to', `on top of' etc, then
>> >it makes sense to have syntax rules, and functions to give them meaning,
>> >for all of them.
>>
>> My support for prepositions is currently, err, inelegant and flakey.  I've
>> not examined the area in depth, but when I do re-approach it I will want
>> the system to be able to analyse the locations of multiple objects and
>> determine the applicable prepositions which apply to their positions ("The
>> ball and the light are above the table.")  As such the base idea I have
>> stashed is to operate off a tuple which defines the class of preposition
>> (ie list of terms), and the spatial transformation which defines its
>> scope.  This (hopefully) reduces prepositions to a generic form which can
>> be both parsed and back-constructed.

>I think the difficulty in recognizing such object relations stems from
>trying to do everything with a single positional system.

One of the reasons I so dislike my current implementation is that I
followed two rules:

  1) All objects are placed with either absolute coordinates relative to
the room's origin, or with a prepositional tag relative to another
object's origin.

  2) All preposition handling is special cased per the preposition group.

The result is terribly inflexible.  It doesn't work worth squat when I
entirely abandon the room concept, which I'm in the middle of doing.  I
specifically want a system which can take the location of two objects, and
the location of the viewer, and from there derive a suitable set of
prepositions to describe the object's position relative to each other and
the viewer.

>Proposed solution:

>Start with a hierarchical container system at its most abstract.  Let
>each object have a "position" in its container.  The interpretation of
>the position is left to the container.  The position can be a pair of
>coordinates meaningful in the plane defined by the room, or a triplet of
>coordinates in the 3-D space defined by the room, or
>(angle, distance, speed) relative to the room, which is the planet in
>whose gravitational field the object resides.

My current coordinate model works off simple 3D coords (currently 64bit
ints), with objects locations being defined by origin and orientation
coordinates (defines a base line which the origin is mapped against).  I
don't do unit granular motion any more (eg "N" to move one unit "north"). 
Vector motion is handled similarly as an extension of this: as a
coordinate pair defining a vector, a velocity value, and a check/update
condition/point.  User motion will result in parses of the form: "Move
along XXX vector until YYY position, then (don't) stop."  Thus you get the
classic:

  > l
  You are in a large empty field.
  There is a tree far to the west.
  > go tree
  You start walking towards the tree.
  An arrow comes from behind and flies by your ear!
  > run
  You run towards the tree.
  > l
  You are in a large empty field, running towards a distant tree.
  ...
  You have reached the tree.

What I then want is for a second viewpoint, perhaps Bubba the Archer, to
be able to do/see:

  > l
  You are in a large empty field with a large tree
  There is a large tree far to the west. 
  Boffo is running away from you towards the tree.
  ...
  > l
  Boffo is standing beside the tree.
  ...
  > l
  Boffo is hiding behind the tree.

This requires the system, to dynamically generate suitable pronouns given
position sets.  A further example would be the case of a street, in which
is parked a waggon and team close to a large brick wall which forms one
side of the street.  I want to eb able to dynamically generate
descriptions of the form:

  > l
  You are in a street.  In front of you a wagon and team stands.  Bubba is

  in front of the team working with th reins.  It looks like Bernie is 
  crawling abouit under the wagon doing something with an axe.  You can
just 
  see Boffo standing on the far side of the wagon.

The interesting point in that is the careful choice of the "on the far
side" prepositional phrase as vs "behind", as "behind" is ambiguous given
that the wagon has its own prepositional space which (can be) different
from its location's prepositional space.  Bubba's "in front" works there
because the language explicitly names the wagon's prepositional space.

>The position could then simply be a string like "inside", "beside" and
>"above" to indicate the position relative to the container, without
>imposing the same system on the rest of the mud.

Which is what I'm trying to get away from.

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...