Re: [DM-dev] okay, just so I'm clear...

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

On Tuesday 05 June 2001 23:38, you wrote:
> Generations should potentially go up to 100, for large dungeons/small
> maxAge's - I haven't explored that yet but it should remain possible.

That's no problem. The enum can be extended. Also, for all functions=20
which use the enum, I've made them take "int" instead of "SquareType"=20
just for this reason: so people can extend the square types and pass=20
them to "core" functions without having to modify the SquareType enum.

> > be recreated from the grid, is my point. This is the environment
> > the crawlers want, if I remember correctly, so we can get a nice
> > separation of the "dungeon basics" and the "fleshing out" of the
> > dungeon by the crawlers.
>
> Very good, this is indeed what the Crawlers want, every cell one
> value designating its content.

Excellent. This allows us to keep the user-side design completely=20
separate from anything the crawlers need.

=2E..

> I had a Wall class like that designed earlier, just the .h file, with
> WallStartX ,Y , DoorOffset, DoorWidth, ... forget what else...

This is very similar to what I've been thinking, but I didn't know for=20
sure if you were okay with doors bigger than 1 square.

> > data is easily user-editable, so they could mix/match if they want
> > by using emacs (though editing with vi must be righteously
> > unsupported ;).
>
> I guess. If I do the "dungeon evolution" thing, i would also need the
> ability to store data in two files, one "rooms"-file, and one
> "Evolving"-file. I laid those out in an earlier posting.

Yup, I've been thinking about how to handle that. I'm thinking one=20
central object, which is a proxy for several input/output files. That=20
would allow a user to set DungeonElements and genetic data into one=20
place, and that object could then (if needed) split it into separate=20
files. I don't know if that's terribly useful, though.

> Hit things beautifully, i'd say.=20

Oh, good.

> Isn't it much nicer and easier,
> flat-hierarchy style?=20

Easier and harder, actually. The base design is easier, fundamentally,=20
but harder for my brain because I've got what I like to call "The Peter=20
Syndrom," named after my friend and computer mentor Pete Angerani, in=20
Houston. He designs so much flexibility into everything that it never=20
gets finished. You want a text editor which can do your laundry if you=20
write extension LISP code? Pete could do it. He used to "program"=20
pacemakers (it's all done via circuitry, though - no software). He=20
wanted to make them coin-operated, but his mgt didn't like that.=20
I have to back away from that far-too-flexible approach sometimes,=20
because it's not always needed. It's certainly an exercise in=20
self-restraint ;). I agree completely that it's the best approach for=20
this app, though, it's just difficult for me to K.I.S.S. sometimes.

> One thing in case that's not clear: There is no
> need for myself to be able to save dungeons in flat style - all
> saving can be done as higher level objects (in rooms-file). The

I'm trying to take the approach of the higher-level user (i.e., QUB),=20
but you're right in your statement below, I think:

> Dungeonmaker then reads those in, generates flat dungeon, and
> delivers pointer to that dungeon map to library users. Generally,
> users will put more data on the map, and save the map in their own
> format and style.

That's what I'm thinking, as well.

Okay, let me finish up and "flatten out" the object moswl and write up=20
a sample app and then we can begin to mix that in with the existing=20
system, or start writing towards the new genetic stuff you want. I=20
suspect that you will want to wait until colder weather hits before=20
doing that, which (of course) is fine. I can start by porting these=20
objects into the existing DM 0.9x/1.0 architecture, and making an=20
intermediary prototype so we can see where we need to go from there.

See ya!

----- Stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts