skeletons and unit balance

Ok, take two units with perfectly identical stats in the EDU. Then give one of them a fs_slow_swordsman skeleton and the other fs_swordsman skeleton. Am I going crazy or does the normal skeleton win 95% of the time in a one one mock battle on flat ground?

Why does this happen? If I give them both the same speed skeleton, the battles are about even again.

I know the next to last parameter in the stat_pri line is a min_delay between attacks that supposedly accounts for variations in animation time, but I have it set to 50 for both units which should put 5 seconds between attacks (well more than any of the animation times of the units' attacks).

So why are the fs_2handed still beating the fs_slow_2handed. Why are the fs_swordsmans still beating the fs_slow_swordsmans? And more importantly, how do I stop it from happening!

Skeletons, models, and animations (front end) should *not* affect back end (combat calculations). Its just bad programming if they do.

Let's see if I'm able to explain.

Skeletons have no parameters included in export_descr_unit. For me it is not surprising that the faster unit beats the slow one with the same stats. The fast unit hits more times than the slow one in the same period of time.

The delay in export_descr_unit stablishes a wait time between repetition of animations (two hits for example), and it is only a small fraction of the total time. This is the reason because its effect is so small.

And I seem to remember that the dagger animations were the ones that won out against fast spears hands down when testing (I adjusted lethality to compenstate).

It is strange though that CA said the min delay was to adjust the attack animation times (which differ) and then set them all to 25 ... :dizzy2:

that min delay between attacks...is it not irrespective of the animations? or is it added to the animation time?

e.g. let's say swordsmen have several different attack animations ranging from 22 to 28 frames (1.1 to 1.4 seconds). So, if I set min delay between attacks to 30 (3 seconds), then which attack animation it chooses shouldn't matter because after the 22 frame animation, it waits 1.9 more seconds before initializing the next attack and after the 28 frame animation, it waits 1.6 more seconds before initializng the next attack. This is how I *thought* the min delay between attacks paramter worked.

Are you saying that it works like this? If I set it to 30, the game waits 3 seconds after each attack regardless of thge number of frames in the animation?..so after the 22 frame attack, it waits 3 seconds giving the unit 1 attack every 4.1 seconds..and with the 28 frame animation, there is one attack every 4.4 seconds?

That would be just plain silly. That makes attack speed completely dependent upon what animation a unit chooses for each attack with no way of normalizing all units to attack at the same rate regardless of animation speed. I *thought* that is what the min_delay parameter was for.

Does the ai randomly select attack animations so that I can at least average out the number of frames of each attack to get an attack speed? Or does it preferentially select low_attacks against short opponents making balancing of differnt sized opponents nearly impossible?

I found this quote from JeromeGradskye on the subject, but which of the two scenrios I posted above is the correct one is unclear from this post. Perhaps he could clarify his remarks :)

Quote:

---

There are some fairly subtle game balancing facts involved with the animations, which i should probably mention. For example there is only one attack per animation, so the length of the attack animation determines attack frequency for that troop type. The attack delay values in export_descr_unit.txt are used to balance this, so that it doesn't become too restrictive for artists.

---

That's the quotation I was thinking of - I do not think Jerome has posted for a long while though (?)

Not just artists either, eh? ;)

@xerex
I think you are right.

In my opinion the delay was included as an option to "umbalance" more the stats. I mean, there is no reason because a heavy swordsman and a light one have the same stats, in the same way they have not the same animation (speed). The delay allows to slow down even more the animation for heavy soldiers, reflecting the difficulties to move a heavier equipment.

This is a way to "balance" the artists' work, just in the other way you thought. If the correct framerate for slow animation should be 30 and they put 28, we have the option to make it longer thanks to the delay. :juggle2: :beam:

but what isn't clear to me is if the min_delay is the time between the beginings of attack animations or the time between the end of one animation and the beginning of the next.

The latter of these two is useless for balance because every animation has a different number of frames and tacking on an extra 2.5 seconds to that doesn't change the fact that the unit will attack at a differet rate depending on which animation it chose to execute.

The former of these is totally useful if it works as prescribed. In this case, we can set the min_delay larger than any unit's attack animation, and all the units will attack at the same rate.

However, setting min_delay to 50 for two identical units and giving one fs_handed skeleton and the other fs_slow_swordsman still results in a victory for the fs_2handed for reasons passing understanding.

So, I must conclude that min_delay is either broken, or works in the useless manner described above.

Then, noting that setting min_delay exceptionally high slows down combat dramatically, I must conclude that it is working, and thus, must be working in the useless manner described above...which pisses me off :wall:

I guess I am hoping someone will come here and teach me how to make the above mock battle (between two identical units save for their skeletons) a tie for all skeletons so I don't have to go through and figure out the combat benefits of every single animation.

Well, I'm not 100% sure, but I imagine that the sequence is:

[animation time (fix)]-[delay (variable in EDU)]-[animation time]-[delay]-etc

Time lapse between two identical points in two consecutive animations: animation time + delay (= time elapsed between two hits)

Balance:
Slow animation = long animation time; needs short delay
Quick animation = short animation time; needs long delay

The problem is the fine tunning, due to the different units of both times (frames per second and tenths of second).

Thx for the confirmation. I appreciate the help.

as for the fine tuning, the different units is not so much a problem..the game plays at 20 fps and all animations are even numbers of frames, so a 20 frame animation takes 1 second to play in game. So, for a given animation, it is easy to determine the appropriate delay.

My problem is that fs_swordsman for example, has 6 different attack animations that all have a different number of frames associated with them. So the speed with which the unit attacks is variable depending on which animations the unit uses and how the game selects which one to use..

e.g. say fs_swordsman has the following animation times in frames for the attack animations. 20,22,24,26,28, and 30.

If it randomly selects an attack animation for each attack, then we can say the average animation time for an attack is 25 frames and asjust the delay accordingly. However, we have no idea if it actually *is* random. Center attacks may be more common than high or low ones.

Futhermore, what if the enemy the soldier is fighting is only 3.5 feet tall and has hairy feet? Does he still choose randomly from the same 6 animations? or are some animations not used because they are "high" attacks?

So then if 28 and 30 are the high attack animations that get eliminated when fightin the wee folk, the average animation time suddenly dropped from 25 to 23 making the unit attack faster when fighting smaller opponents. The same question is raised regarding larger than normal enemies.

Quote:

---

Originally Posted by xerex

My problem is that fs_swordsman for example, has 6 different attack animations that all have a different number of frames associated with them. So the speed with which the unit attacks is variable depending on which animations the unit uses and how the game selects which one to use..

e.g. say fs_swordsman has the following animation times in frames for the attack animations. 20,22,24,26,28, and 30.

If it randomly selects an attack animation for each attack, then we can say the average animation time for an attack is 25 frames and asjust the delay accordingly. However, we have no idea if it actually *is* random. Center attacks may be more common than high or low ones.

---

Yes, that's true. And it is difficult for us to get a deeper insight without knowledge about the mechanism used by the engine to select the animation in each moment.

If you checked descr_skeletons.txt and made an excel comparison of each skeleton (like I did hehehe) then you'd see that the only thing that's different in animation between fs_slow_whatever and fs_whatever is the running animation. That is it. One single animation. Just like the fast and semi-fast ones. They walk the same, but run at different speeds.

So it might be something to do with the skeleton and not the animation.

I have noticed one thing with fs_slow_whatever: when a unit is routing and getting killed, the model shrunk. Yes, you heard that right, it shrinks. It's like the skeleton is collapsing inward. It changes back to normal for the "falling on ground dying" part of the animation though. But the death-hit animation, they do the weird inward shrinking thing.

My conclusion is fs_slow_whatever is inherently flawed. CA probably used a newer CAS to export the new animation speeds and they're not agreeing with the older ones or the engine. So that might be affecting their kill-ratio.

Yah, the semi_fast/fast and slow/normal pairs have everything but the running speed in common. I determined that earlier today by extensive testing (very stupid way to go) too. Thx for the scientific confirmation though, wles. :)

Quote:

---

Originally Posted by Wlesmana

So that might be affecting their kill-ratio.

---

Tests so far show that slow_ and normal units with identical stats fight to a perfect tie, assuming of course that none of them will do the fall back/charge again thingy. I believe that when equal in morale, only the unit with slower running animation will try to regroup this way.

Quote:

---

Originally Posted by Dol Guldur

And I seem to remember that the dagger animations were the ones that won out against fast spears hands down when testing (I adjusted lethality to compenstate).

---

Nope... Daggers are actually the slowest animations (attack_speed-wise). Spears are the fastest I think, along with 2h_berserkers.

Quote:

---

Originally Posted by Monkwarrior

Balance:
Slow animation = long animation time; needs short delay
Quick animation = short animation time; needs long delay

---

So min_delay is time elapsed between one animation end and the next's beginning.
But then what's the point of naming it min_delay? Naming it just "delay" would suit it better, since it's a fixed value added to animation duration and not a minimum something. I know the reasoning sounds stupid, but everything is there for a reason and so is "min_".
Assuming that's indeed the case, then why CA had every unit's min_delay set to 25 and then Gerome comes forth and says that this was done so that units are more balanced?? Adding a fixed amount to varied values only helps balance (and only by a tiny bit) if it is much bigger than them, so the percentage of value-difference in the overall time is small. And I don't think 25 frames is that a big value... Setting min_delay high for fast units and low for slow ones would do the job much better obviously, if it works as described above and CA wanted to achieve better balance...

Assuming that min_delay is the difference between an animation's start and the next animation's start, then if the average of a unit's atttack animation times' is close to 25 (which I think it's the case), setting min_delay to 25 would partly balance the game, in that faster animations would take place within the min_delay's margins and with the added time would last exactly 25 frames and slower ones would be finished a short while afterwards, eliminating some part of the big difference between slow and fast attacks.

Am I making any sense at all? If I'm missing a critical part of the picture, can anyone more knowledgeable on that matter tell me what it is?
thx

RDN

Yeah, we discovered that fs_slow_whatever is the same as fs_whatever, fs_semi_fast_whatever, etc a few days ago throught extensive testing. I tried comparing animation to animation but my head started to hurt :)

but what we are having trouble with is the difference between skeletons for different weapons (for example: fs_dagger and fs_spearman).

We make the units clones of each other except for the skeleton and suddenly fs_dagger gets obliterated. If we give them the same skeleton or just differ the speed of the skeleton, we get, as expected, 50% victories and 50% losses for both units. And I don't think it is JUST the animation speed of the attacks. Because according to Jerome,

Quote:

---

"as the animation influence was largely eliminated from actual fought battles through the use of time-to-next-attack penalties"

---

Thus, setting all min_delays to 25 as CA did *should* make two skeletons of different types equivalent, but again, extensive testing has showed that while they are closer than before, they are still not equal.

It is my current belief (though I readily admit I have no proof) that the impact deltas of the attack animations as defined in skeleton.txt somehow determine the range of the attacks. This gives a combat edge to units with large impact delta-zs, like spearmen and to a lesser extent, 2handed. Units with smaller delta-zs, like dagger, are at a disadvantage even if their attack animations are *supposedly* normalized to 2.5 seconds between attacks.

Wles..you haven't figured out a trick for editing the impact frame of an animation without compiling skeleton.txt have you? Our mumakil's impact frame needs editing :)

I don't know what to say about the shrinking thing. If there is a combat effect due to that, we haven't detected it empirically yet as fs_swordsman and fs_slow_swordsman appear equal once battle is joined.

@aradan

actually, if you just go by animation speeds, then fs_2handed is the fastest with an average animation time of 21 frames (1.05 seconds). Spearmen come in at 25 and swordsman are 23.3333. Just averaging them may be totally wrong since we don't know how animations are selected, but its the best we can do atm. The largets normal attack animation I have found in vanilla is 38 frames (1.9 seconds). So, if min_delay is the time between the beginnings of attacks (as it should be), then anything over 20 should work. Hence, the value of 25 CA chose.

But, in terms of tests, an fs_spearman clone with 0 min_delay beats any other clone unit with a different skeleton leading one to believe, based on testing, that fs_spearman animations are the fastest.

This means that either averaging is a very very wrong and the game uses some other method to select animations or, as I suggested above, the impact deltas of the weapons are having an *impact* on combat...hahhahah...sorry..that was horrible.

Just a quick thought. Unlikely as it may sounds, is it possible that min_delay is harcoded? to 31/32 or whatever the highest vanilla attack-animation duration is?

thats easy to test...give one unit min_delay =50, the other min_delay=0 and see what happens :).

Whenever ever I take min_delay up really high, my battles slow to a crawl, so I think the parameter definitely does something to attack speed, but how *exactly* it works is very mysterious.

The most horrible thing will be if you are right and impact deltas have *such* a great effect... How the heck are modders supposed to achieve balance if everything from scale to animation has an immediate effect on actual combat results??

Regarding this highly unlikely theory about a min_delay limit and the relating test, I have no doubt the unit with min_delay 50 will terribly lose. But perhaps the game automatically makes every min_delay over 31 equal to 31, if there's a limit and 31 is it of course... The differences can be very subtle some times :)

I guess a great deal of testing is the answer to this, as to many other matters too... So I'll just shut up and go test...

I don't think there is a maximum. I started a battle with min_delay 5000 about 30 minutes ago. It is still going on maximum speed. I think somebody might have died a while ago..but I am not sure. I have been reading the silmarillion :)

LOL.

Let's hope you yourself do not become a skeleton before the battle finishes.

Just a fix of a stupid typo I made earlier.

Quote:

---

I believe that when equal in morale, only the unit with slower running animation will try to regroup this way.

---

Of course it's the unit with the faster running animation that will try to fall back and regroup.

:oops: Soz for that, lots in my mind, I was thinking ten lines ahead when I was typing that...

You are all right about fs_slow and the rest. In some speed tests some time ago I notice that the walk animation was the same for all the skeletons, whereas the only difference was in the run animation (I did not try the attack animations). Something similar happens with horse animations. Rapid and slow horses are only different in the galloping animation.

@xeres

I don't know what version (vanilla or moded) are you using for the tests. There is an additional "point of confusion" regarding the tests: the lethality.

The last value in stat_pri is the lethality of the weapon, and they are always 1 in vanilla with only two exceptions: 2 handed weapons (0.87) and spears of non-phalanx units (0.73). If your tests are on vanilla version, the victory of spears with 0 delay is even more surprising taking into account these values.

In ITW the lethality has been balanced (reduced greatly) to produce longer battles, with lower casualties (in an attempt to improve the realism) and depending on the type of weapon.

Xerex and I are running our tests with Forth Eorlingas 1.9, based on BI 1.6. Same as in ITW, lethality has been tweaked to achieve more balance and realism.

We are more than fully aware of the impact of lethality and those tests are run with "clone" units, that have everything in common except the skeletons.

an interesting thing I discovered today about doing mock battles.

Selecting the "fight this battle again" option at the end of a battle will give you same seed for the random number generator as the previous battle.

In other words, if you give your unit no commands, clicking "fight this battle again" will make your battles produce *exactly* the same results every time.

So, in doing mock battles, to get a new random seed for your next battle (and thus truly random values), you need to exit to the menu and load the battle again.

This has been creating havoc on our results trying to pin down what the combat effects of skeletons are. If anything needs to be change in the above posts, I will post a correction. So far, no changes to things we have posted (though many changes to things we haven't that we were working on).

Quote:

---

Wles..you haven't figured out a trick for editing the impact frame of an animation without compiling skeleton.txt have you? Our mumakil's impact frame needs editing :)

---

Can't do that in animation. It has to be defined in descr_skeletons, just like EVT files. It's pretty annoying since if we could just utilize descr_skeletons, we can make custom animations hit correctly and more importantly: have wargs that doesn't sound like horses.

Thats what I thought. Thx for response