Armor Scaling

[Frostorm]

Jeez, this subforum has been pretty silent as of late. Might as well find something to discuss lol. Anyways, I'm currently using Armor Scaling in my project, which is to say damage is reduced by a percentage amount with diminishing returns, scaled w/ DEF or MDF of course. Now, Yanfly's plugin gives the following formula by default:
value *= 100 / (100 + armor)

After I first started using this formula, I noticed the mitigation ramped down way too fast (at least for my project). By end game, my Heroes would have anywhere between 100-200 DEF, for example. The latter would mean only ~33% dmg is received. Even 100 DEF is already a 50% reduction! It's just too much too fast. My (simple) solution was to edit the formula to this:
value *= (100 + target.level) / (100 + armor)

So now, our Hero has to gain at least 1 DEF (or MDF) per level just to stay at the same % mitigation. But notice how I used "target" instead of "user". This is intentional since this way higher lv enemies take less damage while lower lv enemies take more. Levels range between 1-50 in my game btw.

I'm curious, what Armor system/mechanic do you guys use and why. If you also use Armor Scaling, do you use the default formula, or something else? What other disadvantages have you experienced using this mechanic, if any? Lastly, feel free to argue in favor of other armor/mitigation mechanics.

 

[Redeye]

Preventing Armor from scaling too quickly with your DEF is pretty easy. Either you make your game a small-numbers game where levels/equipment only give you 1-2 DEF apiece (maybe even have some levels give you nothing), or you can just divide the target.armor by a specific amount in the damage formula.

value *= 100 / (100 + (armor / 3)) would divide the value of DEF by 3, meaning that you'd now need 300 DEF in order to reduce incoming damage by half, which would be a pretty reasonable amount of DEF for endgame characters. I'm not too fond of having defense scale with your Level. If you want higher level enemies to take less damage than lower level ones, just increase their HP / DEF.

As for me, I like to throw in a second stat into the mix that deals with Armor Penetration. I typically name it "Focus" or "Dexterity" or something like that. The stat simply subtracts from the target's armor value. If the Armor Penetration is significantly higher than the target's Defense, then the attack may potentially INCREASE the amount of damage the target receives. It makes way for interesting "Tankbuster" skills that punish foes for building Defense. So the formula for a Tankbuster skill would be something like this:

value *= 100 / (100 + (target.DEF / 3) - (user.FOC / 5))

 

[bgillisp]

What I did was I put the calculation in my damage formula directly. That way I didn't have to worry about it. My overall damage formula was:

(a.atk + a.level) * (a.atk + strength of skill) / (b.def + 20) all times * 2 then + a.level.

 

[Frostorm]

What I did was I put the calculation in my damage formula directly. That way I didn't have to worry about it. My overall damage formula was:

Ah, I did that before too, until I realized I could sub different things in for "armor" in Yanfly's plugin. In my case, I added conditionals to check for various elements present in the attack to decide if the defending stat used should be DEF, MDF, or (DEF+MDF)/2.
E.g.
For "Physical Base Armor": if (this.getItemElements().contains(4) || this.getItemElements().contains(5) || this.getItemElements().contains(6) || this.getItemElements().contains(7) || this.getItemElements().contains(8)) {(target.def + target.mdf) / 2;} else {target.def;}

For "Magical Base Armor": if ((this.getItemElements().contains(1) || this.getItemElements().contains(2) || this.getItemElements().contains(3)) && (this.getItemElements().contains(4) || this.getItemElements().contains(5) || this.getItemElements().contains(6) || this.getItemElements().contains(7) || this.getItemElements().contains(8))) {(target.def + target.mdf) / 2;} else if (!this.getItemElements().contains(4) && !this.getItemElements().contains(5) && !this.getItemElements().contains(6) && !this.getItemElements().contains(7) && !this.getItemElements().contains(8)) {target.def;} else {target.mdf;}

Lol, sorry for that wall of text/code. Basically, this lets me better utilize hybrid skills, such as "Frost Strike" (melee skill that also deals Weapon/Frost dmg).

(a.atk + a.level) * (a.atk + strength of skill) / (b.def + 20) all times * 2 then + a.level.

Btw, would you say that ATK & DEF are valued equally in your game? Or is one weighted more than another? Also @Redeye, the same question regarding your formulas as well. (i.e. Is 1 point of ATK worth as much as 1 point of DEF?)

 

[Dr. Delibird]

I decided to scrap DEF as a stat entirely in favor of having HP being the only defensive stat for both players and enemies. I like the idea of the player being able to see that their new sword does X amount of damage all the time (outside of elemental resistances) and it's easier for players to see that if a lot of the more complex math is taken out. I balance the HP totals as I'm going through the game as any formula I've tried to use ends up just not being balanced the whole way through so yeah manual scaling is the way I am able to do it.

 

[duty]

This is sound advice.

I decided to scrap DEF as a stat entirely in favor of having HP being the only defensive stat for both players and enemies. I like the idea of the player being able to see that their new sword does X amount of damage all the time (outside of elemental resistances) and it's easier for players to see that if a lot of the more complex math is taken out...

First, decide how long you want each battle to last. This will then give you both the enemy's total HP and damage output.

If you want your boss battle to last for 10 player actions, then the boss monster's max HP is 10 multiplied by the average party member damage output per action.

The boss's damage output per turn is then the party's total HP divided by however many actions the boss should get during 11 player actions. This ensures that the party will likely fail if they have not defeated the boss within the 10 action timeframe.

Encounter and overall game design starts to feel a lot more streamlined when you're balancing your battles based on the time to finish. How much damage an attack should do, how much HP should something have, how much MP, etc. all falls neatly into place.

And as the dungeons/quests get progressively more difficult, you will also be able to derive how many levels the party should gain before the next area. That then translates into the number of mob battles and the XP rewards for those battles.

Other small recommendation, scale stats in your game by increments of 60. It's a marvelous number, as it's easily divisible by 2, 3, 4, 5, and 6. That makes adjusting anything by 66%, 50%, 33%, 25%, 20%, or 10% relatively simple math.

Let's take a Zelda like clone as a really simple example. The starting hero has 3 "hearts" that each represent a full unit of health. Each heart is the equivalent of 60 HP.

One of the weakest enemies in the game, a bat, deals a quarter heart of damage per action. That means its base attack deals 15 damage. If you want to make the numbers seem a bit more random, give the attack a 20% variance, so the bat will be doing somewhere between 12 and 18 damage per attack.

Now let's say, that at the end of each dungeon or quest, the hero should have the equivalent of a new heart.
You could do something really simple like increasing the hero's HP to 120 at level 2.

Or you could make it a combination of armor that provides a health bonus and leveling, so the new piece of armor the hero finds grants a +30HP bonus and the hero gains +30HP at level 2.

Or you could make it a combination of armor that provides damage resistance, so the hero is taking an average of 30 damage or less per attack, and the hero gains +30HP at level 2.

 

[Frostorm]

Other small recommendation, scale stats in your game by increments of 60. It's a marvelous number, as it's easily divisible by 2, 3, 4, 5, and 6. That makes adjusting anything by 66%, 50%, 33%, 25%, 20%, or 10% relatively simple math.

I'm definitely gonna make more use of "60" in general now lol.