[DM-dev] design decision question:

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

Good morning, all!

Question for Peter:

There a couple of ways of managing the Rooms/Walls/Dungeon=20
relationship, and I'd like to detail what I see as the differences and=20
get your idea on which one to choose:

As we discussed once, we could get rid of Dungeon, and make everything=20
a Room. This has the advantage of simplification of the API and=20
heirarchy, but it may not be compatible with the crawlers. Rooms could=20
contain any number of other rooms, just like a UI does with it's=20
widgets. A dungeon is just a big room, after all.

I started on the Walls last night and came up with the following=20
parameters for each wall: x, y, length and orientation (horiz or=20
vertical). This keeps the user (and us) from having to check for=20
(x1=3D=3Dx2 || y1=3D=3Dy2, i.e., for enforcing non-diagonal walls), and=20
simplifies the API further.

The question, though, is about the x/y: should they be relative to the=20
dungeon or to the containing room? It could be done either way.=20
Room-relative _seems_ to make more sense to me, but I'm not sure if=20
that's the best approach for this project.

I think the answer lies in the Crawlers' behaviour: do they navigate=20
the dungeon based on the values of the map grid, or do they interact=20
with the Rooms objects in a more complex manner? If they navigate the=20
grid directly, then I think it's safe to make the x/y ROOM-relative,=20
because we will render the rooms, then let the crawlers lose. If they=20
navigate the rooms in some other way (by interacting with the Rooms=20
objects), then I'll need a much clearer understanding of this=20
relationship before I start so I don't break the crawlers.
Room-relative is a higher-level approach than making them=20
Dungeon-relative (but if the Dungeon was just a room, "stray" walls=20
could be placed in the Dungeon with the same API). The main advantage=20
of this approach, I think, is that it's consistent with UI-building=20
techniques: you always give coordinates of child objects based off of=20
their parent. It also allows easily creating heirarchies of rooms and=20
walls and them dumping them into the Dungeons (or removing them). This=20
also means that in config files, users don't have to change a room's=20
walls if they move the room - they simply change the x/y coords of the=20
room itself and all child walls move with it.

The disadvantage, though, is that I'm not sure if that internal=20
representation is compatible with the crawlers. If a crawler breaks=20
through a wall of a room, for example, that "hole" won't be stored in=20
the room itself (because the crawler is working off of a rendering of=20
the room, and not the room itself, so the room never sees the hole), so=20
regenerating the dungeon won't be as simple. I don't think that's=20
_such_ a concern because we can regenerate the dungeon as long as we=20
have all the rooms intact and the random seed, I think.

If you'll tell me that the crawlers simply analyze the grid after the=20
rooms have been rendered to it, I'll continue with this more=20
heirarchical approach.

I've got save/load of data working, so now I just need to get the=20
objects done so I can save them ;).

Your opinion(s)?

See ya!

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet