Author Topic: Virtual Wilderness (again)  (Read 3016 times)

Offline quixadhal

  • BFF
  • ***
  • Posts: 619
    • View Profile
    • A Waste of Time
Virtual Wilderness (again)
« on: August 05, 2013, 06:14:46 PM »
This is an old topic, but I'm pondering the idea of trying to actually make something useful from it.

Those of us who aren't buried in text MUD's only might have noticed a trend in graphical games of late.  The rise of the procedurally generated sandbox game.  Minecraft was the first super-popular example, and now Everquest Next appears to be using a hybrid approach with parts of the world being hand designed, while other parts are generated on the fly.

We've had tinker-toy virtual rooms in LPC mudlibs since 1995 or so, so it's not new... but nobody (to my knowledge) has really made use of them yet.

So, here's an idea for you guys to ponder and help me with.  Let's see if this idea makes any sense, and is doable.

Virtual rooms are essentially a fallback for an object not existing yet.  When your LPMUD tries to load "/d/foo/grassland12.c", if the file exists, it loads and you're done... end of story.  If it does NOT exist, the virtual system attempts to provide an object to associate with that path.  In my understanding, you can do whatever you want, but it makes sense to impose some structure on the path names so the virtual system can hand back the right kind of object.

So, let's say you want your entire world to be data-driven.  You have some method to generate a height map for your terrain, and some method to describe what kind of climate/vegetation/etc would be at various points.  The game tries to load "/d/wilderness/rooms/12,387,-9.c" and that gets passed to the virtual system.  It picks it apart and sees that you want a room and the coordinates are 12,387,-9 (x,y,z).

You look up the height map and find that it intersects at -9 (height) for coordinates 12,387 (x,y), so you are indeed on the surface.  You go lookup terrain, vegetation, climate, etc and see you're in a swamp.  Now, you have to look at some number of coordinates around you (on the height map) and see what other values are nearby, and feed that block of data off to your virtual description engine.

"You're in a murky swamp that stretches south and seems deeper to the west.  A few low hills struggle out of the muck to the north, and some possibly dry scrub brush lies to the east."

You fill in whatever other details you need and create the room.  Now, in addition to handing back the object, you might want to save the room as a permenant file so the next time you walk here, it doesn' t have to regenerate it.  That depends on how much you want to use CPU vs. disk space.  Disk space is cheap.

If your CPU is fast enough, maybe you want to also generate a few other surface rooms around this new room, on the principle that whomever caused it to load will probably walk soon, and so pre-generating a small number might reduce lag and CPU use... YMMV as to the right radius to use for this.

Now, let's say you chose a coordinate that was UNDER the height map?  Your room generator now has to decide... are you underground, or underwater?  If you're underground, we can play minecraft and make tunnels!  If you're underwater, do we make water rooms in a column, up to the surface and down to the floor?

Same goes for above the height map.. you make an air room.  If you're not able to fly, it might be pointless to generate a whole set of air rooms, since you're just going to fall and splat.  Even if you are... do you really want 200 rooms of empty air?  Perhaps making a few layers is enough... from 1-10 above the surface is "air", 10-100 is "high up", and 100+ is "very high up", giving you 3 different "rooms" with descriptions appropriate to the general height.

Perhaps underwater should also work that way.  Nobody wants to type "/repeat 300 up" to get to the surface.  No mud admin really wants a billion seldom visited air or water rooms cluttering up the disk.

In light of that, maybe the actual disk naming should be "/d/wilderness/rooms/12,387,surface.c" where the virtual system would take the original pathname and check the height map, and then recurse itself with the chunked filename.

Thoughts?

Offline chaos

  • BFF
  • ***
  • Posts: 291
  • Job, school, social life, sleep. Pick 2.5.
    • View Profile
    • Lost Souls
Re: Virtual Wilderness (again)
« Reply #1 on: August 05, 2013, 10:20:58 PM »
The "overland map" on Lost Souls (which is a collection of 20 3D maps, each 81x81x11), and various other areas, are handled through a mechanism something like what you describe.  A typical filename format is /d/Project/Subproject/rms/m_x_y_z (aka Project_Room("m_x_y_z") in our project accessibility macro convention), for example /d/Almeria/Cimbra/rms/m_12_-31_1, at which the description looks like:

Quote
     a forest of trees and shrubs [compass, compass:up, u]

   A thick layer of leaves forms the forest floor.  Large trees grow in proliferation, with branches of evergreen needles mingling freely with broad-leafed deciduous branches.  The air smells crisp, and heavy with the scent of pine, cedar, and maple.  Above is empty air.  Northward, southward, eastward, and westward is a mixed forest.  The area is reasonably well-lit. 

    Above you is a slowly moving, heavily clouded night sky.  A breeze blows around you.  The moon is not visible. 

    Obvious exits lead in all compass directions and their upward variations, as well as up.

The terrain is configured, not procedural, and in the case of the general world map at least it really should have been procedural.  There is no height map; everything is just defined by coordinate.  (Which supports things like the area Corpore Scyros, which is a dead god's skull floating in an extraplanar void; height mapping not helpful.)  A partial config file for a smaller area (11x11x5) looks like:

Code: [Select]
<X> 5
<Y> 5
<Z> 2

<SpecifyArea 2>
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''   
'''''''''''   
'''''''''''   
</SpecifyArea>

<SpecifyArea 1>
'''''''''''     
'++''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''     
'''''''''''   
'''''''''''   
'''''''''''   
</SpecifyArea>

<SpecifyArea 0>
...........
.||***...*.
....%T%....
...%TTT%...
..%TTTTT%..
...%oooo%..
.......oo%.
........o%.
.......oo%.
..%%%ooo...
...........
</SpecifyArea>

<SpecifyArea -1>
~~~~~~~~~~~
~#####~~~#~
~~~~###~~~~
~~~#####~~~
~~#######~~
~~~######~~
~~~~~~~###~
~~~~~~~~##~
~~~~~~~###~
~~######~~~
~~~~~~~~~~~
</SpecifyArea>

<SpecifyArea -2>
___________
_#####___#_
____###____
___##ccc___
__##cc###__
___#c####__
_______###_
________##_
_______###_
__######___
___________
</SpecifyArea>

The significance of the terrain type specification characters is configured by terrain definition objects attached to the project.

There's no attempt to write out .c files for generated rooms; as matters stand, that would cause a lot of pain, since writing a .c file is how you create a "custom" room that deviates from the map-generated configuration.  Nor is there an attempt to avoid empty air or underground rooms.

As matters stand, the mechanism is clunky, memory-abusive and insufficiently mutable for my purposes moving forward.  (I require a fully dynamically deformable world, dunno 'bout y'all.)

There's a severe limitation in how much MUDs can draw from "voxel games" like Minecraft because of the requirement that we linguistically describe things.  In Minecraft, if you see a bunch of voxels stacked like this:

Code: [Select]
  ___
 /   \
/_____\
| o o |
|     |
|  H  |

your brain does the work of supplying the description "house".  It's completely impractical to ask a MUD engine to look at a bunch of dynamically deformable voxels and construct "house" out of them, or "mountain range" or "forest".  So in order to get my requirements, I think I'm going to have to have polygons, not voxels, which is a whole area of development that I loathe and am profoundly inexpert with, unfortunately.

Offline FallenTree

  • BFF
  • ***
  • Posts: 476
    • View Profile
Re: Virtual Wilderness (again)
« Reply #2 on: August 07, 2013, 12:41:35 AM »
but.. I guess we don't have to stick to "pixels" ?  That's just how graphical engine draws stuff.  You could. instead, generate a map of objects,  like generating a town with several house and shop, which requires no brain to re-construct :-)

Offline quixadhal

  • BFF
  • ***
  • Posts: 619
    • View Profile
    • A Waste of Time
Re: Virtual Wilderness (again)
« Reply #3 on: August 07, 2013, 02:57:58 AM »
Yeah, I wasn't really thinking of voxels... I was thinking in terms of terrain.  I assume people would hand-edit the rooms if they want them to be more detailed than empty wilderness....  My only interest in "visualizing" the world would be to spot landmarks from a longer distance than the normal scan.

For example, in a normal description engine, perhaps you look at the rooms in a ring that's 3 deep, so you look at 49 pieces of terrain info to construct your local room description.  That will probably give you a reasonable view of the terrain with a bit of randomness for flavor.  However, if there's a big mountain 12 rooms away, and you're on a piece of flat terrain, you SHOULD be able to see it.

I would just like to have a more-or-less infinite wilderness to wander around in without having to create an infinite number of files, or draw on an infinite sized canvas. :)

Offline chaos

  • BFF
  • ***
  • Posts: 291
  • Job, school, social life, sleep. Pick 2.5.
    • View Profile
    • Lost Souls
Re: Virtual Wilderness (again)
« Reply #4 on: August 07, 2013, 07:25:09 AM »
Yeah, I have the distance landmark thing going on.  It basically scans the world out to a distance determined by the maximum visibility distance set by any terrain type and draws lines to see if there are any obstructions, then performs some very rough aggregation by terrain type and tries to describe that.  Slightly more complex output example, from ~Cimbra/rms/m_24_8_0:

Quote
    a forest of evergreens with a paved road [compass, compass:up, u, road:e/w]

    A dense mat of fallen needles forms the majority of the forest floor.  Large evergreen trees grow in proliferation, creating a haven of safety from the cold winds that blow through the region from the north.  A paved road has been constructed here to ease travel between important areas.  It bears signs of considerable use, with shallow paths worn to either side from the many feet that have tread upon it.  Small tufts of grass have begun to grow over the road.  The air is thick with the scent of pine and fir.  Above is empty air.  Northward, southward, eastward, and westward is the evergreen forest.  Far to the south and above, southeast and above, and southwest and above stands a mountain range.  The area is reasonably well-lit.  The road continues eastward and westward. 

    Above you is a still, heavily clouded night sky.  The moon is not visible. 

    Obvious exits lead in all compass directions and their upward variations, as well as up.

The road is an example of an "overlay".  Overlays are secondary map features whose configuration is merged with that of the base terrain types they affect.

The part relevant to what you were saying is "Far to the south and above, southeast and above, and southwest and above stands a mountain range."  You're only seeing it to the south and above because there's forest in between you and the mountain range and it's obscuring the view of the parts of it that are straight south of you.

Speaking of modes of visualization, something else this facilitates is views like this one, which is from that same position and presently available only through a magic item called a panoramicon:

Quote
+++++++++++++++++++++++++++++
+                           +
+ tttttttttttt-ttttttttt-tt +
+ tttttttttt--tttttttttt-tt +
+ ttttttttt-ttttttttttt-ttt +
+ ttttttt--ttttttttttt-tttt +
+ ttttt--ttttttttttttt-tttt +
+ tttt-tttttttttttttt-ttttt +
+ tt--ttttttttttttttt-ttttt +
+ t-tttttttttttttttt-tttttt +
+ -tttttttttttttttt-ttttttt +
+ ttttttttttttttttt-ttttttt +
+ tttttttttttttttt-tttttttt +
+ tttttttttttttttt-ttttteee +
+ ttttttttttt-@---ttteeeeee +
+ tt---------tttttteeeeeeee +
+ --ttttttttttttteeeeeeeeee +
+ tttttttttttttteeeeeeeeeee +
+ tttttttttttteeeeeeeeeeeee +
+ ttttttttttteeeeeeeeeeeeee +
+ tttttttttteeeeeeeeeeeeeee +
+ ttttttttteeeeeeeeeeeeeeee +
+ tttttttteeeeeeeeeeeeeeeee +
+ ttttttteeeeeeeeeeeeeeeeee +
+ ttttttteeeeeeeeeeeeeeeeee +
+ tttttteeeeeeeeeeeeeeee... +
+ ttttteeeeeeeeeeeeeee...tt +
+                           +
+++++++++++++++++++++++++++++

If you're wondering why in the world somebody decided to make the mountains "e", well, so I am I.

Offline FallenTree

  • BFF
  • ***
  • Posts: 476
    • View Profile
Re: Virtual Wilderness (again)
« Reply #5 on: August 08, 2013, 08:52:54 PM »
in chinese mud there is also "maze" generator, which is less awesome in practice, but it is same concept

Offline Nilrin

  • Friend
  • **
  • Posts: 85
    • View Profile
Re: Virtual Wilderness (again)
« Reply #6 on: August 09, 2013, 09:19:09 PM »
I use virtual rooms extensively as well. Simply put, I have moderate sized text based map files which tell the virtual room server what room is loaded where. I also have a set of commands which populate the map files with different rooms. For example, I can tell the MUD to design me a forest based virtual map, populate it with lots of obstructions, and various forest based rooms. I can then manually go in to the map file and edit the remainder of it by hand, adding roads and such. Finally, the rooms have some limited procedural code which modify how their description is displayed, connecting rooms, verbally describing blocked directions, landmarks, etc...

I couldn't agree more with chaos, having the server spit out .c files would probably be terrible. I currently use the persistence concepts already put in place in DS. If a virtual room is destructed and has anything worth saving in it, such as the player leaving some items there, it persists and creates its own .o file. If the virtual room is unchanged, it destructs and returns to the void, as there isn't anything worth saving that the virtual server can't recreate.

Offline donky

  • Acquaintance
  • *
  • Posts: 35
    • View Profile
Re: Virtual Wilderness (again)
« Reply #7 on: August 13, 2013, 12:21:05 AM »
Special room paths with an embedded coordinate, used to dynamically instantiate virtual terrain, were standard in Discworld mudlibs back in the late 90's.  The ability to see beyond your current room was not.  Well, you could probably "look north" and see who was in that room, but that was about it.

We took it a bit further and procedurally generated room contents based on coordinate.  Our algorithm was only a simple one, but it worked rather nicely as a prototype.  Then we wanted to see people in the nearby area, as if there were no rooms in the virtual terrain area.  So we went with an approach where the player didn't move rooms, and all players in an area were simply in the same room.  What they could see and interact with, was determined by proximity.  Writing this, it sounds much more advanced than it was, it was still just a prototype and very roughly coded.

At this point, it gets fuzzy.  But I imagine that one of the other creators went away and just mucked around, and came back with a polygon based world.  We had gravity, sea level and contour following.  There was a VRML module hooked into the web server, to allow visualising the now 3D world.  And people could write static rooms to override the virtual terrain.  However, all rooms were now clones of the file "/std/object/terrain", and were indexed in the movement handler and requested directly by the movement code.  There was no reason to virtually clone rooms based on embedded coordinates in the path.  Drop from the sky to the water, and you drowned.  Drop from the sky to hit ground and you likely reached terminal velocity.  Contour following checked steepness of slope for each player movement, and disallowed it if it couldn't be climbed.  These were all trivial things built into the initial system, and I think development petered out after that.

The reason I am posting about this, is that I just stumbled across the post and it was rather topical for me. Just last night, I coded a simple dynamic description generator based on 3D coordinates.  When it became obvious that I'd need to write some ray casting mechanism in order to say something like "the desert extends in all directions, except the distant west where dirt ground can be seen.", I went back to look at our old code and our old board archives.  I can provide a stripped down mudlib, if anyone is interested in the code.

Offline donky

  • Acquaintance
  • *
  • Posts: 35
    • View Profile
Re: Virtual Wilderness (again)
« Reply #8 on: August 13, 2013, 01:15:44 AM »
Okay, I went back and looked at our mudlib release, and the code is in there.  Download url on this page.  If you modify anything to get it running, please feel free to submit a patch, and I'll update the public version so people can play around with the weird stuff we implemented.

Likely files to look at:

/cmds/creator/room.c
/cmds/creator/struct.c
/cmds/creator/terrain.c
/handlers/area.c
/handlers/coord.c
/handlers/polygon.c
/handlers/room.c
/handlers/terrain.c
/handlers/vrml.c
/std/body.c
/std/body/movement.c
/std/modules/coord.c
/std/terrain.c
/std/polygons/
/std/objects/terrain.c

Note that all the code should be define based, and I think the defines are in /include/global.h or whatever LPC used by default back then.

Offline quixadhal

  • BFF
  • ***
  • Posts: 619
    • View Profile
    • A Waste of Time
Re: Virtual Wilderness (again)
« Reply #9 on: August 13, 2013, 04:17:40 AM »
Sounds interesting, I'll definately take a look at that this week.  Thanks!

I'm certainly not fixed on the idea of needing to use a particular mechanic.  The goal is to make a virtual wilderness that's auto-generated (perlin noise, fractals, pulling GIS data, whatever), so people can freely wander around and explore, encounter random events, and so builders can find an "interesting" area and plunk down to build things there.

My idea environment would be one where you can wander around and type "edit here" to have it write out an actual room file which could then be hand-edited, or use whatever OLC system your MUD already has, and which you could return to wilderness by just removing the file.