Unit Efficiency: Geometric Average Method

[Neddie]

This is not my own work, and this is the premier posting of it. I hope that, eventually, the creator, who has given me permission to post it, will surface to contribute more under his own identity.

It is intended for general use, but may be applicable to Spring.


Unit Efficiency: Geometric Average Method
This article introduces a method for estimating the cost-efficiency of a unit.

Formulae
Efficiency = sqrt(damage per tick * durability) / cost (Eq. 1)

Damage per tick = damage per attack / ticks per attack (Eq. 2)

Durability = hit points (Eq. 3)

Derivation
We begin with a thought experiment. Consider a single unit; say, a single Flash. In combat, the Flash will deal a certain amount of damage every second. Obviously, the more damage the Flash deals per second, the more effective it is. However, we must also consider how long the Flash will be able to deliver this damage output. In a combat situation, this is dependent on how many hit points the Flash has. The longer the Flash survives, the more damage it deals.

From here we can develop a formula to estimate the cost-efficiency of a unit. In the interest of simplicity, we make several approximations:

Total Involvement: All units in combat are always able to attack.
Even Damage Distribution: Damage to a force is distributed so that all units suffer the same percentage of their durability in damage. In other words, all unit types suffer the same casualty percentages at all times.
Damage and Durability Proportionality: As a force suffers damage, its ability to deal damage (hereafter referred to as "firepower") decreases proportionally with the durability they have left.

Now consider what it means to have two equal forces, A and B, subject to the above approximations. We define some variables:

A and B are the proportions of the inital forces A and B remaining.
Adpt and Bdpt is the damage per tick that A and B deal when at full strength.
Adur and Bdur is the durability that A and B possess at full strength.
t is time.

When the two forces meet in combat, each of them will lose durability at a certain rate; by our approximations, this will likewise reduce their firepower. Therefore, if after some time one force loses a lesser proportion of their starting force, they will have also lost a lesser proportion of their firepower. As such, they will both lose less of their strength in the remainder of the combat and be more effective at reducing their enemy's strength and will prevail. As such, for two equal forces, both will reduce the other's proportionate durability at the same rate. That is,

dA/dt = dB/dt (Eq. 4a)

and since both A and B start at 1 (full strength),

A = B (Eq. 4b)

The proportional reduction of each force with time is how much damage they suffer per time divided by their durability. As such,
dA/dt = - Bdpt * B / Adur (Eq. 5a)
dB/dt = - Adpt * A / Bdur (Eq. 5b)

But these are equal, so
Adpt * A / Bdur = Bdpt * B / Adur
=> Adpt * A * Adur = Bdpt * B * Bdur
=> Adpt * Adur = Bdpt * Bdur (Eq. 6)

This fits the intuitive sense we developed in the thought experiment at the beginning of this derivation. The dpt of a force times its durability describes how powerful it is. We define this quantity as the power squared, for reasons which shall soon become apparent.

We must now relate this to the cost of a force. Suppose we have some force A subject to the above approximations with cost C and power P. Suppose we construct a second force B of the same unit types, but b times as large. The cost is now bC. Since there are twice as many units, the dpt is scaled by b, as is the durability. The power squared is then b^2 * P^2 = (bP)^2. An invariant quantity in the transformation from A to B is the power squared over the cost squared, since P^2 / C^2 = (bP)^2 / (bC)^2. This invariance is good, since efficiency should be something independent of how large a force is (an intensive quantity, as it were). However, it is more useful to have something inversely proportional to the cost, so we take the square root of these expressions, which yields

E = P / C (Eq. 6)
Efficiency = Power / Cost

In this case, as defined above,

Power = sqrt(dpt * durability) (Eq. 7)

Whence we arrive at Equation 1,

Efficiency = sqrt(dpt * durability) / cost (Eq. 1)

Note that this is the geometric average of two parameters divided by the cost. The single parameter case is simply the parameter divided by the cost, for example, worker time / cost.

Ideal Versus Non-Ideal
Of course, this formula is only as good as its approximations. We consider each of the approximations in turn:

Total Involvement: The major non-ideal factors here are range and mobility (speed, slope tolerance, etc.). A unit with a range advantage will be able to fire on the enemy without taking return fire. Meanwhile, a mobility advantage will offset this effect, and also allow more control of local force superiority. Therefore, this formula is best used for comparing units with similar ranges and mobility, or comparing the ranges and mobility of units with similar efficiencies.

Other non-ideal factors include ability to fire over obstacles, and targeting AI.

Even Damage Distribution: This is perhaps the approximation most directly affected by the human factor. Generally, one will want to first attack units that have high firepower but poor durability, such as artillery. At the same time, one will generally try to protect such assets. Victory should, of course, go to the more skilled player. The relevant question, then, is whether it is generally easier for the attacker or the defender to select the target of an attack. Usually this advantage will lie with the attacker.

Damage and Durability Proportionality: This approximation tends to be well-fulfilled in practice, due to the large number of units involved in most games of Spring. The amount of firepower one has is proportional to the number of units one has left.

Each of the variables in the formula also has some subtleties attached to it. Some factors to consider:

Damage per Tick: Splash damage, special damage against certain types of units, accuracy.

Durability: Resistance or vulnerability to certain attack types, armor.

Cost: What the relevant cost is (e.g., time, metal, energy).

Miscellaneous: Other abilities, psychological factors, factory cost, unit AI, synergy with other units.

Case Study: Warcraft III Melee Units
As a demonstration of the effectiveness of this formula, we apply it to the melee units of Warcraft III. We use hit points * (1 + 0.06 * armor) as the durability due to how armor works in Warcraft III, gold as the relevant cost.
The number before the slash is the unupgraded efficiency, the number after the fully upgraded efficiency. Stats taken from Mojo StormStout's Strategy Guide.

Alliance Footman (T1): 0.4889 / 0.6554
Alliance Knight (T3): 0.6113 / 0.8523
Orc Grunt (T1): 0.4755 / 0.7297
Orc Raider (T2): 0.5193 / 0.7010
Orc Tauren (T3): 0.5830 / 0.7777 (0.8980)*
Undead Ghoul (T1): 0.4859 / 0.7351
Undead Abomination (T2): 0.6579 / 0.8733
Night Elf Huntress (T1): 0.4085 / 0.5463 (0.5004 / 0.7225)**
Night Elf Druid of the Claw (T3): 0.6511 / 0.8440

*The Orc Tauren can get a special ability, Pulverize, that deals 60 extra points of splash damage on 25% of attacks. The number in parentheses is the result of the formula with 15 points of extra damage. The splash effect, of course, makes this much more impressive than this in practice.
**The Night Elf Huntress has a bouncing attack that can affect multiple units. The value in parentheses takes this into account, assuming the maximum number of bounces are made.

Note how all the unupgraded tier 1 efficiencies are quite close together; indeed, the lowest differs from the highest by less than 5%. Even when fully upgraded, their efficiencies are very close together, with the exception of the Footman, which is the only one of the four not to get a significant attack or hit point upgrade beyond standard attack and armor upgrades. There is a definite trend toward higher efficiencies as one moves to higher tiers. At the top tech end of the upgrade scale, the Alliance Knight and the Undead Abomination have the highest efficiencies; however, they are also the units with the least powerful abilities outside of the formula. The Orc Tauren gets Pulverize, as above, and the Druid of the Claw is also a part-time spellcaster. The speed of the Alliance Knight and the Disease Cloud and Cannibalize of the Undead Abomination, while useful, pale in comparison to these abilities.

[Ishach]

yeah, right

[DemO]

Tired's work?

[jcnossen]

nice. However it says "Unit efficiency" whereas the text talks about durability and how it decreases firepower of a force. That applies to large groups of units, but in most games not to the invidiual units.
I think a theory that compares individual units would be more interesting, as that is actually used in AIs

[Neddie]

No, not Tired.

[imbaczek]

ain't that easy... it's somewhat good if you don't consider any kind of player involvement. in reality, you can kill a gollie with 2 flashes if you're smart and click fast enough when needed, or with 1 if you add luck to that.

project idea for someone with more time than me: setup a webpage that pairs up units and lets people decide which wins (better: how many of one are needed to draw with the second one) when a) both are left alone and b) both are microed. then throw players at it and we'll have a "believed efficiency" matrix. of course this is useless if you don't have players (AIs and mod devs don't always have that luxury), but may be useful for validating all this interesting math.

[Dragon45]

I can kill a guardian with 3 AKs if they're undisturbed otherwise.

See, OTA tried this many many times over. You simply cannot assign a value to a unit's overall "goodness". It's a noncomputable function. Too chaotic, too many interactions between too many different variables.

The only way to find out the goodness of a unit is by playtesting exhaustively.

[Neddie]

Nothing is perfect, no calculation is without error. However, you cannot playtest every little thing - you cannot have perfection. These are approximations.

[Caydr]

Dragon: Your AK example isn't difficult to solve if you take into account turret rotation and barrel velocity speeds, as well as unit speed (in this case 0), but most importantly, a value I refer to as "risk" which is a value generated by the unit's costs and likely usage based on factors such as range, dps, etc, etc, etc.

Mathematic balancing is something I've been experimenting with for a long, long time. My stuff operates on the same sort of principles, just takes into account basically every unit, weapon, and script value with various nonlinear values for each that I've found work well. I've only actually used them in AA in a few dozen cases but the result has been uniformly excellent. Reason I don't use them more often is because it's time-consuming and often using simpler methods is faster... recent AA disast... versions haven't had enough time for development.

Math can go a very long way towards creating a balanced mod, just don't tell anyone you're using math or some people tend to freak out and say it's impossible.

[Dragon45]

Dragon: Your AK example isn't difficult to solve if you take into account turret rotation and barrel velocity speeds, as well as unit speed (in this case 0), but most importantly, a value I refer to as "risk" which is a value generated by the unit's costs and likely usage based on factors such as range, dps, etc, etc, etc.

You just iterated exactly what I said. You need to take into account a lot of factors. And yes, it is difficult to solve. Difficult enough that if you could get the error in your model down to something "small" (say, 5%), you would probably have figured out some algorthim that woudl win the Turing Prize, or at the very least, earned you a few million in sales.

To repeat: You cannot reduce units' properties to any sort of really useful mathematical models unless you have very, very, heavy duty mathematics behind it, and even then its extremely iffy.

and even then (as has been discussed numerous times in the OTA community), things like barrel turn rate, animation speed, weapon velocity, etc - all that stuff is not insignificant, weight and whatnot.

Here is where modeling *is* useful: Math is useful at a very shallow level in making sure you don't go overboard in some respects. It may even be possible to approximate reasonable ranges for many values based on relatively simple models. But they cannot provide any real solid balancing mechanism. It has to come through intuition and solid play experience at high levels (hmm... sound familiar?)

Otherwise, face it, you'd just be playing (and making) a glorified versiuon of starcraft, which is so much simpler than TA and its sucessors its not even funny.

[KDR_11k]

lol i buff Weezl!

[smoth]

not even reading that rubbish:

unit move speed on land, water, around obstacles.
unit break and turn rate and how they effect movement
unit slope tollerance
unit aim time
unit turn speed
weapon movement speed
weapon tracking
turn rate on tracking
weapon accuracy
idiosyncrasies in the engine for a weapon type(dumb fires being shot off into trees)
AOE
how AOE effects unit bases
weapon impulse knock back
paralysis
fire arc



blah
blah
blah


blah
blah
blah



blah
blah
blah


these sort of notions are never proposed by developers with a modicum of sense.

[SwiftSpear]

Nothing is perfect, no calculation is without error. However, you cannot playtest every little thing - you cannot have perfection. These are approximations.

It's WAY WAY WAY WAY WAY WAY WAY WAY WAY too simplistic currently.

It's like looking at falling objects and only accounting for the variability of gravity... Your results won't be accurate because you're completely ignoring air resistance, not to mention a half a dozen other small contributing factors.

[jcnossen]

Here is where modeling *is* useful: Math is useful at a very shallow level in making sure you don't go overboard in some respects. It may even be possible to approximate reasonable ranges for many values based on relatively simple models. But they cannot provide any real solid balancing mechanism. It has to come through intuition and solid play experience at high levels (hmm... sound familiar?)

You're stating that as a fact but you really don't have any proof for it. Read caydr's post for example..

And newsflash, Spring runs on math It's just a matter of trying to approximate the spring simulation to a less complex set of math operations. If you want to keep insisting "its all impossible" great.. but just stop posting here, cause its not constructive

[KDR_11k]

jc:nossen: You can possibly calculate the efficiency in Spring but you cannot calculate how a player uses the unit.

[Lindir The Green]

Efficiency alone doesn't help balancing at all, but it provides a useful tool and can help ensure that all units are useful, when combined with everything else about the units.

[1v0ry_k1ng]

that system is not all that useful unless it includes a speed and turnrate against range and turret speed

[Dragon45]

Here is where modeling *is* useful: Math is useful at a very shallow level in making sure you don't go overboard in some respects. It may even be possible to approximate reasonable ranges for many values based on relatively simple models. But they cannot provide any real solid balancing mechanism. It has to come through intuition and solid play experience at high levels (hmm... sound familiar?)

You're stating that as a fact but you really don't have any proof for it. Read caydr's post for example..

And newsflash, Spring runs on math It's just a matter of trying to approximate the spring simulation to a less complex set of math operations. If you want to keep insisting "its all impossible" great.. but just stop posting here, cause its not constructive

There's massive complexity that arises from Spring's physics. Yes? Yes. He's basically trying to come up with a closed-form function to model a complex, chaotic system. Modelling that complexity would like trying to model the behavior of, of, oh, i dunno, finite-state cellular automata on a fucking huge board that can itself change.

Something tells me a function to model that would be really really hard. Of course, that's just me.

[Zpock]

There's many tools to use in the art of balancing:

1. Pure intuitive feeling
2. Statistics
3. Math
4. Popular opinion
5. guessing
6. madness
etc

The thing they have in common is that none of them is perfect, and none of them is useless. They can all (more or less) possibly be used to achieve great balance. Personally, I think what's more important is the balancers vision of what balance itself actually is. With sucky presets even if he gets there using These tools the balance will suck anyway. Another common problem is that many people probably only think (often together with the players!) they achieved something but in reality it's not happening in actual gameplay, but in an idealized situation that only excist in the mind (and trailers).

As for the formula itself, it's simply obvious damage multiplied by hitpoints and divided by cost is central to balance, you don't need to do all that fancy math to "proof" it

The squaring is a good point tough. For example, two units with 1*1 firepower*defense, against one unit with 2*2=4, is an even fight except the big unit not getting crippled halfway.

[imbaczek]

Conclusion: this thing is useful as in 'simple, reasonable and better than nothing'.