In earlier versions of the DungeonMaker I used both normal wall tiles and high
wall tiles (which are supported in the GridSlammer engine and can thus be
seen nicely rendered). The high wall tiles were placed when a Crawler
changed direction or spawned a baby. This gave the walls much more structure,
and made them look nicer. However, in some instances these high wall tiles
looked out of place, e.g. when a Crawler made lots of babies, but most of them
got deleted without ever placing a wall tile of their own. Also, some situations where a
"special" wall tile should be placed cannot be identified in this manner,
such as door-like openings, which should be decorated on both sides. So I
came to the conclusion that all such decorations should be placed in a second
step of dungeon generation, where an algorithm would have to be created that
went through the entire dungeon, looked at the local neighborhoods and identified
special situations that would benefit from decoration.
(how to make the dungeons look fantastic)
However, when the time came to write this function and I pondered its
implementation, it became clear to me that it would really be a waste
of effort, since I didn't know what to decorate with. How many wall types
would I have, how many end decorations, how many corner decorations... would
thicker walls (with two or more wall tiles side by side, mostly seen in
rooms and pyramids) be rendered as higher walls as I envision or not? Would
there be special connector tiles between walls of different types? And so on,
and so on... the Decorate()-function can really only be written well if it
is written in full knowledge of the graphic design of the dungeon, and the
various graphic resources, each of which must be programmed into this function.
So I have not written Decorate(). Right now I am quite willing to write it if
someone comes up with a good set of graphics. But in the future I will be busy with
other projects, so here is my description of how I envision the dungeon graphics
and how I would write Decorate():
I envision the dungeon open towards the top.
Like in Aztec architecture, walls would
become slightly narrower towards the top. Thicker walls
would be rendered as higher, and pyramids would be just that, Aztec type
pyramids. Wall ends and inside corners would have special ornaments
adorning them, like small wall mounted fountains, statues, or shrines.
Many openings would be selected to become portals or doors and be heavily adorned.
There would be at least three different types of normal (not extra wide) wall,
each becoming successively
smaller: Type 1 for generation 0 and 1, type 2 for generations 2, 3, and 4, and
type 3 for later generations.
The Decorate()-function would go through the entire dungeon, examining every
grid square. For squares that are not open, the function would examine a
neighborhood of maybe 11 x 11 (with the square to be tested at the centre)
and determine whether the test square required special treatment. In some cases,
such as wall branchings, doors, and portals, Decorate() would test whether there was enough
room to place extra wall tiles to accentuate the place, possibly building
a small pyramid there. Some walls, particularly of generation 0 and 1, could
be doubled or tripled to become extra high. Columns would be examined to check
whether they had enough evenly spaced sister columns to look cool, and be
deleted otherwise. In a second run through the dungeon, open squares would
have their neighborhoods checked to find large open spaces that the
Crawlers might have missed. Into such spaces other structures would be placed,
such as series of extra large columns, or ornate fountains and mandala-like squares.
This would make it possible to use rooms- and stats-files where
Crawlers die out before all space is filled, which makes for very interesting
and varied dungeons, but which can of course not be implemented without
doing something else to fill large empty spaces.
Now picture this: In a 3D rendered game with a landscape based on a
heightfield, you could write a function to sink a DungeonMaker-made
maze into the landscape. Such a maze could be bordered by impassable mountains
on two sides, thus being the only passage between areas of the map. The heightfield
inside the maze area would be clamped to a finite number of evenly
spaced heights, and corridors would have steps where there are height changes.
Ahh, this would be so cool. The first step, of course, would be to write
classes that render a flat dungeon in 3D, but if you do, do me a favor and
make it flexible enough to allow mazes embedded into landscapes like this.
That's it for version 1.0!
Over and out.