[MUD-Dev] Rooms, 3D arrays, etc.

Raz muddyraz at mushroom.demon.co.uk
Mon May 26 03:43:57 New Zealand Standard Time 1997


Damn.  Some time after writing and queueing this message, I discovered =
the
conversation going on in "RP Thesis"... ah, well, never mind... =3D)

[time passes]

And now I find the "Virtual rooms" thread!  Aarg!  Well, its written, and
its getting posted... =3D)

On Sun, 25 May 1997 12:20:58 PST8PDT, Michael wrote:

> 	So why not set up such a 3D array, with a default description=20
> based on terrain type.  For the rooms that actually get "created", you=20
> simply give it a special description.  In this system, "exits" should =
be=20
> replaced by barriers.  In effect, you should be able to go in any=20
> direction you please, as long as there isn't something in the way.

You wouldn't believe the shock I got when reading this =3D)  For a moment=
 I
thought I'd sleepwalked, powered up my machine, posted this message, then
gone back to bed again!

Well, okay, not all of it.  Setting time travel and such aside just for =
the
moment, this is something I really really want in my system, but after
nearly a year of on and off dreaming about it I just can't think of a
system coherent enough, solid enough, and ultimately one which would =
result
in a game world playable enough to be worth taking to implementation.

Incidentally the last point in that little list was something impressed
upon me by friends I told about the proposed system.  They couldn't shake
visions of vast tracts of empty, lifeless, barren mud-world - despite how
much I babbled about pre-determined environment settings, automatically
handled flora and fauna, dynamic landscapes, etc =3D)

I was thinking of posting on this subect again - it was, I think, the =
main
thing I talked about when I was last active on the list - and hopefully
striking up a discussion about it.

I'm very taken with the idea of a system which *never* replies "You can't
go that way", but instead either moves you or suggests *why* you can't go
that way, and lets you figure out how to overcome it.

Working from memory, the closest I got to any kind of system before
concentrating on other things ran something like this:

You have a 2D matrix of abritrary dimensions - this is 'World', your game
world.  (Yes, obviously 3D makes more sense, but that led to problems I
couldn't overcome at the time =3D))
A player's movement along the X and Y wrap, so you have workable if not
physically accurate 'globe'.
World is assigned a 'null' environment, which Beings cannot enter (more =
on
this later).
Builders then construct an Area by first specifying X and Y coordinates
relating to the World a width and height, and environment attributes that
will be assumed by any 'Virtual Spaces' in the Area.
  Within an Area, Zones are constructed be specifying a shape (Y ammount =
of
X-start and X-stop coordinates) and placing it at coordinates within the
Area matrix.
  Each zone also specifies environment coordinates.  If I recall, this
arrangement was to allow smoother environment transitions between two
radically different Areas placed adjacent to each other.
    The builder is then free to follow a Space syntax and construct what =
I
named 'explicit Spaces' in each zone, giving each a coordinate and fixed
size; thus providing the means to add any textual/descriptive richness =
the
builder wishes.
    Any part of the Zone and, therefore, the Area without an explicit =
Space
becomes a virtual Space when the game runs, most likely created when the
first player enters and destroyed when the last exits - though things =
never
got that far.

That, pretty much, was the idea, and I think at first glance it offers
quite a nice world.  However, there were many problems I ran into.

The first was 3D world features.  How to model pyramidial mountains, for
example?  That was one of the reasons I kept the model 2D and tried not =
to
think about players flying =3D)

Space sizes was another thing I wanted to take further.  Spaces shouldn't
really be all of a fixed size, but ig explicit Spaces were allowed to be =
of
differing sizes, how does the system reasonably try to fit virtual Spaces
around them?  Players would face a nightmare just trying to walk around.
16, or even 32, points of the compass, anyone? ;)

Towns and cities were a major headache.  Back alleys, houses and gardens,
walls that could be climbed over or broken down made me cry; images of
players with ropes and grapples swarming over guildhouses and Crocodile
Dundee'ing their way through a top floor window haunted my dreams.

Anyway that's what I had and how I was going, and why I put it firmly on
the back burner =3D)  Recently though, after telling myself I was going =
to
forget the whole thing, I've started thinking about it again.  I've =
thought
that a possible answer, at least to the towns problem, would be some kind
of 'structure' object, which would be dropped into a Zone and mark off =
the
size and rough shape of any particular, well, structure.

The structure wouldn't care about what was inside it, we'd sort that out
with additional Spaces... hmm, which I suppose would need to be tied to =
the
Structure in some way...  In fact this would seem to describe a general
'container'.  Castles and beltpouches really of the same ilk..? =3D)

Oh yeah... castles... ick.  Model a castle...

Okay, time to stop the thinking aloud.  I'm generally at my least =
coherent
then.

Continuation eagerly, and hopefully, awaited =3D)

Raz




More information about the MUD-Dev mailing list