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

[Nathan Yospe]

On Sun, 25 May 1997, Raz wrote:

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

*chuckle*

:[time passes]

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

Good, good... always nice to get more input.

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

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

:You wouldn't believe the shock I got when reading this =)  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.

I've been playing around with coherent positional modeling for quite a
while. Two words: smoke & mirrors. Only... what happens when someone gets
a sonar mapper? *grin* OK, so we have to make it at least plausibly model
reality... this is where it gets hairy.

: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 =)

Which list? Ah... *shrug* Well, there are two issues here. 3D, and random
generation. The two are independent, but both pose interesting problems.

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

Well, we've got one going now.

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

Ah, now we're getting into interesting new thoughts. Um. OK, I've tried to
get some degree of this The edges of the approved format area in
Singularity 2 are essentially randomized repeated landscape types seeded
off of the location that continue on indeffinately - or at least, for some
2^31 cm in any given direction. 21,000 km is pretty well a continent
already, so that should be enough, I think. Other than that... well, you
can blow down walls, dig through ground, fly over obstacles, dive under
water... I think I've pretty well got the basis of the kind of system you
are suggesting. Unfortunately, it does depend of the diligence of
builders. Walls and ground default to concrete and bedrock, etc, etc, etc.
In order to have your cardboard wall tear down when a drunk stumbles
against it, you have to designate the walls as cardboard. A builder could
seal a wall, make the exit a tube and everything around it some
indestructible material.. or the roof of some vast underground cavern
could be battle steel, and unscratchable... or infinite stone.

: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 =))

2D of arbritrary dimensions... I'm sure I'm missing something here... And
3D does work better. But I'll get back to that.

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

Interesting...

: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 =)

Which is where you begin to run into the limits of a grid...

: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? ;)

OK, here is how I handled this: rather than turning X degrees, you turn
"toward" a destination. You are evaluated in terms of your current 3D
coordinates, but everything in the region of a node is still stored in a
list. (I am experimenting with a version of the list that is actually,
inside of its guts, a quadtree implementation... but my container classes
are interchangeable.) So... you have a description of what you see, from
where you are standing and the direction you are facing. You evaluate a
command to move toward something in your FOV, or face it, or turn around
~180 degrees, or look up, or down, or turn right (default at ~15 degrees,
though it may evaluate differently depending on circumstances) relative to
your character's POV. This is an element of my natural language parser, in
any case, and tied up into the fundamental concepts of the game. I do
prefer the node/relative coordinates/list storage approach to the rather
more limiting grid approach, however.

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

I love these sorts of things. Of course, there has to be an element of
resetting for an area... the citizens must rebuild, and total destruction,
while not repairable from one character's POV, is moved into a sort of
parallel universe for everyone else. Kinda confusing, when I try to
describe this, but I have provisions for absolute destruction only
applying to Character's belonging to the destroyer of said city's
controller.

:Anyway that's what I had and how I was going, and why I put it firmly on
:the back burner =)  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.

I still do have "rooms" for this very purpose. (Well, that and aesthetics.
I think getting a room described in its entirety is appropriate, while a
field only describes what is in front of you, witha  speed narrowed cone
of vision.

: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..? =)

Mine are. =) After all, an imp's castle is a giant's shot glass.

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

*grin* Don't worry, it'll come to you. (I use composite rooms of variant
dimensions.)

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

:Continuation eagerly, and hopefully, awaited =)

:Raz

Speaking of which.... if I was incoherent, blame it on lack of sleep.


   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu