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

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.

Prefabs

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.