Official development blog

Map Composition

Much of the “living dungeon” concept described previously applies to the main complex, and some branches. Roguelikes of significant scope tend to use a combination of map generation techniques, necessary to fill the game world with unique maps appropriate for their respective areas. Different map types are also likely to require different algorithms to populate them with content including inhabitants, objects, events, etc. Thus Cogmind utilizes a network of systems to produce the wide range of maps needed for the world.


Cogmind map type composition, where thicker arrows represent a heavier relative emphasis on a given system as an input.

In total there are about two dozen types of maps (six of which will be included in the first alpha version). Those belonging to the main complex are generated by the tunneling algorithm, which may draw on a small amount of handmade content in the form of prefabs and encounters. A number of branches are created in the same manner, but a second category of branches, those described earlier as being outside the central AI’s area of direct influence, use an alternative method. As you can see in the diagram above, branches require more work (more inputs).

An explanation of usage scenarios for each of the four primary sources of map generation will help demonstrate how each plays a role in creating individual maps.

Tunneling Algorithm

This is Cogmind’s primary map generator, which I introduced in an in-depth post back before it was complete.

A single algorithm is capable of producing a broad range of unique layouts by adjusting dozens of parameters.


Some example maps generated for main complex areas (click for full size).

In some cases the differences are subtle when viewed like this, but in play will lead to different experiences (even when we overlook the fact that content will vary between the maps as well). In general it would be out of theme to use wildly different parameters since after all these maps are a part of the same complex.

Shown above is the first stage of map creation, the basic layout as passed from the procedural map generator to the game for content insertion. During the first-stage mapgen process, data about every junction, door, room, and open area is recorded for reference, along with analysis results like a relative seclusion heatmap (see the dungeon metrics post for some related images and explanations). The first stage map generator also comes with a range of visualization tools to examine different aspects of a map’s layout for parameter tweaking--changes can be made to a text file, then press a key and immediately regenerate a map based on new parameters. It takes a while to reach a preferable style, but is still much more efficient than try to tweak in the game itself, where there is a lot more to map generation than just the layout!

Tunneler-generated maps are furnished and populated in game based on a system that weighs random content according to depth and/or map type. This applies to machines and stockpiles (see here and here for methods and diagrams), as well as robots.

These maps make up the bulk of the game world, and are the ones in which the living dungeon really shines.

Cellular Automata

A portion of the branches require a layout very different from what a corridor-and-room tunneling algorithm can provide. For that purpose we also have a modified cellular automata algorithm (see the algorithm’s in-depth introduction for more info and images). Like the tunneling algorithm, it is driven by a variety of parameters capable of producing maps in different styles, though for now there is only one usage found in game: the mines.


A fully revealed mine (click for full size).

Because these maps have a fairly different structure compared to tunneler-generated maps (more linear, less branching and looping), they cannot feasibly use the same content distribution system. They are instead populated entirely by so-called “encounters,” which are described in more detail below.


Encounters are an additional mechanism through which to add content to tunneler-generated maps, and the only way to add content to automata-generated maps. A single “encounter” can be as simple as a local patrol or stockpile of parts, or something more complex like a story event.

Regardless of map type, the most useful feature of encounters is the ease with which they can be used to add handmade content. Encounters can make use of both pre-drawn map pieces and the powerful scripting system originally developed for X@COM. Thus there are now practically unlimited possibilities for unique map content.

However, taking full advantage of this “anything is possible” scope in the main complex is both unnecessary and would interfere with the living dungeon mechanics, while also making much of the game unpredictable and therefore unreasonably difficult. Instead, the more interesting/unusual encounters are concentrated in branch maps, making those optional areas of the game a playground for the most experienced, curious, or lost players ;).

Encounters have their own weighted distribution scheme, with the option to randomize their content (within parameter bounds) for additional variation. To aid in tweaking encounter frequency values, the system comes with a debugging visualization tool that shows where encounters are placed on a given map in game.


A mine with distributed encounter types marked with their associated category color (click for full size).

Encounters are divided into four categories to help visualize how a map could play out:

  • Fluff: Provide atmosphere rather than a mechanical effect on gameplay. A common example would be an area filled with debris.
  • Rewards: Unprotected “free” rewards that can take many forms, components or allies being the most common.
  • Risk vs. Reward: Like rewards, only you’ll probably have to overcome some obstacle to gain that reward.
  • Danger: Outright dangerous encounter with no explicitly defined rewards (though you could theoretically still benefit from salvage). Most often these are simply hostile robots, but the power of encounters can create other interesting situations…

The way in which some of the encounters are implemented might break the otherwise consistent realism that defines the living dungeon, for example a robot could suddenly “emerge from the shadows” in a dark area, though I believe this is a worthwhile sacrifice to enable more interesting and unexpected encounters. Said encounters may be found in some branches to liven up the experience--you won’t see this behavior in the main complex, again reinforcing the idea that the core world areas offer a more traditional roguelike experience while outlying regions contain experimental and less predictable content.

Though not required for content that can dynamically fit any space, encounters may also specify a “prefab” when applicable.


Last year I described how handmade map pieces are drawn in REXPaint and integrated into the map generation process. That was back when the prefab system was first developed, and not yet put to use in game. Those prefabs are now used for two things: encounters and special entrances/exits. The latter are integrated directly into both map generation algorithms, while encounter prefabs can be dropped into an existing room or “cave” (a single room-area in an automata-generated map).


One of many storage area layouts (shown in both ASCII and tiles versions). Now that is a room you want access to! (Then you’ll want to figure out a way to simultaneously equip 12 grenade launchers =p)

Like encounters, prefabs can randomly change their orientation and shift their position (it’s often even necessary to face and link to a door!).

As you can see, all sources of map data are procedural in nature, or support randomization in terms of where and what is injected into the maps. Every run is sure to be unique.

Update 3/16/2016: I’ve since written Generating and Populating Caves, demonstrating how prefabs are integrated with cave maps as part of the post-generation process.

Update 1/11/2017: And the newer Map Prefabs, in Depth covers prefab integration in room-and-corridor style maps, as well as the elements that go into constructing an individual prefab itself.

This entry was posted in Design and tagged , , , , , , , . Bookmark the permalink. Trackbacks are closed, but you can post a comment.


  1. Posted May 12, 2015 at 10:00 am | Permalink

    What I see when I look at the ASCII fully revealed mine, is a generator close to my own heart. Namely, most passages are not one space wide, but rather two spaces is the rule to the exception of one. Hopefully the narrow passage cluster of rooms standard dies a quick painless death.

    • Kyzrati
      Posted May 12, 2015 at 10:24 am | Permalink

      I recall you making a similar comment when I showed a mine map over on /r/roguelikedev SS. Throughout the game I do try to ensure that a majority of passages have a width of two or more, especially because there are so many robots, and many are not hostile. So it’s both realistic and necessary, the latter because for now you can’t push past even non-hostile robots (unless you are flying) as that would make escaping from enemies a little too easy. (I may change this; we’ll see.)

      Wider corridors are easier for Cogmind than some roguelikes because a lot of maps are large to begin with. Narrow corridors still have their place for their tactical limitations. For example, most passages in DCSS are 1-space, and it works well for that game, I think, at least because there are many alternate routes and parallel paths. (So, not exactly a realistic dungeon, but tactically it works.) On the contrary there are many more roguelikes, those you probably have in mind, in which there are so many of those long single-cell corridors and that is quite boring…

      The mines shown above are probably one of the most confining maps in the game. The average corridor width throughout the game is about three spaces.

      • Posted May 13, 2015 at 4:02 pm | Permalink

        You have a better memory than me!

        • Kyzrati
          Posted May 13, 2015 at 4:16 pm | Permalink

          Oh I don’t know about “better,” just selective ;). I remember fairly well when anyone mentions something about Cogmind, but precious little else…

  2. Reiver
    Posted May 15, 2015 at 7:51 am | Permalink

    There are prefabs and encounters in the main complex, right?

    • Kyzrati
      Posted May 15, 2015 at 8:58 am | Permalink

      Sorry if it’s unclear--that’s what the first section explains, but only with one sentence because the information is also conveyed by the first diagram.

      There are, but not nearly as many.

Post a Comment

Your email is never published nor shared. Only the anti-spam entry is required. See here for the privacy policy.

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>