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

[bart at wotf.org]

On Mon, 14 Jul 2008 18:08:12 +0000, chris . wrote
> 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'.

A few comments on this.

While DS may be limited to 2d/3d grids, there is no need for a grid, neither
to limit a grid to 3 dimentions.

As long as you have a way to uniquely name your rooms, and can keep track of
'connections', a virtual room system is not limited to a grid at all.

Then, the 'contained in one room' and 'all having the same description' are
implementation details. I'll attempt to write what I believe is a more generic
description of virtual rooms.

Virtual rooms are rooms managed by a daemon in such a way that when a location
is needed, the daemon will either assign an existing but unused, or if that is
not available, a newly created room object to it, and configure the room
object according to information kept for that location.

Those rooms can be cloned from one or more 'master rooms', but it is also
possible to generate an array with code and compile a new room from that for
each location.

In order to not end up with a very large number of otherwise unused room
objects, the daemon also needs a way to cleanup rooms that are no longer in
use (and often as an optimalisation, keep a few empty rooms as a sort of
cache, so they can be configured when needed without having to clone or
generate new ones).

As an aside, my lib contains something called the automapper. It uses a
virtual room system and produces a nice ansi map. It allows builders to walk
around (or directly move to any managed 'location') and edit a set of basic
properties for the location (descriptions for various times of day and
seasons, room items, exits etc). In due time this will be extended to also
cover player building.

Two things I'm currently playing with: 
- A new virtual object system that does much more then just rooms.
- A simple scripting language (using parse_string) to allow adding simple
functionality to virtual objects.

--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/