Official development blog
[ Latest Cogmind Release Notes: Feb 2026, "Unchained More" ]

Special Game Modes in a Roguelike Context

By Kyzrati | Published: May 29, 2019

By their nature roguelikes are highly replayable, but can also serve as a great foundation on which to essentially multiply that replayability again and again. Adjust a few variables here, add a little content there, and you can have a very different game, one that some people admittedly might enjoy less, but they don’t have to play it--others who do like the the alternative mode have a whole new way to interact with an otherwise familiar world, or take it as a challenge depending on how it’s designed.

What I’m calling “special modes” includes everything from timed events to challenges and conducts, basically different ways to play the same game, primarily ways which are explicitly codified by the game, although non-codified alternatives are also within the scope of this discussion.

Why Special Modes?

There are many good reasons to including special modes in a roguelike. Here are some of the advantages I’ve encountered during my work with them over the years:

  • Value: Well obviously as with any additional content, there’s more value for players. This also translates to value for the wider community as well, since special modes serve as another source of interaction whether it’s sharing stories, bragging rights, or just talking strategy.
  • Replayability: Special modes can require players to explore whole new strategies within the context of a body of knowledge they’ve already accumulated about the game so far, just seen in a different light, making an already replayable genre that much more replayable.
  • Learning: Having seen the game in a new light, some of the knowledge gained through these alternative experiences can even translate back to improved skills while playing the main game.
  • Experimentation: Special modes enable players, and most importantly the developer, to experiment with new ideas that may even make it into the game proper--the design can go out on a limb here without any real repercussions. Of course you can already do this with prereleases/beta releases/EA/whatever, but the idea here is that these mods can also continue to live on on their own, without having an impact on the game as well, for those who choose to play them.
  • Interlude: As a developer, sometimes it can take a while to put out a major update. In the meantime, rather than keeping players waiting too long for something new, why not release a special mode to play around with? (Note this category also includes postludess as well, breathing new life into a game after most or all of its updates are out there and development is “complete.”)
  • Efficiency: Handling special modes as “interludes” is also made easier by the fact that they’re generally not that hard to implement. You get lots of bang for your buck in terms of dev time here, due to reusing not just assets, as you might with an expansion or DLC, but basically reusing pretty much “the entire game” and just changing the experience, possibly even significantly, in a relatively short time. This generates a lot of low-cost value.

Naturally it makes more sense to apply special modes to an existing expansive project, since there’s more content and systems to work with, though technically many of the same characteristics can apply to any roguelike, large or small. Still, these modes are more of an optional “extended development” sort of goal, and if the base game isn’t yet complete or at least itself an already compelling experience, then clearly more work needs to be focused there first :P

Sample Cases

To demonstrate some of the above, let’s look at the range of Cogmind’s special modes, which take multiple forms.

Timed events

A few times over the past couple years I’ve added special modes that trigger automatically at a certain time, for everyone to participate in. Of course there is/should also be a way for people to opt out of this if they’d like to play a regular run during that period, but I also make it so that these modes don’t kick in unless a player has already finished several runs and has some experience (or in the case of one of the events, a fair bit of experience).

I’ve seen a number of indie devs do holiday-themed events these days, though most don’t seem very expansive, maybe just a little change or bit of content here or there.

April Fools Day is a good candidate if only because the theme can be a combination of something totally crazy/funny/unexpected. Plus of course there’s the fun result that some people don’t even believe the news is true, while for those who learn it’s a real thing it also kinda counteracts the growing internet annoyance at all the fake game-related announcements people wish were true xD. I like making an April Fools announcement about features everyone can actually play with.

I’ve done a couple of these so far, starting in 2018 with Launcher Mode. This one is a good example of a quick modification that changes the entire experience in interesting ways. All it does is essentially convert all obtainable weapons to a random launcher instead. Launchers are powerful, but also resource-hungry and not great at solving every sort of challenge, so strategizing ways around their shortcomings (with a more limited set of options) is a pretty new kind of experience. Plus players get to use fun weapons that tend to be more rare in regular runs :)

cogmind_afd2018_launchers

Sample map area with all items replaced by random launchers for April Fools Day 2018.

Being put together so quickly there were a couple of oversights, like at first enemies could still drop their weapons and you could arm up with non-launcher weapons that way, but I fixed the main issues with a quick patch shortly after release.

From conception to implementation to deployment, this entire mode took only an hour to put out, and wasn’t even planned at first, but literally on the morning of 4/1 a player asked about April Fools and it sparked an idea (another reason having an active community is so great--lots of interaction to spark new ideas). Overall a relatively small effort for big gains.

Unfortunately I don’t know how many people actually played because at the time I simply decided to deactivate score uploading if using that mode to avoid polluting the leaderboard with non-standard runs, but news about the mode did get posted around (and even attracted attention from new buyers) and people thought it was fun, or at least funny even if they didn’t play :P

Certainly the AFD (April Fools Day) data could be directed elsewhere, but I wasn’t thinking about it then, and there wasn’t time much time to think through doing that anyway--it was already the morning of release!

In April 2019, however, I once again released a special mode, and this time I had both more experience and some time to dedicate to redirecting scores for this mode so we could get some player data, and a dedicated leaderboard. Participation was limited (42 players) since the leaderboards are opt-in and it was just a timed event, but it was nice to be able to look at some stats from the runs.

cogmind_pay2buy_leaderboards_190419

Cogmind April Fools Day 2019 Leaderboard

The theme for AFD 2019 was “Pay2Buy,” where players don’t find or salvage spare parts, but instead earn coins and buy items from the “Cogshop.” There’s even a market economy, loot boxes, and special deals!

cogmind_pay2buy_demo

Buying items from the Cogshop.

This was most certainly not a one-hour job like AFD 2018.

I spent a week designing and putting together the Cogshop and related mechanics, but I think it was a week well spent since as per the “interlude” concept mentioned above, it gave me something new to put out there during a lull of regular releases. The previous release was 7 weeks before 4/1, and now 7 weeks later (as I still work on some extremely time-consuming features) the next major release still hasn’t hit, so yeah we really needed a little something out there :P

Pay2Buy actually wasn’t the first idea entertained this year--in the run up to April 1st I experimented with turning Cogmind into a real-time game, but that didn’t feel like it would be fun for a majority of players so I dropped it. I talked about this mode and its design on Patreon here (patrons only).

Another important detail about these particular “timed” events, is that I built them to also be available after the event period. Not everyone who might want to can necessarily play on April Fools Day, so just like there’s a method for players to opt out of the events, they can also opt in on other days (both handled via command line switch). This wasn’t true in 2018--back then the advice was simply “change your system date when you start a new run,” but it’s kind of annoying to require that players mess with their system for something like this! I added the mode-forcing feature this year.

So these event modes have become permanent optional features. They’re simple and/or isolated enough that there shouldn’t really be much maintenance involved in future versions, may as well make them available to everyone down the line :D

Late last year we had another timed event which I approached very differently: “Limited Edition Holiday Mode 2018.”

cogmind_holiday_mode_2018_present_matrix

Cogmind Limited Edition Holiday Mode 2018 logo

Running from December 20th through January 1st, the highlight of this event was getting PRESENTS.

cogmind_holiday_mode_2018_scrapyard_presents

The Scrapyard is full of presents! Who could’ve done this…

cogmind_holiday_mode_2018_present_art

Go ahead, open it!

Opening each present revealed one or more items, really good stuff, and available right in the starting area. Not just any good stuff, though, the majority were chosen from among 17 brand new holiday-themed items, some with new mechanics (see this followup announcement for details).

cogmind_holiday_mode_2018_black_coal

Dropping a piece of “Black Coal” outside a Garrison and making a run for it.

A few of the less special items were randomized, but most I handpicked for each day to allow for different experiences through different combinations, of course taking into account special days like Christmas Eve, X-mas Day, and New Years. The craziest, flashiest item was reserved for reigning in the new year:

cogmind_holiday_mode_2018_RPDS_ASCII

Behold, the RPDS!

cogmind_holiday_mode_2018_RPDS_tiles

RPDS Demo: Now With More Tiles Edition

Yeah it looks OP, but it’s also an insane drain on resources so is not easy to properly use! Not to mention the complex gets really mad when you destroy so much stuff that quickly, and that usually means trouble. Still fun though :D

Now this all seems like a fairly big production, but I only spent two days on it! Surprised myself with that one, really. It would’ve taken longer had I decided this event’s features would be future proof and available through all following releases, but this one was a true limited-time event only available in that one version of Cogmind. As a one-time event, I was able to rapidly add content without putting any time into considering or preparing for possible long-term consequences of my decisions (or even organized/coherent scripts and code xD) like I normally have to do.

This highlights one of the drawbacks of special modes, that in order to keep them usable in future versions they may have to be maintained along with changes to the rest of the game, which can be time consuming and possibly not worth it, so it’s good to differentiate between temporary but extensive modes and those modes with a more limited feature set which can more easily be kept with minimal maintenance going forward.

Both AFD 2018 and Holiday Mode had really high “bang for buck” quality. Less so with AFD 2019, but it was definitely still worth it since we got to keep the mode and it’s a pretty interesting way to play.

Challenge Modes

Cogmind currently has 12 “challenge modes.” The design scope for these is somewhat narrower than time-based events, which might inherently be challenging to various degrees, but the focus there is mainly on fun. Challenge modes, on the other hand, are an optional way to increase the challenge level of the game through various modifications. Multiple challenges can be active at once, and each one intermittently awards points for reaching milestones. Plus of course there’s the advantage of allowing players to simply face different or unusual challenges compared to those they might normally face during their runs.

I haven’t covered these on the blog before since I’ve generally considered them an “experimental” part of the game, although I’ve been maintaining a forum thread updated with their content.

They’re not even accessible from in-game menus, actually, only via an external config file, but challenge modes have technically been integrated into the game proper via achievements for winning them, and there’s a separate leaderboard as well.

Below is the current set of possible modes, just stuff I either 1) thought would be challenging to try or 2) easy to implement anyway and worth experimenting with:

  • Devolution: Start with three times as many part slots, chosen randomly (from a weighted distribution) and lose a random one at each new evolution, growing from super strong to eventually extremely weak.
  • Fragile Parts: All parts are destroyed on removal, mimicking the standard behavior of processors.
  • Gauntlet: All exits from each map are blocked from use except for the furthest main exit from the map’s entry location.
  • Inhibited Evolution: Only evolve half as many slots as usual at each depth (essentially weaker throughout the run).
  • No Salvage: Destroyed robots leave no salvageable parts, only matter (a resource), making it harder to find the right/useful spares.
  • Pure Core: No inventory slots are available for the entire run, only what parts be attached.
  • Scavenger: There are no random part stockpiles in the main complex, and any lone items strewn about are damaged. Everything else must be salvaged from other robots, stolen from haulers, or fabricated.
  • Simple Hacker: No indirect or manual hacking of any kind.
  • Sticky Parts: No parts can be removed or swapped out manually, and must be destroyed to free their slot(s).
  • Super Gauntlet: All exits from maps are locked, and the only way to advance to the next depth is to find and fight through the one unlocked Garrison.
  • Trapped: Most maps have 10 times as many traps, which are also more likely to trigger, and most methods of learning trap knowledge are unavailable.
  • Unstable Evolution: No control over slot type evolution, which is random.
cogmind_challenge_scavenger_example_map

Random damaged parts lying around in the Scavenger challenge mode.

cogmind_challenge_simple_hacker_no_manual

Manual hacking option disabled for the Simple Hacker challenge mode.

(See the forum thread for sample images from more challenges, along with other ideas and discussion. Also the manual has more specific mechanics and scoring descriptions than what’s found above.)

Most of these are actually quite easy to implement, again a good way to add value and new experiences to the game at little cost.

They’re also still an ongoing part of feature development. It’s been ages since the last batch was added, but I’ve got dozens more ideas in this area (and of course many suggested by players as well), I just need to decide when to add more… I guess the plan was to make an in-game menu to access them first, and do this and more as a dedicated release, but as a time-consuming but low-priority feature that’s been repeatedly pushed back.

Conducts

Conducts (also called “challenge games” or “challenge runs”) exist in many roguelikes, from as early as the classics. Conducts are different from Cogmind’s so-called challenge modes in that the latter actually modify the content or mechanics in some way to create the challenge, whereas traditionally conducts work within the base game itself without any changes--they’re purely dependent on some kind of player-based limitation.

For example NetHack includes a number of optional conducts that you can read about here on the wiki.

nethack_conducts

Some of the conducts NetHack tracks, as listed in game via the extended #conduct command.

Brogue also tracks conducts, which it calls “feats.” The full list can be found here.

brogue_win_feats

Victory screen from Brogue, having achieved two conducts (source).

Unlike the above examples which are just detected automatically as you play a normal run, Angband players essentially treats some of its “birth options” as conducts, though there aren’t very many--some roguelikes lend themselves to conducts better than others.

Not all conducts are necessarily tracked by a roguelike, many more originate in the player community and become established as “unofficial” conducts, challenges attempted by many players but that aren’t technically coded in the game, instead relying on players self-enforcing the appropriate limitation(s) or requirement(s).

NetHack also has a decent-sized list of unofficial conducts (some of which are tracked by variants even though vanilla does not), and ADOM has a number of established unofficial conducts as well. Some of ADOM’s achievements have since become semi-official by having them recognized via Steam achievements in that version of the game.

Cogmind definitely has its share experienced players who self-impose conducts, too, and even an “official” set as in those represented by relevant achievements. Although Cogmind achievements don’t require Steam, the achievement system is the only one to codify and enforce these conducts, and therefore technically each only works once (the first time it’s achieved). Later this could be expanded to recognize them in any subsequent run even after having been previously achieved, but I’m not too sure of the value in doing so just yet since there’s a lot of other more valuable features, not to mention there are so many achievements that it’s easy for players to stay occupied doing new and different things anyway, as opposed to repeatedly attaining the same goal.

One difference worth noting here is that “conducts” are traditionally more specific than a lot of achievements, which may be accomplished before actually winning the game. A conduct is not fully earned until the run is won, so they’re generally challenges by and for the minority of experienced winners choosing them as a way to intentionally make the roguelike even harder.

Cogmind currently has 256 achievements, but win-related conduct achievements all fit into the following subcategory:

cogmind_achievements_win_challenges

Cogmind sample achievements in the UI.

Then there are 12 more for winning with each of the Challenge Modes, though again these actually change the game, and I wouldn’t consider them conducts as defined here. And quite a few more of Cogmind’s achievements require long-term conducts within a given run, but can technically be earned before winning so don’t really count, either.

Non-meta Conducts

Conducts as described above and generally thought of by the roguelike community are “meta achievements,” basically optional challenges imposed on top of the game itself, and probably can be stopped/forfeited at any time by player choice, regardless of whether or not the game is tracking a given conduct.

But I think there’s an interesting alternative category of conducts embedded within the gameplay.

DCSS god conducts would be an interesting example here. Once you worship a specific god, they may expect you to avoid certain behaviors, or reward you with greater piety for other specific behaviors. This clearly restricts or at least affects the player’s “conduct” for much of the run, or at least until (if) the player is willing to suffer the consequences of leaving for another god.

See here for a list of DCSS gods, which link to more information about each, where the “Deprecates” heading indicates what kinds of conduct that god expects.

dcss_god_deprecates_chei

DCSS’s Chei is a good example of a restrictive god.

Most gods don’t have a whole lot of limitations, instead focusing more on behaviors they’d expect or prefer that you do in order to gain piety and reward you for it. An interesting exception here is Ru, the god who will only reward you (greatly) as you take on additional permanent drawbacks (“personal sacrifices”), which essentially act like minor conducts.

Cogmind also does some of this non-meta “embedded conduct” stuff, although not god-related and instead on a more macro scale. For example you can permanently install RIF in order to gain a range of useful abilities, but doing so makes two of the other factions hate you, and you’ll therefore lose access to their respective help and abilities for the rest of the run.

There are a number of long-term effects like this, though unlike traditional roguelike conducts which are purely negative, Cogmind generally (but not always) balances them out so that something else of similar value is gained in the process. Either way, the effects are for the long term and some will make certain areas, or even the entire run, more challenging.

Randomized Challenges

Beyond tradition, there is still plenty of room for innovation in the roguelike “special modes” space.

One of the more interesting possibilities is randomization of challenges. As a highly replayable run-based genre roguelikes are quite compatible with this approach, where you have a pool of mini-challenges which can include things like tweaks to mechanics, items, enemy behavior, or the player character themselves, and at the beginning of a run a combination of these tweaks is chosen to be combined as the challenge. With enough tweaks to choose from, different combinations can create very different experiences, all without too much work beyond the supporting framework.

Even better is having the combination be shared across the community as daily and/or weekly challenges, giving the community more topics to discuss and allowing for separate leaderboards.

I’m not too sure this is appropriate for Cogmind given the game’s wide range of interconnected systems and far-reaching balance concerns (it’s a very tightly balanced game compared to many roguelikes…), though the concept certainly deserves more thought and possibly experimentation. Could be fun!

While combining multiple Challenge Modes is a thing, personally I have a pretty specific idea of what constitutes such a mode, which tends to exclude tweaks which might be too small a change (or, less likely, too large an overhaul) to consider for a pool of mix-and-matchable mini-challenges. The target scope would be different in that case, so this would need to be a different system. I can see affecting game variables like item availability, salvage drops, and map demographics, adding permabuffs/debuffs of various kinds, or possibly starting from different parts of the world.

Anyway, there’s already (still xD) lots of do, but maybe this could happen one day.

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

Turn Time Systems

By Kyzrati | Published: April 23, 2019

I’ve always enjoyed turn-based games, giving you unlimited time to consider and react to changing situations (even if you don’t always take advantage of that opportunity and instead bumble into mistakes far faster than necessary). Turn-based mechanics are especially apt in traditional roguelikes, where the RNG typically plays a starring role and therefore said changing situations can be unpredictable, but exactly what can be accomplished in the space of one turn, and what a turn really represents, varies from game to game.

At the most basic level, we have turn mechanics which are simply [player acts] -> [enemies act], all in sequence, one action per turn, and then the queue starts over again, [player acts] -> [enemies act], and so on. Then some games might add longer actions, though still very clearly based on “whole turns,” like performing a longer action forces the player to skip their next turn. Or the more complex variety: An action requires first waiting for two consecutive turns without interruption (by attacks, for example) in order to be carried out.

But sometimes even more granularity is desirable for content or balance purposes. Like what about actions that take one-third of a turn? Or 2.5 turns? Roguelikes of significant scope are more likely to need a greater level of granularity in order to accommodate more content in a balanced manner. (It’s not absolutely required, of course, but it’s helpful in the long run :D)

This granularity can be a double edged sword, though, since there’s always the chance that as a time system grows increasingly nuanced, the more oddities arise and the more opaque or confusing (or at least challenging) it might become, both to build around and for players to master. As with any game mechanic the opaqueness is at least generally solvable through a better interface and feedback, if necessary, but it’s worth noting that systems with higher granularity will also be much less predictable, so hopefully precise turn predictability isn’t an important factor in a roguelike that also features extreme granularity!

Cogmind Time, 2012~2018

Cogmind 7DRL, written in 2012, was my second roguelike project, based mostly on the X@COM source code. Well, X@COM being a reimagining of the original UFO Defense, it was a squad-based game with explicit Time Units which could be used to perform actions by each soldier until declaring the end of the turn and allowing enemies to act. There was no single player character, and most turns by each individual involved a sequence of multiple actions limited by their stats and what kinds of actions they wanted to perform.

Migrating from this sort of system to a decidedly more roguelike time system would be a pretty big leap, and being a 7DRL I wasn’t going to have a ton of time to experiment with what does and doesn’t work, so I searched around and decided to adopt the system demonstrated in this useful Rogue Basin article.

What is a “roguelike” time system? I think the most basic assumption is that it consists of a single actor performing a single action at a time, and after their action it’s at least possible, if not likely, that other actors will get to perform their own action. Of course there are many potential variations, and definitions don’t mean much in the bigger picture, but X-Com’s TU-based turns would not be considered very roguelike, which generally boil down to [one command] -> [one action] -> [implicitly done].

I picked the system in the linked article because it seemed easy enough, and at the time I wasn’t really familiar with how roguelike time works under the hood anyway. The system is not a simple queue, and has some interesting characteristics, but I’ll get into those details later when I cover how they eventually became a problem and I recently decided to replace it!

For the next bit of discussion, all you need to know is that each “turn” is subdivided into 100 “time units.” Actors can carry out actions that might require only a fraction of a turn (< 100 units) or multiple turns (e.g. >= 200 units). While sometimes more difficult for players to wrap their heads around at first, and also sometimes difficult to accurately predict even once it’s understood, I believe its flexibility outweighs those potential negatives.

Action Costs

The length of an action is extremely variable in Cogmind. Most actions require a static amount of time, but the two most common actions, moving and attacking, are calculated based on multiple factors, and therefore change throughout the game depending on your status.

To keep things simple, the majority of actions take either one turn, half a turn, or 1.5 turns:

Cost Action
100 Pick up Item
100 Attach Item
150 Attach from Ground
50 Detach Item
50 Drop Item
150 Swap Item (Inventory <-> Equipment)
100 Misc. Actions (Ram / Rewire / Escape Stasis…)

And that’s it--Cogmind doesn’t actually have a wide variety of unique action types, and for simplicity sake a lot of miscellaneous actions require precisely one turn. But with one turn the equivalent of 100 time units, there’s a lot of leeway for fine-grained requirements when it comes to the most common actions: moving and attacking.

Moving even a single space involves a potentially huge range of time, quite different from the average roguelike. How long it takes to move is highly dependent on the form of propulsion:

Cost Propulsion
40 Flight
60 Hover
80 Wheels
120 Legs
160 Treads

Those are simply base costs, though, which might vary somewhat with unique items, and which in the case of flight and hover can be further modified by using multiple items at once. For example using three flight units will be faster than using two.

So in a simple scenario, a flying actor (robot) can move three times for every one move of a legged robot, or four times compared to a treaded robot. And that’s only given the base costs! Assuming a loadout of five flight units, each of which gives a -3 cost modifier after the first, the movement cost is 40 + [-3 x 4] = 28, or 3.57 moves per turn, or the equivalent of 5.7 moves for each treaded move. For Cogmind’s first several years the additional flight unit cost modifier was -5, but for balance purposes this was adjusted down in 2016 as it was a little too easy to reach very high speeds.

The highest speed currently possible is 20 moves per turn, though that speed is much more difficult to reach than it was in the early days. Not to downplay the effects of even “average” fast speeds once compounding is taken into account--a meager three-times speed advantage means that for 10 moves by a pursuer you’ve traveled 30 spaces, which is usually plenty to reach safety.

In the opposite direction, movement is slowed if overweight (an effect that matters more for the normally faster forms of movement), so it’s quite difficult to escape a swarm of flying robots tailing you if you’re a mass of components hopping around on one leg.

As you can see, flee/chase situations can play out very differently depending on the relative speeds of those involved, but it doesn’t lead to boring play; instead it’s possible due to the world being an active ecosystem spread across huge maps rather than than based on individuals or groups of monsters waiting within a small area. Escaping danger in one area can still lead straight into danger from another.

Overall, this approach to movement leads to interesting scenarios, like being stuck in an overwhelming firefight without any propulsion (or weak propulsion) and forced to drop things and run in order to survive, or flying so fast that almost nothing can catch you (so long as your sensors help keep you from running into more trouble ahead), or so fast they can’t even see you (since robots only register targets during their own turn, by which time you could be long gone!).

Because movement speed is an important factor in turn-to-turn play, it is displayed on the HUD at all times, though in one of two forms. For beginners it’s shown as a percent of base speed, so 100% when one move = one turn, 140% when 1.4 moves = one turn, etc. This is to keep it more intuitive at first, rather than having new players misunderstand that in terms of time units, technically lower “speed” numbers are faster. Players who activate the more advanced “Tactical HUD” mode in the options see instead the actual current movement cost itself (thus the meaning is reversed, higher is slower).

cogmind_speed_display_cost_mode

Speed display, percent mode

 

cogmind_speed_display_percent_mode

Speed display, cost mode

 

cogmind_speed_display_slow_warning

Warning: Dangerously slow. When beginning a new sequence of movement while quite slow (one-third normal move speed or slower), confirmation is required in case the player simply forgot to activate/attach a propulsion unit, because the consequences can devastating if you take one slow move while under fire!

Attacking has smaller time cost scaling than movement, but is interesting in that its costs are greater than those of other actions, especially movement. The base cost to fire a single weapon is 200 (two turns!), meaning defenders can more easily escape after coming under attack (if they want to). This effect is even more apparent once the time cost of an entire “volley” is taken into account. Weapons are often fired in groups (called volleys), and the total cost of firing the entire group is applied at once (front-loaded, like all action costs in Cogmind):

Cost # Weapons
200 1
300 2
325 3
350 4
375 5
400 6+

In the earliest versions of Cogmind, firing costs for multi-weapon volleys increased about twice as quickly as they do now, but the rate was later reduced to encourage builds with more weapon slots, since they already have other issues to contend with such as the resource costs involved in larger attacks.

Most robots have two weapons, so if you’re relatively fast, each time enemies fire you can fly something like 10 spaces. Even average-speed robots can move three spaces in that time, important for repositioning to a more defensible location. And for combat-focused players, the system is obviously designed to give them an advantage in one-on-one combat, since few actors other than the player are capable of using that many weapons at once.

Sometimes individual weapons may modify the required time (firing speed), though they’re the exception rather than the rule. More unique among this system are melee weapons, which can only be used one at a time (multi-wielding is possible, but additional weapons only have a chance to follow up a primary attack). They are almost always slower than projectile weapons (~300 time/attack), but also more damaging, and come with their own special effects.

Before firing, the HUD displays how much time the currently activated weapons collectively require to fire:

cogmind_volley_firing_time_demo

Volley firing costs indicator, changing as weapons are toggled (Autoguns have a faster firing time).

I think Cogmind is a good example of a unique approach to time management, showing that even while using a very traditional system roguelikes don’t have to follow the principle that the cost of one action is near or equal to a single turn, or a multiple of turns.

New Challenges

Of course it’s only a matter of time before extreme min-maxers come along and pick apart all the system details in a roguelike to scour it for every last possible advantage. They got around to the time system in 2017, and discovered that it was possible to game subturn actions such as quick movement to figure out when it would be impossible for AIs to mark the player as a target, thereby guaranteeing free peeks around corners without being spotted.

Only a few players knew about this, and even fewer actually used it, but as an “optimal but tedious” strategy (and also an unintended one) this was definitely something to eventually put an end to. Besides, the original time system might not even be the most appropriate for Cogmind--heck, I barely understood its current gameplay implications and had just brought it on board for a quick 7DRL years ago!

At first, mainly because it wasn’t having a broader impact on play, I just wanted to try some quick band-aids to see if I could fix this under the existing system without digging too deep.

So I slapped on two separate “fixes” that year, specifically: 1) randomizing turn offsets for each AI (so they didn’t always start their life at 0 time, and therefore be likely to act on turn boundaries, especially if stationary like guards), and 2) changing the “wait” action to cost 100 time units, rather than simply draining the actor/player of all their remaining time in the current turn.

And neither of these worked because, well, I admit I didn’t understand the time system I’d borrowed seven years before, and hadn’t actually read through to understand what was really going on xD

At this point I should explain the actual mechanics of that time system! Basically:

  • Each actor gets a certain amount of time units to spend on actions during their turn, for example a base amount of 100 time units, which might be modified by stats or status effects.
  • During their turn they perform actions that consume this pool of time, and as soon as their remaining turn time reaches zero (or even goes negative due to a time-intensive action), their turn is over, and they are moved back into the queue of actors where they belong, depending on their current time value.
  • Each time they reach the front of the queue, they again have a new pool of time units to use, again based on their stats or status effects.

This system has some interesting characteristics due to the fact that in some cases it can allow for an actor to make multiple uninterruptible actions in a row, assuming the actions cost less time than their available pool. Really you might notice that’s a lot like the X-Com TU system, only handled at an individual actor level (plus you can overspend your available time) and therefore feels much more roguelike.

Such a system also allows for different actors to have different amounts of time available to them per turn, essentially speeding up or slowing down all of their actions relative to other actors. Now in Cogmind I actually never used this adjustable time pool feature at all! Funny enough, I do distinctly remember back in 2012 liking that the system offered such a possibility. There was a spot for it in the actor turn code, but every actor always got exactly 100 time for their pool. Apparently this just wasn’t how I wanted to handle the 7DRL actor “speeds,” not to mention Cogmind’s special movement and attack time mechanics already introduced a lot of variability without the unnecessary complexity that another layer on top of that would bring. Actors could already affect the cost of their individual actions, such as using utilities to fire faster, or attacking with weapons that were simply faster on their own, or speccing for fast movement, or any number of other actor-controlled variables--this level of nuance seems more appropriate for robots built of components.

Anyway, the whole “player always gets at least one full turn” aspect made it impossible to solve the peeking issue--the time system simply wasn’t compatible with Cogmind’s “enemies cannot spot you if it’s not their turn” mechanic. It’s a good system, just not right for Cogmind :P

At this point I still didn’t go as far as replacing the time system though, because there was one other relevant mechanic I’d thought up in the meantime: “off-turn spotting.”

This tackles the issue from a different angle, allowing actors to maybe know about something passing through their line of sight, even if it happens extremely quickly, where the chance for them to notice depends on their type, e.g. Sentries should be more likely to investigate a “potential anomaly.” While so-called “partial spotting” won’t lead to an aggressive chase, they’ll at least check out the area where they think they saw something before going back to their original task.

I like how this mechanic turned out, but honestly it’s tangential to the whole peeking thing.

New System Time

Seeing as I wasn’t even using the original time system as intended, the obvious answer for this problem is to just allow “turns” to be interrupted--immediately reorder the actor queue after every action. Duh. I finally made this change in Beta 8.1, ripping out the old 7DRL system and replacing it with a very simple standard queue.

This change has a number of implications:

  • It’s impossible to be completely sure one won’t be immediately spotted when rounding a corner
  • The chance of being spotted immediately becomes essentially directly proportional to movement speed
  • Common sequences of actions that cost less than one turn, like dropping a couple items, can now technically be interrupted by other actors
  • Other fast-moving actors won’t appear to move so fast compared to a fast player, since moves will be spread out and not lumped together in a sequence

Honestly I’m pretty sure the differences will barely even be noticeable for most players, if at all, but it was about time to remove this unintended, basically non-designed, part of Cogmind. Revisiting it also had another nice side effect which I’ll get to, but first… the bugs.

Oh my, the bugs. I’m pretty bad at technical stuff, so I needed some extra debugging features before I could track them all down.

I already had the first debug visualization from back when I was messing with turn offsets ineffectually trying to solve the problem the first time. (Seriously, if you truly want to solve a problem, examine the entire circumstances first or you’re probably just wasting your time like I was xD)

cogmind_debugging_new_time_system_entity_values

Visualization: Current relative time values for every actor on the map.

This wasn’t enough, though, since under the shiny new system some actors were acting out of order. I originally tried just debugging it internally by looking at values and queue contents, but this was a slow process and before long I had a fully visible turn queue.

cogmind_debugging_new_time_system_entity_queue

Visualization: Current turn queue, soonest to last to act.

The visible turn queue not only shades actors by the relative amount of time until their next turn, but also shows in yellow any that are acting out of order (or somehow managed to get a positive value :/), which had thankfully been fixed by the time I took the above screenshot.

Once all the bugs were ironed out, I also used this opportunity to actually add binary searching to the turn queue. The original time system just uses a linear search, which is fine if you only have maybe 20 actors on a map, but Cogmind has literally hundreds! I did a bit of quick profiling and found that on a mid-game Cogmind map (Factory) 11.59% of the turn processing was taken up by putting actors where they belong in the queue.

cogmind_debugging_new_time_system_optimization_before

Profiling Cogmind’s turn queue updating under the old linear search.

That seemed like a lot, and switching to a binary search brought it down to 2.25% :)

cogmind_debugging_new_time_system_optimization_after

Profiling Cogmind’s turn queue updating under the new binary search.

 

cogmind_debugging_new_time_system_scrapyard

The final time system and visualized turn queue in action in Cogmind’s opening Scrapyard.

 

Turn Queue Explained

Since I’ve gotten questions before, I should probably go into slightly more technical detail about how my basic roguelike turn queue works, especially since it seems so amorphous with regard to absolute time. Where does the idea of a “turn” even fit in here?

A specific example will really help:

  1. Say you have three events in your queue: Player [0], Enemy [0], and Turn [100]. The initiative is set in that order.
  2. Player goes first, spends 120 time on their action, and the new queue order is Enemy [0], Turn [100], Player [120].
  3. The first event in the queue is always the next one to take place, so Enemy goes next, and decides to perform an action that requires 50 time. The new queue order is Enemy [50], Turn [100], Player [120].
  4. So now the enemy gets to act again because they are still at the front of the queue. This time they do something that requires 100 time. The new queue is now Turn [100], Player [120], Enemy [150].
  5. At the front of the queue is… the Turn counter itself! So it handles any absolute turn updates, i.e. things that should happen “once per turn.” Then because each turn is set to be 100 time, the new queue is Player [120], Enemy [150], Turn [200].
  6. So the player acts next, and so on… As you can see, the turn itself is an event/actor, just like the others. You can even add other types of events into the queue if you like, for example as of Beta 8 Cogmind has autonomous weapons that take their own actions independent of the turn counter or even their owner.

Action costs are repeatedly added to each actor and everyone’s time goes increasingly positive as they take actions.  Technically if you have a lot of persistent actors over a very long period, you’ll want to consider eventually resetting the values by subtracting from every event the [time] value of the first event in the queue.

Inserting a new actor is as easy as adding them to the front of the queue and matching their current time value with that of the actor already at the front (or insert them elsewhere as appropriate if it’s desirable to delay their first action).

Posted in Mechanics | Tagged , , | 8 Responses

Roguelike Level Design Addendum: Static or Procedural?

By Kyzrati | Published: March 28, 2019

Having walked through both static and procedural map design in the previous posts, this is a good opportunity to examine the qualities and value of each. Why use one over the other? Why not use both?

Roguelikes tend to be associated with procedurally generated maps, so much so that we see mainstream non-roguelike games having the “roguelike” label applied purely for that reason alone (despite possessing no other roguelike qualities…). That said, not all maps in a true roguelike need to be procedural, either, nor is that extreme necessarily desirable. Static maps can serve roguelikes well, and most sufficiently large roguelikes contain a mixture of the two.

Not every roguelike needs both static and procedural maps, but I’d argue that both are good for roguelikes, and properly mixing the two can combine their strengths into a better experience.

With procgen we get the first advantage that generally comes to mind: increased replayability. More specifically, the player lacks perfect knowledge on which to base strategic and tactical decisions, leading to variable challenges. Roguelike players also enjoy discovering interesting and unexpected results, the likelihood of which increases with the number of systems interacting with one another.

Static maps offer a much wider variety of advantages:

  • They help with world building and anchor the story/lore (a topic I covered in my series on Weaving Narratives into Procedural Worlds), while also allowing for specific hand-crafted challenges.
  • Being familiar with certain areas of the world means players can plan for them. Certainly a more general form of planning can be done for procgen maps through knowledge of the range of possibilities, but sometimes having more concrete goals at various points makes for interesting experiences--knowing those goals or checkpoints in advance also builds anticipation!
  • In general, static maps offer a change of pace, and like good books, movies, and other forms of entertainment, varying the pace makes the content more engaging when properly spaced out. Navigating back and forth between areas of the known and unknown is also less stressful, allowing certain parts of the mind to rest for a bit.
  • Outside the single-player experience, static content also has value for the community at large, giving players more concrete landmarks to discuss. They can also more easily share some of the memorable experiences related to static content that others are familiar with.

That’s a decent list!

An important point to make here is that the distinction is not absolute, either. Even individual maps do not have to belong solely to one category or the other, it’s more of a spectrum. Close to one end we have static maps with bits of procedural content, and near the other we have procedural maps including pieces of static content, either fully static by location as well, or perhaps simply “guaranteed to be on that map” but not necessarily found in the same location each time.

cogmind_maps_procgen_vs_static_demo

Demo of the static-procedural composition spectrum using several Cogmind maps as examples, from fully static to fully procedural. Larger areas are more suited to procgen :)

I went through Cogmind’s map types and classified each according to which it most closely identifies as, and found a pretty even distribution, slightly favoring mixed maps.

cogmind_maps_static_vs_procedural_distribution

Static-procgen distribution of Cogmind’s maps.

Note the above distribution is based on map types rather than actual map count, in which case the ratio of procedural and mixed locations in the world would both be somewhat higher than shown, each at least twice the number of static maps, rather than as close as they are now.

In any case, Cogmind has benefited greatly from having a wide variety of maps, and I highly recommend taking advantage of both approaches, considering which is more appropriate for the goals you have in a given area and the world as a whole.

For patrons, there were more comments and discussion of this article over on Patreon here.

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

Kyzrati is on Patreon

By Kyzrati | Published: March 11, 2019

Well here we are, after eight years of roguelike development and blogging, it’s time to try a little something new: I’ve set up a Patreon page!

patron_cover

I’d use my real name but most people aren’t as familiar with it :P

If you’ve never heard of it before, Patreon is basically a subscription service through which you can support individual creators and their work.

A number of developers have relied on ongoing donations (or specifically Patreon) over the years to help support their projects, and I’ve always thought this kind of model would be more suitable for the way I do things--less focused on the end-game commercial value of something and more about just making cool stuff :D

Even $1/month can really add up, but I guess we’ll have to find out together how feasible this is over the long term. You can always change your subscription amount (note that Cogmind in-game rewards are permanent even if you do so--you only need to get those once). And while there are benefits, it’s not really about the benefits. I’ll get to that below, but first, a little recap for those who may not know me so well:

Background

I’ve been making roguelikes since 2011, and full time since 2013. You can hear a bit about my past in this talk I gave in 2016. Over the years I’ve written hundreds of thousands of words on roguelike development here on this blog (and some other blogs), plus a sizeable collection of crowdsourced FAQs. I’ve helped build and moderate the largest group of roguelike developers in the world, r/roguelikedev, and I do lots of work to promote the genre and help other developers. I also built REXPaint, a user-friendly ASCII/ANSI editor popular among devs and artists.

My largest project is Cogmind, on which I’ve already invested over 10,000 hours and still update regularly. It’s a sci-fi roguelike that’s been innovating on the genre for years as a polished immersive experience in a living world with compelling lore, deep mechanics, an accessible quality interface, and plenty of audiovisual goodness.

patreon_cogmind_gifs

Who would’ve thought flashy ASCII would be a thing?

My work has been recognized in Rock, Paper, Shotgun, PC Gamer, Destructoid, Strategy Gamer, multiple gaming magazines, and according to RSS aggregator Feedspot, my blog is one of the internet’s top 50 development blogs. A number of my crossposted articles have featured on the front page of Gamasutra as well. Actually, if you’re interested in roguelike development (or maybe you don’t know you’re interested but will be soon ;)) check out my primer available in both text form and a video of the talk I gave at the 2018 Roguelike Celebration in San Francisco.

Why Contribute?

There are perks listed in the tiers, but it’s not really about those incentives. The best part is that I’ll be able to keep doing what I do, with less pressure to focus purely on commercial endeavors and more freedom to share helpful and creative roguelike content. Eventually with enough support this could even include additional side projects that wouldn’t be financially viable on their own, but that I’m sure fans of my work would enjoy.

Specific to Cogmind, releases like Beta 8 are a great throwback to the alpha days where we’d get significant chunks of new content added to the world, but without DLC (which I want to avoid) it’s not sustainable in the long term to continue this line of development when most of the niche core audience has already purchased the game and revenue starts to dry up. By this point a smart developer would have already moved on to their next project, but I see so many more ideas that would be right at home in Cogmind and it’d be nice to unlock that extra potential. This is one reason I’ve decided to try transitioning to a new supporter-based model, or (more realistically) at least a hybrid model. I may have released a commercial game, but after years of updates above and beyond what were “necessary,” I’ve clearly never operated like a normal business :P

I have other goals as well, including more 7DRLs (have you seen POLYBOT-7? :D), an even more powerful REXPaint 2.0, probably a Cogmind sequel, and hopefully one day reviving X@COM.

And of course I’ll continue writing, too! I have so many more topics to cover, and this blog will continue as it always has, albeit assuming there’s demand for it we’ll be getting even more articles ;)

So if you have the means and would like to support my work with the roguelike genre and community, I am grateful for any amount you can provide. I appreciate everyone’s support over the years, and couldn’t have done it without you all :D

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

Roguelike Level Design Addendum: Procedural Layouts

By Kyzrati | Published: March 6, 2019

Last time I described the entire design and creation process behind Cogmind’s latest new map, though a single map can’t quite cover all aspects of the so-called “standardized approach” I’ve taken to level design in Cogmind. So we’re back again today to expand that article with a look at some more potential parts of the process.

Most aspects of map design follow the same routine regardless of whether using a static or procedural base--compiling notes, writing a design doc, thinking high-level gameplay, integrating it with the world, creating and adding content and so on, all detailed in the previous post. But there are a few steps that I apply to level design specific to procedural maps, particularly when establishing their initial layout.

The Exiles being a static map, I could draw out everything in exactly the layout needed to create the desired flow for that experience, but most Cogmind maps are either partially or entirely procedural, requiring that we use other approaches to constrain their generation and exert some amount of broader control over the experience.

The largest main maps in Cogmind are giant 200×200 squares with great freedom in terms of mobility and player options. How do we guarantee a relatively balanced experience in a place like this?

cogmind_factory_map

Sample map generation (Factory).

Since advancing to a new map in Cogmind is generally the safest course of action (because it escapes any pursuers, lowers the current alert/danger level, and can both heal you and improve your capabilities), the absolute most important factor for balance is the placement of entrances and exits.

Knowing where these are, and being able to reach them, is of the utmost importance to the player as well, so aside from a possible randomly placed exit that the player may get lucky to quickly happen across, the main exit positions are intentionally placed far away, and built into the very foundation of the map’s layout to ensure they’re probably not all that easy to access.

So the first step to a procedural map, before even setting the parameters or running mapgen tests, is actually to fire up REXPaint (surprise :P) and do some orientation mockups. To take some of Cogmind’s earliest floors (“Materials”) as an example, here is a set of possible orientations as planned in REXPaint:

cogmind_materials_mapgen_layout_mockups

Procgen map layout planning in REXPaint (Materials).

Like the above Factory map sample, this one is built with tunnelers, so placing the initial tunnelers to seed the map also forms its backbone for exploration purposes, basically working “backwards” from all the points of interest until they all collide at various other points. Based on their relative distance and the way they travel, they’re not likely to directly connect with one another for a while, producing circuitous routes.

The generator may also decide to randomly instate one or more optional barriers (thick gray lines) to prevent tunnelers and rooms from crossing over that area, increasing the circuitous nature of the local area relative to other exits. (Please excuse the terrible coloring--the image was taken directly from my messy dev files rather than produced/modified specifically for the blog :P)

Light gray thick lines, on the other hand, are designed to always prevent the map from creating paths in that direction, enforcing a more specific shape for the map and its general routes.

As per the legend there (again, not ideal, usually just for me), more specifically yellow shows where each guaranteed entrance/exit is placed, randomly shifted around in the approximate area indicated, with a tunneler digging out in a random direction from among those represented by the lines. Gray lines on brown are more directional tunnelers that can pick a random direction from among the options, but are used just to fill space rather than act as access points. And brown empty blocks indicate space for random placement of prefabs that lead to branches.

A map can choose from any one of the patterns available, each of which is fairly different so the player doesn’t know which pattern they’re currently playing in (or even that there’s a pattern at all!) and can’t reliably deduce a way out without more info. That said, players do learn and know that edges of the map are more likely to contain main exits (if far away), so trying to follow the edges is usually a good idea, and there are also other forms of “map sense” which players develop over time to recognize various signs that might indicate an exit is nearby.

Different maps in Cogmind have different types of plans and layouts, but in the end the methods and goals are more or less the same.

cogmind_mapgen_layout_mockups_various

Procgen map layout planning in REXPaint (various).

In the end these layouts are all represented by numbers in Cogmind’s mapgen scripts, but it’s nice to have images for reference during development. (While it would be possible to create a visual method for scripting, that’d be more work than it’s worth in my case.)

Exits to branches are placed more randomly, thus it’s naturally more likely that exits found closer to where a player enters the floor will take them sideways in the world (to more adventure yet without replenished health) rather than upwards (towards the surface and a win).

cogmind_factory_map_exits_marked

Entrances/exits labeled on a procedurally generated Factory map.

In the example above, there are four (green) points where the player may enter from or can exit to another main map. One (yellow) point where they can leave from ended up being randomly placed around the lower middle area, and two branch exits happen to be up in the northwest quadrant.

Here’s another example with more connections:

cogmind_factory_map_exits_marked2

Entrances/exits labeled on a procedurally generated Factory map.

The second version, found at a different depth, has only three pre-placed main access points and two randomly placed ones. It also connects to more branch maps, so here a player is quite likely to reach a branch before finding a way up, giving the option to leave early (by necessity or to seek out branch rewards) or continue further on for a way towards the surface. (Three of the branch exits on this map are also billboarded by their surroundings, making them even more noticeable from a distance.)

Back to the process, though, with general layout guide in hand it’s time to start generating a base map. This is done outside the game in a separate program I put together called specifically for testing and analyzing layout generation without any actual game content. After setting some initial parameters like tunneler locations and behavior, it’s time to watch them in action to see what they can do.

cogmind_mapgen_samples_storage

Repeated generation previews for the Storage map.

I’ll watch these for maybe 30 minutes--less for really simple maps, longer for complicated ones, seeing if there are any strange outlier results that don’t fit the goal, tweak the parameters, and then continue watching.

Having a separate program is nice since it’s quick and easy, and examining the map at a higher level without thinking about content details makes it easier to focus on macro considerations like how easy it is to cross a given map if one simply approaches it as a maze rather than an inhabited world. The micro can come later.

Still, one thing to remember when working with procedural maps is that what you see in an overview shot during development has very little connection to how it’s experienced in game! It might look like a terrible map but actually be fun while inside it, or it might look like a great map but not be all that interesting, or even tedious or boring to explore. Naturally it’ll be up to the content to keep it interesting, and every game is different in that regard, but even in the overview you can pretend you’re at a certain location and exploring outward from there, see where your path takes you, think about how much you can see or know from a given point, and imagine overcoming game-appropriate challenges along the way to one of the exits (or exploring randomly until happening across one of said exits xD).

I’ve mentioned before the advantage of having “loops,” in which a branching map always allows for forward exploration as well as new paths for reaching earlier points, i.e. backtracking without retracing exact steps (or when looked at another way, loops enable more than one path forward). Backtracking is pretty much always an option for players in games, but if repeatedly forced it can become tedious. Also note that in some cases a game’s mechanics can enable players to create these alternate routes. Cogmind does this, adding another layer of potential strategy.

Some other important factors I keep in mind at this stage are:

  • The “openness” of the map. How many of its cells are actually occupiable? A giant map composed mostly of blocked space will feel and play very differently from one filled with corridors and rooms. Sometimes one or the other is more preferable.
  • Consistency across room sizes. Are there mostly small rooms but a few massive ones? Should all rooms be about the same size?
  • Open area dimensions. Areas where numerous corridors meet could end up creating cavernous spaces (outside rooms). Is this okay or should there at least be a limit to their size?
  • How many of these open areas are there? Open areas play differently from rooms or corridors, so their ratio matters.
  • The prevalence of hidden corridors. These are used to connect some rooms with each other, offering alternative routes if discovered.
  • Are entrances and exits even reachable? Any map where this is not the case is naturally thrown out, but it’s also important to pay attention to how hard it is for the generator to fulfill this vital condition at all.

Each of the above factors is actually tested for explicitly on completion and the map is thrown out if it doesn’t fit within the parameters decided for that map. If map generation becomes too difficult then many maps will be created only to be thrown out before finding one that meets all criteria, which can take a while! Situations like this clearly require parameter adjustments.

It does, however, save time to do all these tests immediately after the initial layout generation, before any game content is loaded in or even considered at all. Some Cogmind maps might fail dozens of times before loading, but even thought they’re quite large it’s not really noticeable because the failure states are checked early in the process.

The layout generator also comes with other modes to help visualize a map’s various aspects while tweaking parameters…

The most fundamental visualization shows routes through the map, using pink dots for entrances/exits, and green dots distributed along the shortest paths between each access point (dots are used because referencing complete lines is both less clear and too CPU-intensive). Also activated in the image below is the room seclusion factor, showing in red those rooms which have a below average distance between their doorway and the closest of those main routes. The darker the red the greater the distance.

cogmind_mapgen_visualization_paths_and_seclusion

Path and seclusion visualization. If an entire half of a map ends up being secluded, hopefully that’s intentional :P (but this is why browsing through many generations is important--looking for those outliers)

Even though it’s usually obvious just from looking at the layout, open areas get their own visualizer if at least to confirm what the generator thinks is an “open area.”

cogmind_mapgen_visualization_halls

Highlighting in orange the areas the generator has marked as “large open areas.”

Hidden doors are one of the Cogmind-specific factors I pay attention to, so there’s a mode to highlight those as well. Maps with more of these are more dangerous because enemies can use them to sneak up on the player or otherwise throw a wrench in sound tactics during a fight, but players can also use hidden corridors to their advantage to escape trouble, sneak around, or more quickly access different locations, assuming they’ve already used any of various means to discover their locations first.

cogmind_mapgen_visualization_hidden_corridors

Hidden doors and corridors highlighted in blue. These are also usually the only way the map generator will directly connect rooms with one another, giving them another unique quality.

Less often used is the monochrome visualizer, which simply shows open vs. closed cells without any type detail whatsoever. Sometimes it does come in handy, though, just to get a clear picture of the possible connectedness of the map as a whole, information which may sometimes be “hidden” behind other visual distractions.

cogmind_mapgen_visualization_open_cells

Open cell visualization for purely looking at connectedness where mobility is concerned, assuming full knowledge and/or a way past any temporary obstacles.

Aside from tunnelers, the only map features placed at this early phase are possibly a handful of special prefabs, similar to how tunnelers are placed, though I’ve already covered that under “Seeding with Prefabs” in this article.(Examples of such prefabs include the aforementioned “billboarded” branch exits.) The same article also covers post-generation embedded prefabs, for encounter purposes, along with how they’re categorized, built, and distributed.

There’s a lot more to the process for tunneler-created maps, but beyond this point it gets extremely Cogmind-specific so this is a good stopping point for now. If we do go there one day it’ll probably better to just look at one specific map type as an example.

Procedural cave maps also have some design methods of their own, but those are simpler and have mostly been covered before.

For patrons, there were more comments and discussion of this article over on Patreon here.

Posted in Design | Tagged , , , , | 2 Responses