Official development blog

Non-Interactive Machines

Non-interactive machines were first discussed in the context of the object placement algorithm of the previous post. But there is plenty more to cover.

Distribution

We can’t simply pick random machines for any and all maps. The types of machines on a given map should reflect the theme of that map, be it storage, factory, research, etc.

Our goal in developing a selection system is to minimize effort while maximizing both variety and logicality of a map’s content. It would be a lot of work to list every possible machine for every map type. The better solution categorizes machines by their “theme” (e.g. mining, matter, energy, processing…). Then each type of map can designate one or more “machine themes” from which to choose its machines.

Mines, for example, pick from the “mining” and “matter” themes; factories select “matter,” “energy,” and “production” machines. This enables maps with overlapping themes to draw from overlapping pools of machines. The selection pool is weighted, so machines themselves can also specify how common they are (with a separate frequency value for each placement location: room, hall, and junction).

Gameplay Impact

Although dubbed “non-interactive,” these machines actually serve as more than just a way to flesh out the atmosphere.

Tactical Positioning

Their very presence breaks up large spaces with destructible obstacles. However, depending on the size of the machine this may only be a physical barrier rather than a visual one, because machines only partially obscure FOV.

cogmind_machines_and_FOV

Notice how FOV is not completely blocked by the machines.

Explosions

Even more deadly (and fun!), is that some machines may explode.

For all the ASCII debris fans, even non-explosive machines send out flying debris when a piece is destroyed.

cogmind_machine_destruction

Chipping away at a pair of Electrolysis Chambers.

Some machines may send out different colors reflecting their nature/use, such as this Matter Pump.

cogmind_debris_matter_pumps

Damaging Matter Pumps (the in-game color of matter is purple).

Interactive machines do not explode, but their debris animation can also be a little different, such as sparking from a terminal.

cogmind_debris_terminal

This terminal fades to gray once disabled, since it can no longer be accessed.

Truly explosive machines will detonate in glorious ASCII-plosions that can engulf nearby machines or robots. As with all particle effects, there are many styles:

cogmind_exploding_nuclear_reactor

They didn’t need this Nuclear Reactor, did they? (Don’t get on my case about nuclear reactors not exploding. Because this one clearly just did ;D)

 

cogmind_exploding_fusion_modulator

Lesson: Don’t blow up a Fusion Modulator while sitting in the same room.

(More shots from the sandbox, because I’m not hunting through the game to find these things.)

cogmind_exploding_vacuum_chamber

A vacuum chamber (yes I’m standing too close, but that’s okay because I gave myself 40,000 integrity points =p The sandbox is nice like that.).

 

cogmind_exploding_machines

Scratch one Antiparticle Reservoir. Might as well take out the Power Conduit, too. Aaand.. for good measure let’s just switch to the Rocket Launcher and take out some other machines. (Several times I’ve caught myself unable to stop strolling around the sandbox doing this, again and again and again :D)

There are more, but I’ll leave them for you to discover in game, hopefully when an enemy hits one you’re standing next to ;)

To prevent overuse of the boring (and overpowered) strategy of “lure enemies near a machine and blow it up,” the predictability of explosions for some machines will be reduced by introducing a system of “machine instability.” When a machine takes damage it may have a random machine-dependent chance to become unstable, which starts an invisible timer after which it will automatically explode on some later turn.

The only element of this I’m not sure about is whether the player should have cues to indicate that a particular machine has become unstable and may explode at any time. Since the time remaining before explosion is still uncertain, it makes sense to tell the player at least when there are signs of instability. In any case, the implementation will depend on playtesting, as well as the precise number and frequency of machines that explode (these parameters haven’t been added to the data yet).

With powerful enough weapons you can of course cause a machine to explode instantly, but machines prone to deadly explosions are generally more heavily protected against weapons as this is not exactly the safest of environments.

Melee

Melee weapons, however, are particularly good at hacking up machines, though for obvious reasons point blank attacks on explosive machines are rarely a good idea. On a related note, recall that knock-backs are possible with impact-type melee weapons, thus as a new extension of that mechanic, you can now smash robots into a machine.

Normal machines will simply shoot debris from the point of impact (and coincidentally make some pretty cool metal crunching sounds). Explosive machines on the other hand will probably roast whatever robot is so unlucky as to be smashed into ground zero, and probably engulf those nearby, too.

cogmind_knockback_explosion

Whacking a flying swarmbot with a Gravity Flail, sending it careening into a Nuclear Reactor which explodes and takes out all his friends, too ;)

Be wary of enemy brawlers that may unwittingly do this to you!

Posted in Design | Tagged , , , , | Leave a comment

Furnishing a/the Dungeon

Most traditional roguelikes are pretty barren, especially those of the subterranean variety where a map is composed of rooms empty except for monsters, items, and a small selection of interactive props or obstacles (e.g. altars, plants, pools of some liquid). This reflects, and highlights, the genre’s focus on tactics and strategy. If an object doesn’t have some direct affect on gameplay choices, then we don’t care about it. Traditional roguelikes take place just as much in the imagination as they do in the visible space, so players are used to seeing only what information they need to make decisions.

Some might argue that the limits of ASCII mean we only have just enough symbols to represent important interactive parts of the map, but this isn’t really true given the number of possible color and glyph combinations (especially once you add extended ASCII) as well as foreground and background colors. See Dwarf Fortress for an example in the extreme.

Cogmind’s 7DRL prototype, being a simple game focused purely on its core mechanic, had absolutely no props despite its uncharacteristically large rooms and corridors (to make room for long-ranged combat and more robots). To an extent that has now changed with the addition of machines, though the game still very intentionally leaves much of its map area as empty “periods” (‘.’). While this lack of furnishing makes for more boring static screenshots, I believe it’s important to preserve the clarity of the player’s field of vision for tactical purposes. (The only exception being dark gray debris left from destruction--to inform the player where something happened as well as positive reinforcement for the good old “hell yeah, I blew something up!” feeling.)

That’s not to say there’s no diversity to the maps. As you’ll see below, on their own machines already do a good job of indicating what a given area is for. And with that we arrive at the meat of this post: Now that we have these beautiful procedurally generated maps, what do we decide to put where, and how?

Furnishing Types

“Furnishings” refers mostly to machines. One advantage of Cogmind machines is that they always occupy more than one cell (space), and are always represented by ASCII line art. These characteristics mean they won’t be confused with robots or items, and enables significantly greater variety than if each had to be represented by a single ASCII glyph. This is made possible by the fact that maps are large and open, and big machines give the map content a better sense of scale--roguelikes are an abstraction, but when possible it’s nice that objects which should take up more space actually do.

More on each of the three categories of furnishings below.

Interactive Machines

These have been discussed several times before in terms of their functionality and hacking. Interactive machines are those which can be accessed via a special window to perform certain actions, including terminals, fabricators, scanalyzers, recycling units, and repair stations. There are plans to add some special interactive machines with unique features, though those haven’t been added yet.

cogmind_terminals1_sprites

The sprite sheet for low-level terminals. All interactives are drawn in grayscale and the game applies color automatically depending on their type. Each is surrounded by a faint rectangle and the props definition file specifies the coordinates of the top-left corner so the game can find the right sprite. (That first terminal is the one exception to the “machines always occupy more than one space” rule.)

There are three levels for each interactive machine, which generally offer increasing rewards at the cost of hacking higher security. Each visual style is associated with a specific type of operating system version, and Cogmind gains familiarity with each system based on the number of times each is accessed, somewhat limiting the number of possible styles (they need to be recognizable). Recognizable styles also means that meta knowledge can be helpful here as some of the terminals are always easier to hack than others.

Non-Interactive Machines

Machines Cogmind cannot hack (because their function wouldn’t serve the gameplay) are categorized as “non-interactive.” These all appear on the map in grayscale to denote their non-interactive nature.

cogmind_machines_noninteractive

A sample selection of “research”-themed non-interactive machines as seen in the sprite sheet.

In addition to lending the maps more atmosphere, these machines also serve to break up large spaces. This is important because Cogmind now has even larger open areas than seen in the 7DRL, and there really needs to be something to hide behind in the largest of them to make a stealthier approach possible, or simply to put something between you and an attacker.

More information on non-interactive machines in the next post.

Stockpiles

Being a collection of items, “stockpiles” are not a permanent dungeon fixture, but act somewhat as a furnishing since they occupy more than one space and you often won’t want the entire batch so some/all of it will remain in place. They are therefore placed along with machines during the “furnishings” stage of map generation.

In Cogmind items are frequently found in groups rather than individually. A single stockpile contains a random number of items (from 3 to 9), divided among 1-3 types. Thus it is common to find multiples of the same item, a design decision that pairs nicely with Cogmind’s mechanics since you can (and often want to) equip more than one of the same item, or carry spares for when one is blown off.

cogmind_stockpile

A typical early-level stockpile containing a couple wheels and some storage units.

Object Placement

The object placement process is largely data-driven, relying on a substantial number of interrelated arrays to describe object count, relative frequency, type of location, amount of padding between walls and other objects, etc. The details are way beyond the scope of a blog post (and also fairly boring), so I’ll describe the process here in a general sense.

Objects are placed according to a “composition” system that determines how to decorate a room or hall (open area). An area can contain:

  • An interactive machine, any number of non-interactive machines, and one or two stockpiles.
  • An interactive machine and any number of non-interactive machines.
  • Any number of non-interactive machines and one or two stockpiles.
  • Any number of non-interactive machines.
  • One or two stockpiles.
  • Nothing (empty).

Each type of map specifies the chance that each room or hall will pick a certain type of composition (weighted probability). I’ll use a hall as an example:

The interactive machine, if any, will be placed first.

cogmind_hall_placement_interactive

Interactive machines are initially placed along the edge of an inner rectangle defined by maintaining sufficient machine-wall padding on each side.

It then has a chance to be pushed back against the wall, as long as doing so won’t obstruct any doors or pathways.

The stockpiles, if any, are then placed using the same rules (along an inner rectangle, and possibly pushed against the wall).

Non-interactive machines, if the composition requires any, are used as a final stage “filler.” The largest possible array of a randomized type of machine is placed randomly within the hall’s inner rectangle. Any location in that array which overlaps another object or its padding area will remain empty. In this case the generator chose to place an array of Processing Tanks.

cogmind_hall_placement_noninteractive

A two-dimensional array indicating potential placement of non-interactive machines.

In the above example, placing the bottom-left tank would be too close to the scanalyzer, so it is removed from the array.

cogmind_hall_placement

The final hall.

Non-interactive machines usually appear in repetitive clusters, though sometimes one or more within the group may be replaced with a different machine that is no larger than the others.

Because their frequency affects gameplay balance, there are a limited number of interactive machines and stockpiles that can be placed on a given map--as limits are reached those objects are skipped in the placement phase. Technically this also means that not all of them might be placed if there aren’t enough rooms/halls, though properly designed map parameters should have the right amount of space to fit them all.

Note that most machines are allowed to be rotated in any direction, making it easier to fit them into more areas and increasing the chance of placing everything the map requires.

During the furnishings placement stage, halls are parsed in largest to smallest order--the larger they are the more we need to put something in them, while rooms are parsed in a completely random order for now. Later placement stages put terminals in high-traffic junctions, and individual (non-stockpile) items anywhere on the map, preferring more secluded areas for higher-rated items.

Some map excerpts showing machine placement variety:

cogmind_machine_placement_matter_filter

This Matter Filter fits nicely into this room.

 

cogmind_machine_placement_nuclear_terminal

This terminal presumably controls the neighboring nuclear reactors, as well as providing a point from which to hack the local system.

 

cogmind_machine_placement_electrolysis

Hm, what could they want with all those electrolysis chambers?

 

cogmind_machine_placement_matter_pump

Matter Pumps and an Integration Channel in a side room. Plus someone left a pile of Assault Rifles here for the taking.

The next post will take a closer look at non-interactive machines, including the system used to decide what machines belong on each map. Also some fun stuff like blowing them up ;)

Posted in Design | Tagged , , , , , , , , | Leave a comment

Dungeon Prefabs

Procedurally generated maps are great, but even with variety factored into an algorithm it naturally won’t produce anything outside its parameters. This is good in that it keeps the style consistent, but individual areas sacrifice character as a result.

Hand-crafted map pieces can restore some of that character where you really need it, be that interspersed with generated content to mix things up, or at key plot areas where a specific environment is necessary. Prefabs integrated with the rest of the map will really stand out, and be more memorable for it.

prefab_skull

Just a silly example, but writing a separate algorithm to procedurally generate skulls would be overkill.

Prefabs are a way to deviate from what may otherwise be a repetitive experience (even if that repetition is masked behind layer upon layer of random content). They also give players a “common ground” from which to discuss specific parts of a game. The more a roguelike is completely random and unpredictable, the more discussion is limited to “general survival tips.” Static areas open up a whole different category of discussion--”what can we do here” rather than “what can we do when XYZ.”

And it’s not only strategy--a whole new category of stories emerges from static areas, since readers who’ve played the game will have a much clearer idea of where the story takes place, having explored that same area themselves.

Creation

I chose to draw prefabs in REXPaint, assigning different palette colors for each cell type and painting them on the first layer.

prefab_skull_REXPaint

Initial tests used the same palette as the algorithm development program.

Other layers in the image store additional information, because prefabs are obviously about more than just the layout.

cogmind_prefab_skull_REXPaint

I changed the palette to give it the black background similar to what would be seen in game, to simplify the design process.

Above is a fully “rigged” prefab with some test content. Layer 2 (above layer 1) contains map linking/integration information (that yellow ’2′, which I’ll talk about later). Layer 3 is where unique machines/props are drawn (those gray lines and boxes). Layer 4 contains references indicating static object locations (the green letters/numbers).

Any prefab that includes specific objects (most), needs an accompanying text file that describes the objects placed in layer 4.

cogmind_prefab_skull_script

Test data/script for the skull prefab, containing a random assortment of objects.  Ideally this information could be entered/viewed/manipulated directly in the prefab editor, but in the case of Cogmind prefabs and their objects are fairly simple so I’ve opted to use a text file instead.

Objects can be listed in any order, and use any letter or number as a reference. More features, including the potential for randomized objects, will be implemented when necessary--this is just what the game currently needs to get things working on a basic level.

And here it is loaded in game connected to an actual map:

cogmind_prefab_skull_ingame

Entering the skull test in game. (The map generator dropped an extra robot and item into it because the area wasn’t set as off limits to random spawning.)

Integration

The main issue with prefabs is how to connect them to the rest of the map. Letting the map generator do whatever it wants could make a mess of the prefab and defeat the purpose, so dark gray cells surrounding the skull keep the map generator from encroaching on it. Instead we control the connection from the prefab end.

First, based on instructions from a map definition text file the algorithm reads in .xp files (produced by REXPaint), parses them for their contents, then places those cells on the map (at a random position if indicated) before any other generation begins. The yellow cell on the skull example indicates that when corridor-building begins, a 2-wide tunneler will start digging south (the nearest edge) from there, and will eventually connect with the rest of the map.

cogmind_prefab_skull_placement

The section of the map definition file that places a prefab, where the “type” is the file name containing the image. Maps also support other general [FEATURE]s besides prefabs, most useful for designating areas that are off limits to the generator.

Because the features are placed before any tunneling and random generation begins, they also support randomized placement so that, for example, you won’t always find the same point of interest in the same area of a map.

Uses

Carving skulls and other fun shapes from the map isn’t entirely what I meant by “character.” Prefabs are ideal for more functional layouts that fit specific needs of a game, like special NPC and plot-related areas.

I don’t want to rely on “finding” the right place in a map for a certain encounter to occur. I’ll just build it.

prefab_base

You meet a potential ally in the main hall and if he doesn’t like what you have to say his minions hanging out in side rooms ambush you, otherwise he lets you check out the secret weapon stash in the back. (Or: You use a terrain scanner to find that you can just blast/drill a hole into the back room from another part of the map and take whatever you like ;)

More or less the same method is used to add hand-crafted content to caves, although direct links are used instead of a tunneling algorithm so they don’t get out of control and take over the caves.

prefab_cavebase

Hm, we could walk in the front door… or not.

This is the fifth in a five-part series on procedural maps:

Posted in Design | Tagged , , , | 4 Responses

Dungeon Metrics

Rarely will an algorithm produce a perfect procedurally generated map, and even if it does, some degree of post-processing will still be necessary to analyze the layout. When we look at a map produced by a generator, we can determine pretty quickly whether or not the layout is sufficient for our purposes; we can also see likely bottlenecks where enemies might gather to stop the player, or areas considered “out of the way” that might hold more treasure. In the program, however, a map is nothing but coordinates telling us what each space represents, giving us no hint as to its overall composition and layout. How do we teach a game to understand and use the map as we do? We need “dungeon metrics.”

Requirements

First and foremost we have to check if we even want a given map. Without any constraints on the results, the same algorithm can produce a wide variety of layouts, some of which are either not what we expect or downright unplayable. In those cases we’ll want to throw out the map and try again.

Composition

The most basic requirement is the final amount of playable, or “open,” space. A lower bound ensures the map isn’t too sparse, while an upper bound keeps it from being too open.

map_metric_openness

These two caves were generated using the exact same algorithm, differing by only one parameter: the amount of open space required (15~30% on top, 40~60% on bottom).

Another important requirement to consider controlling for is the number of individual rooms/caves of varying sizes.

map_metric_roomcount

These two maps were generated using the exact same algorithm, differing only by the number of rooms required (20 or more small rooms on top, at least 20 medium and 5 large on bottom).

Pathfinding

Some games use precalculated map data to optimize pathfinding, but that’s not what I’m referring to here (it’s also not too useful in Cogmind due to the completely destructible environment).

Pathfinding is an important part of map analysis since you have to ensure it’s possible to reach one or more exits from the entrance of a map. This won’t be an issue for cellular automata assuming the final tunneling phase is doing its job, but tunneling algorithms constructing maps with more than one tunneler must confirm that the tunnelers did eventually meet and join their respective creations.

Another possible requirement pathfinding can enforce is a minimum distance between entrances and exits. If too close together much of the map area remains unexplored, an especially relevant issue in Cogmind because there is no XP system--the best reward (“evolving”/leveling up) comes when you find the exit. Having an exit too near the entrance would be poor design in this case since there’s little incentive to stick around.

Etc.

An alternative to automating the selection process is to use procedural generation but hand-pick the set of maps that are actually used in game. This works, but ultimately limits the pool of possibilities to the number of maps selected by the developer. (Nonetheless some games out there do use this method.)

Whether selecting maps for final use or simply to trying to improve an algorithm, it can help to have multiple ways to look at the same map. For example a monochrome view is useful for checking available play space and overall layout without being distracted by a map’s individual parts.

map_metric_monochrome

The normal view on the left is nice for clearly identifying size and positioning of caves, but the monochrome view is the purest representation of playable vs. non-playable space, and is closer to what the player will see and experience.

See the previous two posts for images showing individual highlighting of tunnels, caves, rooms, junctions, “halls,” etc. Those are not processed images--the debugging features of the map generator itself include many such views to aid development.

Another tip for more efficiently addressing issues during development: Always have the generator output the random seed used to generate each map (I have mine added to an ongoing list). That way you can always feed the seed back into the generator to repeatedly generate the same map and find out what went wrong or how the algorithm could be improved.

Records

Once you’ve decided to keep a generated map, there’s still plenty to be done. It’s time to analyze the content and layout to record what useful info we can.

The simplest component we’ll want to remember is where all the rooms/caves are located. Rooms (and corridors) dug by tunnelers are easy since we built them in the first place--just record as you go. Caves are a different story since they were grown randomly. To find them we just scan the map with a standard floodfill.

map_metric_floodfill

Locating caves in a map via floodfill before connecting them.

Herein lies another advantage of allowing cellular automata to create many disconnected caves then reconnecting them during post-processing: The caves are naturally separated into discrete “rooms” for you by the algorithm! This means we’ll later be able to take advantage of any of the methods of analysis that work on normal room-and-corridor dungeons. More on that later.

Location and size are not the only important information that could come in handy when deciding how to use different parts of the map. We can record doors and which direction they face (used for optimizing some types of pathfinding, or setting up ambushes), which rooms and corridors are attached to each junction, which tunnels are linked to which cave(s), and which caves are directly accessible from another cave. My favorite piece of data that I’ll be discussing further below is relative seclusion/connectedness.

General statistics collected from the final map may also affect what you decide to do with it as a whole, data like the percent composition by cell type, maximum and average seclusion of areas, the largest individual hall/cave, etc. These could of course be used as additional requirements to filter out unwanted maps.

Analysis & Application

So what do we do with all this collected data besides decide whether to throw away a map? The obvious application is object placement.

Robots and parts in the 7DRL were spawned without regard for whether an area belonged to a room or corridor; you could find a stockpile of parts sitting anywhere out in the open. It would make more sense to store most of those in rooms, both for realism and from a gameplay point of view (“do I open that door to search for parts even though my scanners show robots on the other side that may or may not be hostile?”).

As mentioned before, corridor junctions are likely to contain terminals, and large halls will contain bigger machines. Guards are more likely to patrol intersections. Choosing the best locations would be difficult without first recording details about the map layout.

Connectedness

My favorite analytical tool for cave systems is the relative connectedness of each cave.

map_metric_connectedness

Visualization of cave connectedness, where brighter caves are better connected to the system.

Because the number of direct cave connections alone is less meaningful in many scenarios, I define “connectedness” as the number of immediately connected caves plus the number of caves those are connected to as well. Notice in the above visualization that outlying caves are shaded darker, representing a lower connectedness value.

Less connected caves in different parts of the map are likely positions for entrances/exits, and others are good candidates for placing loot, secrets, or perhaps nastier surprises for nosy explorers.

At the other end of the spectrum, well-connected caves are where most enemy activity will probably be concentrated.

Seclusion

For maps created by the tunneling algorithm, all rooms are rated by their “seclusion” value. Seclusion uses different calculation criteria than cave connectedness since map connectivity is much higher. Instead it’s based on the distance from the fastest path the player can take between an entrance and the exit(s).

map_metric_seclusion

Visualization of room seclusion, where darker red rooms are further from the quickest routes across the map.

The four entrances/exits (pink dots) are connected by the most direct paths between them (green lines), then the entrance to each room pathfinds to the closest point on any of those lines. Notice that the further a room is from a path the darker its shade of red. (For purposes of the visualization any room with below average relative seclusion, where “average” is based on the map values, is not shaded.) The more secluded a room, the more likely it will hold something of value or interest to the player. Of course this idea of “seclusion” assumes the player knows where they’re going when they may very well not! But that’s okay, because the player deserves a little something for having traveled so far out of their way, and having overcome whatever obstacles they had to in order to arrive there.

This is the fourth in a five-part series on procedural maps:

Posted in Design | Tagged , , , , , | 7 Responses

Mapgen: Cellular Automata

Unlike the 7DRL, which only spanned a 10-level “main dungeon,” Cogmind will cover a much greater area. Naturally a larger world needs a greater diversity of regions to explore. Taking place underground, many of the outlying areas tend to be caves, and for that cellular automata are usually the best choice for generation.

I say that but I’m actually not going to use the standard application of cellular automata. (Read about the standard process here, here, or here; I won’t be explaining it in detail.) Instead I kinda fell in love with a related idea described by Andy “Evil Scientist” Stobirski over on his blog earlier this year.

Evil Science

His method still relies on cellular automata in that you apply adjacency rules to open and close cells organically, but instead of repeatedly applying the rules across the entire map at once you pick cells at random. (Hey, we make roguelikes and we like random, so random it is!)

Performance-wise I believe that once fully optimized Andy’s method is faster than the standard method for achieving comparable results, and it’s a lot more versatile in terms of what it can do. I don’t have a lot of experience fiddling with cellular automata, but the few times I tried it was somewhat difficult to tweak for good results. This method produces good results with ease. “Good” is of course relative, but what I was looking for wasn’t quite available with vanilla cellular automata. I need more variety, and the flexibility of this method makes producing a variety of nice maps a simple matter. I’m sure variety can be coaxed out of cellular automata (via switching rules partway through generation), but it won’t come as easily as these did:

evilscience_map1

evilscience_map2

evilscience_map3

I like how in many maps the random distribution of rule application creates variety even within the same map, in the form of a mix of sharp and round, large and small areas.

One of the variables you can tweak using this method that is not normally adjustable when using cellular automata is the number of cells randomly visited, which is where some of the additional variety comes in. Lowering the number of applications will result in some rougher maps, but a final smoothing phase can still operate on that and get some interesting results:

evilscience_map4

Connectivity

As with any cellular automata-based procedural map generation, connectivity is an important issue to consider. If there’s no way to travel between multiple disconnected areas on the map, then the extra ones may as well not be there. In that vein one solution is to remove unconnected areas entirely, but that doesn’t work with certain cave styles because there will naturally be many disconnects resulting from algorithms used to achieve thinner “sprawling” styles (as opposed to big blobs).

The better solution creates new connections to reattach those areas. One possibility is to “grow” some areas so that they reconnect with others. Another is to dig tunnels between them. I prefer tunnel connections because they 1) fit the style and theme I’m going for, and 2) allow a cave system to consist of many smaller caves that can be individually identified as “rooms” for purposes of object placement (this advantage will become apparent in the next post on dungeon metrics).

My solution here varies a bit from Mr. Evil Scientist (mostly since I’m delving into the specifics of applying it to a game while he was building a more generic generator). Mine removes most pointless U-bends, goes through multiple corridor-digging phases that may not apply to all caves, has an adjustable ratio of cave-spawned corridors vs. branching corridors. and sometimes chooses to dig wider tunnels based on both set parameters and the relative size of caves being connected.

cogmind_map_automata_tunnels

Tunnels connecting individual caves.

Guided Generation

Cave maps in Cogmind won’t be as large as the main dungeon maps introduced in the previous post, but even then smaller square cave maps tend to simply not be very fun to explore, at least in the disconnected style I’ve chosen to go with. Taking the above map as an example (that’s one of the styles I’m currently planning to use):

cogmind_map_automata_flow

Flow path of a square cave map.

Assuming we’re not putting a meaningful destination at the end of every dead end, the above map will require a lot of backtracking, and even if more tunnels are dug to turn it into a more intricate web of connections (enabling more loops), the map really won’t be too fun to explore due to a fundamental difference between caves and normal dungeon maps: The rough edges are filled with nooks and crannies that you have to fully explore to make sure you didn’t miss an important pathway.

In a normal dungeon with flat walls and rectangular rooms you can quickly scan the entire visible area and be relatively sure of where there is and is not a valid path. In caves you can’t be sure you haven’t overlooked something until checking everything out up close. That gets tedious, more so when you weren’t headed in a certain direction in the first place.

The solution is “guided” cellular automata. Let the generation play out as normal, but enforce a general shape that the cave must fit into, such as the narrower corridor seen below.

cogmind_map_automata_guided

Caves made fun with guided cellular automata.

This way we can continue to use the sharp spiky style with longer offshoots but keep everything moving in the same general direction.

Mines

Another variation on this algorithm will be used for mines. These are generally smaller maps where you have rectangular areas dug out for processing machinery and storage purposes, as well as the actual mined areas connected to them via corridors.

cogmind_map_automata_mine

Mines have a higher number of connections and loops.

Composite Maps

Who said a single algorithm has to control an entire map? Some special areas could very well combine cellular automata and the tunneling algorithm for special cases.

cogmind_map_composite

A hidden base?

This is the third in a five-part series on procedural maps:

Posted in Design | Tagged , , , | 4 Responses