The Decorate()-function
(how to make the dungeons look fantastic)

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.

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.
previous page            contents            there's nothing after this, really