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

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

>> 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 
>sure if you were okay with doors bigger than 1 square.

Actually, you should ensure that all doors are larger then minCorrWidth.
Currently I have minCorrWidth = 2, and I expect to have agents in those
dungeons with radius 1.2 or so, definitely over 1. Imagine the fristration
if they could not move through the doors in some dungeons. That's what
minCorrWidth is for, insure that all passages are wide enough for the
agents, so it must be enforced on doors too.

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

Yes, KISS!! - we all have to remind ourselves of that from time to time.

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

I'm actually considering scrapping the dungeon-evolution stuff, due to some
negative feedback I got on the idea: Basically it was that users would
always (mis-)use their ability to rate dungeons to try to get the highest
score, and rate dungeons higher not on the fun they had while playing them,
but on the ease with which they could beat them. If that is done, it will
IMO tend to lead towards extreme and possibly degenerate dungeons - either
very open or very labyrinthine, whatever is better for the player to win.
That's something I don't want. So i consider scrapping the evolution thing.
Anyway, I'll do the "random room" thing first, that definitely has higher
priority with me ( and with you, right?). I think next cold season I will
want to do the rooms-thing, the "focal point - precomputed paths"-thing, and
then write a sample game in SDL or Nebula Device. 

If you come to finish the things you want to do on the DungeonMaker, and
have switched it over to work with your objects and files, I would probably
do the rooms-thing even over the warm season, just slowly. I can handle
writing a bunch of code every week, just not keeping up with your furious
pace of change;-) Remember though, it must compile on MinGW:-( or I'll not
work on that branch. The Windows market is still quite a bit larger than
Linux<sniff>.

Peter
http://alifegames.com      website re-launched with new content
read    "Complicity and the Brain: Dynamics in Attractor Space"
at           http://alifegames.com/project/ComplicityBrain.html