• [2018/06/22]
    By using our forums, and our in-game services, you agree to be bound by our Privacy Policy found here:

Other Piercing and defense aren't working as intended


New Member
Nov 8, 2023
Reaction score
I was told to make a post here, even though this is a bug by conventional nomenclature.

Referencing: https://forum.skullgirlsmobile.com/threads/official-4-0-2-update-notes-available-now.15980/ (sub-stat changes section)

Quoting the Piercing description: "If your opponent has 50% DEFENSE, but you have 50% PIERCING, then your opponent won't reduce any incoming damage!"

This is false. The current game formula is the following:

Damage = BaseDamage x (1 - (DEF x (1 - PRC))

This means that with an enemy with 50% defense, if you have 50% piercing, you will deal 75% of the base damage instead of the intended 100%, as per the official description of the interaction between the two stats. This original description in line with the way Accuracy and Resistance are described and (I assume) work in the game, also in that same referenced link right below the piercing description.

Hence, the description for piercing was misleading as is the way it works, and it's also inconsistent and unintuitive; one can argue that the current formula is good to avoid 100% damage reduction scenarios, but those already happen for the majority of players that won't have 50% piercing in their moveset, since you need a minimum of 34% piercing to be able to do any damage to an enemy with a 150% defense stat - i.e. 50% defense and 5 stacks of armor, which would be the only scenarios where enemies could have 100% damage reduction regardless.

The formula should be fixed to match the original description by changing it to:

Damage = BaseDamage x (1 - (DEF - PRC))

or there should be an official announcement aknowledging that it was working incorrectly, but due to (whatever) reasons, it will be left as is and this is now the official and intended working way.

For practical purposes, the current formula means enemies with 50% defense and 3, 4, or 5 stacks of armor take more damage from attackers with 50% piercing. Alternatively, the fixed formula means enemies with 50% defense and 1 or 2 stacks of armor take more damage from attackers with 50% piercing (the inflexion point is at 100% effective defense or 2.5 stacks).

Anecdotally, I find that most enemies I fight have 1 stack of armor most of the time, sometimes 2 and rarely more than that, so fixing the formula would at the same time mean an overall increase in damage for attackers and also allow the existence of armor stacking defense compositions like Heavy Metal Big Band or Armed Forces Cerebella, which currently will still take damage even with maxed defense and 5 stacks of armor, and I very much feel like this is not the intended variants' design (as well as quite sad).
  • Like
Reactions: Bones
I also believe that the reason why Piercing and Defense (as well as Accuracy and Resistance) were capped to 50% is very much to allow the stacking of armor up to 5 stacks to work (and allowing 100% debuff chances to keep their ensured-hit effects if the user has 50% accuracy). Otherwise, they could've followed the same logic as Crit Rate and Crit Resistance: a minimal investment in Crit Resistance will already mean that Crits aren't guaranteed even with a 100% stat investment.
Furthermore, making armor stacks an "ignorable" buff on the enemy with a simple piercing stat investment also makes the armor break debuff mostly obsolete (in its use as a debuff counter to armor), being trivialized as a 20% damage increase debuff for the variants happen to use it in their movesets, sometimes. The game seems to strive towards a "counter" style metagameplay in buffs and debuffs too: deadeye counters thorns, unflinching, etc.; precision counters signature abilities; quietus counters blessing and final stand; slow counters haste and viceversa, enrage + cripple, regen + bleed... Debuffs like slow and cripple are already vastly obsolete, and this fix would prevent armor break from becoming one of those while keeping the "counter" logic in line.