[MUD-Dev] Rooms

[Travis S. Casey]

On Fri, 4 Jun 1999, Greg Munt wrote:

> Discussion about how to represent the world environment usually seems to
> focus more on co-ordinate systems (remember neighbourhoods - did anyone do
> anything with that?) than room-based systems. This statement assumes that
> you have to choose between one or the other (everything co-ordinate based,
> by using things like R-Trees or Oct-Trees - or everything room-based ala
> StockMUD), or have a hybrid system, having a room-based world, where every
> room maintains its own co-ordinate grid/cube.
> 
> Is the choice nothing more than co-ordinates, or rooms, or both? Or are
> there other alternatives? By how much can the room concept be extended from
> the StockMUD implementation - if at all? For those who have implemented
> their own worlds, what system have you used, and would be interested in
> discussing them, here on this list?
> 
> I personally feel that - to some extent - co-ordinate based systems have
> been done to death on MUD-Dev, and would welcome discussion of alternate
> systems, even new ways of developing the StockMUD room-based concept.

Some wargames and paper RPGs use "area movement."  Instead of using a
square or hex grid and marking off distances on that for movement, maps
are divided into "areas" of irregular shape and size.  Indoors, small
rooms are typically one area, while larger ones may be divided into
several areas.

A similar idea could be used instead of rooms -- instead of having each
room be a separate place, each area could be a place.

On Psyber Age, I partially implemented area movement, and had a lot of
plans about other things to try that never worked out.  Here's the basic
outline of my ideas:


Each area has a size, which governs basically expresses how many people
can be packed into it and still be able to move around a bit.  Thus, a
closet might be size 1, a small office size 5 or 6, and a ballroom might
have a size of 200 or so.

Areas are adjacent to one or more other areas, with which they share
exits.  Like areas, exits have a size -- which in this case is used mostly
for governing whether vehicles can move through them.  Exits also have a
distance, which roughly corresponds to the distance between the centers of
the two areas.  This distance can be used for ranged combat, sighting,
etc.  Exits can be transparent, in which case you can look into the next
area.  Exits can also be soundproof, and can have functions which
determine who can go through them.  (Thus, you could implement a glass
wall as an exit which is transparent and soundproof, and which no one can
go through).



This system was intended to solve some of the problems we'd run into on
SWmud with ranged combat and vehicles -- specifically, ranged combat on
SWmud is done with ranges expressed by a number of rooms.  However, that
gave weapons huge ranges in outdoor areas that were represented by just a
few "big" rooms.

Vehicles were added to SWmud as an afterthought, and it showed.  No
"indoor" or "outdoor" flags had been made for rooms, so vehicles were able
to drive into shops, through buildings, etc.  This led to ridiculous
things like someone's getting an AT-AT walker and taking it inside a
building to use to kill a particular monster in there.

In addition to the vehicle problems, there were problems with some
monsters that were supposed to be huge, like the Rancor, yet which could
go through any exit the player characters could.

Since PA was to be a cyberpunk mud, it was also going to have ranged
weapons and vehicles... but this time, we wanted to design rooms and exits
to prevent the problems we'd had with them on SWmud (and which SW
continues to have with them).

The sizes and distances were going to have reasonable defaults, depending
on whether the rooms in question were indoor or outdoor rooms.

Some things that I thought about, but never got to implement:

 - Grouping of areas.  Builders would be able to create groups of areas
   and have them all be visible to each other.  The grouped areas would
   also be treated as a single area by some routines.  (I was planning on
   doing this in terms of area containers -- sort of "superareas" which
   could contain other areas, and which had many of the same function
   calls as areas.  Thus, a message could be sent to a superarea, and it
   would pass it on to all its subareas... some of which might actually
   be other superareas.)

 - Built-in functions for keeping objects in two areas synchronized --
   e.g., doors.

 - Area-creation commands which would take care of a lot of the
   headaches... like making sure that exits match up, etc.  (I didn't
   want to implement this at a low level, in order to allow for things 
   like mobius rooms, etc. -- while PA wasn't going to have magic, it
   was going to have a cyberspace in which such things might exist.)

--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_) 




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