[UMC] Extension to [movetype]

[Xudo]

Currently, movetype contains [resistance] tag, which describes how much damage the unit takes from different types of attacks in percents.
I propose [mitigations] tag in addition to [resistance]. It will describe how much damage the unit will mitigate from damage taken per each attack of enemy. It can be positive (decreases damage taken) or negative (increase damage taken).

Unit can not take less than 1 damage after resistance+mitigation calculations.

For example. Unit A have resistance to fire = 150 and mitigation to fire = 1.
Someone attack unit A with fire. Base damage is 10.
Unit will get 10 * 150/100 - 1 = 14 damage per attack.
(Base damage) * (resistance) - (mitigation).

Resistance works same for everyone, mitigation will work better for units with many strikes and worster for units with heavy damage-per-strike.

Potential uses:

• Solving balanse problems.
  If you want to increase strength of unit A against unit B (for example 10 damage and 4 attacks) and do not touch balanse against unit C (20 damage, 2 attaks), developer can decrease resistance of A by 10% and add 2 points of mitigation.
  Result:
  • B (10 + 10%) - 2 = 9 damage and 4 attacks (-4 damage total)
  • C (20 + 10%) - 2 = 20 damage. (no difference)
• Create "boss" enemies in campaigns
  You can increase their mitigation to force player to use damage-amplifier factors like Backstab, Leadership, Charge, ToD and so on.
  Spoiler:

  For example:
  Attacker have 100-2 damage. Boss have 80% resistance. Expected damage is 20-2. After Leadership (+25%) it will be 25-2. Leadership have amplified damage for 5 points of damage.
  Attacker have 100-2 damage. Boss have 80 mitigation. Expected damage is 20-2. After Leadership it will be 45-2.
  Leadership have amplified damage for 25 points of damage.
  In the same time:
  • they will get more efficient healing from Regenerate and Villages than if you just give them high hitpoints
  • they will decrease efficiency of using Drain against boss.
• Introduce "tiers" in your add-ons.
  Each tier will increase mitigation against attacks and damage.
  Compared to increasing of resistances, developer is not capped at 100%.
  Resistances still can be applied to change strength of one unit against other in the same tier.

[Insinuator]

This is an interesting idea, but I think it is overpowered. Even a low mitigation of 1, 2, or 3 would have an significant effect on gameplay. Most level one units don't do much more than 5 to 10 base damage per strike. Because mitigation would have to be measured in integers, it would also make sense to apply per strike. An Orcish Grunt's 10 damage would be reduced significantly, especially when combined with resistances. But far worse would be the effect on high strike, low damage units. These units are already slightly prejudiced against. This change would make them next to worthless.

[Dugi]

It's relatively easy to code as an ability, btw.

[Xudo]

This is an interesting idea, but I think it is overpowered.

I'm not proposing to add positive mitigation to EVERY unit in the game.
Who will ever do nonsense like combining high mitigation with high resistance?

I see following ways to use mitigation:

• Add additional way to solve balanse problems.
• Improve RPG's in Wesnoth. Current resistance mechanic does not allow designer to tune "armor" or scale it the way like damage (per point, not per percent).

It's relatively easy to code as an ability, btw.

I have no idea how to do it. May be you show some examples?

[Dugi]

Improve RPG's in Wesnoth. Current resistance mechanic does not allow designer to tune "armor" or scale it the way like damage (per point, not per percent).

You haven't read my reply or what? I said that it can be done relatively easily.

This is something in that style (this is the dumbest way to do it, and the most comprehensible, but it can be just a couple of events as well).

Code: Select all

#define ABSORB_EVENT VALUE
[quote][event]
    name=attacker hits
    first_time_only=no
   [filter_attack]
      type={TYPE}
   [/filter_attack]
    [filter_second]
        ability=absorb {TYPE} {VALUE}
    [/filter_second]
    [heal_unit]
        animate=no
	[filter]
		x,y=$x2,$y2
	[/filter]	
	amount={VALUE}
             restore_statuses=no
    [/heal_unit]	
[/event]
[event]
    name=defender hits
    first_time_only=no
      [filter_second_attack]
         type={TYPE}
      [/filter_second_attack]
    [filter]
        ability=absorb {TYPE} {VALUE}
    [/filter]
    [heal_unit]
        animate=no
	[filter]
		x,y=$x1,$y1
	[/filter]	
	amount={VALUE}
             restore_statuses=no
    [/heal_unit]	

[/event][/quote]
#enddef
{ABSORB_EVENT fire 1}
{ABSORB_EVENT fire 2}
{ABSORB_EVENT fire 3}
{ABSORB_EVENT fire 4}
{ABSORB_EVENT fire 5}
{ABSORB_EVENT cold 1}
{ABSORB_EVENT cold 2}
{ABSORB_EVENT cold 3}
...

[Xudo]

I think your example proves expediency in implementation of mitigation in core.
There are two reasons:

• AI will never know what unit have any mitigation.
• This example absolutely not "simple". It require additional WML events to execute. I believe implementation in core will be much more efficient.

Though, your example is good workaround for this issue. I think you should add it to Unit Abilities thread.

[Dugi]

It was meant rather as an example, this becomes very large when preprocessing, and it can be done in a more elegant way. But I never needed to code it, so I didn't post it there. If you need it too much, I can do it.

Btw, it would show up, it is tied to an ability named 'absorb (damage type) (amount)'; and you can give that ability a name that would show up. But, it would not show up in the damage calculations.

[Max]

can you provide a reason for this addition? do you have any units of mainline factions in mind?
would it improve anything - like balancing issues?

[Dugi]

It would certainly make the game more interesting. More variety in abilities -> more complicated thinking about strategies required. But it's only my opinion, and I think that wesnoth should develop in also another way than developing graphics, balance and UMC support, like new abilities, new advancements, etc. Once I develop this idea good enough, I will post about it in Ideas.

[Insinuator]

I see following ways to use mitigation:

• Add additional way to solve balanse problems.
• Improve RPG's in Wesnoth. Current resistance mechanic does not allow designer to tune "armor" or scale it the way like damage (per point, not per percent).

What "balance problems"? And since when does adding additional variables ever make balance easier. That's like saying playing Jenga gets easier after adding ten moves.

Wesnoth is not meant for RPGs. It is a TBS. While it is cool to see the innovation accomplished in this area by some campaign designers, adding every hotshot's abilities to the core would make the game awkward and harder to balance. Leave it to people like dugi, who actually care enough to code it, to make their own.

[JaMiT]

This is something in that style (this is the dumbest way to do it, and the most comprehensible, but it can be just a couple of events as well).

Or it could be done with no events, with the provision that the unit in question has both melee and ranged attacks:

Non-event implementation

Code: Select all

# Replace "TYPE" and "AMOUNT" in what follows by appropriate values.
# I am not including them as macro arguments because that is a bad idea when it
# comes to translations.

#define ABILITY_MITIGATE_TYPE_AMOUNT
    # Canned definition of the mitigate ability to be included in an [abilities] clause.
    # Requires all attacks to have the mitigate special to function.
    # Also requires the unit to have attacks for all ranges.
    [mitigate]
        id=mitigate_TYPE_AMOUNT
        name= _ "TYPE armor AMOUNT"
        female_name= _ "female^TYPE armor AMOUNT"
        description=  _ "Armor:
This unit is protected against TYPE attacks; AMOUNT is deducted from each hit against this unit by TYPE-based attacks."
        affect_self=yes
    [/mitigate]
#enddef

#define WEAPON_SPECIAL_MITIGATE_TYPE_AMOUNT
    # Canned definition of the mitigate special to be included in a [specials] clause.
    # This supplements the mitigate ability.
    [damage]
        id=mitigate_TYPE_AMOUNT
        name= # No name so it does not show up anywhere.
        apply_to=opponent
        sub=AMOUNT
        [filter_opponent]
            [filter_weapon]
                type=TYPE
            [/filter_weapon]
        [/filter_opponent]
    [/damage]
#enddef

This will show up in damage calculations. (Unless I messed up somewhere. It is untested.)

However, this is not really a forum for discussing how to do something in WML (hence I hid my code in a section tag). Presumably the person proposing the idea had already gone to the WML Workshop to find out if it could already be done? The current discussion should really be about whether the game would benefit from this addition to movetype. (Personally I do not see much benefit from it, and it seems like it would make balancing things even harder.)

[Xudo]

Take knalgans vs undead. Main point of discussing is that footpad is too strong against skeletons.
What if instead of decreasing footpad melee damage, add 1 point of impact mitigation to skeleton and decrease his impact resistance by 10%
then at evening skeleton will get:
Footpad melee 4-2 (now 5-2) -1 damage per attack. -2 total
Footpad ranged 5-2 (now 6-2) -1 damage per attack. -2 total
Dwarvish fighter 9-2 (now 10-2) -1 damage per attack. -2 total
Elvish shaman 4-2 (now 5-2) -1 damage per attack. -2 total
Mage 5-1 (now 6-1) -1 damage
HI 14-2 (now 13-2) +1 damage. +2 total
Wose 16-2 (now 16-2)
Drake glider 7-2 (now 7-2)
Troll Whelp 8-2 (now 8-2)
Mermaid Initiate 8-1 (now 8-1)
Walking Corpse 7-2 (now 7-2)

This move will increase value of skeleton mainly against Knalgans and decrease it against Loyalists.

[Dugi]

@JaMiT
You messed it up really badly. The syntax is absolutely bad, the substituted parts should be wrapped in {BRACKETS}, and there should be breaks to separate the macro name and its arguments. Zookeeper would cry when seeing this.

And you can also write the names of the abilities like this:

Code: Select all

       name= _ "{TYPE} armor " + {AMOUNT}

The problem with a possible absence of ranged attack could be only fixed by some event-based trick that would be again not counted into the calculations.
But in general, I wrote it in that style simply because I had a very similar ability coded somewhere, whose purpose was also to allow the unit to heal from weak attacks (especially for a boss named Achilles, who had 100% resistance to everything, and healed when he was hit; he could be harmed only by poison, and also piercing attacks, that were quite rare in that location), and I just wanted to show him that it can be done and does not need a special development of the system. Like the guys who wrote in Era of Myths that some units are immune to poison because there were meant to be immune only to poison and plague, but the engine does not allow that (as if there couldn't be an event making the unit manually become poisoned when attacked by a poisonous attack doesn't, but should affect it).

[Iris]

And you can also write the names of the abilities like this:

Code: Select all

       name= _ "{TYPE} armor " + {AMOUNT}

Which breaks internationalization (i.e. translations).

[Dugi]

No. You write translation for 'fire armour', 'blade armour', 'impact armour', so that means only six translations for all combinations of damage types and amounts.