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

[bart at wotf.org]

On Tue, 15 Jul 2008 13:39:10 +0000, chris . wrote
> > 
> > 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.
> 
> I chose 2d/3d grids so that i could use graphical ansi maps (as in 
> dead souls).  The rooms will not necessarily be in a big block at 
> all.  The DS_style function, however, makes big blocks.  I decided 
> to keep it despite its 'squareness', for things like rooms in a 
> skyscraper, or etc.

Grids are convenient, and I use them for exactly that reason, but the
underlying virtual room system is not limited to those.

The actual need for that arrises from wanting to be able to connect rooms to a
mapper that are not part of the grid and do not show directly on a map, but
are still managed by the same system.

> I prefer using write_file to create physical copies of room.  This 
> design choice may make the map maker daemon more applicable to Gurba 
> and Windfall than to other libs.  The reason for this is legacy, for 
> MudOs orientated builders, as well as my own preference to handle my 
> objects from the file system.

Any lib that I have seen can support both designs. The big advantage of using
a storage server is that you can take a much more efficient approach to
virtual rooms (see some discussion in the cleanup part below)

For the record, while I am not familiar with it on a code level, I know
Cratylus and discussed the virtual room system in DS with him when he was
working on it.

> 
> > 
> > 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).
> 
> Yes i had neglected to deal with the clean-up issue.  My approach 
> will be to create physical room objects when the daemon runs.  As 
> such, clean up would be a matter of compilation / creation.  Object 
> clean up is probably a seperate matter from the Map Maker, and since 
> Gurba and Windfall are in non-persistent state, I will probably deal 
> with this in coming months for my second version of Windfall.

I disagree because it is possible to design a virtual room system that never
uses more room objects then it really needs and seldom needs to clone or
create a new room object.

Consider the following approach to a virtual room system

Player enters the mapped area, the coordinates for his new location are
checked for an existing room object, if it exists, player is moved to it.

If it doesn't exist yet, a new room object is cloned, assigned to the correct
coordinates, configured according to whatever data exists for that location,
and player is moved to it.

When the player moves to a new location on the grid, it is checked for an
existing room, if none exists, the room with the player is reconfigured for
the new location and the player is given appropriate messages as if he moved.

When the player moves to a room outside the grid, the player is moved, and the
room he came from checks if there is anyone else in it, if not, it destroys
itself.

You have to account for objects and monsters, but the idea should be obvious.

Variations on this setup are widely used on traditional lpmuds (I didn't think
it up, no idea who did), and are very efficient cpu and memory wise.

It does require that the rooms are cloned, and that it is possible to
reconfigure rooms for new coordinates at will.


> > 
> > 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.
> 
> I like OLC and i certainly plan to implement it heavily.  Your 
> specific idea with adding commands for builders to work on rooms 
> while in the room is a great convenience, than for the builder to 
> call functions directly, or to 'patch and upload'.  And especially 
> easier than using ed, for freaks like me.  Are you developing for 
> the community or for your own project?  I dont remember seeing a 
> release for your lib. In a couple weeks I would like to have my 
> DS_style function working, and have designed a set of 'option 
> functions' (really just simple text matching scripting).

This is for my own gamelib which is not public.

I am using a variation on the above described system which needs a few extra
room objects but causes the player to actually get moved to a new environment
on each move, so all the things that are caused by an environment change also
get triggered properly.

The goal of my automapper project was to be able to create relatively large
(upto a few hundred rooms) areas that can be decorated efficiently while
preserving the 'feel' of handcoded rooms, and to make it easier for some not
very technical but quite creative people to be involved in building.

> Thanks for your time.  Ill be happy to learn more about your map 
> work and/or participate in its development where there is common 
> ground between the 2 map daemons.

Codeveloping with me is not an easy task :P

Maybe I can show you some of the mapper and virtual room stuff on the
development version of my mud later, try to catch me online (wotf.org, port
23, usually during the evening, central european time)

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