[MUD-Dev] DGN: Rooms, Directions, etc. - any alternatives?

[Sean Middleditch]

On Sat, 2004-05-22 at 23:32, Skane2004 at aol.com wrote:

> I realize that just about every mud uses the direction system of
> north, south, east, west, up, down -- but are there any
> alternatives?  One of the common complaints I hear about are that
> people don't like having to memorize cardinal directions from
> recall to get places -- or new mudders have a hard time getting
> where they want to go because they don't have the directions
> memorized...  Are there any muds that don't use NSEWUD?  If so,
> how does their system work, and how do they define where a
> character's location is?  It seems more realistic to be able to
> manipulate (or at least see) what's in the rooms around you...is
> that implemented anywhere?  How does it work?  I'm just trying to
> think outside of the box here...any suggestions?

The system I've been designing for AweMUD has a movement method you
might be interested in.  I've got the design pretty much done, I'm
just waiting on finishing up a few other features before I begin the
code. If you want to help hack on it (after reading the below), we
always accept more help.  AweMUD is fully Open Source, under the
modified BSD license.  </plug>

The first part of the system is to break up the room system.  Most
MUDs work by having each room be a completely distinct location with
no overlap or intersection at all.  A better system would provide
instead a list of specific locations you can be in which may or may
not overlap. My favorite example would be a large room, with a stair
case on the side up to a balcony near the top, with a door at the
balcony level leading into the hallway.  People can stand in the
hallway, on the balcony, on the main floor, under the balcony, etc.
The relationship map between these locations would indicate if you
can see, touch, or hear people in the adjoining locations.  For
example, anyone in the room can hear anyone else talk (but not
whisper), but those on the balcony cannot see those under it or vice
versa.

Now you simply name the parts of the room, and update your "go" and
other movement commands to move between them using these name or
alternative keywords.  go under the balcony.  climb stairs.  go down
stairs.  etc.

Another example would be a room with a large statue.  You could "go
behind statue" or whatnot.  In this room, one might hear any noise
made in the room, but you can't see on the other side of the statue.
So this could provide some interesting role playing chances if you
know some people talk in this room a lot; just hide behind the
statue and snoop.

You can also use the directional movement commands in this system,
where it makes sense.  I'd argue that every plainly obvious movement
node (door, open hallway, etc) should have direction associated,
simply because it's a lot easier and quicker to type "n" or "se"
than "go hallway" or even the short-hand "g h".

This system would be *very* easy to implement in any sanely coded
MUD base, I might note.  A quick "hack" version would just add a
couple flags to the normal room exits, extend the movement commands,
and extend the room display command (to show people and objects in
rooms connected by exits with the appropriate flags).  Adding
hearing of text and such would also be very easy: again, just send
the speech to any room connected to the current with an exit with
the appropriate flags.

A more complete system would require a little more architecture
change; rooms need to be linkable with hear/see relationships even
if there is no way to move between them.  (Imagine being able to see
people across a chasm, even though there is no way to get to the
other side.)  Being able to have the room descriptions display this
better would be nice, too.

--
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev