Development Blog

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. (You can read more about the underpinnings of Cogmind’s early low-level balance in my article from the pre-alpha days.)

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.

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:

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.

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 ;)