[MUD-Dev] Re: Overworld Maps on diku style Muds- Design notes

[Katrina McClelan]

On Wed, 22 Jul 1998, Richard Woolcock wrote:

> > a) Coordinate World
> > 
> > The coordinate world, would be divided into square terain sectors.  Each
> > Sector Grid would have it's own table of encounters.  Also each sector
> > grid would have a localized list of 'objects' (programming term, not
> > swords) that one might see.  The world would be (MAX_X by MAX_Y by 2) (the
> > z dimension is either ground level or sky level)
> 
> Ground, sky...what about underground/water (drow city?  atlantis?)...
> 

ground I had thought about, and planned to have specific caves rather than
worry about it in a coordinate sense, since the main goal was to generate
land mass without having thousands of rooms and detailing it all.
Granted, I now make the assumption that the ground is fairly solid and not
full of as many holes as a sponge, but this is not an outrageous
assumption.  Water I hadn't thought about.  Probably could duplicate the
logic on the overworld, and have bottom of the ocean, and then above it as
sector A, and sea-level, and sky above it as sector B, and then define
visibility between the sectors accordingly.

> vii) entry from below ;)
> 

Yeah, if you start adding depths, you do need this, although, I would tend
to find a floating city uncommon  :)  The big problem with adding too much
vertical perspective is that it makes line of sight a lot more difficult
to handle.  It's not a perfect solution, but it should work, in general,
minus a few specific cases.

> My first attempt at this was a very simplified version of what you describe.
> It was simply a 1000x1000 2D map, each room of which could be either a sort
> of 'wilderness' room, or a link to an area.  It took an entire weekend to 
> code, and I started rewriting again it within a week because I found it too
> restricting.
> 

Well, one of my goals is to avoid having 1000x1000 rooms, and instead
abstract the space and deal with it as I need to.

> My current method is a 5120x5120x40 3D map, each room of which can be one of 
> 512 different types OR have a static room mapped over the top of it.  I don't 
> have EXIT_DATA - instead, each room can contain doors, walls and various other
> room-specific things.  Suppose I wanted to stick your "Myth Drannor" city into 
> the mud... Instead of putting the whole area at a specific location, I would put 
> down each individual room, add any walls or doors, and the surrounding rooms 
> (the air above, earth below, etc) would already be in place.
> 

This is much closer to a coordinate system, which is great, but it is also
a lot more complex to set up than my goal was.  It also has some flaws
that you mention below:

> The main downside with this is that my system doesn't allow overlapping rooms,
> and it assumes that every room is the same size.  In addition you would have to
> 'buffer' empty locations with rooms of some sort...for example if you had a city
> layout which looked like:
> 
> [1]--[2]--[3]--[4]
>  |    |         |
> [5]--[6]       [7]
>  |    |
> [8]--[9]
> 

That isn't as much problem as the standard size room:

[1]--[2]  [4]
 |         |
[3]-------[5]

(2 is a closet in 1, which is a bedroom, 4 is an adjacent bedroom, and 3
and 5 are hallway rooms... yeah, you CAN put room 6, extra hallway in, but
that ends up being a wasted room that usually has a crappy description in
it.)

> If you wanted to go south from room 3, most muds would say something like "there
> is no exit that way" - well in my mud, there is ALWAYS an exit - although it
> could be blocked with walls all around it (but what if someone broke them down?).
> Assuming your areas are written specially to cater for this, you shouldn't have
> a problem, but if not it *can* start to look a bit odd (if you didn't do anything,
> you'd probably end up with an empty room, a patch of plain, or something similiar
> behind the wall).
> 

Heh, this is similar to my ideal mud.... no rooms at all, it's all
objects, including organic (living) objects.  You can always try to go
south, but some object (a big bouncer to the bar, a door, a wall, a pile
of rubble, a tree, etc) could be in the way.  Of course you can always
launch a fireball at the obstacle with varied results.  However it would
take me years to set up and run such a mud, as well as MUCH better
hardware than I have access to, since the game engine would basically be a
collision handler (sword collides with flesh, the sword will do damage to
the flesh, but in turn, the sword could take damage too... for all
solid objects this is somewhat sane.  gases and liquids are much harder to
handle... (Derek jumps into a pool, causing a collision, but how do you
make Derek "wet" with "water" in terms of objects, ot handle the fact that
water can be broken up into an infinite number of infintesmally small
particals)

> On to your other subject, of objects in the virtual rooms...I got around this by
> saving objects as they get dropped, and destroying them as the room gets recycled.
> If someone re-enters the room, the objects get loaded back up, automatically 
> renamed if appropriate (eg corpses become rotting corpses, then rotten corpses,
> then skeletons, etc) and placed back into the room.  I plan to re-write this part
> of the code though, as it's too inefficient by far (and besides, my world is 
> starting to look like a graveyard, with skeletons and bits of bone everywhere).
> One solution I had toyed with in the past was to move the objects out of the rooms
> and into a list, so that they could be re-distributed should that room later be
> re-entered (perhaps if the objects are not put back into play for a while, they 
> THEN get saved to disk?).
> 

First:
Not looking to be that detailed.  For my purpose, it is acceptable to have
objects "evaporate" after a while, as long as no one is looking.  The
problem with worrying about keeping objects forever, is that objects would
also have to not ever appear from nothing, meaning that the world would
have to be set at startup.  Additionally, mobiles would all have to exist
all at initial condition.  If they got killed, they stayed dead.  There'd
have to be a way for normal reproduction.  Extinction would be possible.
The system would also have to be able to deal with a set of blood thirsty
players.  (oh btw: players pose a problem since they can't just appear out
of no where either, and what do you do with them when they aren't logged
in?  That's worse than dealing with objects being consistant)

I don't think anyone has managed this part of it, so trying to worry about
objects is kinda silly.

Second:
If I were going to do that, then I would do it exactly as you propose.
Save them in memory until they idle out to disk so that players can't
merder the system walking back and forth  ;)

-Kat