Siege Tread Mechanics

Hot on the heels of upgradable RIF abilities for bothackers, Cogmind has gotten yet another relatively accessible new mechanic that will lead to a variety of new tactics: all multislot treads have the option to enter “siege mode.”

Patron Item/Mechanic

One of the goals I’d set on my Patreon was to allow players to submit ideas for special items and new mechanics, and we’d all vote on those which we most wanted to see in game. We reached that goal during Beta 9 development, so the idea submission and voting happened in recent months, and the winner of that vote was “siege treads.”

Patron item/mechanic voting results.

At the time the idea wasn’t super fleshed out, indicated simply as “treads with a special mode that confers more combat bonuses but further reduces/prohibits mobility.”

Towards the end of the voting period I took the top four vote earners and posted a somewhat more detailed proposal about their respective mechanics to help people decide, and at the time for siege treads I wrote:

This would add a range of new parts (treads, clearly :P) that don’t need to be rare, so it would be the most generally accessible mechanics among these options.

They’d be toggleable like overloading currently works for other propulsion, with effects like preventing movement while offering accuracy and defensive bonuses, for example increasing the coverage of all treads and/or armor.

Unlike overloading, however, to balance it out the negative effects would last longer once toggled off--basically fully exiting the mode for movement purposes takes some time, which would be indicated on the HUD.

The actual work would start a few weeks later, and before that there was some more designing to do…

Expanded Siege Concept

With siege treads now confirmed, as I started spending more time thinking about this mechanic and the original assumption that it would only be enabled by a few new parts, I felt that limitation was unnecessary (especially for the amount of work this would involve xD).

Why not expand siege mechanics into something that any treads can do? Three other forms of propulsion already have a use for toggling their active state once already active (overloadable flight/hover/legs), but treads didn’t yet have any corresponding ability--maybe that ability could be siege mode!

This would make the patron mechanic more widely accessible, rather than being some rare effect only a handful of people would ever see much less use.

Even more importantly, generalizing this capability would make it easier to teach players new to the mechanic. Tread info pages are already full, with no room left to add more rules info, especially those as relatively complex as siege effects, so by granting the siege ability to numerous treads while indicating that others cannot do it, or some are even better at it than others, we need a new stat, and that stat in turns gives us access to stat context help (i.e. selecting a stat to learn more about the relevant mechanics).

I actually couldn’t see any other way to do it, essentially requiring that this become a bigger mechanic to justify the stat, and here it was clearly the UI which guided gameplay design, which happens a lot.

However, allowing absolutely all treads to do this seemed excessive, and would also be a missed opportunity to make a subset of treads more unique, so I decided to limit it to heavy (multislot) treads. This makes sense on a number of levels, plus by allowing only heavy treads to use siege mode it indirectly restricts this feature to the mid-game and onward, to avoid adding siege mode mechanical and tactical complexity too early for new players.

Interface Work

By far the most troublesome part of this whole process would be how the player controls the mechanic, so I worked on that first. In fact, I even started before nailing down precisely what all the effects would be :P

On the outside it’s not too complicated (good! also important!)--just click/activate to head into siege mode, click again to exit. While transitioning or in the mode, the usual UI features would reflect the current state. The architecture behind overloading non-tread propulsion is quite simple since there is no delay on the effect, and part states can be toggled as a free action at any time. But internally we’d never had anything like the idea of a delayed toggle effect, so there are actually numerous states to handle here: the treads might be inactive, active, or “overloaded,” and while overloaded might be transitioning into siege mode, fully in the mode, or transitioning out. Plus we’ll have to deal with special conditions during some of these states!

A GUI mockup in REXPaint including an early concept for the siege mode interface components. Specifically that Movement line  info and SIEGE tags (this was before the need for separate tags during transition became apparent).

Since I hadn’t dealt with anything like this before in Cogmind, my first instinct was to have the architecture centered around the robot itself (rather than entirely based on the parts), i.e. treads would be toggled into different modes, but the parent robot separately stores what mode it’s in.

I actually spent four hours implementing this system, and had it working, but the problems were about to begin when I starting getting ready to tackle all the edge cases and special rules a system like this would need. As it turns out, Cogmind has naturally always had a very part-based architecture, and trying to split this behavior between the involved parts and the robot was going to be a crazy amount of error-prone edge case work.

In hindsight: Duh.

Another hour later and I’d reworked it to instead be a part-based attribute, so that treads could be toggled individually (the first iteration also tried to toggle multiple treads at once), and instead of the robot storing any data at all, it could determine its current mode whenever necessary by querying all of its active treads.

This way the edge cases became much more manageable, so in addition to the delayed effect toggling I applied the other special rules one by one…

• The transition timer could be reversed in either direction before toggle completion
• Treads in siege mode or transitioning cannot be affected by EM disruption, corruption, overheating, or any other effect that could break or temporarily disable them
• Treads in siege mode or transitioning cannot be removed, swapped, or dropped
• Cogmind can still remove treads in siege mode by purging all parts (“going naked”)
• While a robot is in siege mode, other propulsion cannot be turned on (or autoactivated when attached), a restriction that would also have to be applied to the propulsion cycling feature

Some of these had to be checked in a fair number of places, but not having to also worry about maintaining a separate robot state at the same time meant it wasn’t too much trouble.

With that up and running, it was time for the “Siege” stat to appear on the item info. Like the weapon stat line which displays either EM Spectrum or Heat Transfer, whichever is applicable for the current weapon, I could simply replace the propulsion Burnout stat with Siege when necessary. That data was wasted on Tread info anyway since none of them can use it anyway (but Cogmind lists inapplicable stats for items so that side-by-side comparisons are easier to make).

Note that although in this case I also did it first because it was going to be a harder part of the feature and possibly introduce limiting factors, I like to work on as many of the interface aspects of a feature as possible before doing the mechanical or logical aspects, since the former is required to better develop, observe, and debug the latter anyway ;)

Siege Treads

Now it was time to lock down the actual effects of siege mode and implement them one by one. As per the original suggestion this mechanic can be summarized as sacrificing mobility for increased combat abilities:

• +20% accuracy bonus to non-melee attacks
• Recoil has no effect on accuracy
• 25% damage resistance to treads in siege mode
• All armor and heavy treads have double coverage
• Immune to part destruction from critical hits
• Cannot move
• As per standard hit chance modifiers, being immobile gives +10% accuracy to all attackers
• Entering siege mode requires 5 turns, as does exiting it, and during each transition there are no benefits (only the inherent drawbacks of immobility and being an easier target)

Siege mode UI demo, also showing the relative coverage display.

There are three possible values for a tread’s Siege stat:

• N/A: Not capable of entering siege mode (applies to all single-slot treads)
• Standard: Capable of siege mode, as described above (most multislot treads)
• High: As Standard, but with a +30% accuracy bonus and 50% damage reduction (a select few treads)

Once the effects were known, a new set of specialized “Siege Treads” could be added (but not earlier, in order to know how to balance their various stats against other tread options). Dedicated Siege Treads have average integrity since their incredible damage resistance artificially pumps that up by a lot when put to their greatest use (not to mention their above-normal accuracy bonus for all weapons, which all but guarantees hitting every target)

Sample info page for Hvy. Siege Treads.

In addition to the new set, one of the rare unique tread types (spoiler) in the game is also capable of High Siege, making it even more desirable and interesting despite its own drawbacks.

With the mechanics decided, I could also get back to the info page and write the all-important context help, which in this case barely wins out as the longest context help for any stat…

“Siege” mode context help.

Details and Polish

There was also the usual stuff to take care of as with any stat, like adding it to the gallery item data export formats (TXT/CSV/HTM) as well as some relevant stats for the scoresheet!

Sample siege-related scoresheet stats.

It’ll be interesting to see how many times people use this mode, and for how long. There’s also a separate entry for the total amount of incoming damage absorbed by treads in siege mode, though that’s listed under the damage section rather than the section sampled above.

There was no doubt in my mind that siege mode would require sound effect feedback for the activation, so I put together some cool mechanical transformation sfx one for that, too. (And another less exciting one for fully exiting the mode, for completeness and, again, state feedback purposes.)

The Evasion window is also supposed to show the effect of any defensive factors that affect enemy hit chance, so that needed a little addition as well.

Evasion’s Speed category can now show a negative value while under the effects of siege mode.

AI Siege

Throughout work on siege mechanics, I intended for it to essentially be a player-only feature, as in the AI would never use it even if they technically had that capability. I was mainly worried about spending forever trying to get the AI to use it properly, and that in turn interfering with other behaviors.

But 1) obviously having them use it would be very FUN, adding more dynamic possibilities to certain situations, and 2) I also remembered that I recently already added turrets (in Beta 8) which are stationary combatants and that ended up okay. (Also having a few hours left to actually work on this played a part!)

So yeah, that’s a thing.

Though once the AI can do this, too, suddenly we need yet more indicators to reflect their state! For that I added a “+S” next to their name in the scan window, and an additional “(Siege)” text to their info window when that’s the reason for their immobility.

Robot siege mode indicators in the scan window and info window.

There’s also an on-map indicator: a blinking yellow ‘X’ temporarily appears over robots that have just entered siege mode.

This also reminded me I should probably add log messages for siege activation and deactivation, both for the player and others.

Plus of course you’ll hear when other robots enter siege mode (they get the cool sfx, too, although you might not be so happy to hear it when they do it!), so there are numerous avenues of feedback for this situation.

Tactical Implications

I’m eager to see how players make use of this new mechanic, especially given that it’s fairly accessible and comes at a time when other changes are also shaking up the combat meta. Using siege mode is entirely optional, but it does offer some new opportunities to consider alongside its potential drawbacks.

For one, in a tactical game like Cogmind where you’re often engaging numerous enemies, mobility is quite important. You always want to be in the optimal position, but with siege mode you’d have to make that determination further in advance, and be less flexible when things change for the worse.

Repositioning is often important even in the middle of a fight, and especially in dynamic fights where unexpected events lead to more dangerous situations, like a wall suddenly being removed and revealing new enemies, or being flanked, or being in a fight where additional nearby patrols are alerted alerted and start to overwhelm your position, or… much worse? :P

There are quite a few cases where even on treads, as slow as they are, you’ll want to get to a better spot to continue the fight, but if already in siege mode that won’t be such an easy option anymore, so whether or not to use it isn’t always a clear decision.

Due to the transition delays, overall one can’t use siege mode as effectively without prior knowledge of nearby enemy locations*, but the best siege loadouts will be specifically built for it, so whether or not it’s possible to capitalize on that capability requires a certain kind of situational analysis. (*For that reason I think it will be quite an effective combo with FarCom, if not sensors or other forms of tracking/detection.)

The transition requirements also mean you’ll always spend at least 10 turns not moving, plus any time spent in the mode, which might be time wasted. Some of this effect might be mitigated by turns spent doing actions where you’d be stationary anyway, like inventory management, but we’ll see how people react to it. There are certainly more ways to tweak it if necessary--like the transition duration can be modified (although I think 5 turns is a good spot to balance against the effects), or, more likely, certainly actions like firing would not be possible during the transition.

Although the defensive potential in terms of free damage resistance and extra coverage is nice for protecting your other parts regardless of situation, personally I think it’s most effective at range, where you can take advantage of the accuracy bonus better than enemies who would almost certainly hit you if they were close by (given their additional accuracy bonus from your immobility). Of course engaging enemies at range is overall more difficulty to do when slow.

Shortly after implementation, I started streaming a new heavy combat run aiming to use and talk about siege tread mechanics (among other new Beta 9 stuff). Part 1 is here:

After the stream Zyalin shared his impression of a Cogmind in siege mode:

Siege treads concept by Zyalin.

What are treads doing when they’re in siege mode, after all? ;)