next »

[Kyzrati]

Heh, yeah I have trouble going small xD

SFX are indeed an extremely effective feature to take maximum advantage of in a roguelike--a perfect complement for the medium, I think! Thousands of samples in Cogmind already, and adding more with every release... (whenever necessary for new content)

[Kyzrati]

Spicing Up Primary Maps 2: Area Denial
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Our first dose of spice last time leaned heavily on risk-reward potential in the form of dangerous cargo convoys, whereas our second dose here is more about introducing additional challenging situations and increasing overall difficulty--less reward, more risk (although as you'll see this new feature might also involve rewards for some builds).

Introducing the Heavy class, the first new common combat class ever added to Cogmind! New uniques and otherwise special bots from other factions have joined us over the years, but the ranks of standard 0b10 combat bots had remain unchanged in the time since the first release in 2015.

Heavy class tiles. The ASCII version is an uppercase 'H'.

The "Heavy" name was first used in Cogmind offshoot POLYBOT-7 back in 2018, where it represented a defender built around a single cannon and stronger than a typical Sentry, so kinda like a "1-tile Behemoth." At the time I imagined we might see something like that in Cogmind one day, and here we are, although as you'll see in this article there is a lot more to these guys than just cosplaying a smaller Behemoth!

The majority of threats in Cogmind's primary maps come in three forms: active patrols, security bots guarding over a small area, and garrisons which can dispatch reinforcements. Heavies combine all three of these by usually defending a single location, but sometimes moving to guard another location, and also capable of calling in additional squads like a garrison can. In other words Heavies are a sort of "mobile garrison" that tends to be stationary more often than not.

As such, these are obstacles you're more likely to want to avoid rather than confront, in many ways even more dangerous than garrisons since these can fight (!) and the latter can be destroyed or even hacked. Heavies can technically be hacked as well, although only by RIF builds--there is indeed a Relay Coupler [Heavy].

Of course, avoidance isn't always an option, or in some cases doing so could put you in even more tactical danger for whatever reason, so let's take a look at what confronting a Heavy really entails and how they live up to their "area denial" role.


Heavy Capabilities
There are multiple reasons to fear a Heavy, otherwise they wouldn't make very good area denial bots, now would they? :P

Loadout
Even ignoring their other abilities, simply based on their build alone Heavies are not to be underestimated in a head-on fight. They're heavily armored with a fairly well-covered chunky core and lots of supporting offensive utilities behind a huge cannon.

Compared to facing an entire squad of bots with more combined integrity and weaponry they're technically not that bad when encountered alone, and in that regard can be considered somewhat glass cannon-y, but few enemies carry such a devastating weapon as their heavy cannon. Specifically for Heavies I added a set of new dual-slot kinetic cannons capable of inflicting a concentrated blast of damage along with a non-insignificant chance to also apply the Blast critical effect, which is quite powerful in combination with such high base damage. Of course as with most parts players can also acquire these cannons and put them to good use, along with other potentially useful Heavy salvage including their treads, unique sensors, Transmission Jammer (the only way to reliably get one of these via salvage), Weapon Cycler, Kinecellerator (no other reliable salvage sources for this, either)...

Extra-heavy, extra-large heavy variants of existing cannons created for Heavies.

Mechanically speaking, the star of their loadout would be the other part added specifically for Heavies, namely the Active Sensor Suite which I detailed in an earlier article. This plays an important role in service of their area denial capabilities, since they can use it to accomplish two powerful AOE effects:

• 1. Call reinforcements: Unidentified signals detected within their sensor range are considered suspicious and they'll eventually take action against them by summoning a squad to check out the area. Up to two separate such squads can be active at once, so spending too much time near a Heavy without actually engaging it could be problematic in the long term.
• 2. Mask allies: All of the Heavy's combat allies within its sensor range are masked from detection by normal sensors, making it somewhat more dangerous to approach them, not knowing whether a regular patrol is passing through, or where summoned reinforcements may be lurking. Cogmind can see through the masking if using their own Active Sensor Suite, FarCom, or a relevant RIF ability, but those are special options many builds won't necessarily have access to or want to take advantage of and therefore have to consider the threat of masked enemies if relying on sensors (builds not using sensors anyway simply won't care about this aspect :P).

Destroying a Heavy here shows what their sensors were masking.

Here it's important to bring up several of the QoL mechanics that round out the Heavy experience.

First of all, as soon as Cogmind enters the Heavy's active sensor range, its exact position is revealed on the map. This is important for balance, since projecting their location lets players plan for how to approach or traverse the area, if they want to at all. Heavies are fun challenges, but would be a lot less so if they didn't reveal their location! This kind of mechanic also logically falls in line with the idea of "active scanning."

Heavies don't just pop into view, either, instead animating their full sensor range around them on the map as a prominent warning.

Heavy Active Sensor Suite AOE warning animation.

Holding the cursor over a known Heavy will also recall that range for reference.

Another important piece of info clearly telegraphed to aid planning is the timing of relevant squad dispatches, which we'll get to further below.


Summoning
Tangling with a Heavy, or even passing nearby, is cause for concern because it's hard to be certain just how far such an encounter could escalate (unless you're really confident in your tactics). After all, they're going to call for help, which means more enemies, more danger, more alert (also more loot, for players into that type of salvage!).

There are actually two kinds of reinforcements available, the first being those sent out to search for the source of the sensor blips, and another which the Heavy calls to its side as soon as it comes under attack. Heavy behavior is rather unlike other combat bots: since it can rely on allies to go after potential targets while it holds its ground, it therefore doesn't need to chase them down on its own, but may also want additional protection capable of reacting to visible threats against its position. This mechanic makes it more dangerous to attack a Heavy without fully committing right away, since there will definitely be another squad arriving to fortify the area at some point. This "close defense squad" is composed of more typical front-line combat bots, different from the types sent after enemies (like Cogmind) detected on sensors. (Like most other calls for reinforcements, the Heavy can also be jammed with a Transmission Jammer, which again they happen to also use themselves so become a source for a second type of salvage that's useful against them.)

Note that none of the reinforcements summoned by a Heavy actually go after a specific target until they spot one, they're just sent in to reinforce the area, emphasizing the area denial aspect by increasing hostile bot density in the local area.

Regardless of the type of dispatch, all of them are announced, and in the case of reinforcements targeting sensor blips, they'll even specify the type of squad sent out because Heavies don't react in the same way to every signal!

This Heavy is calling in... Cutters?!

Over time Cogmind has been trending towards more dynamic responses to different play styles, especially the significant difference between fast and slow player builds. Thus a Heavy that detects an unknown high-speed bot on their sensors is more likely to send out faster bots to intercept it, or if the target is slow it's better to call in slower bots carrying heavier firepower.

The bot of choice to go after slow targets? Specialists.


Specialists
Specialists are an unusual case in Cogmind, relatively underused despite falling under the "common" (non-prototype) combat bot umbrella. They could sometimes be found in Garrisons or attached to assaults, but otherwise weren't a part of regular patrols/reinforcements/investigations, at least not until now :)

There were also only three variants and that wouldn't do for reinforcements meant to support Heavies across a large number of depths and situations--simply not enough variety and too predictable in terms of their capabilities. We're going to need more variants, so I more than doubled it to seven.

Specialists also got unique depth-spawning rules, made possible as a result of being the only bot with a different variant for every level on which they might appear, and desirable especially due to the unique nature of their loadouts. Unlike other bots that have consistent loadouts across all their variants (e.g. all kinetic weaponry and relevant supporting parts), each Specialist has a mostly unique loadout aside from the common theme of "legged combat bot," building around a different damage type or combat style. And unlike other bots which use the same predictable variant at each depth (the highest one rated at or below that level), Specialists are now selected randomly from among any variants at, directly above, or directly below, the current level. So there are up to three possibilities for a given squad. (A single squad of Specialists will all be the same type, however, to avoid mixing them and making them hard to visually distinguish during an engagement--Cogmind the game is mostly intended to have predictable enemy loadouts known purely by looking at a robot's ASCII on the map without a need to further examine details once you're familiar with them from previous runs.)

Sample chart showing how some class variants are normally distributed by depth, and how that compares to Specialists. Notice the overlap, more easily seen using the visualization. ("Level" 1 refers to -10/Materials, and goes up from there to -1/Access which is equivalent to level 10.)

As you can see above, Specialists may spawn slightly OOD (out-of-depth, giving access to better loot if you take them down!), or even slightly weaker, and this approach is perfect for the job here with regard to Heavy reinforcements since you can't be sure what the variant will be, and therefore not exactly sure whether or not it's a variant you're better equipped to deal with. This again makes hanging around near Heavies a bit riskier, or at least more interesting :)

These unique selection rules apply to all Specialists wherever they may appear, meaning they're also good for convoy defense variability, since those may be accompanied by Specialists, too, as well as Garrison interiors.

But Specialists certainly aren't going to cut it when it comes to chasing down fast movers--for that we now have Cutters!


Cutters
Wow, all those years without any new common 0b10 combat classes and now we have two at once! I've added a second class of bots specifically to play a supporting role for Heavies, aiming to give faster player builds more of a challenge with this one. For a little flying bot it sure took a while to put these guys together, involving a range of new parts and multiple new AI features.

Cutter class tile. The ASCII version is a lowercase 'c'. (Image originally put together for one of my YouTube videos on this topic :P)

Of course if you want to catch fast targets you probably want to be fast yourself, so the Cutter class is blazing fast, or at least can be. To accomplish this it's the first AI capable of selectively toggling overloadable flight units. Cutters normally move at their propulsion's base speed, but as soon as they have a known enemy they'll overload and chase at a speed that only the fastest builds would be able to outrun.

In designing robots there's always the important consideration of what players will do with the salvage, so in this case because I didn't want Cutters to be a reliable source of widely desirable overloadable flight propulsion, I had to add a new set of parts with their own drawbacks. Enter "Surge Thrusters," a rather different kind of flight propulsion which while overloadable and quite fast, also has higher integrity and coverage, lower mass support, and burns out faster than the usual overloadable airborne prop. Surge Thrusters can theoretically be useful in a pinch or as part of some specific strategies, but the average flight build will pass.

Another reason Cutters need speed is that they are primarily melee fighters that need to actually close the gap with targets before being blasted to bits. They're built around a saw, which sounds as scary as it is with its very high slashing critical effect. Maybe one is not too bad, but having several of these bots racing towards you can be pretty scary and cause for emergency measures.

A range of saw variants created for Cutters.

Cutters also have a single-fire ranged option they'll use on first sighting a target, one that also involved adding a new mechanic: AOE knockback.

Explosions in Cogmind don't normally move bots, since as neat as that would be it would also make using them (or having them used against you) even more chaotic, further interfering with the planning that goes into the tactical positioning behind success during Cogmind encounters. But this is a special case where we can make an exception since that's part of the intent...

The first application of this mechanic is the Cutter's short-range "Concussive RPG," which is hard to aim and doesn't inflict much damage, but knocks targets away from its origin to disorient them, and due to the poor targeting the projectile may likely even miss and could knock a target back closer to the Cutter's position!

Firing a basic Concussive RPG. More powerful variants have more significant knockback effects.

The RPG projectile itself (not the resulting blast) is also the first in Cogmind to do ranged impact damage, which is also quite scary for flight players since it's more likely to smash fragile systems, although actually scoring a direct hit on an evasive target with such an inaccurate weapon is not very likely.

Again with the salvage concern, we can't really have players repeatedly firing a reliably accessible AOE knockback weapon like this, hence part of the reason behind its design as a single-use disposable launcher, though this approach also happens to be more appropriate for Cutters themselves anyway since their priority is obviously to cut things :D

This part of their loadout required yet more new AI behavior tweaks to enable them to effectively use a disposable launcher and switch weapons when appropriate, in addition to taking special care to avoid firing while too close to a target, or with other Cutters nearby, lest it become easy to deal with an entire squad of these by letting them get in your face and tanking the first shot so they just kill themselves :P

The Cutter design was inspired by the Striker prototype, which also has a two-weapon design based around firing several shots of its Compact Linear Accelerator at long range before rapidly advancing to engage a target with its Plasma Lance, though internally the Striker was much easier to handle since there's no AOE effect to consider, and getting them to switch weapons was as easy as making sure they'd run out of matter to fire their accelerator after X shots. (Strikers are similarly an anti-fast-bot design, though much beefier and not quite that fast.)

(continued in next post...)

[Kyzrati]

(...continued from previous post)

Heavy Placement
Where and how frequently these new Heavies appear is a vital part of how effective they'll be at making exploration more interesting. Too few and they don't add any of that meaningful and challenging area denial effect, too many and that would be a problem since the idea is that there are usually supposed to be ways to circumvent them if desired/necessary (though again this sometimes comes at the risk of being forced to do something else dangerous--hard to say!).

Heavy presence is not really a thing until the mid-game. Early-game maps are relatively small by comparison, so only a couple maps down there contain a single Heavy. There and even on into the mid-game you might even go a few floors without ever seeing one depending on how much you explore. More importantly, within a single map multiple Heavies will not be stationed near one another, since as one can imagine even just having their sensor ranges overlap could theoretically be an incredibly dangerous place where multiple reinforcement squads could converge more quickly than usual.

In terms of bot quotas, Heavies were not included as raw additions to the original inhabitants of each map. Instead they are replacing some of the Sentries originally stationed on a map, and similarly guard junctions or exits (but not individual rooms like Sentries might).

Heavies are usually placed in high-value junctions, potentially giving them a good vantage point for keeping watch over long corridors to make best use of their visual range and heavy cannon, or at least a position connected to multiple paths from where it makes sense to intercept hostile signals.

Local map junctions labeled with their relative value (see "Desire Paths" for a Robot World for more about junctions). Notice how the highest-rated junction in this are contains a Heavy ('H'), while two others are guarded by Sentries ('Y').

Heavies may also sit right on an exit--good luck circumventing that one if your goal is that particular exit! (just kidding, there are lots of strategies available, but naturally this complicates things)

Sample default Heavy distribution on an earlier Factory map (-6), with circles representing their active sensor range coverage. Not too bad here, as there are clearly many other optional paths, and these two may never even be seen at all depending on Cogmind's route. Both of these are guarding junctions rather than exits.

Another Heavy distribution map including sensor coverage, this one a -5/Factory layout with somewhat higher Heavy density. These also happen to be only guarding junctions.

This Heavy distribution scenario on -3/Research could be a bit more problematic, not unlikely on Research maps since they tend to be more maze-like and have more bottlenecks. Being forced to pass near or directly engage a Heavy is more common in the late game. The Heavy stationed at the top there is guarding an exit to the next depth.

Notice how none of the Heavies are too close to one another, and there are ways around them but they stand as obstacles on some paths.

An exception to rule ensuring each Heavy has its own mutual exclusion zone is a new 0b10 event meant to further spice up the main complex: Security rotation!

ALERT: Heavies on the move!

Every so often Complex 0b10 will call for a security rotation, in which all Heavies will cycle to one of the other Heavy locations (and coincidentally any Heavies found to have been destroyed since the last rotation may be replaced by a new one dispatched before long).

While this can create extra danger in the form of a powerful bot on the move, and even more so when more than one Heavy might be moving through the same area (!), it might also open up a window of opportunity to slip through an area previously overseen by a Heavy.

Of course it also helps that you can always see them while they're taking part in a rotation, due to their active sensors, thereby making planning a route past them, or evading their approach, that much more possible even without your own sensor data. From a design standpoint this is another part of their appeal, giving players a critical piece of information needed to help face a challenge, without solving the entire problem.

Aside from the above predetermined defense points, Heavies also star in Complex 0b10's new cargo convoy interception response mentioned in the previous post, where "Access Lockdown redirects Heavy bots posted at junctions to exits across the map, and if necessary calls in additional Heavies to defend any other unprotected exits."


Player Reception
In general players are loving the addition of a Heavy class, as its serving to spice up the main maps by making them even more dynamic and challenging on an intermediate level we didn't really see before. We've always had "low-level" stationary enemies and roaming patrols that require LOS on a target (or a corresponding alert) to go after it, and "meta-level" extermination and assault dispatches with accurate long-distance tracking, but nothing quite like Heavies, occupying a space in the middle of that spectrum in the form of an enemy that can use sensors to more effectively control an entire area.

I'm really happy with how they've turned out!

[JobLeonard]

I feel like the next time I start up this game again it will be like playing the polished sequel, hahaha

[Kyzrati]

You almost will! Very different feel overall, not just different but better

Still, more already confirmed to be coming in the subsequent releases, things that will also have some really big impacts, but just this stage alone is most likely the biggest of all before and after..

[JobLeonard]

There's a steam award category for "keeps updating game after release", right? Maybe you should ask your players to nominate you?

[Kyzrati]

Ha there are a number of them I'd say are quite appropriate for Cogmind, including some that players have mentioned/reportedly voted for, but to be honest I think the voting on Steam is pretty pointless  for most developers because it's purely a reflection of the games that have the largest player bases... so meh.

[Kyzrati]

Map Comments and Log Notes
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Back in August I was watching the first Tone-MTF combo stream...





...and listening to them repeatedly strategize aloud so they could collaborate brought more than the usual planning talk to the forefront of the conversation, through which I noticed the occasional potential for manual map comments to be helpful.

Very few roguelikes support freely adding annotations to specific locations on the map, perhaps because most roguelikes don't have very large maps anyway, or rely on other features like map memory to serve enough of that purpose (some roguelikes will even store old enemy position data in addition to items and other objects/environment features), or don't allocate quite as many dev resources to non-essential UI features.

The Ground Gives Way remembering that a particular creature was left outside your FOV when you moved away, a simple way to let you know you avoided or fled from something in that area earlier. See the two 'c's to the south of the player (@), where 'c' represents a canine type creature. (Wild dogs are fast but can't open doors so I used a rod of slowing on them then retreated to close the door.)

For a while on Patreon I had suggested map notes were a possibility for Cogmind, and although there was a fair bit of support for them among the player base, it wasn't high compared to the desire for various other features. Some potential roguelike criteria to consider as far as the usefulness of map comments:

• If backtracking to earlier maps is possible, players may need to remember some important local detail(s) long after they may have forgotten them due to having since interacted with many other subsequent maps and encounters.
• If maps are large or complex enough, players may have a harder time remembering details about an area they might revisit later, or after saving and loading their game for another session.

There's no backtracking to previous maps in Cogmind, so my personal preference is to avoid ending a session partway through a map if possible, to reduce the chance I'll forget some important piece of information without having to make notes on everything. On that note, however, back in Beta 10 I did add "log notes" which can help with just such a situation. Compared to an interface feature like map comments, simply adding notes to the log is much easier to build :P

Adding a custom note to the log. Implementing this feature is as simple as calling up a dialogue box to accept a line of text and copying it to the log once confirmed.

In terms of temporarily preserving info as a reminder for later, log notes are similar to map notes but without the positional data, though as is these will of course also scroll away as the log progresses since they don't have a separate dedicated display.

Log notes could also be used to add more explanation to the message log for those players who will export it in full at the end of their run, for example to describe in greater detail what was going on at the time (in fact this was the original reason one player requested it a long while back).

Interestingly, since the log notes functionality allows players to type a line of arbitrary text in the middle of the screen, some streamers have taken to using it as an in-theme way to write a message letting viewers know they're away for a short break.

Back to the idea of map notes, although I one day finally decided to just add them on a whim for fun (I do rather enjoy taking dev detours to implement little interface QoL bits), I quickly discovered this was a complicated endeavor filled with potential for bugs and coming with plenty of UI challenges! You've got your typical data storage considerations, the need to write but also edit or delete existing comments associated with a particular location, a new modal interface to handle all this separately from the rest of the main UI, and visualization work involving showing the comments normally, or just reminders of the comment locations when not shown in full, or relative directions to comments to help pinpoint them across a larger map... All told, this feature ended up taking a week to complete.

Fortunately for the visual parts I eventually managed to get the comments piggybacking on the exit label system (including support for displaying relative direction of off-screen comments) rather than having to write a separate system, which would've taken even longer.

I will say that at first I didn't really feel this system would be worth the amount of time invested in building it, but in the time since I've been discovering more uses (including automated ones) that have made it seem more worthwhile.

Map comments are added by entering "Comment Mode," currently activated via Shift-Alt-c (but later also coming to the "special commands menu" in Beta 11 for easier access).

Adding a comment to the map.

Even when not in the mode, the map view reminds players about comments made earlier by intermittently highlighting those cells (the interval is adjustable in the advanced options, or can even can be turned off entirely if it's distracting). Hovering the mouse or keyboard cursor over a single comment position also shows that one comment in its entirety, but on entering the mode they all appear at once and remain visible as long as the mode is active. Right-clicking on an existing comment (or the 'r' key) removes it.

Highlighting individual comments, as well as showing them all and demonstrating individual removal.

As with other on-map labels, of course we need support for showing indicators of those not currently within the map view area. This was where it came in extremely handy to already have lots of architecture in place for displaying directional labels.

Demonstrating off-screen map comment markers.

Comment Mode also supports cycling through existing comments via Tab/Shift-Tab for added convenience.

Tabbing through map comments, and also editing one of them.

Overall there's a fair amount of overlap between map comments and other existing features (including the aforementioned log notes but also other new Beta 11 features like item searching) so their usefulness will likely vary greatly from player to player depending on preferences, but it's always nice to enable extra optional possibilities.

Map comments are indeed the only way to add custom spacial info where it matters, though in my understanding player-side uses are probably pretty niche and I'll be keeping an eye out for what people end up actually doing with this feature.

Either way, I am starting to like the potential for automated uses, making map comments a potential new tool I can apply to have the game serve up reminders of certain location-based knowledge that doesn't already have or justify adding its own unique method of display. I already have some ideas of my own, but this is also one area where it could help to see what players are doing, since repeated manual behaviors in certain situations are always good candidates for automation.

One potential issue I'll be on the lookout for here is whether map comments actually add tedium to the game, mainly in terms of optimal play. Like marking known Sentry/Heavy defense points? Behemoths? It's true people can theoretically use screenshots as a recording tool for this sort of optimal play, but that requires enough work that it's not something players do in practice--we just rely on our brain instead :P. Once you give players a tool that reduces the cost of some form of optimal play, one that was previously safely beyond the threshold of reasonability, there's always the danger that this new tool will invite tedium.

Again though, if some form of map comment is useful enough, it may become automated if possible. That said, doing this in a way that's both useful and accurate could end up being a lot more complex than it seems at first!

Map comments have been in prerelease test builds for a little while so far and I have yet to hear about them getting a lot of usage, so I guess we'll need more time to tell!

// TODO: Add list of automated map comment features here ;)


...and here we go, since publishing this I've started posting some other examples of automated comments, so the list begins:

• Fabricator Network(Status) command results, as well as a related Trojan (see "Complex-initiated Fabrication")
• (more to appear later on the blog version of this article)

[Kyzrati]

As Cogmind enters its 9th year of continuous development, let’s once again take a look at the past year of progress in our typical annual review, now available on the main dev blog! Beta 11 is approaching completion, Patreon support is looking (really) up, and we've finally met the requirements for two new factions to come this year :D

[JobLeonard]

Patreon support is looking (really) up

Hey, that's awesome!

EDIT: But the fact that you manage to build a vibrant community around this game is even more impressive

[Kyzrati]

Well, not just me it's more the type of players this sort of game attracts, which has been quite the boon! I can only take so much credit here

[Kyzrati]

Maps Between Maps, and DSFs
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

I've described a few times (most recently when introducing Cargo Convoys) how Cogmind's world is divided into two primary types of maps: main areas and branches. There is technically a third category serving special purposes, one that after many years is once again growing as part of Beta 11. This other category is what I call "maps between maps," essentially much smaller maps forming optional bridges between the regular maps.

In its first year of Alpha builds Cogmind gained two such varieties of what we could call "intermaps," in the form of Waste and Garrisons. Waste is reached via Chute Traps that suck robots down into a dangerous but potentially useful disposal area, looping back out to another area of the Factory at the same depth, and Garrisons are a primary source of combat bots that you can chose to proactively infiltrate for various reasons. Waste maps have not been explicitly covered on the blog before, but Garrison design was discussed at length. Today we'll be covering a new type of intermap, the DSF.

The sample world map I put together earlier this year, now with DSFs and specifically highlighting all intermaps (redacted-level spoilers have been edited out) (full size here).

Intermaps share a number of characteristics that differentiate them from most other maps:

• Access from multiple depths: Intermaps of each type can always be found at more than one depth, so even if Cogmind doesn't visit them at a given depth, there are more chances to encounter and/or take advantage of them later.
• Numerous access points: Maps containing links to intermaps usually have multiple points from which to access them.
• Unique access methods: Intermaps are not entered via the usual openly available stairs or doors, and instead each have their own special types of entrances.
• Small interiors: The majority of regular Cogmind maps are fairly large, with main maps containing an average of 16,000 open cells, and branch maps around 4,000, but intermaps have only about 1,000 open cells.
• Strong theme: Intermaps are tightly designed around their own unique mechanics and theme.
• Optional: For the most part intermaps are entirely optional pathways (except being caught off guard by a chute, although some players opt to jump down known chutes as well).
• Strategically meaningful: These special maps offer unique challenges for specific benefits, and choosing to visit them can be a part of short- or long-term plans. Intermaps are also the only way to loop back to another variant of the current main map, which sometimes factors into strategies as well.
  

Comparing the total accessible area between main maps, select branch maps, and intermaps.

The closest common analogy for these maps to be found in other roguelikes is the concept of "vaults," or small thematic areas often with some sort of risk-reward mechanic or otherwise challenge or cost for access, though in cases where these are presented as actual separate maps (rather than contiguously embedded within larger maps as I've discussed with prefabs), one important difference is that vaults would generally lead back to the same map and location from where they were entered, i.e. just going back out the door or some other portal. This is not something Cogmind's intermaps can do because by design backtracking is not possible--leaving a map always pushes the player upwards or sideways on the world map to a completely new area, as seen in the sample world map connections above.

DCSS contains "portal vaults" (aka mini-branches or sub-branches), like this sewer entrance. See portals on the DCSS wiki, and info about Treasure Troves; you can also browse many portal vault sample layouts and content in the source here.

Distributed Storage Facility
"DSF" have been in Cogmind lore since the very first release, and were actually one of the earliest pieces of background lore, just a bit of world building in that it describes an aspect of the Complex that was not otherwise represented in game.

The latest iteration of the DSF lore entry hacked from a Terminal.

Worldbuilding generally calls for having a larger unrealized amount of content which is still at least referenced throughout the game, and Cogmind has always had a fair bit of that, though this sort of content also tends to be ripe with ideas for future features, or at least suggests where new playable content might want to emerge in a way that fits well with what already exists. So six years later, here we are with the real deal :)

In the past players had speculated that the Storage map might be an example of a DSF, which could indeed have been one explanation (no need to provide all the details when players can do a great--and better--job of filling these in on their own!), though the new official implementation aligns better with its stated intent, and Storage shall remain just a unique branch map by comparison. Storage and DSFs do, however, share a color theme.

Originally I wasn't planning on adding DSFs in Beta 11 (or ever, necessarily), but the opportunity presented itself when I needed a way to offer some form of guaranteed access to Authchips as part of the fabrication overhaul. So this really was an example of taking advantage of the existing lore and bringing it to life, expanding upon it, in order to meet other design needs. Of course if that's all it was for this might seem like overkill (adding a whole new map type?!), but I felt there was plenty of room to play with here for it to become an interesting strategic option, regardless of tie-ins to the fabrication system.

So let's look at how you get into this place, and what you might find there.


DSF Access
All Factory and Research maps have a number of DSF entrances, special-purpose Terminals that control an adjacent access point, similar to how Garrisons work. These locations have a unique look to them, a simple Terminal adjacent to an open cell where the door appears once unlocked via the Terminal, and surrounded on three sides by reinforced walls.

Sample Factory map layout highlighting all DSF Access locations, including an up-close look at the small prefab's appearance. The space adjacent to the 'T' is where the door appears.

Although there are enough access points that the chance to eventually spot one at some point on each map is quite high (that they're placed in corridors rather than inside rooms further increases this chance), the desired number here is mainly taking into account the fact that any which aren't somewhat near the player's entrance are unlikely to be accessible. The reason is due to a DSF-specific mechanic whereby all of the DSF entrances are permanently locked (as far as the player's time on the map is concerned) as soon as any hostiles are spotted. So to actually get inside one, the player must do so without being spotted by anything on the lookout for enemies of the Complex.

Even though DSFs were added to the game as a guaranteed method of obtaining Authchips, as I emphasized again in the recent fabrication article Cogmind's philosophy focuses more on adapting to what you find rather than having high control over predetermining your build, so although the Authchips themselves are guaranteed consistent rewards inside, the ability to access a DSF at all is the less consistent part of the equation :P

Opening a DSF via its Terminal.

To facilitate locating the nearest DSF, among the other usual possibilities there is also a new non-RIF Hauler hack that anyone with a Datajack can perform: find_dsf. The result of the hack takes advantage of the new map comments system, adding an automated comment marketing that particular Terminal for what it is.

Hacking a Hauler to find the nearest DSF. Here you can also see the difference in color scheme for a map comment added automatically as opposed to manually by the player.

There is a global message when anything hostile is discovered on the current map and DSF lockdown is engaged (technically this doesn't have to be the player, but the player is the most likely to trigger it first), after which attempting to open any DSF will simply report that it's in lockdown mode.


Layout and Defenses
DSF map generation is similar to Garrisons in that it is based on quadrant prefabs, albeit simpler overall since there are no variations--each quadrant is either present or it isn't, and there must be at least two of them (one to hold the entrance and another for the exit).

A full-sized four-quadrant DSF with its major features annotated.

There are quite a lot of good items to steal from a DSF, with four sections of Authchips around the center, two to four quadrants each with their own random theme (e.g. weapons, devices, traps...), and main corridors lined with random parts. Each quadrant also has a chance to include a hidden (but sometimes guarded) area behind its walls containing extremely good parts, and the Matter Repositories can also be damaged to recover a lot of Matter if necessary.

The primary defensive feature is the Heavy stationed at the center, around which the entire DSF layout was planned. Its sensor range covers almost the entire map (except the corners), and reaching the exit always requires passing through its visual range, so it's necessary to have a way to deal with this bot. Each corner also has a chance to contain a dormant Specialist. As usual the Heavy can call in reinforcements, and an infiltrated DSF will eventually also be subject to additional patrols, thus limiting the amount of time available to freely loot the area.

Destroying enough robots within a DSF triggers another emergency defensive measure, "rapid sterilization," or a quicker version of the sterilization system found in other parts of Complex 0b10 which gradually raises the ambient heat until no robots can survive. This offers another optional strategy to afford more time for looting since with enough cooling Cogmind can survive longer than other bots.

DSF are generally predictable as described above, and though the types of items found within can vary greatly (aside from the Authchips), there are so many of them that stashes will usually have at least something useful for most builds. But it's always nice to throw in a little more extreme variety for fun, so there are a number of possible DSF events that occur more rarely (without removing the chance to loot).


Routing
In most cases leaving a DSF will exit to the next higher depth, although there is a small chance it instead leads directly into a Garrison, to throw a little wrench into the best laid plans, for fun and excitement.

World map UI mockup reflecting intermap-related routes.

There are definitely more ideas that could later become new types of maps between maps (much longer-lived plans than the spontaneous DSF :P), and while I'm not sure how likely it is to happen, I'd also like to do experiments with small maps that can return the player to the same map that was left earlier. This would be a pretty complicated endeavor after so many years of building an architecture that assumes it's not possible--plenty of room for bugs and design issues in there xD

[Kyzrati]

Special Commands Menu Design
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

For years now I've been planning to eventually create a menu for accessing Cogmind's lesser-used "special commands," features not only requiring the keyboard, but even all assigned to Shift-Alt key combos. So these rarely needed (but still sometimes useful) features were already pretty clearly grouped together as a unit by their annoying modifier, but ideally they should be easier to trigger, not to mention also more readily available to mouse users.

I waited quite a while to implement this menu, mainly because I wanted to design and build it for a more stable and complete set of special commands, one that we couldn't really be sure about until later in development (and sure enough these features have been gradually expanding and fluctuating over time, coming to a head in the current Beta 11). In the meantime it wasn't an especially pressing issue because, again, these aren't exactly commonly needed features, so occasionally requiring a player to wrangle with awkward commands via Shift-Alt-["some-letter-I-forgot-because-I-rarely-use-it] wasn't all that terrible. Even with the advent of a dedicated "Special Commands" interface, the Shift-Alt-[letter] approach is not going away--it's still available for those who don't mind, or even prefer it, but as you'll see we also gain other benefits in the process.

All you need to do is press Spacebar and a new menu pops up with a range of options originally only covered by one of these Shift-Alt-modified keys, and the menu allows both button access via mouse or hitting the corresponding key to enter a given "special command" (basically a blanket term for less commonly used UI features).

There are lots of advantages here:

• Allows mouse access to special commands
• Players aren't forced to use Shift-Alt for these commands (especially on non-Windows systems, where the use of Alt can be problematic), where Spacebar+[letter] will do
• Feature discovery is greatly improved, since all relevant options are listed following a single keypress
• No need to remember the letter associated with each command, since those are listed as well
• Having an explicit menu visualized in the interface also offers an easy way to describe what each feature does

The menu appearance is animated in standard Cogmind style, but input is accepted as soon as Spacebar is pressed to keep it responsive for people who simply want to use this as an alternative way to enter keyboard commands they already know, for example Spacebar+s to dump stats, without the window annoyingly popping up in between the keys. In fact, for this purpose the window even has a slight 150-millisecond delay after pressing Spacebar before it appears, a delay that isn't really noticeable for someone using the mouse, but plenty of time to enter a second key.


UI Mockups
Before actual implementation, as always I used REXPaint to design the general layout of this menu based on its intended functionality, and to inform later UI coding work. I streamed the process when getting started, in this video where I also covered REXPaint and glanced at other past UI designs:





It's not exactly the most exciting piece of UI design, especially since for consistency sake it mostly draws on existing simple elements from prior window designs, though I'll cover some of the design evolution here.

The initial mockup drawn on stream in REXPaint.

The first iteration above aimed at simply getting all the likely elements into a box and work from there, so it uses a pretty typical title and border style (the missing notch in the bottom-right is for a potential close button, which in Cogmind uses a different double-width character so can't be shown in this same REXPaint file), shows the full list of commands we'll be including (11 in all), and includes two separate sections of gray text, one to point out that the commands can also be entered directly via Shift-Alt, and another to provide a description for each button/feature as the mouse hovers over it. As this is a mockup, the gray text is not actually written out in its final form (or even to make sense :P), just copied from elsewhere as I was moving things around to get an idea of layout. Real content comes later.

Having a vertical list of options is generally ideal as far as menus go (especially alphabetically-listed options), but the problem here is that, at least all other things equal, a tall-style window ends up limiting the amount of horizontal space available for command descriptions unless they potentially span numerous lines, which doesn't make for good reading.

Something wider would be preferred, so let's split the options into two columns...

The second mockup continued improving the layout on multiple fronts.

Unequal column length aside, this will generally look a bit better insofar as giving us more horizontal space for descriptions. Also here I split up the two gray text areas by straddling the options, since keeping them apart seems to make sense given they have different purposes, one static and another dynamic.

Altogether it was looking better, but I didn't really like the unequal amount of space afforded to the option rows, and decided to equalize that:

Further refinements with a third mockup.

In this layout the UI looks less lopsided, which while not a necessity (either could work), I preferred this aesthetic, plus we even get a little extra room for the additional text.


Final Layout
Now there's no way I'm doing my best work while streaming, certainly not alongside an unavoidable loss of focus due to chatting and whatnot, and streaming or not I tend to sit on things like this (any kind of design work) for a bit after an initial pass and revisit them for refinement anyway. Sure enough, later that afternoon after some hours away from it I took another look at the interface and immediately had a new take on it...

What started it was that I didn't really like the idea of this being a relatively small floaty window out over the large map view. We don't really have those in Cogmind--windows are usually either large or connected to some other associated object or UI element, but in this case it's a general-purpose feature menu so doesn't have a natural place in the interface to associate with.

I thought it'd be better to try to redesign it with an eye towards having it occupy more space, and in that vein came up with an aesthetic pretty different from what we had going before, but very much in line with other pieces of the UI which offer functionality not entirely unlike this one: Cogmind's options menu and commands reference pages!

Fourth and final mockup, quite different from the others but I like it!

The above mockup assumes that the window appears over the map and extends out to either side of it in both directions. The button style already matched the options menu (as does the help text), and now the header and border does as well.

Other improvements in the final mockup:

• Some commands were renamed, ideally so that their first letter matches the associated key.
• We actually only need one section of gray text, rather than two, because we only need the descriptions available specifically when the mouse is hovering over a button, otherwise it can display the "default" message about Shift-Alt access.
• The extra width allows for even longer descriptions without newlines, where instead each description will be written to keep it within the length seen in the mockup above (too long is also bad). This also allows the window layout to be more consistent since we don't need to leave room for potential additional lines.

Here is the final implementation in action:

A demo of Cogmind's new Special Commands window, here using it to activate the map ruler overlay.

Notice how the special commands menu is not vertically centered on the map. This is to leave some environmental context around Cogmind while it's open, for reference. Not exactly a very important feature, but there's room so why not :D


Notes
During the polish phase a few automations were added for convenience when it comes to mode switching and feature toggling. For example, Spacebar will automatically deactivate an active map ruler overlay since this will generally save time, particularly for mouse users who otherwise have to open the menu and click on the button again to toggle it off, and there's seemingly no real reason one would need to keep the ruler on and then also access a second special command at the same time.

There are a few Shift-Alt commands not found in the menu, all three of which probably almost no one ever uses anyway, but they also require holding the key to take effect, so probably aren't all that compatible with this menu approach anyway.

As for mouse access to the menu itself, I considered enabling that via middle mouse button, but that already has a somewhat more important use (plus again special commands aren't that commonly needed...). Spacebar is also big and relatively easy to hit in these cases. I also considered having a clickable button on the main UI that could be used to open this interface for even better discoverability, and completely not needing the keyboard at all, but don't really want to go that far just yet--it's probably not all that needed compared to the extra clutter it would add for such low-use features.

[Kyzrati]

Rebalancing Cogmind
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

A decade of development into a huge project is almost unavoidably going to accumulate some amount of cruft. Mechanics that are never quite worth taking advantage of, items that haven't lived up to their potential, or were later superseded by other options but remained unchanged, or even long-term experiments that were included at some point but never updated/expanded/removed.

Cogmind began its life as a 7DRL, and a portion of items designed back when the game was overall a very different environment didn't evolve at the same pace. Now obviously the most egregious of these have been gradually addressed over time--we don't want these sorts of things sticking out like sore thumbs, and it's not like such issues have been completely ignored. That would be bad :P

But it's all the tiny bits and pieces here and there which add up over the years, and across the breadth of the game, which do need to be examined and polished to fit into what the game has become. For the most part, elements that haven't been addressed yet were relatively minor, out of the way enough that they could be safely ignored, though the pursuit of perfection necessitates a proper full pass to refine... well, anything that needs it. And if we want to find an explanation other than temporarily suppressed OCD, the current timing of this process is significant: Cogmind is well past "complete" status, especially ever since Beta 10 released in 2020 and finished off the last of the required features (ambient audio), so now is the time to do a more thorough job refining everything before embarking on new expansions.

Some roguelikes don't strive for balance, but maintaining balance has always been important to me for Cogmind, since it fits better with my vision for this type of game, heavy on tough, complex, and consequential decision-making at multiple strategic and tactical levels.

Actually, beginning over five years ago there was a plan to one day do a sweeping review of Cogmind's parts, especially utilities (as they represent the bulk of Cogmind items and offer the widest variety of unique effects), basically to ensure that everything was working together smoothly and had its proper place in some compelling Cogmind build or another (or at least for other robots!). The first part of this so-called "Great Utility Update" began during Alpha 12 with a few fundamental mechanical changes, but since then the project remained on the to-do list until 1) even more content was added to the game, and 2) we collected more info about what items people were and were not using, and why.

It made sense to wait as long as possible to carry out this process, but the wait is finally over! Beta 11 is finally tackling this project, and we've already seen it manifested across propulsion, weapon mechanics, storage units, fabrication and more, but the comprehensive item-by-item review has only come to pass as part of the conclusion to this dev cycle. I must say this has been an exciting time, having the opportunity to revisit everything to iron out as many kinks as possible, in many places adding new build possibilities or even whole new mechanics.

The scope of this rebalance is way too large to cover in its entirety, and while I don't plan to write about every aspect, we'll be looking at the broad strokes and pick out some representative examples here and there.


Categorical Approach
Before doing a full item-by-item review, I started with two special categories of unique build-defining items: aliens artifacts and Exiles prototypes. These are items relatively limited in availability, and only a small subset can be acquired in each run, though they're also extremely powerful when used effectively. Due to these shared characteristics, while cutting across slot types, it makes sense to work on their design as a group--they're balanced against one another as much as they are against other parts.


Alien Artifacts
I won't get deep into the artifacts here, but there were a fair number of changes.

One in particular was removed because its effect was unfortunately impossible to balance (somewhat funny because almost no one used it for years until discovering its true potential)--the Stasis Generator was an example of an item with a mechanic added "purely because we could, not because we should." Some early utilities got effects like this during pre-alpha development, before Cogmind was released, when no one had even played the game yet and I was experimenting with more extreme mechanical possibilities without a strong tactical basis for their design.

Beta 11 added six new artifacts though, with even cooler (but balanced :P) effects, so that makes up for it ;)

It's important when rebalancing to try to make up for any losses in gameplay options by adding new ones.


Exiles Prototypes
The Exiles prototypes, accessible from the early game, are in most cases not meant to be incredibly OP gear to hoard for most of a run when it could give an edge in the late-game.

Even after updates this is still a reasonable goal and fine in some cases, and many of them started off intentionally incredibly powerful (for fun, right?), though having plenty of collective experience them it became pretty clear which could use a bit of a nerf, buff, or... [my favorite kind of change:] some other sort of unique twist ;)

ASCII art for Exiles prototypes.

As an example, by far the most sought after prototype was Lightpack 2.0, the low-mass storage unit with huge inventory space. I originally liked that it could enable very different builds if you lucked into it, but being a storage unit it was generically amazing for everyone rather than leading to interesting options--an outright significant power boost, and one that would last an entire run, at that.

Now that I was allocating all this design time to rebalancing items, there was plenty of impetus to do something more complex with it. (Back when I was first adding the Exiles prototypes, there were already a few which individually required lots of special plumbing, several days worth in some cases, so when it came to add something as "mundane" as a storage unit it was nice to take a break and speed things along by drawing some art and slapping new stats on it.) So for Beta 11 I came up with a new mechanic which was definitely going to take some implementing...

The idea is that the Lightpack does indeed allow for any build to take advantage of low-mass storage, and I even vastly increased its storage capacity, though it achieves this miracle by utilizing unstable extradimensional space which sometimes swallows an item. It might return that item when next disturbed (e.g. storing another item), or might destroy it forever. The more items packed into it, the greater the instability.

Overall the mechanics are balanced such that it's a boon for builds that care less about losing specific inventory items, but clearly not everyone is going to want to use something so unreliable. This aligns with the concept that although Exiles prototypes are meant to be very good, they're also usually flawed in some way, such as eventually breaking down, blowing up in your face, or something in between :P


Slot-wise Approach
Next we can actually tackle the item-wise review, basically looking at them one slot type at a time, e.g. all power sources, propulsion, and so on.

The latter were technically covered as a group early on during Beta 11 development because it would underpin a lot of other potential changes throughout this rebalance--along with storage, propulsion is the most fundamental part of a build! As Beta 11 evolved I did revisit propulsion a bit later, though just for smaller tweaks rather than to the same extent as seen with other parts.

But power sources definitely called for a comprehensive review, so it was time to break out the spreadsheets!

If you've seen them here on the blog before, you may recall that my own tab-delimited Cogmind data files are similar to spreadsheets, and have their own syntax highlighting, but they're not true spreadsheets. For the purpose of analyzing raw stats it can be nice to drop all the relevant data into a regular spreadsheet, since having the same data in a different format can reveal aspects that may be more difficult to observe in their normal environment.

This is definitely the right time to do just that, so I used Cogmind's data exporting feature (which players have access to as well) to output CSV files, then prettified them to help with the review process.

Power source data in Excel, formatted and including updates along with supporting formulas. New or modified values appear in red text.

Another advantage of spreadsheets we can use here is the ability to define formulas and tell us more about items beyond what's shown directly by the stats alone. In particular with power sources the generation-mass ratio is especially important when comparing across types, and with that column I identified several that needed tweaking. Conditional formatting is also very useful here to help certain values stand out, an approach I'll be making even heavier use of further below, but it's already come in handy with power sources.

For the most part I was already satisfied with the progression of power sources, more easily balanced since they are the smallest (and technically least creative...) slot type, with pretty well-defined subcategories. Beta 11 does, however, move towards making power slots more attractive by increasing variety and potential benefits. Aside from the handful of stat tweaks, a new subcategory was added ("hybrid" power sources which are lighter and generate less energy per turn, but store a lot), Fusion Compressors and their matter-to-energy conversion mechanic was converted from a utility to a power source, and the only artifact-level energy generating part was also converted over from being a utility. I imagine more will be added in the future, but for now we have a seemingly balanced state to work from.

As another example here's an excerpt of airborne propulsion data in Excel, from when I revisited propulsion stats for the umpteenth time during Cogmind's development, seen here with formula-based supporting data points and conditional formatting.

(continued in next post...)

[Kyzrati]

(...continued from previous post)

Weapons
Although the original intent years ago was to eventually focus on updating utilities, at this point weapons actually needed a lot of refining, number-wise even more so than any other slot type!

Again in a general sense there was nothing hugely out of whack that wasn't addressed already as necessary, but Cogmind's mechanics have expanded significantly since the early years when the templates on which the weapon designs were based made certain assumptions about the rest of the game at the time. Taking a fresh look at everything could allow for new perspectives and suggest even subtle changes that would result in an overall improved experience.

Probably the best example of a change that came about as a reflection of Cogmind's mechanical evolution was actually applied to an entire subcategory of weapons rather than a single one: Almost all kinetic guns had their max range decreased by 4.

I didn't originally expect to make such a categorical stat shift at this point, but it makes sense in context. One of the big goals of Beta 11 has been to ensure items are sufficiently differentiated, and while cannons and guns have been diverging over the years via several mechanical changes, for a while guns have had the upper hand in many tactical scenarios, especially since "gunslinging" was added. Kinetic cannons could use a little something extra, so they have retained their max range as one of those advantages. That said, average kinetic gun range still exceeds visual range in most cases anyway, so this change is only relevant to certain build types.

Another area I'm instead not so surprised to see sweeping changes is impact weapons. I keep experimenting with updates to those every year since they use a different hit location model than all other weapons, one that isn't generally conducive to the most commonly desirable goal of combat (destroying targets), and Beta 11 is no different. So I reimagined them yet again, taking into account their unique targeting mechanics and what that means when fighting other bots.

The biggest change there was simply yet more significant damage buffs. They've always been pretty scary when used against Cogmind, and I'll have to say they've technically become even scarier! But they also might be fairly more useful for Cogmind now. We'll have to see if more changes are necessary (...nerfs???) since this was quite a buff for weapons which were technically already starting to get good in their own niche xD. As is the changes are too new and we'll have to see what real playtesting turns up.


Fine tuning
The weapon balancing process didn't result in that many blanket changes, though, it was more about adjusting individual items, usually at most just one or two stats wherever they had become unreasonable for one reason or another.

Cogmind's items were originally designed and balanced based on a large set of desired data ranges and mostly linear progression from the lowest to highest ratings, though it's been many many years since that time, and some items were later adjusted for various reasons, usually taking into account the original scale, but not always other important factors like all potentially related other existing items, leading in some cases to either undesirable deviations from the scales, or more annoyingly items that weren't unique enough to justify their existence.

Of course the idea of scaling for balance here is referring primarily to commonly available items, not unique one-of-a-kind items or other special gear, which are where even more of the fun comes from. But we need a stable core set of items, and that's where the strong desire for balance comes in, especially now in Beta 11, after which we will again be free to start adding new and interesting parts to the fringes :D

Even with a scale on which to base balancing decisions, its values can only be applied to a smaller number of core items, whereas there are many parts available at each rating, and each one should ideally be different somehow, while still potentially worth using in some build, if possible. ("If possible" because there's always some cases where a part is intended primarily for the AI bots, though it's nice when these can also be made useful to Cogmind as well; plus there's always the times where Cogmind will take anything they can get in a pinch!)

So anyway it was finally time to look at every. single. weapon., hundreds of them, and take into account a wide variety of balancing factors while doing so. There are a number of checks and axes along which stats are compared:

• Does each common weapon have suitable stats for its rating?
• In a general sense [<-insert this phrase before all statements here :P], is it unique enough compared to other weapons equal to its rating [this one, too->] in the same category?
• Is it better than weapons of the previous rating?
• Are prototypes at a given rating better than non-prototypes at that rating?
• Are prototypes somewhat equivalent to non-prototypes of the next higher rating? (though perhaps still have some unique quality that might make them better)
• Do weapons using a given prefix have characteristics that accurately reflect that prefix?
• Do weapons across different ratings that share the same tech/name also share similar characteristics?
• ...and probably some more concerns but those are the big ones

Note: Comparing between categories, e.g. thermal guns vs kinetic guns, is occasionally needed but not quite as important anymore since each category already has a pretty clearly defined set of characteristics that make all of its constituent weapons fairly different from those in other categories.

Balancing usually takes the form of simply adjusting numbers to meet our goals here, though it's worth pointing out that one of the advantages to doing this now, as late as Beta 11, is that we have more levers than we did back when these parts were first created. New mechanics have been added over the years, giving us new benefits and drawbacks to consider, or even use to directly control the balance by assigning brand new values and moving some of these extra levers. The original weapon designs weren't able to take advantage of stat-based mechanics like heat transfer, unique critical strikes, and EM spectrum, or as mentioned above even widely applicable new mechanics like gunslinging.

For example, neutron-based weapons were given spectrum effects (and disruption), the first non-EM weaponry to have them, as that effect didn't exist back in 2014. Technically this was a flavor thing, however, since these weapons didn't need to be more powerful or effective, but part of this process has also been ensuring that weapon characteristics fit the tech represented or implied by their name. More on naming later.

Below is the weapon spreadsheet I worked with, where new or modified values appear as red text, highlighting only those changes that were made as part of the comprehensive review during late-Beta 11 (thus excluding all new weapons and adjustments made earlier in Beta 11 development):

That's a lot of weapon data. I've stripped about 50 spoiler entries and uniques, mostly at the high tiers, and you can also download the Excel file here. (The image excludes some of the launcher data values and a few other lesser-used columns off to the right.)

While examining the weapon data, some oddities that needed addressing were more likely to stand out in this spreadsheet format compared to my normal approach. For me it was also simply helpful to visually parse a ton of compact data using a small font :P

After I was done working through the spreadsheet on my own, I also streamed it to share the process with the community, if you're interested in checking out more:





During the stream I covered many of the individual changes and logic behind them, and we even made a few more tweaks based on feedback.


Not... Cogmind?
One important thing to remember here is that item changes tend to affect bots that use those items! Cogmind isn't the only one relying on these things to operate, and some robots were slightly redesigned here as a result, but for the most part changes are just accepted, for example some Hunter variants were indirectly nerfed due to the minimum damage reduction on their primary weapons. I'm sure they'll still manage to fulfill their duty just fine, so that's okay ;)

This is even more true with changes to power sources and propulsion, as those are more fundamental components supporting an entire build. So after a batch of changes is complete, I always have to go back and check over the robot builds to make sure they won't... you know... melt, deplete their energy then sit around, fire a few times then run out of resources, and so on.

For that purpose I have a tool I can run which outputs a range of bot performance data that summarizes aspects we care about, like reporting their effective speed based on how much they're carrying, and their ability to sustain combat, maintain proper heat levels, have sufficient energy under different scenarios, etc.

An excerpt of output from my build testing tool, which prefixes problem values with a '?' that the syntax highlighting picks up on and colors red so I'll notice it and address if necessary (some bots are intentionally designed with "problem values" outside normal parameters, but there aren't many such cases).

Utilities
At last we've reached the final category, the one for which the Great Utility Update was originally named... despite ending up applying to a much broader range of parts :P

Before starting this item-wise review process, I was really wondering what would be the best way to collect additional useful feedback about what utilities we wanted to change and how/why. One approach I considered was making a public spreadsheet listing all the items and just let anyone contribute opinions there, but while maybe fun it also seemed pretty chaotic and inefficient. With the success of the first dev stream I did with the weapon spreadsheet, I realized that would also make a pretty good format for getting feedback on utilities.

Of course after literal years of waiting to do this I also had plenty of prior notes to work from in many cases, but it would still help to go line by line with some of Cogmind's most frequent players and get updated opinions, especially from those who'd been playing the Beta 11 prerelease builds, which include quite a few changes and new features of their own (so already a rather different experience from the public release at that point).

So in addition to my notes, a number of utility adjustments came from discussions spanning a series of streams totaling ten hours in all:





https://www.youtube.com/watch?v=Xc5e4S-hf8s

https://www.youtube.com/watch?v=pEugYn1aTf0

The streams were mostly for discussion of areas to address rather than making actual changes or final decisions, parts of the process I'd go on to complete later, one reason being that, unlike weapons, utilities are less of a number-focused item type, revolving as much or more around their mechanics and functionality they enable. Since it's more than just numbers it'd take more focus and broader consideration to finalize details after determining what they would entail both architecturally and design-wise, activities that are harder to do well while streaming.

Some of the tweaks were straightforward enough, while some utility redesigns even got their own spreadsheets to more accurately test their effects :P

Examining multiple possible mathematical approaches to a more straightforward Core Analyzer effect.

I'll pick a few examples to discuss below, and more can be seen in the videos (since we literally went down the entire list xD).


Overload Utilities
Cogmind has always had overloadable energy weapons (toggled for extra heat and energy costs but greater damage and a random chance of triggering a nasty side effect), and back during pre-alpha when trying to pack as many different mechanics in as possible into the utility set, I decided to add Overload Amplifiers and Overload Regulators to specifically buff this subcategory of weapons. So yes this was another of those early "purely because we could" things without any playtesting or strong design basis, and it eventually showed.

Overloadable weapons were already situationally decent even without support from utilities, and it didn't really make sense for a build to bother with such utilities since there aren't that many overloadable weapons, so possessing both this kind of weapon and a supporting utility geared only to it would be relatively rare, not to mention the side effects are generally undesirable vs. the predictability of regular weapons.

Following this realization, I decided something would eventually need to be done about it and simply made them much rarer until that could happen. Well... something was eventually done about it: Beta 11 removed them :P

Overload utility art. Maybe we'll see you again one day?

I rarely outright remove items from Cogmind. I prefer to try fixing whatever's wrong with them (nerf/tweak/buff) so that they're viable on some build (and reasonably acquirable for that build in the hands of an experienced player), or if that's not possible then turn them into some other item with a new mechanic just to always keep the number of items and interesting options stable or expanding.

One thing that made these harder to work into a system like Cogmind's is that they had such a niche use that you don't want them to be all that common a find--most people would ignore them, but that also means they're even harder to apply to situations where they might actually be useful. What I like to do is add parts to at least some robot build that players can then seek out and target for salvage, but overloading is not an appropriate mechanic for other common bots to be utilizing, so that strategy doesn't really work here.

So they were removed, but having done so I also decided this would be the perfect time to revisit the overloading mechanic itself since overloadable weapons were now "merely" powerful rather than being buffable into a ridiculously powerful state anyway (which was technically possible before).

Removing the utilities allowed me to remove the most detrimental (and only permanent) side effect, meltdowns, while rebalancing the severity and weight of other random effects. Overall the changes are a net positive for the mechanic, since it's usable in more situations now, but we no longer need to balance for the low-likelihood synergy between dedicated supporting utilities.

Aside: I don't actually remove mechanics like this from the source code--they're still in there in case they want to make a comeback some day for whatever reason, but the items were removed so it's simply no longer possible to access this mechanic.

(continued in next post...)

[Kyzrati]

(...continued from previous post)

Trap Extractor
"Trapper builds" have never quite been a thing in Cogmind, or at least not a plannable serious build type one can work toward. For a long while we have indeed had a few non-guaranteed unique parts that greatly facilitated trapping strategies, but if they're not guaranteed (and also not replacable...) that's not a long-term build. Not to mention this strategy is pretty limiting as it places an outsized burden on inventory space, with each trap taking up one slot.

Beta 11 changes all that.

Trap Extractors, which remove friendly/hacked traps from the ground, have new functionality allowing them to store those traps in an internal storage space, up to a certain limit. For the first time ever in Cogmind, inventory items can store other items...

I've avoided going this route for a very long time because it could easily be taken too far and lead to all kinds of more complicated inventory management scenarios (and balance issues) that we don't want, but for trapping in particular it could be worth it, and it turns out that the feature can be enabled entirely via existing part interaction functionality, a very important aspect when deciding what mechanics to implement.

By design, Cogmind doesn't have a way to allow for more detailed/unique interactions with individual parts--everything must fit into the existing range of basic inputs. Fortunately it was possible to work out a suitable approach for trap storage and deployment through an item's cycleable third state, usually used for overloading, or in more recent years other secondary control functions that were also used to improve some utilities (for example the Field Recycling Unit).

So the three states for Trap Extractors are now inactive, extract, and drop, the extraction working as before, and the new "drop" state dropping one contained trap per turn. Clearly for this to work right we also have to limit each extractor to holding only one type of trap at a time, which is fine. There's also nothing stopping players from carrying multiple extractors, which is likely what a real trapper build will do now.

Trap Extractor demo.

This is a pretty good example of the heavy influence interface limitations can have on game design. Sometimes devs are tempted to add yet more esoteric or one-off interface features to support some interesting or otherwise desirable mechanic, but then it's no longer a net positive for the game as a whole since it adds to confusion and the bad sort of complexity.

It's better to build a flexible enough simple interface that can support a desired variety of interactions, and always create features that stay within those constraints, either redesigning those that seek to break constraints, or simply leave them out. If the interface was flexible enough to begin with, there's always plenty of different features that will work!

The advent of trapper builds might require more balance tweaks to extractors down the line (in particular with regard to their internal storage space), but they are very new so we'll have to wait for more playtesting. I look forward to trying these out myself!

During Beta 11 this new capability did already lead to a change with AOE EM damage triggering traps, since setting off a group of them (especially Dirty Bombs) was always very effective, but acquiring the means to do so has become much easier. Now the chance of chain reactions is reduced to compensate.

Overall there might not be too many changes, though, since there is still a bit of danger associated with trapping, and you still can't produce traps on your own and are therefore more reliant on the environment.


Force Booster
Force Boosters were always kind of a weird utility, and due to those oddities generally underused... Prime balance target alert!

High resource costs necessitating precision toggling aside, their main purpose was to increase melee weapon damage, but they did so indirectly by boosting momentum. Even with damage modifier previews to help, conceptually it's just not great to make that unnecessary leap, so they got a pretty significant redesign.

The new design directly increases maximum melee damage by a percentage (so technically increases the damage range, since the minimum remains unchanged), and also decreases accuracy. This is the first common utility to balance its own effect with a simultaneous negative effect as a tradeoff, which I think is a neat new approach that I'll have to keep in mind.

Force boosting in action.

(This change from the old dynamic momentum-based model also loses the ability to automatically buff ramming/kicking damage, but that's not very important.)

While designing the new Force Booster mechanics, I included extra calculations in my weapon spreadsheet to show what boosted damage values looked like for different melee weapons:

Force Booster effect on melee weapon damage (partial excerpt, green values).

The 60% buff in the chart above would be the result of combining two of the best boosters since they have the <half_stack> tag, another new Beta 11 mechanic that was determined before the comprehensive review since it definitely informed a number of utility balancing decisions.

That sure is a lot of damage...


To Be Continued?
I'm quite pleased with the results of the balancing efforts, with so many improvements all over the place, although there were a few topics of discussion surrounding utility mechanics that involved some compelling ideas but were ultimately inconclusive.

For example there is contention around the ability to extract resources from containers on the ground and what it means for tactics, and there is some interesting potential in the direction of allowing drone bays to repair and build new drones by consuming their own integrity as a resource.

Those and more got tabled in my notes and maybe we'll see the same discussions resurrected again one day (actually the resource thing has been hashed out at length multiple times before...), but there weren't yet strong enough arguments on one side to drive change.


Naming Items
The last thing I did at the end of this process was another complete pass over the items looking instead at their names. I felt there were places where we could potentially reduce confusion and cognitive load, in particular where there might be too many different names for utilities that have the same type of effect.

In naming items there's the eternal dilemma of flavor vs. function. Do we want naming schemes to lean more on the functional side, which tends to be drier and lack character (see POLYBOT-7, where I leaned heavily in that direction!), or more on the flavorful side, a route I decided to take with Cogmind 7DRL, and by extension the subsequent commercial version, but have gradually scaled back over time.

The 7DRL could benefit from flavorful names because it had fewer truly unique parts (being a 7DRL...), so the idea was that this was a quick way to add some flavor, by giving unique names to different-tiered parts with the same effect type (just differing in strength). But now after all these years we do have a lot more items that actually do something different, so having different names be more likely to actually have different effects is a less confusing approach.

As a particularly crazy example, ever since the 7DRL Cogmind has had a Weight Redistribution System, Gravity Neutralizing Apparatus, Inertial Stasis Machine, Quantum Shading Machine, and Dimensional Manipulator, all of which share the exact same effect type as a utility which draws energy to provide an amount of mass support xD. So now you probably have a better idea of what I'm talking about if you didn't already.

Unifying the names of items with the same type of effect also reduces the raw amount of terminology to remember, important since Cogmind is technically a game of static items in which you are eventually intended to be familiar with them and not have to even examine stats in order to know whether something will be good for your current build/strategy, and can also better plan in advance for acquiring certain parts. Having too many different names just complicates that process (and we're definitely going to want to keep opening the space for even more unique items down the line!).

Since I stopped doing crazy stuff like that later on as the item pool expanded, there's a good reason to go back and reduce some instances where it went overboard.

In most cases I've stuck with tiered utilities all sharing the same root name with a separate prefix for each (the ubiquitous "Improved," "Advanced," "Experimental," etc.) though I've sometimes allowed for two or three different names in other cases where it's worth it because the items are extra special.

Taking the mass support example above, that was simplified as follows:

There wasn't really a better low-variety, prefix-based approach that could accommodate the same number of tiers we needed. Mass support is actually a somewhat unique utility in that it's so commonly used by other bot designs to make them work, and we need a lot of tiers for flexibility.

On the simpler front, Maneuvering Thrusters and Reaction Control Systems were merged under the latter's name, as were EM Shields and EM Dispersion Fields, and System Backup Modules and System Restoration Modules. This also opens up some of that terminology for future use in other new items, like Maneuvering Thrusters could be a whole different thing, if a suitable mechanic is desired at some point.

Renaming was primarily an issue with some of the utilities, but I did some renaming elsewhere, too, including one type of weapon which is worth a mention: Electrolasers were classified as thermal guns, but technically they should be doing electromagnetic damage based on, you know, real electrolasers :P

This was pointed out to me by a player, and Cogmind does lean on a lot of harder sci-fi concepts where possible (plenty of research went into the items!), so I'm all for changing something like this.

It was actually really hard to come up with a fitting replacement--I couldn't switch the damage type or anything because that's not how Cogmind design works, I needed a thermal gun with those stats and that rating. Coming up with an alternative name that also fit snugly between all the other names of weapons around that tier took hours. Eventually I settled on quite a neutral sounding "Field Laser" (non-existent and virtually meaningless? perfect xD), which was actually a decent fit considering the bots armed with it (front-line grunts). Throughout such a long process I'd listed out so many possible names that also started suggesting new ideas for weapons tech that could be applied elsewhere, one of which I even ended up implementing then and there, the Thermic Laser.


BREAKING: Renaming Leads to New Mechanics
During the naming review I decided it was time to consider removing the lowest tier of terrain scan processing utility, the only one dubbed a Seismic Analyzer in a world where all the other tiers were more obviously named... Terrain Scan Processor. No one uses it, after all, it's really just there for flavor, as a part on one of the common non-combat bots (Excavator).

But I liked that flavor, and really wanted to somehow keep it in the game, so in a roundabout way I got to thinking back to new types of sensors I wanted to have, and that this might just be a good opportunity for one of those: a seismic sensor.

Now as a "sensor" item we'd have to convert it from a Processor to a Device, and I guess that means also renaming it to "Seismic Detector," but... hey, we have yet another new sensor in the game! It's cool. (Note Beta 11 already added multiple new sensor types, for example the Active Sensor Suite. In fact there are now six new types coming in this release.)

Even better is that this sensor can be acquired from a common bot, meaning that it's yet another option frequently on the menu for anyone looking to salvage some infowar capabilities. So what does it do...

Well obviously it senses vibrations, meaning it provides a way to detect some robots, some machines, some weapons, cave-ins, basically a subset of objects and activities going on in the surrounding areas, any that cause a vibration, though without explicitly identifying what those distant readings represent--that's on the player to figure out based on what it looks like or how it behaves, e.g. shape, intensity (because stronger readings are brighter!), movement...

Like all sensors, there is an animation associated with its activation, one that also reflects the detection range.

The idea is that Seismic Detectors offer a unique new slice of data, one that cuts across numerous object categories, but is limited to a subset of each one. So while it's a very interesting utility due to the wide variety of objects it can detect, like any sensor data the user must be aware of its shortcomings, since for example it won't include non-mechanical machines, flying objects (airborne patrols!), or stationary objects (guards!).

Below are some examples of the Seismic Detector in action.

Exploring with an active Seismic Detector.

"Seeing" combat outside a room play out via precision seismic data. Kinetic projectiles also light up targets (including terrain) due to the impacts, and at the start of this battle you can see two mechanical machines fall silent after being disabled.

Major seismic readings from our destructive friend causing explosions outside on ambushing a patrol.

 

Bonus dev image showing seismic data in a Waste area ;)

So yeah, this neat new item came about due to a name pass, and I guess it doubles as an example of prioritizing repurposing over removal, woohoo :D

And that concludes our very comprehensive comprehensive review... for now. Balancing never ends as long as there's new content being added, and there's definitely new content to add ;)

[JobLeonard]

Having never gotten far/good enough to play with the stasis generator I'm now curious how it broke the game

[Kyzrati]

Heh, you know just ways you can cheese with it, which is to be expected considering it can outright stop anything from moving. It takes a lot of creativity in general, which is why it wasn't even used for years. Don't recall the specifics since I removed it quite a while ago.

The more extreme the effect of something (and outside the realm of what any other mechanics are designed around), in general the harder it is to balance so that it makes sense to even keep it in the game.

[Kyzrati]

Cogmind Beta 11 "Mechanical Renaissance" is released! Over a year in the making, for Cogmind's 10th anniversary we have a massive set of new toys, challenges, revamped mechanics, and more.

For more details and demo images check out the release notes.

[Kyzrati]

Garrisons 2.0
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Garrisons were originally added to Cogmind in the months after the first Alpha release in 2015 (see an overview here) as an optional location for players to visit, adding a unique extra dimension to the world to answer the question "what if I infiltrate these things where many enemy squads come from?" (More recently here on the blog I covered that category of Cogmind maps, the "maps between maps," since a third such map type was added this year.)

In the time since Garrisons were added, however, a combination of relevant changes to the game started putting pressure on their original design:

• Many more full branch maps were added, along with factions, each with their own enticing reasons to visit them compared to the weaker incentives for entering a Garrison.
• Eventually Garrisons themselves became a sort of faction home as well, in the form of RIF-using bothackers, which in turn meant that some styles of play encouraged visiting many Garrisons.

As a result, for a while now I've wanted to revisit and update Garrison design to better merge it with what the rest of the world had become.

This always felt like a kind of side project though, one which could be small (doesn't live up to the potential?) or large (hard to fit the work in?), so it simply floated around on my lengthy todo list forever. For Beta 12 I decided to include it on the patron feature voting list, and... it won. Cue several weeks of work which has definitely been worth it!

The amount of content variety offered by the original Garrison design was more suited to a lower visitation rate, not the "I'm going to play almost my entire run inside these things" which it had become for some people. RIF garrison diving became increasingly common, because it's a fun style, but we could totally make it even more fun with greater variety!

So the goals for Garrisons 2.0 are to increase variety in the form of encounters, events, and new layouts, while also reworking the clock and giving even non-RIF players good reasons to enter.

Let's get started!


1.0 Garrisons
As a quick reminder of their fundamental structure, unlike most maps which use more involved generation methods, Garrisons are built entirely from large prefabs, four of them to be precise, fitting and rotating randomly selected quadrants to create a larger square map.

Sample Garrison interior layout (major features labeled), under the old system first introduced in 2015.

So each quarter of the above map is a separate prefab rotated such that their corners form the central room. With 44 variants in all, many with somewhat variable content of their own (random items, traps, maybe potential allies instead of hostiles, etc.), this results in quite a few possible permutations, but seeing as each map is composed of only four of these prefabs, when players start exploring upwards of ten of this same type of map in a single run, some of these corridors start looking all too familiar, especially betraying hidden areas that might otherwise be surprising! (and by design there are quite a few of these inside Garrisons)

One of many Garrison prefab quadrants as seen in REXPaint.

We're going to need to inject more layout randomness in here to liven things up over the long term...

Before getting started with that, I first built a little tool to get an idea of the complete contents of a random set of Garrisons. This might help spot areas I wanted to adjust, or at least offer a clearer picture of the total challenges and rewards possible in a given map as of Beta 11. For Garrisons the complete list is also more relevant than elsewhere, since "full clearing" a Garrison is a lot more common than in many other maps.

The tool would load up the game, visit a Garrison at every depth, and tally its contents, adding the results to a file, doing this for however many seeds are specified. I could save the data to revisit it later, after adjustments are made.

Sample Garrison content list from Beta 11.

Relay Couplers are not reflected in this list, since there are almost no free-standing couplers in Beta 11--they're acquired separately from Relay machines, and I already have a good idea of their distribution since it's more directly controlled anyway. Here I'm more interested in the non-RIF-related rewards.

One very noticeable issue is that for some Garrisons there was little to nothing under the "usefuls" or "items" categories, making the entire map almost purely of benefit to RIF players (since there are always Relay Couplers to be found, plus the RIF Installer for abilities).

Sometimes other players would Garrison dive for fun/something different to do, and sometimes come out with nice rewards/out-of-depth gear, but unlike the alternative (going for branch rewards instead) that was definitely not guaranteed, so not really a reliable long-term strategy to play around. It'd sure be nice to resolve that!

Adding extra content could have the dual benefit of both spicing up Garrisons and making them valuable to more than one type of player. I'm reminded of Beta 11's spicing up the main complex with Heavies and Cargo Convoys, though in this case it's not just adding one or two new mechanics but instead about turning Garrisons into proper branch maps in terms of content distribution...


Encounter Architecture
If you've read some of my earlier map generation articles (specifically here, and here for caves), you might be familiar with how I make use of an "encounter system" to procedurally distribute and insert map content, generally via prefabs.

The question was how to apply this approach to Garrisons.

Embedded prefab encounters in other tunneler-generated maps have a defined set of empty rooms to work with, but Garrisons don't have any empty rooms at all, themselves being composed purely of prefab quadrants where every space is hand-crafted with purpose.

I considered a lot of options here, going as far as thinking of building a new generator from scratch (one that would make encounters much easier to implement), but I liked the established and consistent core theme of existing Garrisons and didn't want to mess with that. Instead I came up with a way to integrate Garrisons into the room-based encounter system: If we don't have any empty rooms to place encounters, we'll just have to dig some!

And I mean dig manually...

Remember that prefab quadrant from before? Now it's got more rooms!

I went back through each prefab and outlined areas as essentially "optional placeholder rooms" which the generator could use to insert prefabs, but any of these areas not used for an encounter would actually not appear in the final map.

While a more algorithmic approach could also be used to do this, I prefer the handcrafted touches this allows for, like what nearby prefab sections the encounter at a given position is allowed to connect to, and how wide to make the links (which also determines which types of encounters can appear there).

Also we could've done something like choose an encounter then build a suitable space for it, but I was trying to take advantage of as much prior work as possible here, and that meant simply handing the encounter system a list of existing empty rooms to work with.

How the encounters link up with the map is a little different than usual, too. As drawn, some areas have multiple connections to main Garrison corridors or rooms, but only one connection is chosen at random to be used. This enables yet more variation in layouts.

Check out some full-sized Garrisons in the map generator before the game gets hold of them to actually insert the encounters, shown here with potential encounter areas in dark gray:

 

 

Here it's important to remember: Encounter rooms aren't nearly that large (usually), outlined is just the available space within which to place them, space which is then shrunk down to match the necessary size. Let's see the steps as I shared for the embedded prefabs in other maps!

Steps to embed a Garrison prefab in an optional placement area.

• 1. Find an optional placeholder room large enough to hold the desired encounter/prefab. The one above has two possible connections with the Garrison, one to the south and another to the west.
• 2. The southern link is chosen and the target prefab area is shifted against the southern edge of the room. The horizontal offset is selected randomly but still allowing access to the prefab interior in cases where the prefab itself contains objects that would otherwise block the path.
• 3. Areas of the room unused by the prefab are filled in with earth.
• 4. The prefab's contents are placed on the map, and any walls still needed are created adjacent to open space (most prefabs don't specify their own outer walls, but this one in particular does because it wants to surround an interior section with reinforced walls).

The right column shows an example where prefab contents are rotated and shifted to use the western link instead.

Also notice the blue phase wall at the entrance to the western-facing prefab, instead of a door. This is another key difference with Garrison encounters, that they specify the form of their outer connection with the Garrison, be it an open space, hidden door, or phase wall. Some encounters force a certain type of connection, while others uses weighted possibilities, whatever is suitable for the design.

Unlike 0b10 encounter rooms, these cannot actually expand or move doors, and use a tunnel-like connection rather than sharing a wall with an outer corridor. As with 0b10 encounters though, random horizontal flipping is allowed for further variation.

For now encounters only connect directly with main Garrison prefab areas as per the drawn suggestions, so only one entrance/exit each. I considered introducing the possibility of dynamically generating more loops via hidden paths between some encounters, though there are already a fair number of hand-crafted loops built into Garrison quadrants anyway, and players can always try to create their own additional connections given the circumstances and layout. Rampant terrain destruction is awesome, by the way ;)

Generating more paths would likely make Garrisons easier in some regards (unnecessary!), and not be compatible with many of the encounters anyway, since knowing which direction the player will enter from is often an important part of their design.

Below is a collection of images showing the full layout of several Garrisons after the complete generation process, including encounter placement:

New Garrison Quadrants
With a new encounter system in place, another thing I did was go back and create two new sets of Garrison quadrants, adding 12 more variants on top of the original 44. Each "set" of quadrants follows certain rules for their layout, and in this case one of the rules was to take into account the fact that encounter rooms may be embedded into the quadrant, something none of the earlier sets expected when they were created.

One of the new Garrison quadrant prefabs which follows a different style than earlier sets, including consideration for encounter insertion.

The new quadrant above moves some of its "standard contents" to beyond the entrance/exit (represented by the red '0') when pathing from the Garrison center (top-right here), and includes some especially large prefab areas with wide entrances, even leaving room for some within its main structure rather than the more typical outer edge locations.

Of course simply having a larger pool of quadrants for the map generator to pull from further expands the potential number of unique Garrisons as well, which was the first thing I was hoping to do with this update before even thinking about encounters at all.


Encounter Types
In my previous related articles I wrote about dividing encounters into four categories: Fluff, Reward, Risk-Reward, and Danger.

When Cogmind was pretty much done in 2017, a survey of encounters throughout the entire game recorded 25% of them to be fluff, 46% reward, 15% risk-reward, and 14% danger. By comparison, a breakdown of encounters in our newly expanded Garrisons shows 3% fluff, 40% reward, 55% risk-reward, and 3% danger.

Garrisons are already fairly dangerous given their concentration of hostiles, so I really wanted to focus on the risk-reward aspect--go the extra mile with these mostly optional side encounters, face even more dangerous situations, and likely be handsomely rewarded. In playtesting so far this (among other benefits we'll get to later) is already clearly tempting players who would otherwise always prefer regular branches over infiltrating a Garrison.

Garrison encounter distribution samples, color-coded by category.

The above samples show encounters added to a variety of Garrison layouts, highlighted with a dev visualization overlay. Those sections of the map would have otherwise remained filled with solid earth.

Notice that encounters do not generally fill the space available to them, with some even occupying only a tiny portion of it, so the sizes of rectangles here can be deceiving in terms of determining the prevalence of encounters. We're mainly looking at respective counts, color, and placement.

Grey rectangles in the visualization show areas not chosen for encounter placement. As with other maps, during generation there are X number of available encounter rooms, and different map types set their own percentage of those to attempt to fill, so it's easy to adjust overall density.

For Garrisons I've started with a 50% usage rate. If that turns out to be too overwhelming it can be lowered, or if we want even more encounters for some reason it can be increased (that said, I don't think the number of available encounters I've created so far is enough to support a higher prevalence while maintaining each Garrison's unique feel).

Some Cogmind maps have a 100% usage rate, though the circumstances are different in those cases, for example caves being populated by a much higher number of fluff encounters to add to their character. Others have very low rates like Access (10%), being a huge map with wide corridors and large machines, designed for lots of open space and more predictable content.


RIF Installers
Back when I added a proper bothacking system to Cogmind, creating RIF Installers and inserting them in Garrisons for both lore reasons and in a bid to increase the map's relevance, they were always placed adjacent to a random entrance/exit, since by design the Garrison prefabs always left some open space in those areas.

Having introduced encounters, this method was no longer reliable as these locations might now be occupied by other rooms in some or theoretically even all cases. Certainly one option would be to reserve the necessary area in advance, but that wasn't very compatible with the existing architecture, and there was an even more enticing and natural idea in this case anyway: put RIF Installers into the encounter system, too!

RIF Installers were already a prefab to begin with, one which (without precedent anywhere else in the game) were actually inserted via a separate hard-coded method, so let's add it as an encounter instead. Of course this change comes with significant balance repercussions, which we'll cover when we get to discussing that topic further below.

RIF Installer locations just potentially got a lot more interesting...

After implementing all the encounters, I went back and added them to my original Garrison content summary tool, primarily looking to ensure that RIF Installers were indeed being included everywhere as expected, though notice that even this earliest Garrison is quite stacked compared to before (again, excludes standard content like the normal Relays and their Coupler contents):

Sample Garrison content list from Beta 12.

(continued in next post...)