[MUD-Dev] Room Generation

[Patrick Dughi]

On Fri, 19 Jan 2001, Nathanael Dermyer wrote:

> 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.
 
> 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

Sure.  Though it was only useful for 2-d maps.  I just made a simple
bitmap.  Originally I used a 16 color palette, and had fancy colors
for terrain type, later a 256 (though I never used all colors).

In my map loader, each discrete color represented a room type, or some
other classification.  I was trying to create contigious rooms though;
you may want to do something as easy as declaring rooms only on the
intersections of even rows and even columns - leaving 8 spaces around
each room for connection information.

In the end though, it was pretty simple to access the whole thing like
an array and use the info in there.  If I didn't want to load the
whole thing in memory at one time, I could easily skip to the
row-column I wanted and grab that information (unlike your text file
which would need to be parsed and stored en-masse in a table, else
parsed each time info was needed - yuck). It was also easy to take a
bitmap editor program and add my new information quickly.

If you needed to go 3-d, just layer a few (though that's not the best
solution I can think of, just an easy one).  Not make multiples, but
have a fixed max width/length and each level is represented as a
multiple of that - like animated gifs.

You'll still have to figure out how to make up/down exits.

One thing you'll notice though is that this is hard to work in reverse
- many muds are not 3-D correct.  That is, if you take 10 steps north,
10 steps east, 10 south, and 10 west, very rarely do you end up even
remotely near where you started.

So, as a slightly different topic, I wanted to broach that subject; is
there a 'good' way to take a standard non-graphical, not 3-d correct
mud, and display the rooms in a graphical format so that someone could
easily edit it?

I thought of two off hand, one is vaguely difficult, the other
involves more conflict resolution than not;

1. Cat's Cradle

Determine the shortest path to each accessable node from each node.
Identify the ((# of nodes/20) + 1) nodes with the largest shortest
(via something like BFS) paths (not necessarily to eachother).  Draw a
circle with a subject-to-change radius 1.5x the distance of the very
longest shortest path. Space the nodes you've identified above and
place them at places on the circle equidistant to eachother.  Fill in
the longest paths first, as geometrically accurate as possible (ie, a
node with a north connection would have a higher precidence connecting
to a node's south exit, etc).  Then add the rest where possible,
obtaining (at the end) a set of 2-d maps, one for each verified unique
elevation level.

Ie; think of your node graph as a large number of rings with threads
linking them to others.  Find the threads with the most number of
connections between them, put them on your fingers, and stretch you
hands apart.  The majority of the rings seem to be more probably
likely to fall in a 2-d space, or at least close enough that they can
be understood.

2. Conflict

Assume the map is 3-d correct.  Place node in that way, but when the
user selects a node, they're listed with all given conflicts, and
required to choose one.  Represented graphically as color schemes for
how many are conflicting, and an identifier at the top for the current
default.  Something akin to right click to select new default.

Again - these are off the top of my head, and I know this is a problem
that has been - if not resolved - at least examined in depth before.
Any clues, pointers, links, or critisisms of the above?

End goal is to have a world builder which allows a map-view with
drag/drop/cut/paste/double click to edit/rubber band connectors/etc -
but still display the data so that it's usable.  Yes, they're already
out there.  I want to know how that's done.

PjD

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