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

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

I just spent some time on SourceForge trying to change the default behavior
of this list so that posters reply to the list instead of to the previous
poster, but alas, that is not possible. So I guess we'll keep going private
by forgetting to paste the list address in the address field, like Stephan
has done. So here I'm responding to a mail you haven't seen.

>no, i just changed the first one i saw:
>  unsigned int tT = 13;   //tickTime, makes movie speed

Is that a good speed? I can't really test it on my box here.

>> Dungeonmaker's labyrinths - as for the dungeons, that'll come later... or
>> maybe you'll get them on the web somehow, Stephan?
>
>i was thinking about this last night. Using Qt it would be pretty trivial to 
>make an app which reads in a dungeon (from an ascii file or a dungeon object 
>directly) and outputs a graphic version of it. Similar to what QUB does not, 
>but with the output saved to a file, instead of just shown internally in QUB. 

We could save output to text or whatever files directly from the
Dungeonmaker if we want to have other formats. Maybe the easiest output to
the web would be like we had it at first, with X's and O's and other letters?

>Another, more portable but also Much slower method, is to use write a small 
>Perl script which can read in an ascii dungeon and create the shell script 
>code needed to use the 'convert' tool to build the graphical dungeon. This is 
>much slower because using 'convert' to append many images together can be 
>very slow, but it's also portable to any system which can run bash and 
>'convert' (which should include cygwin).

I think I've seen that done, and I think it's way too slow.

>> I will make other simpler ways of initializing the Config-object though,
>> because this design file is rather daunting I think. 
>
>Amen ;).

Snicker, snicker... but hey man, I followed the design philosophy to not
have any numbers hardcoded, so i threw them all in that one file, whether
they were likely to be changed in a design or not. Anyway, until the
Config-object has very much stabilized, I'll not write other file input
things, for otherwise I'd have to change several input chains every time I
need different data.

>A completely automated run would be ideal, but i understand that this may 
>pose a problem for your gentic algorithms (they must have some input, i 
>guess?). Perhaps we can come up with an object which can provide "random" 
>configuration data from a set of "working" inputs. Thus we would have the 
>interface for providing random dungeon inputs, but it wouldn't be really 
>random (at least not intitially). We could then add other "profiles" to that 
>object to provide more random dungeons without clients having to change any 
>code.

I think we can easily make fully automated dungeons now, though we probably
would use standard design files with that. However, the variation with
different random numbers is tremendous, particularly with dungeons. Later we
can make some parameters evolvable, maybe. Still not sure whether I want to
do that, and whether it's worth the trouble.

>> 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. 
>
>Excellent :).
>
>> 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.
>
>That would be ideal for most users, i think. Perhaps we can extend the 
>RandCrawlers so a user can select a more specialized one ("this one doesn't 
>create walls longer than 10 squares", as a completely arbitrary example).

Right now there's two things users can choose about RandCrawlers (note the
clever mixing of German and English in the term??) - decide how many are
started (per 1000 edge squares) in which generation, and choosing the same
identical CrawlerData for them all (the same data one can choose for design
Crawlers). This means, if you want to, you can choose them all to never make
babies (=never branch) and to stop after laying down X squares. You can also
give them a fairly large corrWidth, which would imply that all of them that
were born in too cramped quarters would never fill a single square, and
they'd just mosey into open spaces. Many choices possible...

I've made the first Dungeon design which I really like, and I wonder...
should I send it to you? I'd also have to send the latest Dungeonmaker.cpp
file, 'cause I don't know how this design would fare with the older code.
Still fiddling with the code, though I may stop now. Don't know...

Peter