Re: [DM-dev] idea!

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

>I just started working on the Rooms/Walls combos and came up with some ideas 
>I'd like to throw by you and see if they sound as useful to you as they do to 
>me:
>
>Current DM holds it's own array of ints for the map. I'd like to split that 
>into a DMGrid object, which does the same thing but in it's own object. The 
>reason is simple:
>
>bool Room::render( DMGrid & );
>
>lets the room "draw" it's contents onto the target grid. Returns false if 
>there is some error (out of bounds, etc., though the item would still be 
>rendered as much as it could.

That sounds good to me, go ahead. But make sure the bounds checking is
solid;-) We are not concerned with running fast, so definitely check the
bounds in the DungeonMaker, even if the DungeonDesigner checks them also.

>Even better would be to make a Renderable interface and have Room and Wall 
>subclass that, then we have:
>
>DMGrid::render( Renderable * );
>
>But I'm not sure what the Renderable API would have to look like (it would 
>have to be generic enough to allow the DMGrid to handle drawing for all types 
>of objects, and this seems a bit complex). I'd appreciate any ideas on a 
>Renderable API which would allow DMGrid to handle all the rendering.

Very simple - if you accept my idea of keeping anything above Walls out of
the DungeonMaker, there will only be (I think) four different objects that
will ever have to use this interface, and they are all known to you right
now. The complicated object hoierarchy will be in the DungeonDesigner.
However, don't make things more complicated than needed;-) Elegant code is
not neccessarily easier to understand and maintain.

>Does this sound okay? It would also mean simplification of the DungeonMaker 
>class internals and API (plus adding Set/GetGrid() methods).

Yeah, keep it simple, man;-) Use the Renderable interface only if it
actually simplifies things, which i doubt it does. Avoid code bloat!!

Peter