[MUD-Dev] Room Generation

[efindel at earthlink.net]

--<cut>--
Note: This message was written via the list web archives.  There is
no guarantee that the claimed author is actually the author.
--<cut>--
Original message: http://www.kanga.nu/archives/MUD-Dev-L/2001Q1/msg00188.php

On Fri, 19 Jan 2001 14:00:22 -0800 (PST)
Nathanael Dermyer <NDermyer at HNTB.com> wrote:

[arg... I managed to delete the message, so replying through the web 
archives]

> On the mud I admin on (an LP Mud, running aamylars 03.02.01 at 128, on
> a tw lib) we have a "virtual" room system where you feed a compiler
> a file containing a map, a list of what the symbols in the map mean,
> and the appropriate code to create the files.  When the area
> initializes, it builds virtual rooms (meaning no actual file exists
> on the disk, only in memory).  The problem here, is when the map is
> large (meaning bigger than say, 15x15) the virtual compiler blows
> the max_eval.

This sounds like the virutal area code is creating the entire area as
soon as someone enters it.  This is a silly way to go about it.  The
main idea behind virtual areas on LPs is to save memory, not to make
creating large areas easier (you could do that through simpler
methods).  Loading the entire area into memory tends to defeat the
purpose, then.

The virtual area engines I've seen do this instead: they take
coordinates to indicate where in the area the room desired is.  They
can then look in the map file, find that one room, and create and load
just it.  This helps accomplish the goal of saving memory, is faster,
and prevents running into max_eval.

> The max_eval is not the problem.  I don't like virtual areas.  Plus
> the areas I typically create only have several similar rooms, so
> virtual areas are actually kinda worthless to me.

Why don't you like virtual areas?  I can see not liking a particular
implementation of the idea, or the uses to which it's often put (i.e.,
creating large, boring areas with very little in them), but what's
wrong with the idea itself?

Virtual rooms can be used in other ways as well... for example, on
SWmud, I had an area that was a forest.  One of the commands available
in there was "climb tree".  This created a virtual room, with
parameters depending on where in the forest you were, from which you
could see the general directions to several landmarks in and around
the forest.  (The forest floor was not a virtual area -- only the
rooms "up in the trees" were).

Another use the concept was put to on SWmud was ships.  Only one set
of rooms existed on disk for each ship type; multiple ships were
accomplished by making each ship be a small virtual area based on
those files.

Also, many virtual area implementations allow specifying that certain
rooms are to be loaded from disk instead of from the map.  That way,
you can have more interesting custom-coded rooms inside a virtual
area.

> What I'm wondering is if anyone has some sort of mechanism (perl
> script, C program, VB, whatever) that will accept some sort of map
> file and a list that defines what each map symbol means, and spews
> out individual room files.
 
> Sample map file: (it'll have to be viewed with a non-true type font
> to look right)

>   O-F-O-S
>   |\| |X
>   O-F-S-O
>      \|/
>   F-S-S-O

Some of the virtual area systems I've seen in LPC already do this, but
by using two files: one that designates exits and in which direction,
and another which designates the types of rooms (this allows for
one-way exits and for having up and down directions).  Any of those
could be easily modified to spit out files for each room instead of
creating objects, and I wouldn't think they'd be too hard to find.

--
Travis Casey
efindel at earthlink.net
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev