Re: [DM-dev] "stepping through" crawler movement

[Stephan B. <ste...@ei...>]

On Tuesday 21 August 2001 01:55, you wrote:
> >Of COURSE! <smack forehead!> I've never needed to save the dungeon in a
> >post-crawled state! I've been subconsciously assuming that I did! I only
...

> Indeed! I think you never tried the option in the 1.0 version where you can
...

> >I just found my project for tonight...
>
> And that is???

I spent last night re-vamping the file output code. The DungeonElements 
support a full hierarchical approach, but I've made a subclass, DMDungeon, 
which enforces a flat approach, while hiding the data hierarchically. It 
offers a small number of functions for adding elements of specific types 
(Walls, Rooms and Doors, so far). This approach isn't ideal, because a 
programmer would get undesired (invisible) results if he takes advantage of 
the hierachy. The plan is to just warn against that in the docs, and then 
find a workaround for it at a later point, so the user can take full 
advantage of it. It does make dungeon generation (for the user, at least room 
layout and such) much simpler.

So now (in CVS) we've got a DMDungeon with these functions:

virtual DungeonElement *add( DungeonElement *de, int x=-1, int y=-1 );
   virtual DungeonElement * addRoom( int x, int y, int w, int h );
   virtual DungeonElement * addDoor( int x, int y, int w, int h  );
   virtual DungeonElement * addWall( int x, int y, int w, int h  );
   virtual DungeonElement * add( int x, int y, int w, int h , int square_type 
);

For now you should ignore the return values. They are valid, but adding 
elements to them will not show them in the final output. The reason for this 
is that DMDungeon is going to impose a flat model, and will only print out 
it's top-most children (and not let them print their children) in the output. 
This is the only way I've found so far for using a flat text model without 
writing a more complex file parser.

Soooo... code like this:
DMDungeon dungeon;
dungeon.addRoom( 2, 4, 6, 7 );

cerr << dungeon.toString() << endl;

will print:

room=2,4,6,7

If we add walls:
dungeon.addWall( 13, 12, 14, 1 );

it'll print out:
room=2,4,6,7
wall=13.12.14.1

Here's the "problem" with DMDungeon, however:
DungeonElement *de = 0;
de = dungeon.addRoom( 4, 5, 8, 10 );
de->add( new Wall( 2,4, 5, 1 ) );

will output:
room=5,4,8,10
(no wall output!)

the reason for this is long-winded and related to the child objects having 
x/y coordinates relative to their parents. Also, if I output walls here, each 
room would print the following:

room=1,5,10,10
wall=0,0,10,1 // top wall
wall=0,0,1,10 // left wall
wall=0,9,10,1 // bottom
wall=9,0,10,1 // right wall

see the coordinates? The walls are relative to the parent room. The 
"standard" DungeonElement code would print this, but DMDungeon doesn't allow 
climbing down the tree of children.

Such is a hierarchical model. So DMDungeon is going to:
a) only have functions for adding top-level elements.
b) when printing out (i.e., saving), it will not recurse past it's first 
level of children.

that'll get around this problem until I can find a better solution.

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862
Handy:  +49 (179) 211 97 67
"'If' is a pretty big word, considering how short it is." --- Toby Pickartz