I Heart Virtual Rooms

[Nilrin]

It's absolutely true. I do love virtual rooms.

However, the more I toy with virtual rooms, the more ideas and questions arise, some of which I find both intriguing as well as frustrating.

Question #1: Not so long ago I worked on a MUD named Ascension, which was built on the Nightmare library. Sadly it's down now, but I do like to think I learned a bit in the inner workings of the library. My last project before the MUD sadly closed down, was none other than Virtual rooms. When creating 'wilderness' as they called it, a good portion was creating .txt map files. These files would basically be a grid of numbers, telling the virtual room server which rooms are at which part of the grid. If I remember right, the head of the file would be an array of file names and their corresponding character symbol, with the rest of the file being the grid map.

The file looked something like this:

10 12

LF /domains/Zrena/virtual/light_forest.c
DF /domains/Zrena/virtual/dense_forest.c
PP /domains/Zrena/virtual/plains.c

DF DF DF DF DF DF DF DF DF DF DF DF
DF DF DF DF DF DF DF DF DF DF DF DF
DF DF DF DF DF DF DF DF DF DF DF DF
DF DF LF LF  LF LF LF LF DF DF DF DF
DF DF LF LF  LF LF LF LF DF DF DF DF
DF DF LF LF  PP PP LF LF DF DF DF DF
DF DF LF LF  LF PP PP LF DF DF DF DF
DF DF LF LF  LF LF LF LF DF DF DF DF
DF DF DF DF DF DF DF DF DF DF DF DF
DF DF DF DF DF DF DF DF DF DF DF DF

The first part of the file would be the X, Y limit of the array.
The second part of the file are the file names and corresponding map keys.
The third part is the grid.

In short, my question is to what extent is this supported? I do see a couple of sample map files, including desert_map and forest_map, but they only seem to be dummy files, and are not actually used within the current virtual room implementation. Further more, I can't seem to find much documentation on the subject in general.

I'm extremely interested in the capabilities of virtual rooms, and am dying to explore the possibilities.

Question #2: I was wondering what the implications would be in creating moderate to large sized virtual areas, and then using the "unvirt" command extensively to convert most or all of the virtual grid into tangible files. Obviously depending on the size of the grid, this would potentially add up to a large number of files. A simple 20 by 20 grid would be 400 rooms, assuming they were all converted and all were used (no impassable areas or anything).

It seems though, that there would be a few positive aspects. A few that come to mind:

1. No extra functionality would be required with the peer command, as they would be regular rooms, hence peer would function normally.

2. A creator could create a single virtual file, IE: forest.c, which had detailed semi-random descriptions, camps, encounters, terrains, etc... and then go through and "unvirt" the entire area, which would keep those randomly generated descriptions in that state forever.

For example, if you left town into the wilderness and walked due south, you'd run into that same oak tree everyday, and the same boulder laying next to it. With randomly generated virtual rooms, this wouldn't be the case as soon as the room was removed from memory.

3. Might make wilderness, in general, easier to edit and modify file by file, or in some ways, perhaps more difficult.

-------------

Anyways, these are just some thoughts I had on wilderness.

[quixadhal]

First, let me say I haven't look at the virtual room system in DS, but... I'll spew out how *I* would make it work if it were my project.

Essentially, there's no real reason to have to do anything "special" for virtual rooms.  The way I'd handle it is as a hook in the compile_object code.  When you want to instantiate a room (either by being moved into it, or having it loaded via an exit), presumably compile_object gets called with the room filename, /d/Fooland/downtown/mainstreet.c.

If the file in question doesn't exist (or isn't readable), the normal handling is to return an error and not allow you to move there.  However, there's no reason you can't trap that and have it call compile_virtual_object (or whatever) with the same filename, returning the result of that call.

CVO can look at the filename and decide if it's something that's valid to be virtualized, and how to do so.  It might load a file and parse it to figure out what kind of room to make.  It might also call an algorithm.  In any case, once done, it returns an object just as if the file had existed on the disk.

That's the key part.

Personally, I don't really care for virtual maps where you have to lay out the terrain types on a grid.  I've always felt it's far more elegant to use an algorithm which will always give you the same value if given the same coordinates.  It's also more fun!  As a builder, I can walk around the world -- which initially is entirely virtual!  When I see an area I like, I can choose to start building there by editing the rooms and saving them to their filenames.

Let's say I'm walking through /d/world/room_1273x87x-817.c.  The algorithm decided that's a rocky hilltop, and there's a stream to the south, some woods over the stream, foothills to the north, and rough lands to the west.  I decide that's a good place to put an orc camp!  All I should have to do is edit /d/world/room_1273x87x-817.c, and save it.  That should write it to a file by that name.  Now I can go hand-edit the file and change things however I like.

By default, the exits will link to the next coordinates, but I can change that too if I want the scale to be different, or I want to move to a more traditional room layout.  I can make 200 rooms and have their edges link to that one point, or actually take up the space in the map by naming them for all their coordinates.

Now, that's my blue-sky model.  People who actually work with DS can chime in with how much work it would be to do something like that, or how much of it is already in place.  Hopefully this makes some sense, it's a bit later than I though it was.

[cratylus]

I love virtuals, too. Old as they are, they
somehow still have a Next Generation feel to
them, don't they?

Question #1
...
In short, my question is to what extent is this supported?

Not at all, I think. As I recall, a DS user did
eventually get it to work after a lot of work,
but it's not something I've worked on getting
online out-of-the-box.

I'm not against it. I like the idea and probably
will get around to supporting it (especially
since it would make my own project easier). I
just haven't got around to it yet.

Question #2: I was wondering what the implications would be in creating moderate to large sized virtual areas, and then using the "unvirt" command extensively to convert most or all of the virtual grid into tangible files.

Beats me. Depends on what you're trying to accomplish.

1. No extra functionality would be required with the peer command, as they would be regular rooms, hence peer would function normally.

Sure but probably I should just fix "peer" if it doesn't
work for virtuals

2. A creator could create a single virtual file, IE: forest.c, which had detailed semi-random descriptions, camps, encounters, terrains, etc... and then go through and "unvirt" the entire area, which would keep those randomly generated descriptions in that state forever.

Though it depends on the nature of the random feature, I
can see that this would often be of value. I agree with quixadhal,
though, that if load-time consistency is the point, then there are more elegant
ways of accomplishing it.

3. Might make wilderness, in general, easier to edit and modify file by file, or in some ways, perhaps more difficult.

This is probably a matter of preference. I'm pretty sure there
are a couple of folks out there who find the idea of "unvirt"
to be offensive (you know who you are)...and believe that
everything should be in the virt definition. Different strokes, etc.

Further more, I can't seem to find much documentation on the subject in general.

Yeah, virtual rooms are an unfortunate doc lacuna. I've
often found my lib resurrection project to be a kind of
archaeology, and sometimes I feel like a researcher
who finds a fabulous manuscript with huge stains, holes,
and missing pages.

There is pretty much no "virtuals" documentation in DS,
and I have not added any. Why it is missing in the first
place is hard to know. I suspect that it is something
Descartes did not find especially interesting, or just
didn't get to. You can find some documentation in the
Lima lib ( http://dead-souls.net/code/libs/lima-1.0b5/lib/help/wizard/coding/virtual )
but it is obviously not guaranteed to be 100% applicable to DS.

The reason I have not added virtuals docs is that I
like them a lot, and have been actively extending
their functionality (see my excited posts about falling
from one medium to another, etc) and want to write
the docs once I'm sure the thing is static and I
won't have to re-write them. I want to be sure
about the design decisions I finally come to, before
I set them in stone.

I'm talking about lib docs of course. There's nothing
stopping anyone from describing the general mechanics
of how virtuals work, and indeed, I think the lima docs
do just that. Regarding explicit details of virtuals
in DS, I'm afraid the only answer I have for you is
"sorry, not documented yet."

-Crat

[Nilrin]

Alright cool, thanks for the help and replies!

I think I might toy around with Virtual rooms and see if I can get the whole mapping thing to work. It doesn't seem like it'll be too tricky.

[daelaskai]

I had done a virtual area similar to the one you are describing.  I'll see if I can dig it out soon.

Daelas

[Nilrin]

That'd be awesome. Looking forward to it.

[daelaskai]

Okay, after some digging, I pulled out the virtual area that I had working.
This is a port of an old Nightmare/Foundation virtual grid that was modified
slightly (not much at all, really).

First, you have the exits.db file:

Code:

#
# Comment  :  This data base defines which rooms connect to which
#               O is a normal room
#               * is an exceptional room (exceptions.c is called)
#               |/-\ indicate where rooms have exits to each other
#               the ... boarder is just so you included enough spaces
#             The virtual area can be of any size, but you must alter
#             terrs.db as well, so each room has a description.
#
           .
 O-O-O-O-O .
  \|/  |   .
   O   *   .
   |       .
   O       .
           .
............

Then you have the terrs.db

Code:

#
# Comment  :  This data base defines which description is used for each room
#             The spacing of the numbers, and the 0's are significant
#             The positioning is the same as in exits.db
#             The numbers refer to the order the descripions
#             appear in descs.df
#
01 02 03 02 04
-- 05 -- 06 --
-- 07 -- -- --

Now comes the descs.df file:

Code:

/*
// Comment  :  This data file contains the descriptions for the rooms
//             Which room gets which description is chosen by terrs.db
//             You can use the same description for more than one room,
//             but don't over-use this or the area will be boring.
//             I made this a Data File (.df) not a Data Base (.bd) so that
//             you can use descriptions longer than one line per room.
//             NB If you see a room with these comments as a decription
//             then you have made a mistake. (entered a room off the map)
*/
### Short 1
Long 1.
### Short 2
Long 2.
### Short 3
Long 3.
### Short 4
Long 4.
### Short 5
Long 5.
### Short 6
Long 6.
### Short 7
Long 7.

Next.... 3,2.grid.c :

Code:

#include <lib.h>
inherit LIB_ROOM;

void create()
{
    ::create();
    SetAmbientLight(30);
   SetClimate("indoors");
    SetShort( "The Nexus" );
    SetLong(
      "Neon blue light beams strike off to infinity in all directions "
      "forming a giant 3D lattice against the otherwise featureless void. "
      "This is The Nexus - the focal point of all virtual servers - and the "
      "gateway into the myriad realities supported by them."
    );
    SetListen( "default",
      "You feel in your bones the vibrations from a deep background hum." );

    SetItems( ([
        ({ "floorboard", "floorboards" }) :
        "Be careful where you walk, they are rotting through in places.",
        "woods" : "The great woods which surround the shack.",
      ]) );

    SetExits( ([
        "north" : "/domains/default/virtual/grid/3,1",
      ]) );
}

void init()
{
    ::init();
}

void reset()
{
    ::reset();
}

These files were all put into a directory.  /domains/default/virtual/grid/
In /domains/default/virtual, I put a file called grid_server.c and one called
grid.c

grid_server.c:

Code:

#define VIRT "/domains/default/virtual/"

mixed compile_object(string file) {
    string *path;
    object ob;
    int x, y;

    //if( previous_object() != master() ) return 0;
    path = explode(file, "/");
    //if( sizeof(path) != 5 ) return "Wrong size path";
    if( file_size(VIRT + path[3] + ".c") < 1 ) return "bad file";
    if( sscanf(path[4], "%d,%d,%*s", x, y) != 2 ) return "missing info";   
    if( !(ob = new(VIRT + path[3], x, y)) ) return "failed to compile";
    return ob;
}

/* EOF */

grid.c:

Code:

#include <lib.h>
#include <dirs.h>
#include <virtual.h>
#define WHERE "/domains/default/virtual/grid/"
#define SUFFIX ".grid"

inherit LIB_VIRT_LAND;

mapping data;
string *exits;
string *terrs;
string *descs;

varargs void SetLongAndItems(int x, int y, int z);

varargs static void create(int x, int y) {

    SetNoReplace(1);
    virt_land::create();
    SetClimate("temperate");
    SetAmbientLight(30);

    data = (mapping)this_object()->get_data( (x+","+y) );

    SetExits( data["exits"] );

    if( data["exception"] )
this_object()->modify( (x+","+y) );

    SetLongAndItems(x, y);
    SetGoMessage("You can't travel in that direction.");

}

varargs void SetLongAndItems(int x, int y, int z) {
    ::SetLongAndItems(x, y, z);

    SetShort( data["short"] );
    SetLong( data["long"] );
    SetProperties( data["prop"] );
    SetItems( data["items"] );
    SetInventory( data["inv"] );

}

void modify( string arg )
{
    object room = previous_object();
   
    switch( arg )
    {
    case "3,1" :
    room-> AddExit( "out" , "/domains/default/virtual/start");
    break;
    }
}

mapping get_data( string arg )
{
    mapping data = ([]);
    string format;
    int x, y, i;

    exits = read_database( WHERE "exits.db" );
    terrs = read_database( WHERE "terrs.db" );
    descs = explode( read_file( WHERE "descs.df" ), "### " );

    // Get coordinates of room (x,y)
    // X increases to the east, Y increases to the south
    sscanf( arg, "%d,%d", x, y );

    data["prop"] = ([ "indoors" : 1, "light" : 1 ]);

    sscanf( terrs[y][3*x..3*x+1], "%d", i );
    sscanf( descs[i], "%s\n%s", data["short"], data["long"] );

    data["exits"] = ([]);
    data["inv"] = ([]);
    data["items"] = ([]);
    format = WHERE "%d,%d" SUFFIX;

    if( exits[2*y][2*x..2*x] == "\\" || exits[2*y][2*x..2*x] == "X" )
data["exits"]["northwest"] = sprintf( format, x-1, y-1 );
    if( exits[2*y][2*x+1..2*x+1] == "|" )
data["exits"]["north"] = sprintf( format, x, y-1 );
    if( exits[2*y][2*x+2..2*x+2] == "/" || exits[2*y][2*x+2..2*x+2] == "X" )
data["exits"]["northeast"] = sprintf( format, x+1, y-1 );
    if( exits[2*y+1][2*x..2*x] == "-" )
data["exits"]["west"] = sprintf( format, x-1, y );
    if( exits[2*y+1][2*x+2..2*x+2] == "-" )
data["exits"]["east"] = sprintf( format, x+1, y );
    if( exits[2*y+2][2*x..2*x] == "/" || exits[2*y+2][2*x..2*x] == "X" )
data["exits"]["southwest"] = sprintf( format, x-1, y+1 );
    if( exits[2*y+2][2*x+1..2*x+1] == "|" )
data["exits"]["south"] = sprintf( format, x, y+1 );
    if( exits[2*y+2][2*x+2..2*x+2] == "\\" || exits[2*y+2][2*x+2..2*x+2] == "X" )
data["exits"]["southeast"] = sprintf( format, x+1, y+1 );

    if( exits[2*y+1][2*x+1..2*x+1] == "*" )
        data["exception"] = 1;

    return data;
}


/* EOF */

Please note that I haven't tested this on any recent version of DS.  It isn't
the greatest system and I've been working on a newer system that uses a
bunch of default rooms, like you initially mentioned such as:

light_forest.c
dense_forest.c
plains.c

The map file would look something like this once completed:

Code:

.map
.map
 *-D-D-D-D-D-D-D-D
    \  |X|/|\|/|/|
     p-p-H p-p-p-p-p-p-p-p-p
        \|/| |/|
         p-D-D-D
.legend
p is path.c
H is house.c
D is dense_forest.c
* is special.c

Hope this helps for now until I complete my work on the nicer system.

Daelas

[Nilrin]

Awesome! It never occurred to me to include exit keys. With the system I was using, it just assumed that every room was linked every direction.

As I'm a bit new to Dead Souls, seeing your post, I did a "man read_database" command, and giggled at the NOTES section of the document.

This does make me want to ask though, is read_database really that inefficient?

[daelaskai]

Thanks for reminding me.  I think DS uses this:

Code:

string *read_database(string file) {
     string *ret;
    string tmp;

    if(!file_exists(file)) return 0;
    if(!(tmp=read_file(file)) || tmp == "") {
        return ({});
    }
    ret = explode(tmp, "\n");
    ret = filter_array(ret, "database_filter", this_object());
    return ret;
}

int database_filter(string str) {
   if(!str || str == "" || str[0] == '#') return 0;
   return 1;
}

I don't think it is that inefficient, though I'm not really the person to answer that.
The function I use is this:

Code:

string *read_database(string file)
{
    return (filter(explode(read_file(file), "\n"),
    (: $1[0] != '#' && $1[0..0] != "" && sizeof($1) :)));
}

There is another discussion currently going on in the forum about the
differences between the two methods and which one is better.

As to the exit keys, it's a little better in my opinion.  I've never
used a system that assumed every room was linked in every direction.
While it would still be okay, it would probably use more resources
to parse the map file and on top of that, what if you DONT WANT
a room in that direction?  My personal preference really.  As I said
I'm still working on a better version (in my opinion) for this system.

Daelas

[quixadhal]

Hmmm, I've also seen it done by assuming adjacent cells have all exits possible, but trying to draw them out in ASCII makes it difficult because you have to use extra symbols.

If you want sparsely linked rooms, using _ | + X / \ and * work ok, but you can't easily represent some situations with one character.  If you use more than one character, you can't link rooms unless you use a LOT of white space between cells... and THAT makes it really easy to introduce typos.

Code:

~ water
# swamp
. grassland
% forest
^ hills
* mountains

 0123456789AB
0 ~~~~##....%.
1 ~~~##...%%%.
2 ~###...%%%%%
3 ##...%%%%%..
4 ......%%%%..
5 ............
6 .......^^^..
7 ......^^^^^.
8 ....^^^^**^^
9 ..^^^^*****^
A ...^^^^***^^
B .....^^^*^^.

In this case, you'd want all rooms to be linked in all directions (*), but perhaps there is no travel across water or mountains, so the ~ and * terrains would have no exits ( ).  Now, the tricky part is that the edges really should be marked so you can't try to walk into the water rooms.  The swamp terrain wants to be (/), but it also wants to be half of (\), and there's no character to do that which would be easy to remember.

We know we could just assign characters to force the builders to remember them... but that's ugly.

To represent all the possible exit choices for a 2D grid with 8 directions, you'd need....

( ) 1 for no exits
(*) 1 for ALL exits
8 for rooms with only 1 exit, in each possible direction.
8 for rooms with 7 of 8 exits, one missing in each possible direction.
I think the choices for 4 exits are the two crosses (+) and (X), and then a wedge (n,ne,e,se) which can be rotated 7 times (ending in nw,n,ne,e)?
The cases for 2,3,5 and 6 exits per room require math, which I'm not up for right now.

In any case... LOTS more characters than you can come up with that would look reasonable.

Personally, I'd go for a fully connected grid and just hand-edit rooms where you don't want it to be fully connected.  In other words, make your grid_server check to see if the actual room exists and just return that if it does.  Maybe it would already do that...

The idea being, if you hand-code a room with the right name, it should just be loaded.

To be extra-clever, you could add a "save" function to the rooms that would let you forcibly push the virtual definition onto disk as the appropriately named file.  That would let you edit it however you wanted.  Another "virtualize" method would remove the room file and reclone it from the virtual grid, thus removing customizations -- in both cases you probably have to move the player so they end up in the new object and you can dest the old one.

[Nilrin]

With the one I worked with in the past, when it generated a virtual room and it went to look at adjacent rooms for exits, it would know if the way was blocked or not with a "is_blocked" variable in that room. So basically, you made a virtual room type that's sole purpose was to provide a short description and a blocked flag, IE: ocean.c, wall.c, etc...

Apart from this, it also had an "is_trail" type variable. What this would do is look in adjacent rooms to see if any of those also had the "is_trail" variable set to true. If it did, and the room is the same as the current one, it would amend to the description to indicate such.

So, for example, a room could read like this:

This is an area of dense forest with very little undergrowth. A thick canopy prevents most light from shining through. The trees in the area are large, and tall, showing signs of a recent fire.
A vast ocean prevents travel to the northeast.
A vast ocean prevents travel to the east.
A vast ocean prevents travel to the southeast.
A game trail continues to the south from here.
A game trail continues to the north from here.

[daelaskai]

Certainly that works too.  If anyone has a finished system to share that'd
be great.  Until I get the newer system going, I'm just using this roughly
done grid.

Daelas

[Tricky]

Not quite a virtual room system but I thought I'd mention the maze/area generator I posted earlier this year...

http://lpmuds.net/forum/index.php?topic=646.0

Tricky

[Nilrin]

Pretty basic, and it doesn't have error checking, and my coding abilities are stinky poo, but it pretty much works for basic needs.

This would be the basic map/key file. It's just hard coded but easy to modify.

Code:

#include <lib.h>
#include <dirs.h>
#include <virtual.h>

inherit LIB_VIRT_MAP;


string *virtualmap;
string row;
string *column;
string key;

varargs string array BaseMap(){

              // 1  2  3  4  5
virtualmap = ({"FO FO FO FO FO", //5
               "CL FO FO FO FO", //4
               "FO FO PD FO PD", //3
               "FO FO FO FO FO", //2
               "FO FO FO FO FO", //1
             });
return virtualmap;
}

string FindRoomFile(int x, int y){

row = virtualmap[(y-sizeof(virtualmap))*-1];
column = explode(row," ");
key = column[x-1];

switch(key){
case "FO": return "/domains/ylsrim/virtual/forest";
case "CL": return "/domains/ylsrim/virtual/plains";
case "PD": return "/domains/ylsrim/virtual/pond";
     }
}

varargs static void create() {
    ::create();
}

This would be an example of an individual room.

Code:

/*    /domains/Ylsrim/virtual/desert.c
 *    from the Dead Souls V Object Library
 *    created by Descartes of Borg 960302
 */

#include <lib.h>
#include <dirs.h>
#include <virtual.h>

inherit LIB_VIRT_LAND;

string ob1;

varargs void SetLongAndItems(int x, int y, int z);

varargs static void create(int x, int y) {

    string n, s, e, w, ne, se, sw, nw;
    SetNoReplace(1);
    virt_land::create();
    SetClimate("temperate");
    SetAmbientLight(30);
    SetLongAndItems();

    SetShort("Dense Forest");
    ob1 = "/domains/ylsrim/virtual/forest_map.c";

    e = ob1->FindRoomFile(x+1,y);
    e += "/" + (x+1) + "," + y;
    AddExit("east",e);

    s = ob1->FindRoomFile(x,y-1);
    s += "/" + x + "," + (y-1);
    AddExit("south",s);

    w = ob1->FindRoomFile(x-1,y);
    w += "/" + (x-1) + "," + y;
    AddExit("west",w);

    n = ob1->FindRoomFile(x,y+1);
    n += "/" + x + "," + (y+1);
    AddExit("north",n);

    ne = ob1->FindRoomFile(x+1,y+1);
    ne += "/" + (x+1) + "," + (y+1);
    AddExit("northeast",ne);

    se = ob1->FindRoomFile(x+1,y-1);
    se += "/" + (x+1) + "," + (y-1);
    AddExit("southeast",se);

    sw = ob1->FindRoomFile(x-1,y-1);
    sw += "/" + (x-1) + "," + (y-1);
    AddExit("southwest",sw);

    nw = ob1->FindRoomFile(x-1,y+1);
    nw += "/" + (x-1) + "," + (y+1);
    AddExit("northwest",nw);
   
}

varargs void SetLongAndItems(int x, int y, int z) {
    mapping inv, items;
    string str;
    ::SetLongAndItems(x, y, z);

    inv = ([]);
    SetLong("This is the long description for dense forest.");
    SetItems( ([ "trees" : "Bunches of trees." ]) );
        }

Pretty much just modified the virtual stuff already in place.