Official development blog

Design Overhaul 3: Damage Types and Criticals

With fundamentals like storage and propulsion out of the way, it’s time to turn our attention to weapons! Originally there weren’t any plans for sweeping updates to weapons and I just wanted to rebalance them in a few areas, but as you’ll see here, a few smaller ideas ended up snowballing into something decidedly bigger…

Damage Types

To set the stage, let’s first do a quick overview of the state of damage types as of Beta 10. Cogmind has nine damage types, each with their own common properties:

  • Kinetic (KI): Ballistic weapons generally have a longer effective range and higher chance of critical strike, but suffer from less predictable damage and high recoil. Kinetic cannon hits also have a chance to cause knockback depending on damage, range, and size of the target.
  • Thermal (TH): Thermal weapons generally have a shorter effective range, but benefit from a more easily predictable damage potential and little or no recoil. Thermal damage also generally transfers heat to the target, and may cause meltdowns in hot enough targets.
  • Explosive (EX): While powerful, explosives generally spread damage across each target in the area of effect, dividing damage into 1~3 chunks before affecting a robot, where each chunk selects its own target part (though they may overlap). Explosions also significantly tend to reduce the amount of salvage remaining after destroying a target.
  • Electromagnetic (EM): EM weapons have less of an impact on integrity, but are capable of corrupting a target’s computer systems. Anywhere from 50 to 150% of damage done is also applied as system corruption, automatically maximized on a critical hit. EM-based explosions only deal half damage to inactive items lying on the ground.
  • Impact (I): Impact melee weapons have a damage-equivalent chance to cause knockback, and while incapable of a critical strike, they ignore coverage and are effective at destroying fragile systems. For every component crushed by an impact, its owner’s system is significantly corrupted (+25-150%), though electromagnetic resistance can help mitigate this effect.
  • Slashing (S): Slashing melee weapons are generally very damaging, and can even sever components from a target without destroying them (damage/3% chance).
  • Piercing (P): Piercing melee weapons achieve critical strikes more often, are more likely to hit a robot’s core (doubles core exposure value in hit location calculations), and get double the melee momentum damage bonus.
  • (the remaining two excluded from this discussion are rarer special types used by certain factions)

[Reminder: The above descriptions are based on Beta 10.2--some of these factors are now changing!]

As you can see from the descriptions, damage types don’t always have many unique properties of their own, but are in part or entirely defined by the class of weapons that inflict that type of damage.

Before starting work on Beta 11 I put together a chart summarizing the primary four damage types, comparing them across a variety of categories (the other three melee-oriented types are less directly comparable since they’re used in very different contexts, and on a more limited basis):

Cogmind Beta 10 Primary Damage Type Comparison

Comparison of primary Beta 10 damage types.

The purpose of the chart was to force me to think of what color to assign each box and why, not only perhaps helping to visually identify areas that might be reasonable targets for rebalancing, but also as a tool to provide semi-quantifiable supporting evidence for buffing or nerfing a given damage type.

Of course this approach paints weapon types in fairly broad strokes, and although they were designed that way, such that weapons of a given category will generally have somewhat predictable properties around which one can build with some consistency, there will always be exceptional subtypes within each category that don’t fit the same characterization. For example Hypervelocity kinetic weapons would have quite a different color scheme if given their own column, but they are a relatively small minority and of secondary concern here since they have their own pretty clear balancing factors.

Also in some cases a box could go one way or another depending on the situation, for example EM resistance where one could argue red is an appropriate color since many of the most challenging enemies are highly resistant or even outright immune to it, but against other robots it completely circumvents most defenses and armor to reliably kill targets, also reducing their effectiveness in the process.

There are too many unrepresented nuances for the precise “sum” of each column to be especially helpful on its own, though it will be interesting to compare any relative shifts when we look at the chart again later.

Nerfing EM

Although not really reflected in the chart considering it has the second-lowest “sum” (negative even!), due to the unique mechanics of electromagnetic damage it has always been somewhat overpowered, especially (but not only) in AOE form. Sure it’s not really usable against the most dangerous enemies, but you just need to carry around alternative parts for situations like that and rely on EM to solve most every other problem pretty handily! So an EM nerf has always been inevitable, but at the same time very challenging to pull off so I never moved on it for a long time. The time is now.

The goal is not to nerf it into the ground or anything, just improve EM weapon balance so that this particular damage type isn’t so clearly superior over others in a majority of cases.

The first nerf (yeah there are several :P) was already implemented back in Beta 9, and therefore reflected in the chart above: Energy costs for EM weapons were doubled across the board. I think this has worked out pretty well and had the desired impact, requiring more supporting energy and making sudden or sustained EM combat more difficult, or at least increases the preparatory requirements for doing it. However, increasing the cost in terms of an unlimited resource (as opposed to matter) still doesn’t directly address the advantages of having a class of weapon that can not only bypass most enemy defenses but also tend to create more salvageable parts.

Now obviously the easiest way to nerf a mechanic is to outright weaken it, reducing its raw ability to do what it already does, but power reduction is boring and best avoided if possible, so I kept resisting that approach and for weeks tried to come up with alternatives. Like I said, hard to balance xD

We don’t need a weaker EM effect, what we need are more trade-offs for using EM weapons, trade-offs that specifically target some of the reasons players use it, basically new mechanics that increase the challenge of using EM without making players not want to use it at all (which is what weakening it would do).

Enter: Corrupted parts.

Cogmind Corrupted Part State

Corrupted status?!

One of the big reasons for using EM weapons is that they’re good for getting usable (non-device/processor-type) salvage from targets, and we want to keep that feature, but how could it be altered in a way that adds interesting trade-offs?

In hindsight it seems obvious, but there were lots of other ideas floated which just didn’t work, or didn’t make sense, and this one both works and makes sense: Corrupted bots (those that die to corruption, or were partially corrupted then destroyed by something else) often drop corrupted salvage, and attaching corrupted parts increases Cogmind’s system corruption. It’s no small amount of corruption, either (the precise value is dependent on the bot’s original corruption level, and of course somewhat randomized), so attaching these parts means having to deal with any of a number of side effects (if you’re not familiar with system corruption I wrote about this a bit in my old article The Importance of Roguelike Food Clocks).

Cogmind EM Damage Corrupting Salvage

Corrupting salvage via EM damage.

Corruption alone is not run-ending, so the player has a choice to risk managing these side effects in order to immediately take advantage of EM salvage, or saving corrupted parts for later when they have an opportunity to remove the corruption. Thus relying on EM weapons makes it less likely you’ll have access to many spare parts in the near-term, or that immediately using newly-acquired powerful tools will come with an added cost. Saving corrupted parts for later adds inventory pressure by taking up valuable space, especially for players who want to do their corrupt part attaching shortly before reaching an interval where they can clear their corruption immediately, and have to carry the parts until then, whenever that may be…

Cogmind Corrupted Inventory Parts

Corrupted parts in inventory, where they also have a unique color and carry the “Corrupted” prefix.

 

Cogmind Corrupted Part Attach Animation

As a reminder, attaching a corrupted part also comes with an extra animation.

Anecdotally based on both my own experiences and that of players testing out the prerelease, this mechanic is working quite nicely--definitely still worth using EM, but also generally more challenging :D

Another common use for EM weapons is reliably downing huge groups of enemies with one of the powerful launchers, creating huge amounts of salvageable material in the process. The salvage part is already balanced via the corruption mechanic, in fact even more so because launchers also increase the corruption of parts sitting on the ground! But another mechanic was introduced here to add some amount of risk to using this tactic at point-blank range while ignoring the lower levels of corruption this causes the player/Cogmind itself: Being hit by specifically AOE EM damage allows for the spectrum-induced effect to cause a chain reaction in Cogmind’s power source, blowing it up.

Unlike Cogmind using EM on other targets it doesn’t apply to being hit by regular direct-fire EM weapons, since that’s a bit too common and would be seen as unfair. This pretty much just targets the player (since enemies don’t really use this type of weapon), and overall it won’t come into play all that often across runs, I’m sure, mainly added either for fun or to make players less likely to repeatedly use this particular tactic.

Aside from strategic options to reduce the impact of these EM-related mechanics on a particular build, technically Power Shielding protects against the chain reaction effect so there is a way to negate that if so inclined, and if lucky there’s also a unique part which prevents any corruption gain from integrating a corrupted part, but it’s only found in the late game (if available at all).

With this I think we’re probably done with EM. It’s in good shape. Now it’s time to buff something else…

Kinetic Cannons

Kinetic cannons have always been tough to build around. They’re a very appealing weapon type for their cool factor and ability to blow bots to pieces (even at very long range if desired), but they have so many drawbacks that they’re really hard to use for any sort of sustained combat. They have high recoil, overheat after a while, require large amounts of matter to keep firing, and worst of all don’t leave much left of a target by the time they’re done with it. As such, kinetic cannons generally require a disproportionately large ratio of supporting utilities and resources to keep them in action compared to other weapons, and while they nearly always seem really great at first, more than one run (of my own, not to mention others!) has suddenly gone south simply due to the high costs and negative feedback loop of using them xD

Like with EM we do want interesting trade-offs for using a particular weapon type, but too much is too much, so clearly we need to pare back one or more of these drawbacks.

I decided to first attack this issue from the matter resource angle. But instead of outright reducing the costs or reducing their effect on salvage, neither of which are really in line with their nature (and also kinda boring), I came up with a more interesting alternative: Shooting a target with kinetic cannon projectiles blasts some amount of matter onto the ground near/behind them with each shot.

Cogmind Kinetic Cannons Blasting Matter

Using a kinetic cannon to shoot matter off targets.

The formula determining the amount of matter is based on the weapon’s negative salvage modifier, meaning the attacker basically always has a chance to retrieve a certain ratio of the matter used to attack the target, although never the full amount (technically being shot by enemy kinetic cannons also has this same effect!). The difference can be made up via matter filters or acquiring matter from other sources as usual, and the matter blast ratio can be tweaked as necessary, though based on my testing it seems pretty balanced at the moment. Either way, this new mechanic has a noticeable effect since hitting robots with kinetic cannons otherwise leaves little to no salvage.

It’s also neat that you can technically even acquire the matter while still fighting enemies by using a Tractor Beam, so there’s that synergy (which already existed before, but is now even stronger). Without taking advantage of that option (or if too far away to collect), one of the new challenges/trade-offs comes into play in that you may have to move around to collect the matter, which costs time and may not be feasible until the fighting is over.

While designing the blast matter mechanic I did somewhat mitigate the number of required collection destinations by having each blast be more likely to drop matter on locations in the area already containing matter, not to mention this is pretty important for keeping a KI cannon battleground from being completely filled with matter and leaving no space for other parts to drop! I mean filling an area with matter is cool and all, but Cogmind’s one-part-per-cell UI restriction could cause KI cannon builds to have a pretty significant impact on the lootscape.

This wasn’t enough for me. Kinetic cannons still needed a little something more, something also aimed at counteracting their negative salvage modifier in an interesting way. The idea was to give KI damage yet another special side effect on cannons, allowing them to sometimes blast parts clean off the target so that even though the majority of parts still wouldn’t drop normally once a robot is destroyed, 1) at least something useful might be knocked off beforehand, and 2) as far as the enemy is concerned that part is “destroyed” since they can no longer reattach it for use anyway.

Cogmind Kinetic Cannon Blast Critical Effect

Say goodbye to those Light Treads! You can’t use them anymore, but I might grab them later…

Even better, the second part damaged and knocked to the ground is different from the one actually hit--when this effect applies it blasts off a separate part based on slot-wise impact rules rather than coverage, making this side effect that much more effective since it affects two parts (and ensures the dropped part is in a better state in case the player wants it).

So what stat is this blasting effect attached to? Well it was originally envisioned as a side effect of the damage type, only applying to cannons and only on a critical strike, somewhat similar to how slashing damage can sever parts (but with more limitations…), then I realized this would add yet more opaqueness to the system, and there’s a much, much better solution here: Let’s instead use this opportunity to add a variety of critical effects, part blasting being just one of them!

Critical Strikes

Ever since the 2012 7DRL, Cogmind only ever had one type of critical strike across all weapon types, with a high chance on some, low on others, and many more incapable of causing a critical hit. If it procs, it simply destroys the target part (or robot if it hits a core), regardless of integrity or damage amount. As with any additional stat this provides another lever to differentiate weapons, at the extreme end even creating a unique range of Hypervelocity weapons with very low damage but much higher crit chance.

But while working on the kinetic cannon design I noticed that the desired effect would be better off as a separate type of critical strike altogether, more clearly signaling to the player that it’s something different rather than making it an essentially hidden side effect of a regular critical like I originally imagined. And if we’re going to add a new critical type here, this means we can do a bunch more criticals for other weapons to give us even more design levers for further differentiation, greater variation, better balance, more nuance, and of course more fun, too…

Cue lots of brainstorming--this whole kinetic thing snowballed into something much bigger :P

By the end I chose 12 different critical effects that could be used to tweak weapon balance, potentially give more room for build creativity, and lead to interesting tactical situations:

  • Burn: Significantly increase heat transfer (TH guns)
  • Meltdown: Instantly melt target bot regardless of what part was hit (TH cannons)
  • Destroy: Destroy part/core outright (= the original critical effect) (KI guns)
  • Blast: Also damage a second part and knock it off target, as described above (KI cannons)
  • Corrupt: Maximize system corruption effect (EM guns/cannons)
  • Smash: As Destroy, but gets to also apply an equal amount of damage as overflow damage (impact weapons)
  • Sever: Sever target part, or if hit core also damages and severs a different part (slashing weapons)
  • Puncture: Half of damage automatically transferred to core (piercing weapons)
  • (there are four other crit types associated with the special damage types not covered in this article: Detonate, Sunder, Intensity, and Phase)

As you can see above, critical types are for the most part intended to be associated with a particular category of weapons, both for logical reasons and to aid familiarity. In most cases we have different effects for each damage type, as well as for guns vs. cannons.

In a few cases we will need to make exceptions, however, so by necessity the critical effect type is set on a per-weapon basis. To bring up the Hypervelocity KI cannon example again, it wouldn’t make sense for them to have the Blast critical (and would also significantly imbalance them), so they instead continue to use the original Destroy critical effect.

Also a given weapon might still have no associated critical effect, although that situation is less common now that we have a variety of types to choose from, especially as they’re designed to be appropriate for each base weapon type. Like in previous versions almost no thermal weapons ever had a critical effect since that was originally a mechanic added primarily to differentiate kinetic weapons, but now that we have the Burn and Meltdown criticals almost every thermal weapon may have an effect, too!

Cogmind Thermal Cannon Meltdown Context Help

TH cannon Meltdown context help.

Naturally as part of this new system every single weapon needed to be revisited to consider its critical effect and the chance to proc, so there was lots to do in terms of rethinking stats. One important factor to keep in mind throughout this process is that these are meant to be at least somewhat special when they occur, the exception rather than the rule, so I wanted to keep the percentages relatively low. In some cases by the end I had gone back to readjust the actual effect itself to be appropriately powered for something that happens with lower frequency.

Theoretically a potential new positive side effect from these criticals is that new build styles could emerge based on evolving extra weapon slots in order to stack critical effects. Although increasing the variety of crit-stacking builds was not a primary goal behind these mechanics, I did have to take that possibility into account since if it’s beneficial to stack them then of course players are going to do that, especially if such a strategy turns out to be OP ;)

One crit of note in terms of design is the “Sever” effect, which was originally a side effect of slashing damage (using the formula mentioned earlier, damage/3%), but rather than having yet another separate effect tied to this weapon type, the crit expansion was a good opportunity to both make it more obvious and decouple the effect from damage, which is otherwise sometimes limiting when it comes to weapon design, as the ability to sever is then always tied to the amount of damage dealt. Now it can be a separate static value that’s easier to control for, naturally at the cost of somewhat nerfing slashing weapons where it was possible to increase raw damage (and therefore severing chance) via momentum or other buffs.

Crit Immunities

The original critical system was quite simple, as described, and in the early alpha days (2015) stacking kinetic guns capable of dealing damage as well as Destroy criticals was so powerful that eventually some important robots like NPCs became completely immune to critical destruction. This was a pretty heavy-handed nerf that basically killed off the crit stack build among serious players since it couldn’t be used to take on the most challenging enemies.

More recently the crit stack build was once again made viable by compromising with two levels of immunity: total Critical immunity (or once again immunity to all critical effects--used rarely and only very special cases) and Coring immunity, which applied to most of the aforementioned NPCs/challenging bots so that at least they couldn’t be outright destroyed by a crit against their core, but you could still happily use a crit stack build to strip them clean. This worked out pretty well and suddenly crit stacks were back on the menu :)

But now we’ve got a bunch of new critical effects other than simply Destroy, so what to do with the immunity system?

I certainly wanted to avoid creating an overly complex set of immunity rules, though it at least turns out there wasn’t a need for additional immunities, just mainly a need to get more specific with regard to the Coring immunity. It now has to explicitly list the types of effects it provides immunity against, naturally anything attempting to directly affect a robot core, including Destroy, Blast, Smash, Puncture, and Phase.

Cogmind Coring Immunity Context Help

Coring immunity context help.

Also some separate existing immunities apply where logical, like the Dismemberment immunity of course blocks the Sever critical (as it used to block the slashing damage sever effect), and Meltdown immunity protects against… Meltdowns :P (which are now a critical found on TH cannons, but already existed before due to heat transfer buildup)

Crit Messaging

Another new issue surrounding critical effects involves log messages. Now that almost every weapon has one (and sometimes a single crit has multiple effects!), critical messages are going to become more common, but we only have six lines in the main message log and don’t want that to get too clogged up.

One important change here was to only report critical hits if actually applied to the target, whereas before in order to provide feedback to the effect of “technically a critical strike roll just passed” it would always show regardless of later not applying due to the defender’s shielding, immunities, or for some other reason.

Now that the crit shielding situation is a bit more complex, I also felt it was important and useful to report crit blocking results, but didn’t want to clog up the regular log with that info, so I instead have it reporting to the full detail combat log where players interested in all the little details from a combat encounter will be looking for that sort of thing anyway.

Cogmind Combat Log Reporting Critical Shielding

Combat log reporting that a target was shielded from the Gauss Cannon’s critical Blast effect.

Most importantly, because critical effects can sometimes have a significant impact on the course of a fight, I wanted them to be reported directly on the map so that looking at the log doesn’t become a necessity (as per standard Cogmind’s design). Previously we only had the Destroy effect, which simply piggy-backed on the part loss popup label, but now we’ve got a bunch of new ones which players are going to want to see when and where they’re taking effect. So those now also show directly on the map, in a new color.

Cogmind Critical Effect Popups

Sampling some of the possible critical effect popups.

One exception is the Burn crit, which tends to have a higher proc chance than others, and many robots use thermal guns, so to avoid too much “Burn popup spam” on the map, those don’t actually start appearing unless the target is already getting hot and it might start to impact the outcome of the fight because they’re going to overheat, melt or at least have trouble aiming.

All of the critical mechanics have been implemented and I’ve been streaming my first run with them, in particular later on relying mostly on KI cannons to enjoy their newfound matter sustainability and the Burst crits:

Hooray for sustainable KI cannon combat! \o/

Damage Types Revisited

With all that behind us, it’s time to take another look at the damage chart from earlier after applying the Beta 11 changes.

Cogmind Damage Type Characteristics, Beta 10 vs 11

Comparing damage type characteristics in Beta 10 vs 11. Changed boxes have a bold outline for emphasis.

In summary, we got rid of three red boxes (KI/TH buffs) and one green (nerfed EM), turning them all gray. Ignoring explosive damage since nothing changed there, let’s examine the other columns…

Kinetic

Interestingly, KI damage originally had the highest sum of any column, and technically was already a pretty good damage type, but still ended up getting buffed because although guns were great (and remain unchanged here), the cannon situation was dragging down the damage type, and that’s no longer the case due to the matter mechanic changes. I left the salvage factor unchanged since even though cannons blasting off parts is now a thing, that’s not a significant source of salvage in itself and negative kinetic salvage modifiers are as savage as ever.

Thermal

The biggest sum change among the damage types is TH. Although as I’ve said these sums aren’t great for comparison between damage types, the original -3 did kinda stand out and reflected reasons players tend to shy away from thermal weapons except in special cases, so there was definitely room for adjustment there.

Thermal weapons were by design excluded from the old crit system, but with our newly expanded system most of them got their own effects which potentially make thermal weapon stacks more viable now.

In terms of impact on TH viability though, that change is secondary to the even more fundamental stat adjustments coming in Beta 11: Thermal weapon integrity is significantly increased alongside a reduction in coverage. They’re still not as sturdy as kinetic weapons, but no longer so weak as to fall apart easily, while balancing their reduced integrity against a lower chance to be damaged in the first place assuming other sources of coverage like armor, thus helping carve them out a bit of a separate niche here.

Thermal weapon integrity was especially low as far as projectile weapons go, based on assumptions made way back during 7DRL 2012 work and never revisited since, which is what a big part of this ongoing design overhaul is about, looking at many aspects of the game in a new light offered from years of play experience.

Thermal weapons are generally underutilized, and this will give them more staying power. We’ll see how it works out, since no one’s actually played with these new weapon stats seeing as I made the changes while writing this blog post and reexamining the chart along with my previous notes, AKA “development by blog post,” wherein things get done because I’m writing about them ;) (not unlike “development by streaming runs,” which get me adding features I want to play with, as well as reactively updating the game based on my own findings and experiences).

Electromagnetic

Funny enough, in the chart we see EM’s sum went from negative to even more negative, yet it’s still good, a testament to just how different its mechanics are compared to other damage types (and how hard it is to nerf well xD).

EM salvage is now gray since it’s no longer quite as useful in every situation given the corrupting effect, but still certainly not red since it’s still good for ensuring a larger raw amount of salvage in general.

Overall I think there could be more work to do in the area of damage types depending on the results of playtesting, but so far I’m quite satisfied with the results and everything’s definitely on the right track!

Part 4 in this series covers a rebalanced and expanded item and robot fabrication system which makes that feature somewhat more accessible to different build types.

Posted in Cogmind Beta Overhaul | Tagged , , , | Leave a comment

Design Overhaul 2: Propulsion

The previous design overhaul discussion covered storage capping and its changes to the core gameplay, but the first experimental build we played around with also included major changes to another even more fundamental aspect of any build: propulsion. Although not all of the experiments panned out in this case, after a number of revisions I think we’re in a better place.

Propulsion (commonly abbreviated as “prop” by the community) has undergone a number of fairly significant adjustments over the years, being rebalanced in response to various other changes, or more frequently in order to buff those types which were generally underutilized--wheels became a good choice for carrying excessive mass despite their other drawbacks, treads got siege mode, and legs and treads got huge integrity boosts, plus kicking and crushing (respectively).

Flight and hover also saw some smaller changes, though not to the degree necessary to reign in their existence somewhat outside the power curve of Cogmind, so it was about time to address those and bring them more in line with how they were originally envisioned given how expert players had been able to take advantage of them.

Flight and Hover

On the surface Beta 11 significantly nerfs airborne prop by dropping their mass support even further, though in some ways it’s really more of a rebalancing since resource costs were lowered at the same time.

cogmind_airborne_prop_stat_adjustment_graph_beta11

Base flight and hover stat progression, a comparison between Beta 10 and 11.

Values remain mostly unchanged in the early game, with the changes becoming more and more pronounced at higher ratings since the stats were adjusted via their rate of progression to prevent the best late-game airborne builds in particular from repeatedly becoming not only the fastest but also incredibly powerful by carrying heavy gear.

Speed alone gives a significant advantage in Cogmind, not to mention flight’s ability to hop over hostiles and escape or bypass almost any situation without fear of being boxed in, so it really shouldn’t also have access to some of the best direct combat setups.

Ideally, flight is hereby somewhat more restricted to a speedy stealth or hacker-type niche, and newly-nerfed hover can take over old-style combat flight builds, albeit at somewhat slower speeds and without the ability to hop. I say “somewhat” because even after the changes good players have proven it’s possible to put together some pretty powerful flight builds, just not quite as reliably or OP as before.

Of course with reduced mass support per unit there’s always the option to devote more slot evolutions to propulsion, thereby regaining some of what was lost, and although extra prop implies extra resource requirements to run them, it’s at least easier to do this due to flight’s lowered energy costs. Flight builds still won’t really get as heavy as they once were, or if they do the slot cost is much higher than before and such a build will be weaker in other areas overall.

Notice in the graph that I had to add decimals for this! This is actually one of the reasons why these sorts of adjustments to flight balance took so long to happen, because the relevant values were already too small to affect a different progression with whole numbers. I generally avoid using decimals on principle since they aren’t pretty or easy for players to calculate with, but finally had to bite the bullet here and reimplement a bunch of things to allow the game to accept these non-whole numbers… (almost all Cogmind code works with whole numbers). And all for a super simple set of 0.5, 1.0, and 1.5--no other weird numbers needed or used :P

The overall result is a more forgiving flight paradigm not quite as tightly balanced around having the best lightweight power generation available, so it’s a bit easier to get up and running so long as the goal isn’t to go for a heavy build (implying tons of prop slots). Thus although many players will view these changes as a big nerf, in the bigger picture they simply ensure that both hover and flight are further differentiated while better serving their intended niches.

Leg Upgrades

Speaking of niches, players have sometimes noted that legs don’t really have anything unique going for them.

This was intended, as legs are one of the most easily-acquired prop types with both decent integrity and middling speed (hence the recommendation that newer players use them), so I didn’t think they necessarily needed anything special, per se. But I eventually agreed that if we could find another effect suitable for them then it could be a worthwhile addition, especially since (as you’ll see further below) other changes in Beta 11 took away the only reason better players might opt to use them by choice (while overweight a triple-leg setup was still faster than treads).

Treads with their siege mode are already clearly the best direct combat option, so let’s further differentiate legs as the mobile combat option. They’re already somewhat faster than treads and therefore partway there, so what about another benefit while using that mobility during combat? Not in the same way as airborne prop, mind you, since raw leg speed isn’t nearly enough to benefit from that, but instead something more in terms of taking advantage of the potential for unpredictable movements while dodging attacks. So instead of basing it on speed, legs have modifiers based on current momentum. (Momentum in Cogmind is displayed on the HUD along with other movement info, increasing for each consecutive move in the same direction (up to 3), or -1 for moves in the same general direction, or resetting to 1 for moves in other directions.)

cogmind_hud_running_state

While moving (and therefore having momentum), the leg movement state in the HUD shows “Running” instead of the usual “Walking.” The current momentum there is 2.

For each level of leg momentum, shots against a robot* incur a -5% accuracy penalty, so the maximum penalty is 15% (*remember most mechanics, including these, affect all bots in the game, not just Cogmind!). Leg momentum also decreases accuracy of the moving bot by the same amount.

Some benefits of legs under this system:

  • The most useful advantage is the ability to somewhat more safely reposition under fire when a combat situation changes, for example new enemies approaching from a different direction, or an important wall was destroyed, or a need to immediately grab certain parts nearby, or because of a crucial change to one’s build due to damage or other circumstances, or really any number of other reasons to move while fighting.
  • Running into view of an enemy to initiate an attack (intentionally or not :P) at least has them open fire first while your evasion benefits are active, then you wait a moment to get your bearings and open fire with a much higher accuracy.
  • Legged melee builds, which at least in my experience are fun and pretty decent, take less damage while charging a target or retreating to safety during a ranged confrontation.
cogmind_zyalin_fan_art_derlict_on_legs

Even the derelicts know good legs when they see them (art by Zyalin).

As a bonus, players using legs to kick other bots out of the way also never take damage from the attempt. Earlier this required at least five legs for safety to be guaranteed, but that alone would never be reason enough for people to go with legs, and couldn’t even matter until relatively late in the game anyway.

Now we’ll definitely have some players opting to run non-overweight leg builds to complement their strategies. “Non-overweight” because the evasion bonus from running does not apply in that case ;). That said, I think we’ll see an even greater proportion of players trying to keep their builds underweight than before, anyway, due to other Beta 11 changes…

Overweight Penalties

Early in Beta 11 development there was an attempt to completely rethink Cogmind’s overweight mechanics, in particular the way exceeding a build’s mass support interacts with movement speed.

The basic idea was to switch from the original system of thresholds defined by how many multiples of a build’s mass support had been exceeded to instead find some kind of formula that would enable a more granular approach so that exceeding a threshold wouldn’t immediately have such a large impact on speed, and heavier builds on legs and treads would actually get progressively slower as they piled on more and more mass beyond their initial threshold.

Because on top of having five different prop types there are also so many potential combinations of slot counts and mass levels, even before building this new system I had to put together a ton of spreadsheets to test out reasonable values and formulas.

cogmind_propulsion_overweight_spreadsheet_experimental_curves

One of the early spreadsheets set up to easily see the effects of tweaking a set of core overweight values (open for full size).

Even with the spreadsheets it wasn’t easy to find an approach that would work without breaking everything, and at first I settled on a solution (depicted above, if you can decipher the chart…) that applies a single speed penalty on going overweight, as before, but after that includes a further speed reduction based on the amount of mass by which you exceed the threshold, rather than waiting to reach other thresholds.

The mass-speed relationship there was not linear, however, instead following an inverted exponential curve so that the effect is more pronounced earlier on and it gradually tapers off as a build’s mass grows. Although actually the opposite of what one might imagine should happen in reality, the point after all is to balance a game and in this case keep speeds within reason while still allowing for very heavy builds.

cogmind_propulsion_overweight_speed_mod_curves

Sample overweight curves for speed mods over excess mass.

Multiple iterations were tested, including a single overweight formula, and a separate formula for wheels so they could retain their unique overweight interaction, and strong consideration was given to even having formulas specific to each class of propulsion.

Well none of it quite worked :P

There were too many oddities or ways to take advantage of the mechanics (or builds broken by the changes), not all that surprising considering the entire game was designed around the original system devised in 2012, which I’ve always actually liked a fair bit for its simplicity and consistency. Compared to using formulas, clear thresholds are easier for players to grasp and work with.

In the end it’s again kinda funny because this big system change was actually a sort of overreaction to what triggered attention to this mechanic in the first place: mass no longer mattering as a factor to treads and legs once they exceeded the first threshold. This experiment was mainly answering the call of numerous players inquiring about a potential granular overweight system, so I thought we’d try it out for a bit. Too bad it turns out “experimenting with it for a bit” actually took a huge amount of time, both because it was a complicated undertaking and because repeated attempts all failed xD

So the final overweight changes in Beta 11 actually end up being a lot more tame and targeted, more or less keeping the original system, but with significantly greater threshold penalties for overweight legs and treads :P

cogmind_propulsion_overweight_spreadsheet

The final spreadsheet calculating speed modifiers based on Cogmind’s standard overweight threshold system (open for full size).

Overall due to the <no_stack> changes (and leg upgrades discussed earlier) I think more builds will start to lean towards being underweight anyway, either because they have more prop slots to play with (due to freeing up storage slots) or simply less mass support devoted to heavy Storage Units (since storage was usually the heaviest component of most builds).

Mass Support Utilities

A discussion of overweight propulsion and mass support isn’t quite complete without talking about the group of utilities that enable builds to increase their support threshold for a resource cost by allocating utility slots instead of just prop slots. Weight Redistribution Systems and their much more efficient high-rating kin are one of the main alternative ways especially faster builds could avoid going overweight (but without increasing speed which extra airborne prop would help with).

These have always been extremely problematic to balance against the normal propulsion mechanics--it’s pretty much impossible, in fact, given the nature of the systems involved, so despite multiple attempts to rework them throughout Cogmind’s history, it was finally about time to simply remove them…

However, players made some strong arguments for at least keeping them around in a no_stack capacity, which as discussed in the previous article is something I try to avoid whenever possible, but I do rather like the ability of mass support utilities to add a bit of flexibility to a build’s mass support via a utility slot (plus some of the other robot designs utilities these parts!), so we’ll go with that for now.

Sadly, gone are the days of powerful 2-slot flight builds.

cogmind_valguris_2slot_flight_extended_win_build

For posterity, here’s Valguris’ final 2-slot flight build from one of his Beta 8 double extended wins, as recorded in his scoresheet (see the full scoresheet here). It sports three mass support utilities among other crazy good parts. (Some item names might be minor spoilers.)

Part 3, now available, looks at further differentiating weapons with a wide variety of critical strikes, and other new related mechanics.

Posted in Cogmind Beta Overhaul | Tagged , | Leave a comment

Design Overhaul 1: Capping Inventory

Last time here on the blog we covered sensor changes and other new related utilities coming to Cogmind’s next major update. At the time I wrote:

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.

While many of the early design decisions established a good foundation that in a general sense has withstood the test of time by both attracting and holding the interest of many long-time players, and along the way the integration of new mechanics and content expansions certainly resulted in a number of retroactive adjustments to prior work to keep things more or less balanced, there’s never been a much wider review of the kind we’ve wanted to do since like… five years ago xD

Especially with regard to less vital parts of the game, there’s been an understanding in the community that one day they could one day all be addressed together as part of the “Great Utility Update” (so called because Cogmind’s largest category of items and many of those frequently discussed in balance/usefulness terms happen to be utilities), so lots of these kinds of things have piled up over the years.

With Cogmind basically done and preparing to embark on expansions definitely outside the realm of what was originally planned (see the 2020 ARG :P), Beta 11 is finally the time to do this big review.

But we’re not starting with the little stuff! On the contrary, if there are any significant balance changes to be made, those need to happen first, and it just so happens that some of these are indeed coming down the pipeline, somewhat unexpectedly, even…

Capping Inventory Capacity

One of the more fundamental design levers when it comes to utilities is whether or not their effect stacks when attaching multiple of the same type. Storage Units have always been stackable, meaning players who want to carry around even more spare parts (and don’t mind being overweight, because storage is heavy!) could just load up on extra Storage Units and fill them with salvage and looted parts. Among the better players, over time this feature clearly led to rampant inventory inflation, and we saw more and more superheavy storage-laden builds working their way through most of the game like that until they’d shed most or all of their storage and use the contents to assemble their ultimate build for the final stretch/extended game. Basically the safest play tended to be maximize inventory size for as long as possible, whatever players thought they could get away with depending on their build goals and how dangerous their chosen route might be along the way.

zyalin_cogmind_hauler_build

Zyalin‘s depiction of a storage-laden Cogmind build (in particular a bothacking RIF build, a topic we’ll get to later).

This whole approach is actually kinda anti-Cogmind, circumventing much of the “dynamically adapt to circumstances” aspect while being a significant drag on the build effectiveness and the experience in general (due to generally slower builds and more utility slots allocated to increasing storage capacity because spare parts are so valuable compared to using the slot for one other active part).

Either avoid most confrontations, or suffer from higher than average part attrition due to reduced effectiveness both in and out of combat while constantly cycling through replacement parts instead.

Other drawbacks of massive inventory growth start to appear as their size expands further beyond what the interface was designed to handle. The original GUI layout and functionality assumed that builds would generally have one or two pages of inventory content (or at most three), as it can only display up to 12 parts at once and allows interaction with 10 of them (equivalent to the 1~0 number keys). Then of course there are the players frequently running around with 5~6 pages of inventory (10 has happened before, too xD) and it becomes cumbersome to use on top of the weaker build resulting from having so many utility slots devoted to all those Storage Units.

cogmind_tone_104_inventory_capacity

Insane inventory capacity at work in the wild. This particular streamer’s late-game build had a total of 18 utility slots at the time, 10 of which were occupied by storage units xD (not to mention the focus on evolving utility slots meant having evolved nothing else).

Players being inventive and challenging themselves to work their way outside the bounds of a game’s design can be interesting, but less so if it’s a very easily triggered compulsive behavior like hoarding.

That’s not to say the goal here is to completely remove the potential for superheavy hauler builds--even in Beta 11 fairly large inventories will still be possible, but some kind of limitations would really help here and I believe 1) we do still need to tweak the cost-benefit equation when it comes to carrying an almost endless supply of parts, and 2) this can be done in a way that also keeps the game more fun by freeing up more utility slots for other purposes.

At the same time, I’m grateful for the period over which players did put a lot of pressure on the inventory management interface because it gave us QoL enhancements like swap functionality :)

cogmind_part_swap_menu_demo_both_directions

Demonstrating two of the many ways to swap parts in Cogmind.

So with a general consensus in the community that inventory capacities were getting out of hand, naturally the next step is to figure out what to do about it…

<no_stack> Storage Units

In the Balance Overhaul discussion thread on the forums, zxc repeated his outlandish suggestion to go with <no_stack> storage (referring to the in-game tag used to mark utilities that cannot be stacked). One might think that too extreme a change, and I was definitely in this camp from the beginning. For one I prefer to avoid no_stack whenever possible since it’s a very hard limitation, and that can mean somewhat less flexibility in terms of build variety, especially worrisome in this case due to how central the storage capacity element is to a build--to me the the ability to mix and match different types of Storage Units (or multiples of a certain type) to get just the right balance of mass and capacity seemed really important. But it can also be easy to overlook the fact that limitations in one area open up more opportunities elsewhere, particularly in this case as we get even more utility options (like the latest infowar set!).

A range of less extreme alternatives were proposed by other players, but I decided we could try some truly experimental patron builds featuring behaviors which might not actually make it into the official release, and if we’re going experimental, might as well go extreme to begin with and see how that feels before possibly dialing it back or examining other options in more detail.

Numbers

Taken in isolation, simply slapping no_stack behavior onto Storage Units does indeed seem way too radical and likely to both weaken many builds, but compensating with much greater capacity from a single unit as well as adding extra types to choose from resolves these issues nicely.

The main question here is of course what kind of inventory sizes are we targeting?

Somewhere around an inventory size of 20~25 seems reasonable for the average combat build--it’s a size I’m familiar with since I often go with that, and others agreed, so let’s let the Large and High-capacity units straddle that range and extrapolate from there. Altogether this results in only about two pages of inventory items, which is very reasonable to work with, and remember that concentrating this much storage into a single slot also frees up one or two extra utility slots for other uses, helping those existing inventory slots go the extra mile since increased build effectiveness somewhat reduces the need for spares.

Of course some builds might still like to carry more than that, which is fine, so under no_stack rules that would require adding some more options at the higher end which come with pretty hefty costs, namely both significantly higher mass and an additional slot.

After testing and tweaking, it turns out no_stack storage is a great improvement overall, and the final set is as follows:

cogmind_beta11_overhaul_nostack_storage_units

Beta 11 Storage Units reworked and expanded for compatibility with no_stack behavior.

As you can see there the naming system was shifted a bit, allowing all existing robot builds to continue using the same type of storage as before, good for both loadout familiarity as well as retaining names that feel more in line with each robot’s purpose as originally designed (mainly the non-combat varieties).

Numberwise, with the main series mass doubles for each linear increase in capacity, which is the same style of progression we had before except instead of focusing on +2 capacity per jump, the new number is +5. And because most builds will attach some type of Storage Unit, but Cogmind’s base inventory size has always been 4, to avoid creating a bunch of awkward inventory sizes like 9, 14, 19, 24 and so on, the base inventory size (the amount of storage with no additional units attached) was increased to 5. This makes any related mental calculations a bit easier.

Overall these changes to mean player power in the early- and mid-game are somewhat higher, but this is fine because it means we can more safely add more challenges there to compensate ;)

cogmind_cargo_storage_unit_artpng

Cargo Storage Unit art.

The most common question among players with regard to this type of inventory cap is “what about full RIF builds?!” (maybe sometimes with more exclamation marks? :P) Since we could always adjust the RIF system if necessary, this wasn’t even a concern for me going into the no_stack experiment--wait and see, right? That’s just one secondary system, after all, whereas the goal here was to first modify a core gameplay element. It’s an inevitable question, though, seeing as some RIF builds focus on hoarding a huge supply of spare couplers as their main source of power, and using them in smaller numbers doesn’t require the support of numerous other parts so there’s plenty of room for storage utilities.

Once no_stack was implemented I did a full RIF run to test it out, as well as listened to feedback from patrons doing the same, and surprisingly even without any other changes it was actually a better experience! Despite a reduction in total inventory capacity, without the excessive amount of storage myself and others might choose to attach, there was plenty more room for active Relay Couplers, couplers which 1) don’t need to occupy inventory space anyway and 2) can help deal with threats (especially when combined with RIF abilities, many of which rely on having a relevant active coupler in the first place). Plus of course optional room for other non-coupler parts, too, such as infowar, armor, or whatever you need…

cogmind_bothacker_pwning_garrison

More active couplers = more fun :D

The full run is archived on YouTube:

(Also remember this is just relevant to “full RIF” builds, whereas there are alternate RIF strategies that use only one or two types of couplers, or even none.)

Players will notice that the Lightpack unique item is not included in the storage chart above; this is because it will be balanced differently given its special origin. And there is also room for additional unique storage types, in fact even more so given that they’re no longer stackable, since the knowledge that they must be used in isolation rather than potentially in combination with other Storage Units makes more interesting designs possible.

As for acquisition, the new Huge type can be found in stockpiles, and while the new Cargo Storage Units are unlikely to be found just lying around, they can still be fabricated from schematics, or taken from from a new type of robot and dispatch coming to Beta 11.

Up next in part 2 is a significant flight and hover rebalance, leg upgrades, overweight penalty changes, and more…

Posted in Cogmind Beta Overhaul | Tagged , , | 4 Responses

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.

Cogmind Sensor Array Range Diagram (evolution during development)

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

Bot using a Sensor Array, by Zyalin

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.

Cogmind Structural Scanner Behavior Update: Scanning behind walls

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.

Cogmind Trap Scanner Activation Animation

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:

Cogmind Machine Analyzer Detecting Machine Destabilization and Countdown

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.

Cogmind Machine Analyzer Revealing Machines

Exploring with an active Machine Analyzer.

Cogmind Machine Analyzer Message Log Reporting

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

Cogmind Debugging Machine Groups

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.

Cogmind Machine Groups/Links Debug Visualization

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…

Cogmind Machine Group Reveal Animation - Early WIP Concepting

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.

Cogmind Machine Analyzer Toggle Animation

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!

Posted in Mechanics | Tagged , | 2 Responses

The Map Ruler (and other overlay QoL)

As the player’s gateway to accessing the experience they’re after when they want to play a game, building a fluid and comprehensive interface is essential. Many high-priority player needs should be apparent in the earliest stages of development, and help shape the entire foundation for an interface’s design, but still other needs with lower priority may only gradually become more obvious over time.

If you find that players are spending extra time doing a certain task that could be facilitated by improvements to the UI, then hopefully those improvements are feasible and there’s time/resources to add them! Honestly doing everything possible is unlikely--in a sufficiently complex game the list of possibilities seems almost endless, plus of course it has to be balanced against investing in other features.

I enjoy UI/UX work and recognize its importance, so naturally every release of Cogmind comes with its fair share of QoL features, and the huge upcoming release (Beta 11) is no different. In particular a collection of map overlay ideas has been building up in my notes over the years, so recently my tendency to work on related features in batches kicked in and several new options were born: a map ruler for measuring distances, a more powerful volley data visualizer, and robot FOV overlays…

Ruler Overlay

Roguelikes traditionally take place on a grid, and it’s not uncommon to need to know the distance to a location for the purposes of movement, magic, guns, abilities, etc.

Given the discrete grid, this info is generally not that hard for experienced players to visually estimate, although in cases where knowing precise distances is important for optimal decision-making and one miscalculation could mean the difference between a tactic’s success or failure, it’s much more efficient and reassuring if the game can just calculate and display the desired details. Computers are good at calculation, after all.

Previous versions of Cogmind have already contained some ways to use the UI to confirm distances in certain cases, like the Volley window active in targeting mode that constantly updates its range readout to indicate the distance between Cogmind and the cursor location on the map.

Cogmind Volley Window Rangefinder Demo

Showing the the volley window rangefinder distance readout (top right, “R=”).

However, since its introduction this has only ever actually worked with ranged volleys, so melee builds haven’t been able to take advantage of it for this purpose.

Attached weapons and utilities also display their range circle over the map if hovered over with the mouse, or in the latter case many utilities also animate their AOE during their toggle animation, meaning these other features can be used to at least indirectly measure distances, although this is fiddly at best. That said, in the past I’ve definitely relied on this design to help quickly calculate distances, another sign that we need some kind of dedicated “ruler” feature :P

Another argument for a dedicated ruler is that all the existing methods of using other UI features to measure distances assume you want the distance from Cogmind’s current position, when that may not be the case. In fact, many cases of wanting to count spaces arise from a desire to know the distance between two other arbitrary points. Like if I move to this particular coordinate will I be within range to shoot that other position? Or once I reach a certain location, how many more spaces is it (and therefore how long will it be) before I can cross over to another spot?

Enter the new ruler overlay:

Cogmind Map Ruler Overlay Demo (Mouse)

No more guesstimating just how far it is between two cells!

As you can see above, the new ruler overlay shows the distance to every other point from wherever the cursor is positioned, suitable for any general distance calculation need. It’s just an overlay, so of course equally compatible with keyboard mode:

Cogmind Map Ruler Overlay Demo (Keyboard)

Is that ASCII or a ruler? :)

It actually took a while to come up with the best way to visually represent this ruler from among the many options in terms of layout and colors. The underlying functionality itself is quite simple of course, just showing the distance to each cell from an origin, but many more hours were spent figuring out how to display the values in a readable and good-looking manner.

Double-digit ranges are too cramped to print out in full, resulting in a massive block of numbers, so I decided on the alternative of using double digits only for clear thresholds--multiples of ten, which makes the whole thing much easier to parse. I mean the final iteration is by necessity still a jumble of numbers, but at least pretty quick to read by comparison!

Cogmind Map Ruler (early WIP concept)

The earliest test version of the ruler overlay when it still retained full digit values. I also tried variations of coloring and checkering, but it only made things worse :P

 

Cogmind Map Ruler (early WIP concept)

Another early concept where I’d decided on the threshold approach, but still had yet to include unknown cells in the measurements. One player suggested that could come handy for the occasional need to measure across partially unexplored areas as well, so I added that as seen earlier.

Control-wise, the ruler overlay is toggled via Shift-Alt-x (mouse toggle still to come), and since it’s not modal or anything, just an overlay, technically you can continue playing while it’s active, although naturally it covers up a lot of important info!

Playing Cogmind with the Map Ruler Active (fooling around)

The ruler is nice for planning, but playing while it’s active is not officially recommended :P

Do it for the cool (or crazy!) factor?

Terrain Destructibility Visualization

A common question while playing is “can I destroy that piece of terrain?”, be it a wall, machine, or some other prop. This usually involves checking the armor and resistances against your current (potentially modified) volley damage, and although it usually doesn’t take all that long to figure out the answer, crunching data is again what computers are good at, so now I’ve mostly automated that process with a single button :D

This feature is integrated into the volley range visualizer, which has always been useful for showing the relative range(s) of active weapons, but now also highlights in red the foreground of visible destructible terrain depending on whether or not the current volley is capable of destroying it.

Even better, it also checks the player’s inactive weapons and searches through their inventory for other weapons that might still be able to destroy terrain and in that case gives it a different color glow (yellow).

Here you can see it in action, where the Assault Rifle isn’t capable of taking any of the machines, the Beamcaster can only destroy one, and none can destroy the Fabricator (thus it always remains blue):

Cogmind Terrain Destructibility Visualization Demo

Terrain destructibility visualization demo.

The calculations generally take into account all applicable sources of damage modification, e.g. active utilities, current momentum, resistances, etc. The appearance of terrain the player doesn’t likely have the means to destroy at the moment remains unchanged. Note that even in such a case, it may sometimes still be possible to destroy the terrain using other means, since the system does not take into account inactive utilities or those in inventory, special weapons, the environment, or other means to creatively destroy terrain, but it is at least a useful way to quickly confirm that you already do have the capability.

FOV Overlay

Warning: Although I’ll be describing this feature here and even showing demos, it may not actually end up in the final public release of the game, or at least not quite in this form :P

Player-mob spotting is usually not perfectly reciprocal in roguelikes, as in enemies the player can see may not simultaneously be aware of the player, and vice versa. This provides room for additional relevant abilities and/or tactics (stealth/speed/sneak attacks/sniping/etc), as well as allowing for some level of risk taking (might I be able to slip by these enemies undetected?). However, very few roguelikes will actually display on the map those locations where actors can spot enemies (if doing so even makes sense given the mechanics and variable nature of being spotted).

In Cogmind there is an indicator for robots that spot the player, but before that pops up you can’t always be sure whether moving to a given location is close enough to be spotted in the first place, especially where obstacles like machines come into play since they can be used to partially obscure line of sight. The fact that robots can only fully spot you on their own turn further adds to the uncertainty, since quickly passing through their FOV might even go undetected.

Over the years there have been a few requests to allow players in Cogmind to see the FOV of enemies, but for a number of reasons I’ve always avoided adding this feature.

The earliest reason is the significant processing cost of calculating a proper FOV for what is potentially a lot of nearby robots, and it’s for that reason that when I converted X@COM to create the first version of Cogmind back in 2012 I decided to rewrite the entity sight handling to not actually use real FOVs and instead use a method that would scale better for the huge number of robots in Cogmind, specifically just calculating LOS between important points as necessary. This was far more efficient, and still is, for more or less the same results.

Nonetheless, for a temporary FOV overlay display used at most in short bursts and/or with lower robot counts it’d probably be doable these days, so I recently wanted to play around with the idea since it was still on my ever-growing List.

In short, Shift-Alt-v toggles robot FOV overlays, allowing you to identify every cell that each enemy can see. All the FOVs are combined unless examining a single robot, in which case it only highlights areas visible to that robot in particular:

Cogmind Robot FOV Overlay Demo

Keeping an eye on the FOV of several patrolling bots to avoid detection.

While we’re at it, there’s no reason to limit it to just enemies…

Cogmind Robot FOV Overlay Demo (keyboard, different factions)

Another FOV overlay demo in ASCII+keyboard mode, also tabbing around to different robots including even non-hostile bots (neutral FOVs appear gray, and ally FOVs appear blue).

Object popup labels are not active in this mode, since the main intent is to observe the area covered by FOV, and having labels pop up interferes with that goal.

The visualizer also takes into account active Cloaking Devices, using darker shading to represent the FOV reduction effect.

Cogmind Robot FOV Overlay Demo with Cloak Shading

The overlay shows how much closer you can get to that Watcher due to the cloak effect.

So for the most part the implementation worked out okay. I did also have to put some time into optimizing to bring it within acceptable bounds because it could really tank the FPS, and while further optimizations would be possible, they’d also require a large amount of work compared to what was done already. In any case, the problems I have with this feature are actually now somewhat less technical and more on the design side…

My biggest concern is that as a freely usable overlay this has the potential to really change the feel of the game in a lot of situations. Where without this information you’re kinda guessing at the edges of enemy FOV (especially due to the effects of machine obstruction) and maybe have to deal with the consequences of a surprise spot, always knowing exactly what visible enemies can see takes some of the suspense out of those moments.

A smaller concern is that when people can see FOV for all bots, they might not understand or like some of the results and report them as bugs, when it’s simply nuances behind how the system is designed.

Then there are the logic issues. Unless I put a huge amount of time (and program memory) into building a secondary world data and FOV system around what the player remembers rather than the actual map layout, the current approach can sometimes indirectly reveal information you shouldn’t actually know (e.g. missing walls, open doors, and various other situations).

One way to circumvent the logic issues entirely, and also somewhat reduce access to this feature, would be to make the FOV overlay only available by attaching a dedicated part, or perhaps a new RIF ability, which would quite in-theme.

That said, I wonder how necessary that even is given that we already do have the Triangulator utility which… no one really likes xD (in fact, the community makes fun of it all the time!)

Cogmind Triangulator Enemy Spotting Demo

One of a Triangulator’s several functions: See how close enemies are to spotting Cogmind.

Granted, an overlay is much easier to use and less situational than requiring a part that vies with other utilities for a slot, and also more broadly useful since it allows for visualizing the greater FOV rather than just LOS with Cogmind, meaning the ability to see what bots can spot other bots, and also for example plan a possible route past enemies by seeing the limits of their vision in other directions.

Having complete FOV data might indeed make for some interesting precise stealth planning, but in my experience you can get a lot of those moments just fine without it, and I do feel something is lost by showing everything. Unlike the ruler and terrain destructibility, this is not pure QoL--it can actually have a significant effect on gameplay and the whole feel of the game.

We’ve done pretty well with Cogmind’s existing system of hidden FOV for years, so I think this feature might end up getting canned, but having implemented it for testing anyway, I did recently include it in experimental patron builds to try it out for fun and science.

Posted in GUI | Tagged , | Leave a comment