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.
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
connect_the_dots
should path around primary vaults if possible.
We need a Zot version that uses:
1
to 3
per corridorlayout_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:
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.
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:
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.
All this also applies to layout_geoelf_diagonals
, layout_geoelf_octagon
, and layout_geoelf_castle
.
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
.
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:
layout_cross
, with some cross arms replaced with a twisted cavern
Images from version 0.15-a0-889-g5f4c38d
.
To be removed by request from dpeg because:
The idea has also been folded into layout_falls_marsh
, where it works better.
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.
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:
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 dungeon.cc. 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.
Images from version 0.15-a0-2214-ge1da13d
.
The revised version generates circular buildings and no longer makes large open areas.
Deeper levels have:
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:
delve
placing and earlier corridor over them?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.
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:
This also applies to layout_gehenna_pools_box
and layout_gehenna_pools_triple
.
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:
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:
'x's
.
Images from version 0.15-a0-889-g5f4c38d
.
This layout needs something to prevent doors appearing along the pieces of wall that stick in or out. Some possibilities:
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.
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):
Images from version 0.16-a0-1211-ge393dcd
.
The teal (dark cyan) spots on the map are the windows.
In this version:
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.
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.
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-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.
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:
1
cell wide.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:
layout_type_narrow_caves
layout
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.