Re: [DM-dev] lines of communication between objects

[Henningsen <al...@gl...>]

>For the upcoming changes we'll need to define some lines of 
>communication between the various objects. I mean, we'll need to decide 
>which objects know about each other, and how they interact. If we can 
>abstract this a bit (like by subclassing Rooms and Crawlers from a more 
>generic DungeonElement) they we will get the most extendability out of 
>it. These are my initial thoughts about who has to know about who 
>(denoted by arrows pointing to/from the classes):
>
>For example:
>Rooms <--- Walls
>This means that Rooms need to know about walls, but walls don't need to 
>know about rooms.

I would prefer the DungeonMaker to be simply a random dungeon generator, and
all the design elements it needs are Walls, Crawlers, OpenSquares, and
Columns. Single wall tiles are degenerate Walls with start=end. Any other
objects, like Rooms, SpecialRooms, SuperSpecialRooms, etc. should be handled
in a design program that is an extra layer above the DungeonMaker. The
Dungeonmaker should be kept as simple as possible, with no unneeded design
objects in it. If we go that way, the hierarchy is flat, with no design
object needing to know about another.

>All <---- Config (config is a bad word for this, because it implies ini 
>file, when it's really more generic than that - suggestions for a 
>better name?)

How about DungeonData? As I understand it, the config object will manage the
DungeonMaker data, like in read it, serialize it, store it, allow
modifications to it during interactive design... then we'd have the
DungeonMaker, the DungeonData, and, if you want to bring all kings of extra
objects like fancy rooms into the fray, the DungeonDesigner. Or if we adopt
the style of ..Maker, ..Designer, and we want to make a little joke, we
could instead of DungeonData call it DungeonKeeper. How about that?

>The way I envision the basic Room API is something like this (of 
>course, completely up for change, though):
>
>Remove/AddWall( Wall ); 
>AddWall( int x1, int y1, int x2, int y2 ) 
>// creates a Wall and calls AddWall( wall )
>// must assert that x1==x2 OR y1==y2 (no diagonal walls), but this will 
>be done in Wall, and Wall will have a bool IsStraight() method which 
>returns false if the wall is not "straight".
>
>typdef list<Wall *> WallList;
>WallList GetWalls();  // DM can use this to actually lay out the room.
>
>Various other STL-like iterator methods will also be supplied, for 
>looping through the walls.

I hope you see the wisdom of keeping this out of the DungeonMaker class, and
starting a DungeonDesigner class. (Of course, only after the DungeonMaker
runs smoothly on Walls alone.) In the DungeonDesigner, i think you should
start with functions for moving Walls, either in total, or by stretching
them. Then from that you can build functions for morphing Rooms. With the
Rooms, remember that they should have Crawlers attached to them, which will
build unbroken walls between the room and an outside wall or another
structural wall, and thus define the basic dungeon architecture. That is the
whole idea of these pre-defined rooms. Their purpose is to be used together
with the OpenSquares to implement story elements. If they are not structural
in this sense, we may as well wait for DM2 and use random rooms. For
structural rooms, I think it would be best to start with just a few types,
the most basic being "2 doors, 2 Crawlers, player is forced to pass
through". I actually think it would be quite sufficient for design if one
placed a few of these, and then had the capability of morphing them.

Peter