Re: [DM-dev] finally!! how does this sound?

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

On Sunday 10 June 2001 16:50, you wrote:
> >Then we have various convenience functions in Dungeon:
> >DungeonElement * addRoom( x, y, w, h );
> >DungeonElement * addDoor( x, y, w, h );
> >DungeonElement * addWall( w, y, w, h );
> >etc.
> >These are all functionaly identical except that they set the square type,
> > so they'll all just call:
> >DungeonElement * add( x, y, w, h, squaretype )
> >which simply calls add( DungeonElement ) on the created element.
>
> Hmm, I wonder what happens when you addDoor in the middle of open space? Or
> a door that has all its wall on one side, none on the other? I think this
> could lead to problems with rooms, or make very complicated
> special-case-checking neccessary. So I'd prefer if we had two types of
> walls, walls with doors and walls without, but no doors as separate

One of the problems with this non-hierarchical model is that we simply "throw 
pieces into a big sandbox", and hope they are in the right place. It's then 
up to the programmer to make sure that it "makes sense." It is 100% possible 
for a door to end up in the middle of a wide open space with this approach. 
If you add Doors to Walls (or to rooms), this can't happen. But then than 
drastically complicates the file format. I don't have a way to reload the 
data if I use a hierarchical approach, however (without using a binary 
format, XML, or something like it, none of which I really want to use). I can 
save the heirarchy, but if I can't load it, it's useless.

> DungeonElements. The Wall without door could be the same class, just using
> a different constructor (or default values in the same constructor). And a
> higher level design program could have a function "AddDoorToWall", but in
> the dungeonmaker itself we'd only have doors as parts of walls. Would that
> mess up your plans? I'm pretty sure it would be simpler to code, and less
> error prone.

The simplest, from a generic coding perspective, IMO, is the hierarchical 
approach, but we can't save that data in a useful way by using a flat text 
format. With that approach, however, it is a simple matter to do any checks 
to see if this child really belongs here (for example, a Dungeon could 
outright reject a door added to it, but a Room would not, and a Dungeon would 
not reject a room). Also, all elements get placed relative to their parents, 
so you never need to worry about calculating the x/y of child elements. Place 
them relative to where they belong (the parent) and let object take care of 
the coordinates adjustment itself during rendering (which is what they 
currently do). 

During the rendering process, it all comes out to a flat structure, anyway, 
100% exactly like the 1.0 ASCII output format. But it will be basically 
impossible to restrict what the user does before we get to that point, unless 
we have a model where, for example, a Dungeon can only accept Room children, 
and Rooms can only accept Wall or Door children. This type of arbitrary 
restriction scares me, though: "...control is a degree of inhibition, and a 
system which is perfectly inhibited is completely frozen." -- Alan W. Watts

It's been my experience that to add arbitrary limitations to the API does 2 
things: 
1) frustrates the coder, who may not understand the need(?) for them. 
2) adds to maintenance and code complexity as you find yourself working 
around your own (arbitrary-assigned) limitations(!).

e.g., if someone places a door in the center of an open space, let them. 
Maybe it's a magical portal. It's their dungeon, after 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