[DM-dev] okay, just so I'm clear...

[Stephan B. <st...@wa...>]

Okay, before I redo this, I want to be sure that I'm imagining the right 
thing. If not, please feel free to adjust me in the right direction. This is 
as much a thinking session as it is a question. So... I may answer it myself 
by the end ;).


In the end, logically, we will have a grid with N objects on it. These 
objects can be doors, walls, open spaces - anything defined in the 
DM::SquareType enum: (DM.h)
    enum SquareType { sq_None = -1, sq_Floor=0, sq_X=1, sq_Wall=sq_X, 
sq_Hash=2, sq_Open=3, 
                       sq_C=4, sq_Reserved=5, sq_Y=6, sq_Door=7,
                       sq_Gen0=10, sq_Gen1=11, sq_Gen2=12, sq_Gen3=13, 
sq_Gen4=14,
                       sq_Gen5=15, sq_Gen6=16, sq_Gen7=17, sq_Gen8=18, 
sq_Gen9=19,
                       sq_Gen10=20, sq_Gen11=21, sq_Gen12=22, sq_Gen13=23, 
sq_Gen14=24,
                       sq_Gen15=25, sq_Gen16=26, sq_Gen17=27, sq_Gen18=28, 
sq_Gen19=29,
                       sq_X_EW,  sq_X_NS, sq_X_10,
                       sq_Last // just a placeholder, to control looping
                    };


Each cell is completely independent of any other cell. For ease of writing 
new dungeons, we abstract some of that into higher-level objects like walls 
and rooms (which are only a wrapper around 4 wall objects). These objects are 
not hierarchical in any way, and not related to one-another. For flexibility, 
the high-level objects can be "moved around" in the grid while "in memory", 
and are then rendered to an integer-based grid (the top-level container 
object, the "Dungeon"). This means, for example, that a coder could do this:
room->move( 5,7 );
Once it is rendered to the grid:
dungeon.renderTo( mygrid )
the data "in the grid" is immutable as an object - each cell must then be 
dealt with independently. The higher-level objects cannot be recreated from 
the grid, is my point. This is the environment the crawlers want, if I 
remember correctly, so we can get a nice separation of the "dungeon basics" 
and the "fleshing out" of the dungeon by the crawlers.

The utility in functions like move() and resize() and such are that they make 
GUI-based dungeon editors possible. Users can drag the room around, and it's 
position changed. When it's saved, though, it's "rendered". The down-side of 
saving in this format, though, is that you can't reconstruct it later on. 
Thus these high-level objects need to be able to write themselves out (and 
read from) a higher-level format, like:
room=x,y,w,h
wall=x,y,w,h
door=x,y[,w,h]


In actuality, room and wall will be of the same object type, except that it's 
SquareType will be different. This means that the words "room", "wall", and 
"door" will translate directly to some SquareType value. Hmmm. That means 
that the C++ classes Room, Wall, and Door are overkill, as they are all 
DungeonElements with different SquareTypes (under this slight change in 
thinking, anyway). So all I have to do is remove the add() methods, or 
restrict their access to protected (so higher-level subclasses can be 
created, but client apps can't do it), and then do away with Room, Wall, and 
Door, or make them one-line subclasses for convenience and ease-of-reading. 
Then I've gotta add:

	string toString();
Returns "<sq_type_name>=x,y,w,h"
	static DungeonElement * 
	DungeonElement::fromString( const string & );
Parses a dungeonelement from [something=x,y,w,h].

Then there's the file load/save, but most of that code is already done. It's 
mainly re-org of the existing stuff, I think.

So, we would have a file format which looks (for DungeonElements, anyway) 
like:
room=x,y,w,h
room=x,y,w,h
room=x,y,w,h

Or how about simply:
object=x,y,w,h,square_type
this is less human-readable, however.

This format we can read and write and use to restore a 
programatically-generated dungeon to it's original, object-based state. That 
may not be useful for DungeonMaker, but it'll be very useful for other apps, 
where users can edit their dungeons.

The down-side of this, though, is that if you want a door on your wall, 
you've got to keep track of 2 objects:
wall=x,y,w,h
door=x,y,w,h

If you move wall, you've gotta move door. That's the down-side of a flat data 
format. Of course, we could write code to parse things like:

wall=x,y,w,h[,doorx=(x+w/2),doory=(y+h/2),doorwidth=1]

This would assume that all walls get a door near the center, or we could use 
a slightly stricter format:
wall=x,y,w,h  // no walls
dooredwall=x,y,w,h[,doorx=(x+w/2),doory=(y+h/2),doorwidth=1]

Using an altered version of the config file object we can use hopefully use 
that object for the storage of DungeonElement and other dungeon data, like 
the stats data, etc., using ini-style settings for those as we've discussed 
before. Then rooms data can be stored in the same file with the stats, etc., 
but each type of data is easily user-editable, so they could mix/match if 
they want by using emacs (though editing with vi must be righteously 
unsupported ;). 

Have I hit everything, or just beat around it all?


----- Stephan Beal - st...@wa...
http://qub.sourceforge.net - http://gwm.rootonfire.org
http://byoo.rootonfire.org - http://dungeonmaker.sourceforge.net
"Now I'm not normally the kind of person who likes to trespass, but
sometimes you just find yourself over the line." -- Bob Dylan