[MUD-Dev] Object and class heirarchies -- are they really necessary?

[Brandon J. Rickman]

On Tue, 28 Mar 2000 cg at ami-cg.GraySage.Edmonton.AB.CA wrote:
> [Phillip Lenhardt <philen at funky.monkey.org>:]
> 
> > For example, if a door is just a regular object with open and close
> > methods and link attributes pointing at two other roomish objects,
> > how do you determine if it is a door at all? In a class hierarchy,
> > you can ask for the class or type of an object. If that class or
> > type is or is descended from the door class, you know you have a
> > door object. With just a base class, you have to check for all
> > relevant methods and attributes before treating that object like
> > a door.
> 
> I recall someone on this list (JCL?) saying something analagous to:
> 
>     If it acts like a door, its a door.
> 
> Why do you care if the way it gets its door behaviour is by being an
> "official" door? If someone has, within the rules of your world, created
> a non-door object which is intended to act like a door, then I would
> think you would want everyone to treat it as if it were a door. In other
> words, you don't want anyone to be able to find out that it isn't "really"
> a door.
> 
> Possibly there are some rare administrative cases where you want to be
> able to identify "official" doors, but should that kind of requirement
> drive the basic heart of your system?

One of my favorite subjects!

What is a door?  Well, we have doors in the real world, and they look
like, ah, doors.  In a virtual world, the important thing about doors is
that they _function_ like doors.  So what is a virtual door?  Something
that fits in a virtual doorway.

What is a virtual doorway?  The path, the route, the /something/ that lets
you move from one virtual room to another.

What is a virtual room?  In the Zork era, they were very clearly defined
constructs, they were built into the code.  In a coordinate based world,
you have to look for the rooms, look for areas where some combination of
virtual geography and virtual obstacles isolate one cluster of coordinates
from the others.  Eventually you realize that we don't really want to
locate the room itself, but the walls around the room, barriers that
prevent free access to nearby coordinates.

* * *

If object #6 is "a door", and object #6 is not in a doorway but merely
lying on the ground, then you get

% look
A place
You see: A door, 15 coins, an exit to the north.

Similarly, object #23 is "a boulder".  When #23 is lying on the ground, it
is just "a boulder":

% look
A place
You see: A boulder, 15 coins, an exit to the north.

But if boulder #23 is blocking the exit, you could call it a door:

% look
A place.
You see: 15 coins, a closed door to the north.

This is wrong, of course.  The boulder is functioning like a door, but we
need to change the wording:

% look
A place
You see: 15 coins, the passage north is blocked by a boulder.

Now we need to alias some new verbs; "open door" is what we would normally
want, but "open north exit" should work, or "move boulder".  I've seen
"open boulder", which is ambiguous.

The important thing is that when the boulder is _not_ blocking the exit,
it is _not_ functioning as a door.  This shouldn't happen:

% look
A place
You see: 15 coins, a boulder, an exit north that is not blocked by the
boulder. 

Nor should this:

% look
A place
You see: 15 coins, a door which is neither open nor closed (as it is not
functioning as a door), an exit north that does not contain
the door.


- B!





_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev