[DM-dev] Plans for DungeonMaker 1.x and 2.0

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

Hi there.

Stephan has been really getting into the Dungeonmaker code, producing a
sophisticated file structure and make process, and he's not done yet. I have
decided to do the following:

1. I will release version 1.0 of the DungeonMaker, which will contain few
and subtle changes from version 0.91. It will consist of 3 files, have a
very simple make process, will be easy to understand, and somewhat awkward
to use.

2. Then I will hand the hat of DungeonMaker lead developer to Stephan, at
least for a while. Stephan will clean up the file structure and loading
process used by DungeonMaker, and will make DungeonMaker much easier to use.
I hope he will also do some other stuff, such as replace "design-data:Rooms"
with more versatile "design-data:Walls".

While Stephan takes the lead in development i will still be available to
make any changes in AI-related code that might come up, and will authorize
file releases.

Probably by next fall or winter i will take a more active role in
development again, and will implement evolving dungeons and dungeons with
arbitrary percentages of randomly placed rooms (this will allow us to make
all kinds of possible dungeons, not just the maze-like structures the
Dungeonmaker excels at today).

I will now lay out the data structure of the DungeonMaker as i envision it.
consider this the first version of the design document that Stephan will
hopefully implement with his config-object.

DungeonMaker data structure:

1. CONSTANTs - this data is normally used per default, but can per command
line also be read from a file:

minCorrWidth
smallestRoomWidth (this will be obsolete when we go over to Walls instead of
Rooms)

Since there are so few of these, we might do away with this file altogether,
and just have an interface function that changes the defaults (for
programmatic use of the DungeonMaker) and maybe a command line option for
minCorrWidth.

2. DESIGNparams - formerly called the rooms-file

contains these params formerly formerly from the constants-file:
maxCrawlers
chDirOnStraight
joinDist

this parameter that is currently a compiled-in constant:
maxStats (the number of stats-structs that are stored - when generation >=
maxStats, the "getStats(generation)"-functions return GetStats(maxStats-1) )

and from the rooms-file:
dimX , dimY

as well as arbitrary numbers of
        Rooms-struct's, later to be replaced by Walls-struct's
        GuaranteedOpenSquare's
        Hand-Placed_Wall_Tile's
        Hand-Placed-Column's
        Design-Crawler's

DESIGNparams are the parameters that determine the structural layout of the
generated dungeon.
DESIGNparams will be used in the following fashion:

Default: they are read in from file.

Option 1: there are a few "types" of maps that the user can choose, such as
"solo traversal", "2-player-confrontation", "4-entry-point-center-quest",
... , and the program will generate DESIGNparams internally to create
strongly randomized versions of these map types. More things will vary than
just the GENETICparams (see below).

Option 2 (for version 2): We read in two sets of stored DESIGNparams, and
create one combination by "controlled crossover". "Controlled Crossover" is
a sophisticated process I'm working on that allows the combination of two
DESIGNparam-vectors in a fashion that makes sense for the specific data -
the vectors can grow, shrink and mutate. This process is controlled by its
own set of parameters (which will need their own file, and their own
defaults, or which the user might change interactively - i don't know yet,
we'll have to try things out and see how they work - maybe we'll also stick
some in the DESIGNparams-set and some in the GENETICparams-set).

3. GENETICparams - formerly called the stats-file

contains "maxStats" sets (one per generation 0 , 1 , 2 , 3 , ... ,
maxSats-1) of these params:

stepLength
corridorWidth
changeDirProb
noDirectionProb
maxAge

openStartprob
closedProb (this is new, and will be used to make closed rooms - for now
default to zero, and enable values >0 only per command line option for
people who want to manually place doors in the closed rooms that will ensue)

straightSpawnProb
doubleSpawnProb
jumperProb

skipGenerations
lateSpawn
lateSpawnProb

The GENETICparams determine the local character of the generated dungeons,
and are eminently well suited for being changed by crossover and mutation.
They will be used in the following fashion:

Read in from pre-designed files
If the GENETICparams and the DESIGNparams are designed together and kept
tightly coupled, a wider variety of dungeons can be generated.

In version 2 GENETICparams will be used in the following fashion:
There will be a binary file that keeps a number of GENETICparams-sets
stored, together with their "fitness" values. When the user wants a new
dungeon, a new GENETICparams-set is created as a baby from two "parents"
selected from this file. After playing the dungeon, the user will be able to
give a quality rating - if this is high enough, the baby (now matured and
wise beyond its years) will be entered into the parents-file. In this way,
the dungeons can dynamically adapt to the user's preferences.

For version 2, I will write an "evolutionary-engine" object that will manage
the GENETICparams-file, accept user-ratings, and return fresh
GENETICparams-sets upon request.

I will also write another layer on top of DungeonMaker (code-named DM2),
which will compute paths through the generated dungeon, find enclosed rooms,
and put doors into them to open them up according to a (you guessed it) new
set of parameters that will open up the most amazing design options for the
user. This will allow us to make dungeons with any mixture between random
rooms and random mazes that we may desire - plus the predesigned dungeon
structure that comes from the DESIGNparams.

Stephan is writing a config-object that will hold all these data, and make
them available to the DungeonMaker, and a parser that will be able to read
the data from a variety of files in a robust manner. If he's very generous
he will also replace the rooms-related code with walls-related code, and
make the Dungeonmaker more versatile that way.

OK, Stephan. Over to you.
Peter

PS: Do you want me to post my opinion on the best Wall-data-structure? Or
anything else?