Infowar Expanded

Stealth plays a role in most Cogmind runs, with the degree varying all the way from “maybe I’ll dodge this one patrol until I’m in a better position to siege up” to “I am ninja.” To best support a variety of play styles in that regard, we need a range of systems and utilities built for information warfare, of which stealth is one aspect.

Many years ago prior to Cogmind’s Alpha 1 release I wrote about related topics like robot sensors, visual sensors, terrain scanners, structural scanners, hacking, intel and others. Now it’s time for even more!

I haven’t yet covered this here on the blog, but Cogmind’s next update (Beta 11) is taking years of play experience, feedback, and observations into consideration for a comprehensive review of the many items and their stats with an eye towards readjusting a variety of aspects to create an even more balanced and fun game full of interesting decisions and trade offs. A number of values need to be reevaluated in the light of all the changes and (especially) tons of additions that have been made in the years since 2012.

We’ll be getting to other related topics later (here now), but for now as a backdrop to this article I’ll just say that one side effect of a particularly significant change already confirmed is that player builds will on average have a greater number of utility slots to play with! This shift suggests we’re going to also want an even greater variety of useful and generally available utilities, otherwise there’s a decent risk that more builds will start to look alike. Plus of course it’s nice to simply have more options when coming up with builds, tactics, and strategies :)

New Structural Scanners… Trap Scanners… Machine Analyzers… Bring on the infowar!

Sensor Ranges

We begin this story like every good story, with a nerf.

The longest-range sensors, which have allowed you to detect robots up to 30 cells away, are being reduced to a range of 20. This is a sizeable reduction, establishing a trend we can trace back to the 7DRL in 2012.

For the 7DRL utility stats I wanted meaningful steps you could really feel as you upgraded to new parts, and the original set of sensor array ranges stretched from the weakest one at only 5 (!) to the best at 50 (!).  Throughout Alpha and Beta the set of ranges has gradually tightened to make high-end sensors less OP and low-end sensors actually useful sometimes, landing us with a less extreme improvement of 14 to 20 range over the course of a run in Beta 11.

Diagram comparing minimum and maximum sensor array ranges at points across Cogmind’s development (open for full size).

So technically we have a nerf at the high end and several buffs at the low end, though at the same time these changes also give Watchers a bit of extra range within which they can jam Cogmind’s sensors (which they do with their own array based on its range), therefore increasing the challenge when they’re nearby.

Particularly with sensors I think it’s important to shift away from the 7DRL design of noticeable steps and instead ensure that 1) all of them are at least helpful to some degree, and 2) losing a really good one does not feel quite so bad or seriously cripple a run (Watchers can be salvaged for their decent arrays, which are no longer much worse than the best option available). This is a better approach for what can be such an integral component of many builds and strategies.

20 range is still quite good, allowing one to know about robots in all the adjacent corridors and rooms (or even further depending on the layout), and setting the maximum benefit to that distance also does a good job of balancing sensor arrays against visual sensors to make the latter even more interesting in straightaways since the best of them can increase sight range to 24, so slightly further out (alongside their other unique properties).

Now where did that shot come from?! (art by the great roguelike concept artist Zyalin!)

Structural Scanner

The Structural Scanner is probably the most changed item across Cogmind’s development history, having been mentioned in the version changelogs 11 times already… but that isn’t even its final form!

The first iteration, available from Alpha 1, had one function and a simple description: “Scans all visible walls for signs of hidden doorways.” By Alpha 14 that became:

Scans all visible walls for signs of hidden doorways, determines whether an explosive machine has been destabilized and how long until detonation, and provides a 2% chance to detect each hidden trap within field of view (the latter is checked each turn on a per-trap basis, and stacks). Also highlights areas that will soon cave in due to instability even without further stimulation.

The reason for the evolution was that it was originally of questionable usefulness as far as taking up a utility slot goes (so few players would ever use it), that and I wanted to add a way to obtain other bits of info but didn’t have another suitable part to put those on (which themselves would be even less desirable).

Still some people even laughed at Structural Scanners as useless, but at the same time at least a portion of players reported they found them compatible with their build style. To me this is the best place for a part’s balance to reside, right in that sweet spot where players are divided over its usefulness. In that sense I was satisfied with the state of the Structural Scanner, but it’s changing yet again!

For one, reducing its variety of features would bring it closer to my original vision for Cogmind, that each part only has a single function, while a build is the composite of those functions, rather than complicating things by also giving multiple functions to individual parts. But more pertinent to current developments, an increase in free utility slots on many builds plus the desire to add more types of infowar utilities means we can attempt to focus the Structural Scanner on a smaller but still useful feature set while splitting off some of its functionality into other new parts.

As per the description above, over time the Structural Scanner gained abilities related to terrain, traps, and machines, and the goal here is to reduce that to terrain only. The new description (emphasis added):

Scans all visible walls to analyze the structure behind them and identify hidden doorways. Also highlights areas that will soon cave in due to instability even without further stimulation.

Basically this modifies the FOV algorithm to also identify any unseen cells adjacent to visible solid cells, so basically “seeing” one layer of terrain just behind all doors, walls, and earth.

New Structural Scanner behavior revealing terrain behind solid walls.

This is similar to Terrain Scanners, but without any additional depth and therefore entirely focused on finding adjacent rooms and hidden corridors, which is a fairly common use of Terrain Scanners (or poking/shooting walls :P), seeking out ways to make alternate paths through the map layout for more efficient exploration, to circumvent hostiles, or for some other purpose.

However, Structural Scanners operate instantly whenever FOV is updated, unlike Terrain Scanners which take time to gather their data, so the two types of parts each have their benefits and drawbacks. As such there will be builds and players who prefer one over the other depending on their strategy and other factors. Perfect :D

Trap Scanner

The first new utility to poach one of the Structural Scanner abilities is the Trap Scanner, which as designed so far does just what one might expect: detect traps--nothing more, nothing less.

As a part dedicated to a singular function it naturally needs to be more effective to make it worth the occupied utility slot, so the trap detection chance is increased to doubled to 4%, and unlike the Structural Scanner there are actually multiple tiers beyond the base model, including at best a 20% detection rate, which is almost guaranteed to pretty quickly reveal traps that remain in view, especially considering that a lot of traps are found in groups and therefore if you see one there are likely more nearby to be wary of. Note that the 20% variant is an outlier, and the more easily acquired ones provide a 4-8% chance, although even an 8% chance is fairly reliable.

Activating a Trap Scanner. Of course utilities need to have their activation animated ;)

Machine Analyzer

The Trap Scanner didn’t take long to implement (aside from having to put together a new animation); not so with the Machine Analyzer which took ages…

Of course it was quick to transfer over the Structural Scanner’s ability to detect and report on machine destabilization:

Now it’s the Machine Analyzer that can tell whether an explosive machine has been destabilized and when it will blow.

But that’s not new, nor is it sufficient to justify spending a slot on it…

What is new is using a utility to discover nearby machines and those elsewhere on the map! A Machine Analyzer reveals the entirety of a machine as soon as you spot any piece of it, and more importantly, reveals others machine linked to that one--this means both machines in the local area as well as one or more other groups of machines elsewhere on the map, probably but not necessarily nearby.

In Cogmind, knowing machine locations provides a number of advantages:

• Placement of machines suggests where rooms or open areas are located
• Interactive machines generally come with useful features, and the machine group linking system specifically enables you to follow them like bread crumbs--locate one Terminal and another likely nearby Terminal is revealed, giving another near-term goal
• Find nearby explosive machines that could be used for tactical purposes

Again similar information can also be obtained via terrain scanning, but:

• Good terrain scanning requires two utility slots
• Scanning takes time, whereas spotting a machine and analyzing it is instantaneous
• Can also potentially learn about machines that are much further away than even scanning is likely to find

On the reverse side, some reasons to prefer actual terrain scanning over machine analysis:

• Machine Analyzers aren’t as consistently reliable for info--they only work in the main complex, and won’t help in areas that happen to have few or no machines
• They only dig up machine info rather than other terrain layout knowledge, which comes in handy in other ways

In the end some players are no doubt going to really like this utility.

Exploring with an active Machine Analyzer.

Machine discoveries are also reported to the log, by default only listing any new interactive machines because otherwise the list is simply too long and updating too frequent (but I did add an advanced config option to enable the full list of all machines if someone really wants it :P).

Machine Groups

Clearly crucial to the whole idea of analyzing machine networks is exactly how are these links formed?

Figuring out the best approach was quite challenging, since it would require an algorithm to derive the links from the existing map layout and machine positioning, and on the outside I wanted it to make some sense as well as be useful, but not outright too good. I wrote pages and pages of notes on the possibilities before finally coming up with a workable concept.

First of all, note that machine groups technically have no meaningful connection to one another for the purposes of other mechanics or systems--this is purely for intel purposes, simulating behind-the-scenes networks presumed to exist, but here only as a form of data.

The process to form and connect groups:

1. All machines in a single room or hall belong to the same group, and any interactive machine in a corridor junction or embedded in a wall forms its own group. (For an understanding of concepts like “room” and “hall” as they relate machine placement, years ago I wrote about them in the context of procedural generation.) The group system (and therefore extent of the Machine Analyzer’s usefulness) does not extend to prefab machines or those local systems which by the lore are isolated from other machine systems (e.g. door terminals).
2. Randomly order all machine groups.
3. Go through each group establishing link(s) to others, where if it’s a group containing an interactive machine* it automatically links to the nearest interactive group of the same type that it’s not already linked to, and regardless of whether the group is already linked with another, each group also always links to the nearest other machine group it’s not already connected to. This guarantees at least some knowledge of nearby machines, maybe more. (*Based on the rules used to generate Cogmind maps, it’s impossible for a group formed using the Step 1 above to contain more than one interactive machine, if any.)

All links are bidirectional, meaning that seeing a group at either end of a given link reveals the corresponding group at the other end.

Partially destroyed groups are revealed as normal, unless a group’s “representative machine” is damaged. The so-called representative machine is always the group’s interactive machine if it has one (otherwise it’s chosen at random) and also serves as the machine used to visually link to other groups on the map.

Machine groups are seed dependent, so consistent in that regard.

Before adding the real utility functionality, I first needed to build the groups and then a debugging visualizer to make sure they were actually working as intended. Visualizer was a good idea, because yeah there were bugs and it wasn’t always easy to figure out what was up xD

One of the early debug views for color coding different machine groups, which are clearly not working very well here for some reason…

Eventually I got it working and the visualizer could also show the links themselves, which connect representative machines via direct lines if aligned along an axis, or by turning one corner.

Debug view of machine group links and group IDs which came in handy for tracking down elusive bugs.

Animation

Once that was working and the part itself was linked into this system, it was time to animate things.

You’ve already seen the machine-and-link reveal animation in the earlier demo above, but it’s kinda fun to see where it started out. The premise: I’ve never really done any super multicolored effects in Cogmind, and it seemed like a good opportunity to try that out here, especially since I think it can go well with the concept of “calculating” something (further emphasized by the accompanying sfx).

Shifting monochrome shades would work, too, but if subtle it could incorporate more colors and perhaps be more fun for it…

It did not start out subtle :P. The effect here is obviously way too over the top and distracting to be included in this form--at the time I was just making sure the HSV noise generation technique would work, and do the necessary tweaking later.

Later I changed the rate of the color shifting and darkened it appropriately so it wouldn’t be so obnoxious while moving around repeatedly revealing machines.

The Machine Analyzer also has an animated toggle, which simply does the usual reveal animation for any and all groups connected to currently visible machines.

More cool Beta 11 features to come!

Update 210802: Well, apparently we weren’t quite done with the infowar in this build--meet the Active Sensor Suite, the gateway to desire path data visualization and more!