[DGD] DGD Map Maker Structure Report..comments?

[chris .]

Requesting comments re: my approach to designing a robust map making daemon.
thanks




The DGD/LPC Map Maker 

0. Overall Purpose and Planning

 

  The version of Map Maker I will begin building will be designed with both Gurbalib and Windfall R2 in mind.  It should be easily portable to other platforms as well.  The map generation features I plan to include will be coded alongside comments, and will help describe how a builder can create his own map generation features.  I have no plans to offer some 'cliché' map generation features which would be expected on a robust release; things like 'dungeon' maps.  Map Maker will also include generation features not expected, but useful for a modern or post-apocalyptic themed Mud.

  My ambition is to provide a footing for other builders to add on to this code and the map generating features provided in the stock release.  This is not my project nor do I wish to direct development beyond the contributions I am making in code, and to what weight my opinion would offer. 

1.    Virtual Rooms (Other map gen features out there?) 

  Before going into design organization and implementation I would like to discuss the bit I know about 'virtual rooms' and their use as a map generating utility.  If there is any other work i am missing in this respect I would be grateful were anyone to inform me.  There are two reasons i chose to bring up some history.  The strongest of the two is that the implementation of Virtual Rooms into the lib in Dead Souls is done in a similar fashion as I intend to implement Map Maker into Gurbalib and Windfall.  The other valid reason is that Map Maker will possess the functions to create a similar equivalent to Virtual Rooms.

  For those who do not know, Virtual Rooms are rooms contained inside of one master room, all with the same description.  The dimensions of these may be set but they must be squared (X*Y) or cubed (X*Y*Z).  The DS version creates rooms in memory, and than accesses these rooms using the grid inside of the 'master' room (the master room is just a room inheriting the virtualroom library).  Mobiles or objects can be set to load in the newly created rooms at a random rate, or can be added to every room for that matter.

  Rooms created as virtual rooms are able to use a map feature in DS.  This is simple to do, because DS creates rooms in a grid.  In a cubed grid, than the map will show 2 dimensions at a time (X*Y).

That sums up about virtual rooms in DS, and leaves us with what Map Maker has in mind with Virtual Room 'know-how'. 

2. The DGD/LPC Map Maker's version of Virtual Rooms 

  I plan to scrap entirely the usage of a 'virtual room' (a room without a master copy that is created and exists purely in memory).  Instead, the master copies of rooms are created, placed into a designated folder, and are kept on a back burner until a connection is made to an area or the backbone (or they are compiled and visited directly by a builder).

  The rooms will be designed to fit in an x*y(*z) grid, and will have functions which generate an ansi map image.

  The rooms will not 'fill in' a grid in any traditional sense.  Instead a library of 'blocks' will exist; blocks will be placed throughout the grid as best as they can fit.  Blocks would consist of twists, turns, dead ends, paths around rocks, small (6 room) rooms in a somewhat linear path (a 'mini backbone'), and etc etc.  The Map maker would hence fill in the grid with blocks much like a game of tetris gets played.  Since the rooms need to conform to an x*y location, the Map maker functions will all have functional parameters to allow the builder to choose how densely he wishes to fill a certain grid, the choice and/or number of Blocks for Map Maker to build from, the begin/exit point.  Designing this map maker will require lots of testing and observation.  An alpha version will be coming whose code will be open to the community.

  The Map Maker will have several different map making functions, for use with different terrain themes.  These will be based on world biomes (http://www.worldbiomes.com/biomes_map.htm).

The Map Maker will also support room 'stocking' of objects and/or mobiles.  The stockable objects are stored in a library of their own.  The code for which of these objects to be stocked, at what random chance, and etc is determined by room code from within the 'building block' lib.  I will illustrate with a quick example:  A block of rooms exists for a path around a large boulder. Each of these rooms bordering the boulder has a set chance of loading a wildflower object in that particular room.  The individual rooms inside of the block contain the code for object stocking. 

3. Portability 

  I would like to make the Map Maker as open to the community as possible.  What would be nice would be to have a single version which was a standalone daemon.  You could tell it what lib you would like to have rooms created for, and than go wild.  I am not going to code this to work on every lib available on DGD.  For now I will create a version for GurbaLib and Windfall. 

4. varargs string *options 

  Map Maker did have some security concerns while its design was being conceptualized.  I did not want to allow builders the ability to write their own functions into a rooms code.  Of the many reasons, a lack of standardization in room code comes to mind.  Instead I thought out a final parameter, varargs string *options.  Each value entered into options is switch'ed for a match to a case.  Each case thus acts as an 'option function'.  The option functions will provide a robust means for builders to build areas.  Functions will exist for object creation, random chance object creation, room sound effects...a working example will be in the works featuring a full implementation of several useful option functions.  A structural example is included below: 

5. Structral Example (code) 

/*

inherit BLOCKLIB;

*/ 

int x_axis, y_axis; /* Used for maps and map generation */

int z_axis; /* For map generation */

int callout_counter;  /* a value gets set, and is sent through a callout and *

                       * --'ed for as long as this value is> 0. */ 
 

void create( void ) {

  } 

void DS_Style(int x_width, int y_width, int z_width,

              string roomDesc, varargs string *option_funs) {

  int i;

  int totalRooms;

  object connobj;

  string *usedOptionFuns; /* Makes sure we don't double call an option fun */

 

  if(option_funs)

    for(i = 0; i < sizeof(option_funs);i++) {

      switch(option_funs[i]) {

          case "test":

              /* option function 'test' code goes here ->. */

              break;

              }

            }

  totalRooms = x_width * y_width * z_width;

 

  /* Break process into chunks processed over a period of time (max 20m)*/

  /* Is this a good approach/practice? Input welcome. */

 

  switch(totalRooms) {

    case 190..200:

        /* each 10 rooms gets allocated a minute.  A call out is called every

           minute to do another batch of 10 rooms.  Comments for this feature? */

        return;

    default:

        return;

      }

  return;

  }
_________________________________________________________________
Use video conversation to talk face-to-face with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_072008