This is an old revision of the document!

Layout Types

Name dcss:brainstorm:dungeon:layout_types
Summary The layouts sorted by type, with sample images.
Further information See also Layouts, Dungeon Building Functions
Added by infiniplex
Added on 2014-05-18 23:06

All layouts (theoretically) come with a layout_type_??? tag that is used to chose appropriate vaults. However the layout types do not follow any consistent pattern and have now proliferated widely. My goal here is to organize the layouts into a small number of layout types. Each type will have distinctive traits.

This page grew out of a forum thread and ##crawl-dev discussions, and similar.


Each layout type has a description and an archetypical layout associated with it. That layout is the best (by decree) example of the type.

Layout classifications are arranged in approximate order of gameplay danger. Note that this is only my best guess, not a well-researched fact. Also the danger level of individual layouts within a type can vary widely.

Some layouts should be classified under different types, depending on what options they choose. There should be a note with each of these saying where else they should be stored.

General Layout Styles


These layouts are mostly composed of corridors 1 cell wide. They may have rooms, but the rooms are small and/or few in number. Most of the layout is passages.

This layout style was briefly called layout_type_angular. ”Angular network caves form from intersecting fissures of carbonate rock that have had fractures widened by chemical erosion. These fractures form high, narrow, straight passages that persist in widespread closed loops.” ~ Wikipedia. These are also just called “network caves”.

The archetypal layout for this layout type is layout_misc_corridors.


Images from version 0.15-a0-889-g5f4c38d.

Previously named layout_misc.

Needs options for

  • Corridor width
  • Straight corridors flag
  • Allow diagonal corridors flag

connect_the_dots should path around primary vaults if possible.

We need a Zot version that uses:

  • Random corridor widths from 1 to 3 per corridor
  • Straight corridors with no diagonals (as the old layout_misc did).

We need a Crypt version straight, 1-wide paths and diagonals.

Fixes for these exist on Mantis, but are not going in until 0.16.


Images from version 0.15-a0-889-g5f4c38d.

Previously named layout_loops_misc.

Images from version 0.15-a0-2233-ge696fdb.

The Elf version:

  • Places more, larger rooms
  • Sometimes adds glass walls.
  • Does not place “rooms” that just cut a room outline (too ad-hoc for elves). All rooms in Elf are either open (2/3) or filled solid (1/3).
  • Hexagon rooms

These also describe the Elf versions of the “loops” layouts below.


Images from version 0.15-a0-889-g5f4c38d.

Images from version 0.15-a0-2233-ge696fdb.

The layout now places stairs 50% of the time in Elf and never elsewhere.


Images from version 0.15-a0-2233-ge696fdb.

Images from version 0.15-a0-889-g5f4c38d.


These layouts are have multiple rooms connected by corridors 1 cell wide. A typical room is rectangular and 8×6 cells in size, but that can vary widely.

The archetypal layout for this layout type is layout_roguey without mazes or inner rooms.


Images from version 0.15-a0-889-g5f4c38d.

A C++ layout. It is complex and would take a lot of effort to convert to LUA, for no visible benefit. Making the function that draws the river callable form LUA would be nice.

This one looks more like layout_type_corridors at early depths. Deeper depths place increasingly more and larger rooms, as well as more extra features. Features include pools, diamond rooms (sometimes with water or lava floor), and water or lava rivers.

Should this layout occasionally show up in Pandemonium with a river?


Images from version 0.15-a0-889-g5f4c38d.

Elf places rectangular and octagonal rooms, elsewhere places rectangular, octagonal, and round rooms.

The Elf version is not well-distinguished. Should it:

  • Require straight connections?
  • Be the only branch to get octagon rooms? Others would still have rectangular and round.
  • Place more rooms? Or would this just make it look too cluttered?


Images from version 0.15-a0-889-g5f4c38d.

Deeper levels have more maze rooms and more rooms containing an inner box.

In Lair, the “orphan” doors left behind when the wall around them vanishes look silly. We need to do a final pass that removes them after or as part of level ruination. Having doors attached to one wall is fine.


Images from version 0.15-a0-889-g5f4c38d.

Lava pools should only appear in deeper branches (e.g. Depths, Pan). No pools of any sort should appear in Lair because level ruination makes them look bad.

All pools need to be marked with no random teleport. As is, these are teleport traps.


Images from version 0.15-a0-889-g5f4c38d.

This layout was intended to be only used in Elf as part of distinguishing the branch. It generates glass windows between adjacent rooms and passages. It also places some trees, bushes, plants, fungus, fountains (dry, full, sparkling), and statues.

To look really good, this would need a few new tiles.

  • A “stained glass” tiles for transparent rock wall. The discussion suggested applying this to all transparent walls in Elf, which I think is a good idea. Without this, most of the rest don't make sense.
  • Glass door tiles for doors in glass walls. The simpler form of these is just a door that looks like it is set in glass instead of rock and can be applied like in Cigotuvi's wizlab. A fancier (but much harder) thing would be to have the doors themselves transparent. However, this would require adding 2 new terrain types in code. In either case, the glass doors only ever appear as single cells, so no gate tiles would be needed.
  • Special stained glass tiles showing a fountain, an elf (or something else to replace a statue), and a tree. These should have their own names so they can be set individually instead of (or in addition to) mixing into the other stained glass tiles. In a really fancy form, there would be ones for bush, plant, and fungus as well. The layout generator occasionally overwrites these with glass walls when the rooms overlap, and it would be neat to have the features remain as images in the wall. Currently the generator recolours those wall cells. These are least least important tiles by far.

All this also applies to layout_geoelf_diagonals, layout_geoelf_octagon, and layout_geoelf_castle.


Images from version 0.15-a0-889-g5f4c38d.


Images from version 0.15-a0-889-g5f4c38d.


Images from version 0.16-a0-1211-ge393dcd.

This is a special form of layout_geoelf_??? for the branch end. It builds a stone castle around the primary vault and rooms in the space around that. The castle is marked as a primary vault, so it will not be overwritten.


These layouts are mostly made of straight corridors more than 1 cell wide. They are often consistent in width, but may vary. They can contain rooms, but the rooms are not the focus of the layout. These layouts should look artificial.

The archetypal layout for this layout type is layout_concentric_octagons.


Images from version 0.15-a0-889-g5f4c38d.

The placement of diagonal hallways between rings on hallways sizes other than 2 (Snake uses 3) needs to be looked at. They may sometimes be the wrong length or mis-positioned. If this layout appears in Lair, it needs to use the Snake version.


Images from version 0.15-a0-889-g5f4c38d.

Pandemonium uses straight walls, while Dis uses rougher ones - this seems sort of backwards. Possibly this layout shouldn't be in Dis at all.


Images from version 0.15-a0-889-g5f4c38d.

For the smallest paths, this should be classified as layout_type_corridors. Can these versions be detected when generating the layout?


Images from version 0.15-a0-889-g5f4c38d.


Images from version 0.15-a0-889-g5f4c38d.

Dungeon and sometimes Lair allows width-1 corridors. Lair guarantees an open path around the outside.


Images from version 0.15-a0-889-g5f4c38d.

The ragged walls in Tartarus are nice. Can this effect be put into other Tartarus layouts?


These layouts are mostly made of irregular twisting corridors more than 1 cell wide. They can contain rooms, but the rooms are not the focus of the layout.

In the Dungeon, these layouts use the “caves” alternate tiles for the floor and walls. In other branches (as of time of writing), they use the normal tiles for the branch. Should they also use the special tiles in the Depths?

This layout style was briefly called layout_type_anastomotic. ”Anastomotic caves largely resemble surface braided streams with their passages separating and then meeting further down drainage. They usually form along one bed or structure, and only rarely cross into upper or lower beds.” ~ Wikipedia

The archetypal layout for this layout type is probably layout_layer_cave, although it is not perfect.


Images from version 0.15-a0-889-g5f4c38d.

This layout badly needs reworking. Some ideas from a Tavern discussion:

  • Make the path branch (more)
  • Add some rooms
  • Teleporters to bypass parts of the path
    • I doubt this is a good idea, so I will not do anything about it unless I head otherwise from authority
  • Are the diagonal walls preventing vaults from attaching?
  • Combine with layout_cross, with some cross arms replaced with a twisted cavern
  • Force up and down stairs to not generate to far from each other.


Images from version 0.15-a0-889-g5f4c38d.


Images from version 0.15-a0-889-g5f4c38d.

To be removed by request from dpeg because:

  • It looks really bad in console
  • Nobody (no developers?) could remember seeing it

The idea has also been folded into layout_falls_marsh, where it works better.


Version 1

Images from version 0.15-a0-889-g5f4c38d.

In my (infiniplex's) opinion, the round ones look good and work pretty well, but the square ones don't. We need a validate check to ensure that the layout isn't too open (e.g. sample image #7), at least in Zot.

There was a note in the layout_halls.des file saying that this layout sometimes generates small weird layouts, but I have never saw one.

Version 2

Images from version 0.15-a0-1119-g9b3a599.

This layout now appears in Snake and Zot. The only difference between the Snake version and the default (appears in Zot) is that the Snake version is distorted.


Images from version 0.15-a0-889-g5f4c38d.

The non-polar (i.e. vertical instead of circular) layouts for Tartarus should be classified as layout_type_open_caves. Is this just the two here? Does this also happen a lot in Zot (but not our picture)?

This layout is polar (circular) occasionally in Taratrus, half the time in Zot, and always on Zot:5. Other parameters change too, but I don't understand them.

This layout may be too open for Zot. Can it be easily made less so? Or will this disconnect it?


Images from version 0.15-a0-889-g5f4c38d.

The map is distorted in Snake. When it isn't (e.g. in Zot), this should be classified as layout_type_passages.

This layout is open and relatively fixed. It should be unique and/or at a have lower weight.


Images from version 0.15-a0-1676-ga75d591.

A special layout for Orc based on diamond shapes. The edges of the diamonds are quite variable. The original proposal for this layout can be found here.

Depth convergence:

  • Deeper maps are based on larger diamonds
  • The branch bottom has more open area (as in layout_caves)

Note that, at the time or writing, the end vault for Orc is never placed as a primary vault. This prevents the layout from adapting to its shape.


Images from version 0.15-a0-889-g5f4c38d.

Previously named layout_delve.

A duplicate of this layout (without the water) exists as a special case in the _build_postvault_level function in That should be removed. If we want it to always use this layout for Spider:$ and other layouts get added they can be made to not generate on that level.

This one varies widely. Some versions should be classified under layout_type_open_caves. This layout is a variant of layout_twisted_cavern for Spider.


Version 1

Images from version 0.15-a0-889-g5f4c38d.

Version 2

Images from version 0.15-a0-2214-ge1da13d.

The revised version generates circular buildings and no longer makes large open areas.

Deeper levels have:

  • More lava
  • More open area
  • Wider paths
  • More, larger buildings


Images from version 0.15-a0-889-g5f4c38d.

Previously named layout_cocytus when it was the only Cocytus layout.

This layout was intended as a variant on layout_twisted_cavern for Cocytus.

This layout does not change based on depth. It is also not that good. Some possible improvements:

  • Multiple major paths with a down stairs on each. 1 could could start at each corner. Would the other corners would need to be temporarily blocked off to prevent delve placing and earlier corridor over them?
  • Deeper maps have more water
  • Deeper maps have wider or longer paths? I am not sure how this would work out.
  • Some way to make delve handle the edges nicer. Ideally, they would look the same as everywhere else. Failing that, they should at least look irregular. Could this be done by smearing the edge in beforehand? If so, also apply it to primary vaults and make the combination a library function.


These layouts have irregular walls. They may have a single open area, a few disconnect open areas, or multiple large-ish rooms connect by irregular passages.

In the Dungeon, these layouts use the “caves” alternate tiles for the floor and walls. In other branches (as of time of writing), they use the normal tiles for the branch. Should they also use the special tiles in the Depths?

This layout style was briefly called layout_type_ramiform. ”Ramiform caves form as irregular large rooms, galleries, and passages. These randomized three-dimensional rooms form from a rising water table that erodes the carbonate rock with hydrogen-sulfide enriched water.” ~ Wikipedia

The archetypal layout for this layout type is layout_caves.


Images from version 0.15-a0-889-g5f4c38d.

This layout generates quite differently based on where it is. It is probably going to be removed from the Dungeon and just appear in Orc and Slime.

The first sample image has the bayou serial vault on it; this layout never places water.


Previously named layout_pools.

Images from version 0.15-a0-889-g5f4c38d.

This layout generates lava or water pools (never both) in Depths. It also generates fewer rock pools for deeper layouts. It should generate more rock “pools”. The Dungeon version never places water (or lava); the water in the second image is placed by vaults.


Images from version 0.15-a0-889-g5f4c38d.

This one is not finished yet. mumra left comments in the source file to improve it and/or combine it with layout_layer_cave.


Images from version 0.15-a0-889-g5f4c38d.

This layout needs a pass at the end the removes all the dead-end hallways. Possibly it should also have minimum-area validation.


Images from version 0.15-a0-889-g5f4c38d.

This one is not finished yet. mumra left comments in the source file to sometimes add water, twist the passages, and change the size of the pods. It could also be combined with layout_chambers.

If we could make the passages wider, this layout would work well in Spider. Simple algorithm: remove all 'x's bordering at one or more '.'s in a straight direction.


A variant on layout_cave_pods, which it could be combined with.


Images from version 0.15-a0-889-g5f4c38d.


Images from version 0.15-a0-889-g5f4c38d.

Classifying this layout is hard. With straight edges, it should be layout_type_passages or layout_type_open, depending on size. With irregular cave edges, it should be layout_type_narrow_caves or layout_type_open_caves.

The map edges are handled badly. They look like the pattern was cut off when it reached the edge of the array (which is what happens). They should be disguised somehow.

We need some way to make the wide passages narrower and/or more interesting. Especially for Zot. Limit the un-caved version to the size of layout_type_passages.

Elf needs a version that does not look cavelike, but that will not be hard when everything else is fixed.

This layout is open and relatively fixed. If it can't be otherwise improved, it should be unique and/or at a have lower weight.


Images from version 0.15-a0-889-g5f4c38d.

This layout includes lots of lava and was intended to appear only in Gehenna. The portion of the code that draws the round buildings should be moved to a library function.

With increasing depth, this layout places:

  • Fewer “pools”, with more lava ones and fewer rock ones
  • More, larger buildings
  • Buildings closer together

This also applies to layout_gehenna_pools_box and layout_gehenna_pools_triple.


Images from version 0.15-a0-889-g5f4c38d.


Images from version 0.15-a0-889-g5f4c38d.

This layout is pushing the edge of layout_type_narrow_caves, but has been classified here for consistency.


Images from version 0.15-a0-1676-ga75d591.

Previously named layout_gehenna_lava_paths and appeared in Gehena with lava instead of water.

With increasing depth, this layout places:

  • Fewer, wider paths
  • Larger “icebergs”
  • More water, especially around the edges


Images from version 0.15-a0-889-g5f4c38d.


These layouts have a single large open room covering most of the map. This large room then contains many smaller rooms (called buildings) inside it, which occasionally contain still smaller rooms inside them. The walls might be rock, stone, metal, or crystal ('x's, 'c's, 'v's, or 'b's, respectively), and individual buildings might have a type different from the layout as a whole.

These layouts do not look good with non-primary vaults. As a room of thumb, any building that intersects a vault ceases to look like a building and just looks like a weird and disconnected wall. Think carefully before putting these layouts anywhere where vaults are common.

Vaults that are a building/room should probably have a border of 'x's cells with doors for connections. This makes the vault connect nicely to any building it overlaps. Placing a border of '.' cells around it makes any existing buildings it overlaps look silly. If your vault could overlaps the outer wall, some details may never bee seen by the players. This is OK; someone else will see it in another game.

Do not add an outer wall to vaults intended to be open; there is nothing wrong with open vaults.

These layouts normally leave a rock border of exactly 8 cells around the large room. Please respect this: it allows vaults on the map edges and corners (via ORIENT: tags) to reliably line up with the map edge.

The archetypal layout for this layout type is layout_chaotic_city.


Images from version 0.15-a0-889-g5f4c38d.

Previously named plain layout_city.

This layout sometimes places buildings with thick walls or simple inside features. Some buildings are also missing, and the rest may have different wall types.

In Dis, it places features more often, but never thick walls or walls of unusual types. Dis should have no missing buildings, and maybe more consistent sizes and placement at deeper levels. All must conform to the iron will of Dispater.

In Lair, it places thick walls more often, especially with increasing depth. There are no missing buildings, although Lair erosion make give that illusion for thin walls at deeper depths. All buildings are made of 'x's and have fewer doors with depth (1/3 at bottom).


Images from version 0.15-a0-889-g5f4c38d.

A C++ layout.

If/when this is ported to LUA:

  • The “market square” placement in the center needs to be revised. In the new version, a rectangle of some glyph is placed in the middle first, the buildings are placed around it, and then the rectangle is overwritten with floor again.
  • The square could also be made more common at deeper depths, and/or more likely to be filled with water or lava (with a suitable floor path around the edge).
  • Buildings should place with the same different wall types and ratios as other city layouts. Lair and Dis should only use 'x's.
  • Buildings in Lair should have thicker walls with depth, so that they do not always disappear with Lair ruination.


Images from version 0.15-a0-889-g5f4c38d.

The buildings need to also check 1 row of cells around them when placing. Right now, they can touch the walls of a room around them.

This layout lies somewhere between layout_type_open_caves and layout_type_city. It has layout_type_city because it only appears in Snake, where it is be the only “city” layout. There is no problem with it conflicting with other city layouts because… there are no other city layouts.


Images from version 0.15-a0-889-g5f4c38d.

This one needs a size-based cutoff when placing walls in Dis. Possibly veto anything with an X or Y size of 3 or less. Or maybe anything with a side length of 1 or a total area of less than 12. Or something to clean up little isolated pockets of wall after it is finished.

Should different wall types sometimes be used? There may already be 'c's, but I don't think there are 'v's or 'b's? Only 'x's be used in Dis.


Images from version 0.15-a0-889-g5f4c38d.

In Dis, walls are always placed as 'x's, which are automatically converted to 'v's when the level is generated.


Version 1

Images from version 0.15-a0-???.

In Elf, this layout places the occasional piece of glass in the walls.

This layout places around primary vaults.

Problems with Elf version (thanks TS__ and PleasingFungus):

  • Too common
  • Lots of walking around to get to the one door
  • Lots of annoying glass far from doors
  • Terrain isn't exciting
    • It's not an issue with the theme or aesthetics, it's… hm. I wonder if it's almost a problem of the whole shape being designed in such a way that you end up knowing what the entire place looks like when you're halfway through exploring it? idk if that makes any sense. not that you know the 'theme' of the level, but that you can loop around the outskirt and see a big part of the…
    • …inside…?
    • geo-elf has a cool sense of exploration; city feels like a drag to explore. this is still too vague to be really helpful, but I'm not sure if I can articulate it any better…
    • its the limited number of entrances + relatively large amount of glass + autoexplore's tendencies…
Version 2

Images from version 0.16-a0-1211-ge393dcd.

The teal (dark cyan) spots on the map are the windows.

In this version:

  • Rooms have multiple doors, but none too close together
  • Windows may appear 2 cells along the wall from a door in either direction when in Elf. They do not appear anywhere else (except in vaults).

The Pandemonium version of this layout has more doors but is otherwise unchanged.


These layouts often have a single large room with straight edges. The room may have some features in it, but it is mostly open. There can be more than one room, but they must be big. Anything with corridors should probably be under layout_type_rooms. The cutoff between layout_type_open and layout_type_passages is probably around a corridor 5 cells wide. Below that, it is layout_type_passages, above that, it is layout_type_open.

The archetypal layout for this layout type is layout_forbidden_donut when it has smooth walls.


Images from version 0.15-a0-889-g5f4c38d.

Some versions should be classified under layout_type_open_caves.

Should be unique and/or at a have lower weight.

A lava center should only generate in deeper branches, such as Depths. The irregular cave-like walls should only appear based on branch (although some branches could have either).


Images from version 0.15-a0-889-g5f4c38d.

Possibly the versions with irregular walls should be classified under layout_type_open_caves. However, I am not sure if this appropriate for the boxy = true version.

The versions with lava or water outside should only appear in Depths, if at all. Right now, they generate everywhere except Lair. No monsters should generate in the water/lava - already done. If the map validator permits it, the ends of the cross arms should be sealed with glass walls too. Only the boxy = true version on the spottyness should happen, and less often (25%-50% of the time).

It has been suggested that this layout should be combined with layout_twisted_cavern.


Images from version 0.15-a0-889-g5f4c38d.

Some versions should be classified under layout_type_open_caves.

Should be unique and/or at a have lower weight.

The recent revision to this can occasionally disconnect the map. The pillar sizes need to be limited for pillars near the center.

Lava pillars should only generate in deeper branches, such as Depths. Currently, tree pillars can generate in Lair and Pandemonium can generate a portal to the Abyss.


Images from version 0.15-a0-889-g5f4c38d.

A C++ layout. If it is converted to C++, the command make the pool would have to become a LUA-callable function, which would be nice independantly.

This layout has been disabled because the water creatures (especially electric eels) are too annoying to walk past. It may be reinstated if/when this problem is fixed.

It does not generate (water) pools in the Crypt, leaving it just a giant open room. It also did not appear there even before it was disabled, so I suspect that that is legacy code.


Images from version 0.15-a0-889-g5f4c38d.

Should be unique and/or have a have lower weight. Or removed entirely.


These layouts are made by taking a single large room and adding walls. The end result is a lot of smaller rooms right next to each other.

The archetypal layout for this layout type is layout_subdivisions.

Vaults intended for these layouts should always have a wall of rock around them with doors (or holes) for exits. This makes the vault look like another room instead of a weird break in the map style.


Images from version 0.15-a0-889-g5f4c38d.

This layout never places doors in Snake, and may appear with the cave tiles in the Dungeon. It also needs to place around primary vaults (probably at the stage where it grows the cavern).


Images from version 0.15-a0-889-g5f4c38d.

Previously named layout_dis.

This layout was intended to give a unique style to Dis. It did this very well, and form the inspiration for several other layouts, such as layout_jigsaw.

This layout needs to be adapted to place around a primary vault. A simple implementation would just build a smaller layout to avoid it. A more sophisticated one would place multiple divided areas around the primary vault. This is tricky because the walls should not be double-thick, or we make the primary vault conspicuous.


Version 1

Images from version 0.15-a0-889-g5f4c38d.

This layout makes too many narrow (1-wide) passages. Try changing the box edges to every 3 cells instead of every 2. If that doesn't work, probably remove it.

Version 2

Images from version 0.15-a0-2214-ge1da13d.

This layout is intended to be unique to Dis. This is the layout_type_divisions idea taken to its limit: the layout can simply generate a regular grid.


Images from version 0.15-a0-889-g5f4c38d.

This is a Dis-specific variation of layout_honeycomb.


Images from version 0.15-a0-1305-g86892e8.

Internally, this is more like a very randomized encompass vault than a layout. It uses subvaults to place the walls instead of procedural functions. A real layout like this might be an improvement. Or not, depending what it looks like.

Branch Layout Styles



Images from version 0.15-a0-889-g5f4c38d.

A C++ layout that should not be converted to LUA. This layout generates a heightmap which is used for the changing tides in the shoals. It also generates some walls.

The two images for each layout are at low tide (top) and high tide (bottom).


These layouts have trees instead of walls. Other than that, they are like layout_type_narrow_caves. Should they be merged it?


Images from version 0.15-a0-889-g5f4c38d.

Previously called layout_swamp when it was the only Swamp layout.

A C++ layout.


Images from version 0.15-a0-889-g5f4c38d.

Should this be called layout_falls_swamp?

This layout needs:

  • Something to widen the narrow “drips” produced by the noise function. A simple form would be to smear every non-wall cell into a 2×2 block. A more sophisticated algorithm would only change paths that were 1 cell wide.
  • To use branch depth fraction instead of raw branch depth. So changing the size of the branch does not disrupt it.
  • To handle primary vaults correctly. This comes in to parts. The Worley-noise-based walls should adapt if possible. The pools should also adapt, which will happen if the add_pools function is improved to handle primary vaults.


These layouts heavily use the special Vaults vaults in vaults_rooms_empty.des, vaults_rooms_standard.des, vaults_rooms_hard.des.

These are the fourth attempt at the problem (that I am aware of) and very complex, so they should probably not be fiddled. The weights could be changed if absolutely necessary.

These layouts are quite good and don't need changing, so I (infiniplex) am probably not going to make any sample images.














Images from version 0.15-a0-889-g5f4c38d.

This layout was intended for the Forest branch. It is most notable for having (mostly) trees instead of walls. Other than that, it is basically layout_layer_caves with water. Should this layout type be merged into layout_type_narrow_caves or layout_type_swamp?

The devteam has apparently decided against adding Forest branch (after a lot of work on it), so this layout currently does not appear anywhere.

Some possible uses for this layout:

  1. Crypt
    • Dead trees (implemented)
    • Water replaced with graves (not implemented)
  2. Lair (possibly only on at the bottom)
  3. Dungeon:1 (which is therefore outside)
    • This might be too dangerous because it has few chokepoints
    • The water would have to not generate enemies
  4. Slime
    • Trees become walls
    • Less water (possibly becoming acid slime)
    • This would then become a layout_type_narrow_caves layout
    • We would need a way to ensure the paths are wide enough for players to avoid the acid walls.
  5. Swamp
    • More water would be needed

Unclassified Layouts


From layout_grids.des.

This layout is disabled and incomplete. Attempting to run it causes LUA runtime errors. Theoretically, it generates different grid layers like in layout_big_grid and layout_small_grid and combines them.

Logged in as: Anonymous (VIEWER)
dcss/brainstorm/dungeon/layout_types.1413998791.txt.gz · Last modified: 2014-10-22 19:26 by infiniplex
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki