Re: [DM-dev] Data Management and new API

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

sorry I haven't responded to last night's mail. I've been wiped out with the 
flu, and wasn't up to it....

On Tuesday 11 September 2001 15:11, Henningsen wrote:
> I've got this thought: As long as you (Stephan) commit to staying with the
> project and helping people who want to work with your code, it should be OK
> to me if I don't understand your data management code (just as you don't
> understand some of the inner workings of the Crawler engine). 

Sounds completely fair. I can, with absolute confidence, say that I will be 
100% available for any type of support on "my code" for as long as needed, 
regardless of my association with the project, barring any physical 
circumstance which keeps me from it. It just seems like the right thing to do 
- support one's code.

> What's really
> important is the API. 

yeah!

> When I do my next programming session on the
> DungeonMaker, I should just be able to call methods from the API you make
> for data management, without neccessarily having to understand the
> internals.

exactly!

> I have anyway been thinking that when I extend the DungeonMaker to become
...
> However, let's discuss the API first. What do you think it should include?

At a high level, this is what I think I would "need" from the library. The 
exactly layout within the library (breaking up of the objects) is not done 
here:

a) set generic dungeon parameters (random seed, size, etc.) via set-methods.
This should be done in a generic way so that command-line apps could easily 
translate something like:
mydungeonapp -size 80x120
could easily be "translated" into dungeon code. I'm not suggesting that libDM 
do the translation, but if it offers a simple setSize()/resize() method, that 
would be enough.

b) add objects (rooms, walls, doors, etc.) to the dungeon. I would want this 
done in a way such that I can add Rooms within Rooms. The current model 
doesn't allow this. The big advantage to this approach is that it allows 
"embedding" of any data in a room: a chair, a bed, etc. and you do not have 
to move the extra data if you move the room (because they are contained in 
the room).

c) Load/save my options, preferrably. Though saving is not strictly required, 
I think loading would be.

d) Generate output in some lib-specified "standard" (current ASCII output is 
fine with me).

The DungeonElement code does (a) and (b). It's saving of data is currently 
broken, and I don't see much hope for the method it currently uses. That part 
needs to be re-thought-out and rewritten.

The exact API needed to accomplish this seems to be pretty small, including 
perhaps only 3-6 objects:

1) Dungeon object - where inputs go and outputs come out.
2) Grid (could be an int[][]) - "drawing board" - where the rendering is done.
3) DungeonElement (assuming usage of current code). Some generic dungeon 
object type, in any case.
4) Crawlers

Plus a number of helper objects, like Rooms (wrapper around 4 walls, etc).

The majority of this is already done by the DungeonElement objects, but the 
save/load support there sucks, and I need to re-write some bits which I broke 
when porting it to a flatter model. Perhaps those bits are in CVS, so I 
should be able to pull them out of there.

I'm not at all saying that DungeonElement is _the_ way to do it, it's just 
that we already have that code and it does "most of it". I'd be completely 
open to a delete-all-and-rewrite as well, if we'll get an object model down 
which I can follow.

:)

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862
Handy:  +49 (179) 211 97 67
"Now I've always been the kind of person who doesn't like to trespass, 
but sometimes you just find yourself over the line." -- Bob Dylan