Re: [DM-dev] Dungeonmaker going on version 2 ...

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

>The second design file you sent turns out much better than the one from last 
>week.

I haven't really put much energy into making good designs yet - I'm still
fiddling with the code. Today I worked on a design, but also changed the
code about a dozen times, all concerning the same little problem - I was
trying to make it happen less often that Tunnelers abruptly come to an end -
you know, as if the little orcs were still at work there. That was happening
very much in earlier versions, and I have reduced it to a few occurrences (0
- 3 per dungeon), and I think now it's acceptable. I don't think I can
totally eliminate it.

>i haven't been through any code yet (except to slow the movie down),

HaHa, your system must be faster than mine... I put the speed so low because
I wanted things displayed as fast as they could be computed, no waste of
time. Did you try the 3 different showMovie/storeMovie options?

>not sure how the dungeon stored. What i'd like to see is the dungeon stored 
>in an intermediary object, instead of rendered directly to the graphical 
>area, so we can make ascii dumps, etc.

Oh, it is, the Dungeon is stored in Map, and accessible through GetMap,
though only on a per-square basis. However, it would be easy as pie to pass
the entire Map as one reference (though you'd also need dimX and dimY to
make sense of the one-dimensional Map-vector). I also store the movie, and
already pass it to main() - when you set showMovie=0, storeMovie=1 the
dungeon will be generated, and *then* the movie will be shown from this
stored version. This will be useful because the Tunnelers cannot guarantee
to connect all exits from the dungeon to the entrance, and disjointed
dungeons will have to be rejected before the movie is shown. The showMovie=1
option is mostly for design, where one can see exactly which generation of
Tunnelers/Crawlers does what, an insight that is essential for modifying the
design. If you set showMovie=0, storeMovie=0 you get the finished dungeon
shown directly from the Map, and no movie-related objects are ever filled
with data.

>i'm glancing through DungeonMaker.cpp now and i don't know how you got any 
>work done on your place, with all this code! This thing is tremendous! Is it 
>all a rewrite, or how much did you salvage from 1.x?

Actually, since Christmas I've been working full time on this. I've salvaged
bits of code, in particular from the Crawler-methods, but yes, everything
was really re-written from scratch. Whereas generations were a grafted-on,
imprecise hack in version 1, they are now basic to the program design, and
thoroughly enforced, and vital in designing dungeons. That and the fact that
I made better choices as to which parameters are inherited from parents and
which are set uniformly for generations makes the Crawlers so much better
than before. 

>> ... The user interface in the main()-program consists of
>> cin-cout-code, and thus can only run where it is possible to simultaneously
>> have a console open and an SDL-window. This seems to make it impossible to
>> run the compiled program on Windows, though it may be possible to run it in
>> a debugger where one has access to cout and cin.

>You could possibly get around this by not using cout/cerr/cin directly, but 
>#defining a replacements for them, like these:

>// terminal window:
>#define COUT cout
>// no terminal window:
>#define COUT some_dummy_stream_object

>Then replace all calls like:
>cout << "...working on generation << x << endl;
>to:
>COUT << "...working on generation << x << endl;

>i use a similar method for debugging output (and send everything to a 
>different stream for "production versions"):
>#define CERR cerr << "debug: " << __FILE__ << ": " << dec << __LINE__ << ": "

So what about cin? How do Windows users, cruelly deprived of the benefits of
the console by Bill G., get their input? Remember Eric Pankoke, who compiled
the program for Windows, but it would hang when expecting cin input and he
had to CRTL-ALT-DEL it? (I guess we had the last part of that exchange
offlist, so you *don't* remember that;-) Or so I understood the situation.
Did you ever try to run it in the MSVC debugger, Eric? Does one get
cin-services there?

Anyway, I'm not that concerned with this "running on Linux only" for now.
The DungeonMaker (=everything in namespace alifegames) should run on Windows
just as well, people would only have to write a Windows-interface for it.
Pity Qt for Windows is so expensive... as for me, I plan to write MazeRunner
next, which will be a simple Pacman-inspired game (though very different),
and will not use cin/cout, and should run on Windows without a problem.
Inside that I'll amply demonstrate the beauty of the Dungeonmaker's
labyrinths - as for the dungeons, that'll come later... or maybe you'll get
them on the web somehow, Stephan?

Anyway, when you look at the code, check out the Config-object, and the fact
that it is initialized from one single file, as per your suggestions. I will
make other simpler ways of initializing the Config-object though, because
this design file is rather daunting I think. Probably I should write some
documentation about it before I forget what it's all about. I intend to
split the design file into "coreDesign" and "evolvableParams", and create
options to (totally?) automate and do away with the coreDesign-file if the
user so desireth. The "RandCrawlers", which randomly start from the edge of
the map are a step in that direction. You can make a very good labyrinth
design now that just specifies the entrance/exits to the labyrinth, and
leaves everything else to RandCrawlers. I'll do something similar for
Tunnelers (starting one Tunneler automatically at every entrance/exit). Then
we will be able to do another thing you suggested, creating a dungeon from
minimal user input.

Happy hacking,
Peter