Refs for Thesis: Spatial Relations in Muds
Finnegan Southey
Virtual Realities. Basically, it's looking at how muds currently model
the replationships between places and objects' relationships to each other
(ie. the book is on the table). What I need are references of any kind to
this topic. Documentation, research papers, anything would be of
interest. I need to find out how these areas are being handled now and
need references to cite in my paper. Please let me know of anything
you've read/seen on this topic.
I was advised to ask here in rec.arts.int-fiction (I'm an old Infocom
player, and played Adventure and Dungeon way back in '79). While my
thesis relates specifically to muds, the two are, of course, intertwined.
I have downloaded the FAQ and have the references in there, but would
still appreciate more.
Thanks in advance...
( Originally posted to rec.games.mud.misc and rec.games.mud.admin because
rec.games.mud was blocked for local posting at our site for some strange
reason. )
----=== Finnegan Southey : Computing and Communications Services ===----
----=== University of Guelph, Ontario, Canada : finn...@uoguelph.ca ===----
----=== You are in maze of twisty little passages, all alike. ===----
Phil Goetz
"in/contains", "on/under", "by/by", and "partof/part" in my text adventure
_Inmate_ in 1986. An edge in the semantic network
saying "X on Y" meant X was on Y; an edge saying "X part of Y" meant
X was a part of Y (e.g. a tire is part of a car).
Whenever an edge was
changed, the network was searched for other edges that caused other things
to happen to maintain consistency. For instance, if you replaced the edge
"X in Y" with "X in Z", and "W part of X" was in the network, then replace
"W in Y" with "W in Z". Note that the same conditions are tested for
"W in Z" as were tested for "X in Z", so if "V partof W" then "V in Z"
will be asserted. Basically the same happened for "on" and "in".
There were restrictions on when an edge could be changed. If
you tried to put X in Y, Y had to have remaining capacity large enough
for X. If you tried to put X on Y, Y had to have enough surface area
left for X.
This caused problems with on/under. I treated "under" as the opposite of
"on", so if I said the box was under the table, then the player picked
up the box, the table would come with it! Also, I couldn't put a key
under a doormat, because the doormat was too large to fit on the key!
And when I did "hack" the key to have a large enough surface area for
the doormat to be on it, the key was still visible because I hadn't
represented the notion of hidden objects. (I solved that problem by
adding an "invisible" flag and asserting that when one objects was
taken off another, the underlying object became visible. But that
didn't let the key become invisible if the player tried to put the
key back under the mat.)
David Baggett
>This caused problems with on/under. I treated "under" as the opposite of
>"on", so if I said the box was under the table, then the player picked
>up the box, the table would come with it!
Yes, it gets complicated quickly. I just found a similar subtlety while
writing some code to deal with in/on/under/behind containment. It's not
enough to say that when you take something, you don't get the things that
are "under" -- you only don't get the things that are under the container
itself. (Consider a box with a piece of paper under it, a book in it, and a
key under the book. If you take the box, you don't get the piece of paper,
but you do get the key.) There are several cases where the distinction
between immediate parent and non-immediate parent (ancestor) is important.
To make things reasonably efficient, I assume in my code that all
containment types are orthogonal and transitive. Orthogonality (not the
best term for it) means that an object can only have one containment type
at a time; i.e., no object can be under something and on the same thing (or
in, behind, etc.) Transitivity means that if A is in B and B is under C,
then A is under C as well. This isn't necessarily true in the real world
(even if a table is under an umbrella, a cheez kee on the table might not
itself be under the umbrella), but if you don't make that assumption the
code is much more complicated.
Dave Baggett
__
d...@ai.mit.edu Boot up, log in, drop out. MIT AI Lab
ADVENTIONS: We make Kuul text adventures! Email for a catalog of releases.
PO Box 851 Columbia, MD 21044 USA / CIS: 76440,2671 / GEnie: ADVENTIONS
Scarrow
>In article <CHxvC...@acsu.buffalo.edu> go...@cs.buffalo.edu (Phil Goetz) writes:
>>This caused problems with on/under. I treated "under" as the opposite of
>>"on", so if I said the box was under the table, then the player picked
>>up the box, the table would come with it!
>Yes, it gets complicated quickly. I just found a similar subtlety while
>writing some code to deal with in/on/under/behind containment. It's not
>enough to say that when you take something, you don't get the things that
>are "under" -- you only don't get the things that are under the container
>itself. (Consider a box with a piece of paper under it, a book in it, and a
>key under the book. If you take the box, you don't get the piece of paper,
>but you do get the key.) There are several cases where the distinction
>between immediate parent and non-immediate parent (ancestor) is important.
This isn't too bad if you keep it clear that objects underneath another
object are related to the object above them, but not a part of it. In
other words, if I pick up the box the paper doesn't go with it because its
parent is the same as the parent of the box. The key goes with the box
because, like the book, it has the box as its parent. Much more frustrating
is determining how one may rehide the piece of paper. (Note: I come from
a MUD perspective.) I keep physical width, height and depth information,
so perhaps it's enough to be able to place objects like a box over thin
objects like paper (thin is defined to be a 0 value for a dimension). On
the other hand, one should be able to turn over the box and hide larger
items in that fashion (so perhaps the ability to hide objects from a certain
orientation should be a three dimensional figure itself). Anyway, in this
fashion maintaining something as under something consists of maintaining a
pointer from the object to the object obscuring it (if this points to some-
thing the object is obscured and should not be shown) as well as a pointer
from the obscuring object to the obscured object (which is used to find the
object to unobscure when the obscuring object is removed). So picking up
the box moves the location of the box and changes a couple of pointers, but
the location of the paper is still wherever it was. In this way I could
have, for example, a box of paper underneath a table (note that being
underneath shouldn't mean the object is automatically obscured ... need
some sort of a flag for that), a tablecloth covering the table, a bowl of
fruit hiding a stamp, and the fruit in the bowl hiding a few cents in
change, etc. Picking up any given item should be fairly consistant. Note
that I also allow objects to have several relationships with one another.
This is still a rather simple model. I've been considering the worth of
having different sides, with a default side for standing the object (for
example, a coke can would have certain dimensions, be flat enough to stand
on it's top and bottom and round enough to lie on it's side ... a die, as
another example, is flat enough to stand on any given side ... a box might
be standable on any side, and one side would contain an added depth for
obscuring "underneath" objects). This is getting kind of complicated, but
it all depends on the level of realism you want to approach. I'd like to
hit a level that isn't unreasonably complex within the text framework (in
other words, typing "flip over the box and hide the bowl of fruit" isn't
especially tricky, and so it would be nice to be able to do it). Anyway,
this is different from having objects "on" objects (which tends to imply
that the object is contained within the surface space of the under object,
allowing it to be moved if the under object is moved) and having objects
"in" objects. On/in are both forms I consider as child-parent relation-
ships, whereas behind/under are both forms I consider as sibling-sibling
relationships.
(If anyone's curious, I don't really believe in paragraphs, but then
they claim not to believe in me either.) Hope I've been of some help.
--
Shawn L. Baird (Scarrow) | "By all means, take the moral high ground --
bai...@ursula.ee.pdx.edu | all that heavenly backlighting makes you a
-------------------------| much easier target." --Solomon Short