## [interface/engine] Advanced damage inflicted/taken hit count statistics

Brainstorm ideas of possible additions to the game. Read this before posting!

Moderator: Forum Moderators

Forum rules
Before posting a new idea, you must read the following:
Mawmoocn
Posts: 138
Joined: March 16th, 2019, 3:54 pm

### [interface/engine] Advanced damage inflicted/taken hit count statistics

-> Introducing damage calculation and it’s hidden(?) mechanics with some examples

Current damage statistics relies on getting an average amount of damage to offset percentage calculations.

Whether it is good or bad, will depend on the player.

Damage inflicted/taken calculation use these as a reference to calculate percentage result:
Total hit points
Chance to hit
Number of strikes
Culmination of past turns results to create an average percentage

A combination of the things listed above and hidden(?) mechanics, changes the total average percentage, to create a percentage lower than normal result.

Hidden(?) mechanics calculation
Spoiler:
In the examples below, I tried to understand and simplified how it was calculated.

All the sample data below is acquired from Battle for Wesnoth statistics, except for the hypothetical data I made and mentioned.

Turn based statistic example data
Spoiler:
Damage statistic example data

Using Konrad (damage 6-3 sword) and Quintain (57 hit points) as a reference.
Spoiler:
Using Quintain (damage 3-5 flail) and Konrad (32 hit points) as a reference.
Spoiler:
Damage statistic with negative resistance and hit points example data
Using Quintain (3-5 flail) impact damage, 70% chance to hit and Vampire Bat (-20% impact resistance), for a total of Quintain’s 4-5 flail damage as a reference.
Spoiler:
Note : If total number of hits doesn’t hit (0/?), it would be automatically considered -100%.

Percentages would fluctuate greatly because of chance to hit, damage done if there’s a probability of death, and number of strikes. Overall combination of calculated results, will most likely make the average much lower or within a range of single digit positive/negative percentage.

I excluded creating an example for slow (ability) due to large sample size including the probability of death, retaliation damage would be required for data acquisition, and you probably need to take into account on what hit number, slow (ability) gets activated. A combination of these, would be hard, to reliably test slow due relative time constraints I currently have.

-> Suggestions

2. Units that die or has a probability to be killed, would have separate statistics from the current damage calculation result.

3. Advanced statistics tab including detailed information based from hit rate and hit count inflicted/taken.

Advanced statistics, contains successful and overall number of strikes with separation based on hit rate.

Hit rate options would only appear if they’re recorded to be present on the current scenario and total campaign progress.

This will be more apparent when you play specific mainline scenarios, user made campaigns, and other add-ons that alters a unit’s chance to hit or be hit, either in damage inflicted or taken.

Example of hypothetical advanced statistics hit count data
Spoiler:
-> Potential consequences

Accuracy of data might be important but it could lead to problems when it’s interpreted in a wrong way.
There’s a possibility that more complaints would be generated after the creation of this tool. This could garner more criticism than necessary.
Statistics might be cluttered if implemented in a way that combines them without separations or spacing.
It could increase the size of saved games and saved replays.
Backwards compatibility could be obsolete since it’s a new feature that could affect the engine of the game.
Campaigns might need some updates to fit standards if it does get affected.
Help files might need to explain this feature.
Translations might be needed if this was implemented.
Every new feature has a potential to have bugs.
Add-ons that can change chance to hit/evade by 100%, would make this feature nearly useless.

-> Closing statement

Creating this idea, made me feel like a robot ....

I’m willing to answer questions and suggestions if possible.

Thank you for time!

Edit: Corrected and added some information on one hit hidden(?) mechanic
josteph
Developer
Posts: 741
Joined: August 19th, 2017, 6:58 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Thanks for the proposal.

You've described the change but not the reason it's needed, could you comment on that? What's the motivation/purpose for this change?

I agree that "actual damage / expected damage" isn't always a representative statistic, when losing a match the reason for the loss is often more than just "the RNG favored the enemy". For example, if during a match the player's leader had 1HP and was attacked by two Mages and somehow survived, then the player would have been lucky to win, whatever the damage statistics during the rest of the match were.

It should be fairly easy to prototype this by using wmlparser3 on the replay savefile and going through the [replay] tag; the [checkup] tags of attacks state the chance-to-hit and result of each strike.
Mawmoocn
Posts: 138
Joined: March 16th, 2019, 3:54 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

It’s quite related to RNG.

It’s hard to find faults with your own strategy without some sort of graph where you choose to fight.

I can’t determine if someone really won by luck or they won because of strategy because damage fluctuates a lot. Hit points greatly affect results shown by damage calculations.

Damage calculations doesn’t tell you if you made a mistake or did well on using terrain advantage to win.

I want to see if it’s luck or strategy when you land a hit. Actually I want to see the difference on play styles and the reason for very different results.

Hm... the other reason is to determine glitches? Sometimes I feel something is wrong but can’t see where.

It’s hard to put in words... something like did I do well, did I get lucky or are there other possibilities to win?

There are times that I use very risky strategy, and sometimes very safe strategy, I can’t tell the difference between them on how effective they are.

It’s quite abstract in my brain since I’m not sure on how well it will do based on the problems I listed... I probably missed some problem too.

Thank you for your opinions and time!
josteph
Developer
Posts: 741
Joined: August 19th, 2017, 6:58 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

I think you're saying that you think showing the statistics of (number of strikes against P% defense that hit / total number of strikes against P% defense) for each value of P would be... more intuitively understandable than just showing the (damage dealt / damage expected to be dealt) ratio?

I think you might be right. Damage dealt is an aggregate, and it's weighed by the damage-per-strike, which can make it hard to use. For example, if you attack a unit with a Dragonguard and a Thunderer, a miss by the Dragonguard will affect the damage dealt stats much more than a miss by the Thunderer, even though they are equally probable. If the Dragonguard attacks many times in the scenario that won't be a problem (because regression to the mean), but using lower-level units is more effective in terms of both gold and XP, so there are likely to be comparatively fewer attacks with high-level units than with lower-level ones. In contrast to all that, simply measuring "hit/miss" ratios (especially grouped by terrain defense) is much easier to explain and to understand, and it's much more closer to what randomness actually does during a battle.

A possible tweak here would be to show the actual and expected numbers of hits (dealt and received) rather than the actual and expected hitpoints (dealt and received). For example, in your "turn 1" results, side 1 would have "hits dealt: 3/2.4" (2.4 = 3*80%) and "hits received: 3/3.5" (3.5 = 5*70%). We could add this info to the stats dialog alongside (or instead of) the hitpoints dealt/received lines. What do you think?

Note that we have https://forums.wesnoth.org/viewtopic.php?f=3&t=39944 for reviewing replays for strategic/tactical mistakes.
Mawmoocn
Posts: 138
Joined: March 16th, 2019, 3:54 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

josteph wrote: May 6th, 2019, 6:51 pm I think you're saying that you think showing the statistics of (number of strikes against P% defense that hit / total number of strikes against P% defense) for each value of P would be... more intuitively understandable than just showing the (damage dealt / damage expected to be dealt) ratio?
If I understood it correctly, I didn’t mean to imitate or replace the current damage calculations. I would like to categorize total hit strikes with different hit chances, to differentiate which terrain was used more in your battles. Sorry if I’m bad at explaining things. I’ll try harder.

Although I doubt if it’ll be understood immediately, since it’s different for every person..

To be honest, I don’t completely understand the mechanics behind damage calculation. Many variables affect damage calculation and it confuses me.

It’s fun to see your total damage though .

Speaking of number of strike calculations, creating an average for Dragonguard/Thunderer (1 number of strike), would be really hard since it relies on hit chance, and hitting when your chance to hit is merely 30%, would add 230%+ damage inflicted due to the variables I mentioned above. Debugging 1 strike calculations to work with average, might be hard.

Not sure how total average calculation would calculate this on overall damage.
josteph wrote: May 6th, 2019, 6:51 pm A possible tweak here would be to show the actual and expected numbers of hits (dealt and received) rather than the actual and expected hitpoints (dealt and received). For example, in your "turn 1" results, side 1 would have "hits dealt: 3/2.4" (2.4 = 3*80%) and "hits received: 3/3.5" (3.5 = 5*70%). We could add this info to the stats dialog alongside (or instead of) the hitpoints dealt/received lines. What do you think?
It would make things complex probably?

I’m not sure if the average created from those would suffer from different percentage problem.

The calculations probably won’t be noticed since all of the participating unit’s damage and hit strike would be combined as an average. Which could be a problem?
josteph
Developer
Posts: 741
Joined: August 19th, 2017, 6:58 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Mawmoocn wrote: May 6th, 2019, 7:51 pm
josteph wrote: May 6th, 2019, 6:51 pm I think you're saying that you think showing the statistics of (number of strikes against P% defense that hit / total number of strikes against P% defense) for each value of P would be... more intuitively understandable than just showing the (damage dealt / damage expected to be dealt) ratio?
If I understood it correctly, I didn’t mean to imitate or replace the current damage calculations. I would like to categorize total hit strikes with different hit chances, to differentiate which terrain was used more in your battles. Sorry if I’m bad at explaining things. I’ll try harder.
You explained it well, it's just that I proposed a slight tweak to your proposal. As I understand it, what you proposed is to add a breakdown along the lines of "against terrain defense 50%, attempted 100 strikes, 51 of them hit, for an actual hit rate of 51%", and so on, one such line for every other terrain defense value encountered. Is that right?
Mawmoocn wrote: May 6th, 2019, 7:51 pm It’s fun to see your total damage though .
Yeah, that alone might be a good reason to keep the total damage stats
Mawmoocn wrote: May 6th, 2019, 7:51 pm
josteph wrote: May 6th, 2019, 6:51 pm A possible tweak here would be to show the actual and expected numbers of hits (dealt and received) rather than the actual and expected hitpoints (dealt and received). For example, in your "turn 1" results, side 1 would have "hits dealt: 3/2.4" (2.4 = 3*80%) and "hits received: 3/3.5" (3.5 = 5*70%). We could add this info to the stats dialog alongside (or instead of) the hitpoints dealt/received lines. What do you think?
It would make things complex probably?

I’m not sure if the average created from those would suffer from different percentage problem.

The calculations probably won’t be noticed since all of the participating unit’s damage and hit strike would be combined as an average. Which could be a problem?
I don't think it'd be complex; see spoiler for details.
Spoiler:
Whether that statistic would have another problem...well, I don't see any. Counting hit rates is much closer to how randomness is used during combat so I think it's a good approach. Does anyone else see a potential problem? If not, I would recommend to write some prototype code (in Lua/WML/Python) to produce the histogram from a replay savefile and try the prototype on some savefiles to see how it performs in practice.

Could you explain your last concern about "calculations probably won't be noticed"?
Developer
Posts: 503
Joined: April 24th, 2016, 4:18 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

The only problem I see is the "expected" value is a single value, actually the "mean". The question actually should be is the observed value within some confidence interval.

6/2.4 looks like you did real good. But if you admit "6 out of 2.4 +/-4.8" we can see the apparent excellent luck is really nothing at all because the confidence interval is so large.

What should the confidence interval be?

It could be a number of hits ("What would happen if I got one more, or one less, hit?" Remember, our data is grandualr. Our analysis should recognize that. A 4x4 weapon can only deal 0, 4, 8, 12, or 16 (unadjusted) damage, claiming it dealt an average of 6.2 for some set of data might be the correct theoretical value but it will never appear, so why set the expectation? what it really dealt was an average of 4-to-12 HP (8 +/- 4). Or "6.2 / 8±4).

Or it could be some mathematical formula for a real confidence interval ("We're 80% condidence the value should be within this range.") This represents the fact that you're never actually dead-on the mean value. This is random, there should be variance. What throws most people is estimating how large that variance should be: most guess far too low.
I forked real life and now I'm getting merge conflicts.
Mawmoocn
Posts: 138
Joined: March 16th, 2019, 3:54 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Greetings,
josteph wrote: May 7th, 2019, 1:19 pm As I understand it, what you proposed is to add a breakdown along the lines of "against terrain defense 50%, attempted 100 strikes, 51 of them hit, for an actual hit rate of 51%", and so on, one such line for every other terrain defense value encountered. Is that right?
Yes. I didn’t think it was that simple, what made it complicated for me was the involvement of enemy units.
josteph wrote: May 7th, 2019, 1:19 pm The [result] blocks give all the info we need. By iterating all [result] blocks in all battles we can count, for each chance-to-hit value, how many strikes were attempted and how many strikes hit. Then we can easily compute the histogram you proposed, broken down by chance-to-hit value.
I think it could solve the problem of hits counting if the unit can be killed within 1-2 strikes, if applied to enemy as well.

josteph wrote: May 7th, 2019, 1:19 pm We can also condense that histogram to a single pair of numbers as I suggested. It's literally a single for loop (plus figuring out which sides the involved units are on).
I think condensing the numbers would work really well on compressing [result] blocks?
josteph wrote: May 7th, 2019, 1:19 pm Does anyone else see a potential problem?
This was long, probably.
Spoiler:
josteph wrote: May 7th, 2019, 1:19 pm Could you explain your last concern about "calculations probably won't be noticed"?
I’m assuming that your everyday player would probably think, it does the same thing as damage inflicted / taken.
I think you’ll also be confused on what expected hit count does without reading this idea or some sort of post.
The other far fetch hypothesis, based on my experience, games a person played in the past, will affect a person’s behaviour. This often relates to comparison, which leads to all sorts of problems that... could probably make them misunderstand on what it does .

Tad_Carlucci wrote: May 7th, 2019, 2:29 pm The only problem I see is the "expected" value is a single value, actually the "mean". The question actually should be is the observed value within some confidence interval.
I did see that as a paradox. After adding some thoughts, changing the expected value would be probably be worse, even if I wanted to change it. Once it reaches higher numbers, it won’t really be a problem, probably.

Changing it would complicate things, as making it favour the player, would add false hopes, which is good for the player psychologically, but will bad in the long the run, since if the decisions in the future becomes to revert it to normal/other calculation, it would probably cause heavy problems for people who are used to the system.

The conclusion I reached is, don’t change it.... calculating probability is like calculating RNG.
Tad_Carlucci wrote: May 7th, 2019, 2:29 pm What should the confidence interval be?
I don’t think it needs to be changed as it would probably create more problems.

It depends on what you want to do, I created a draft formula that could be, expected number of strikes divided by 50%/75%/80% (depends on what you think of luck), multiplied by chance to hit. (5 * .75 * .70 = 2.625)

I divided it to probably "lessen" the reliance on luck of expected number of strikes. Could either work or not.
Tad_Carlucci wrote: May 7th, 2019, 2:29 pm What throws most people is estimating how large that variance should be: most guess far too low.
It’s human psychology. It depends on the player I guess? Probably not, since we mostly have blank opinions not unless it was something we have faced in the past.

Well let’s say it’s complicated .

Thank you for your suggestions and replies!
josteph
Developer
Posts: 741
Joined: August 19th, 2017, 6:58 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Tad_Carlucci wrote: May 7th, 2019, 2:29 pm The only problem I see is the "expected" value is a single value, actually the "mean". The question actually should be is the observed value within some confidence interval.
...
Or it could be some mathematical formula for a real confidence interval ("We're 80% condidence the value should be within this range.") This represents the fact that you're never actually dead-on the mean value. This is random, there should be variance. What throws most people is estimating how large that variance should be: most guess far too low.
I agree that we should display some indication of the variance / confidence interval.

Let's take a specific example, that out of 100 strike attempts against 50% defense only 40 hit. What should we display in this specific case?

"40/100 actual, 50 ± 5 expected"? [5 is the standard deviation in this case]

"40/100 actual, 50/100 expected; very unlucky, 2.84%"? [2.84% is the a priori probability of having 40 hits or less, out of 100 strikes] The "very unlucky" is there to explain what the percentage means in gameplay terms. It could say, for example, "very unlucky" if the percentage was <20%, "somewhat unlucky" if it's <40%, etc; and "very lucky", "somewhat lucky", etc, in the corresponding cases when you got more hits than expected.
Mawmoocn wrote: May 7th, 2019, 8:11 pm Greetings,
josteph wrote: May 7th, 2019, 1:19 pm The [result] blocks give all the info we need. By iterating all [result] blocks in all battles we can count, for each chance-to-hit value, how many strikes were attempted and how many strikes hit. Then we can easily compute the histogram you proposed, broken down by chance-to-hit value.
I think it could solve the problem of hits counting if the unit can be killed within 1-2 strikes, if applied to enemy as well.
That's not a problem. We would count only strike attempts that actually happened. If a Horseman kills a unit with its first strike, we won't count his second strike at all. The second strike neither hit nor missed; it never happened.

Similarly if either combatant has slows, that affects the chances that the other combatant will get killed. The damage calculations dialog takes this into account, but for our needs here I don't think it's relevant. We just need to iterate over all strikes that were actually attempted and tally whether they hit or missed.
Mawmoocn wrote: May 7th, 2019, 8:11 pm
josteph wrote: May 7th, 2019, 1:19 pm We can also condense that histogram to a single pair of numbers as I suggested. It's literally a single for loop (plus figuring out which sides the involved units are on).
I think condensing the numbers would work really well on compressing [result] blocks?
josteph wrote: May 7th, 2019, 1:19 pm Does anyone else see a potential problem?
2. Replays would increase in size due to [result] blocks, every time it tries to confirm death/hit. Slow heavily affects this if there are implementations to count when there’s a chance to be killed.
The [result] I posted above was copied from a real replay savefile (it was one of the replays name posted to the WoV thread).
Mawmoocn wrote: May 7th, 2019, 8:11 pm 3. Abilities that alter accuracy like Magical and Marksman, might pose a problem within the [result] block.

If you position your enemy in a terrain that yields higher accuracy than Marksman, it could probably glitch to show hitting 60% while it actually hits 80%. Add-ons and abilities that alter accuracy might pose this problem as well.
The value in the [result] block is the chance-to-hit after magical, etc have been accounted for.
Mawmoocn wrote: May 7th, 2019, 8:11 pm 5. Events that use predetermined hits, like hitting an enemy, would automatically create slight inaccuracies to statistics assuming events alter hit chance without letting the UI/Game(?) know about it. Well it depends if events alter hit points, chance to hit, abilities/weapon special, number of strike and if it could end a battle. I think it’s already over stretching it if it could take this into account.
Yeah, there are things like FORCE_CHANCE_TO_HIT that could slightly skew the statistics, but I think they would be negligible. Also, if this is a problem, it affects the existing damage stats too.
Mawmoocn wrote: May 7th, 2019, 8:11 pm
josteph wrote: May 7th, 2019, 1:19 pm Could you explain your last concern about "calculations probably won't be noticed"?
I’m assuming that your everyday player would probably think, it does the same thing as damage inflicted / taken.
I think you’ll also be confused on what expected hit count does without reading this idea or some sort of post.
The other far fetch hypothesis, based on my experience, games a person played in the past, will affect a person’s behaviour. This often relates to comparison, which leads to all sorts of problems that... could probably make them misunderstand on what it does .
I don't think that's a deal breaker. The functionality is well-defined and we can write documentation to explain what it does.
Mawmoocn
Posts: 138
Joined: March 16th, 2019, 3:54 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Greetings,

josteph I agree to most of your statement, therefore I won’t reply to them unless there’s something else.
josteph wrote: May 8th, 2019, 1:50 pm Let's take a specific example, that out of 100 strike attempts against 50% defense only 40 hit. What should we display in this specific case?
The problem of assuming confidence interval in the ranges 48 - 53%, there’re slight differences between them, and would most likely skew results.

The other one I could think, since it’s an ongoing statistic, it would grow exponentially in hit count. Since it’s derived from an average, it would probably fix(?) itself.

I think that confidence interval would fail, once chance to hit/evade reaches 100%. This happens happen rarely due to certain conditions.

I’m mixed about agreeing or disagreeing, about implementing confidence interval due to several reasons. I mainly disagreed, but I think those problems are quite apparent once you do explain it.
josteph wrote: May 8th, 2019, 1:50 pm It could say, for example, "very unlucky" if the percentage was <20%, "somewhat unlucky" if it's <40%, etc; and "very lucky", "somewhat lucky", etc, in the corresponding cases when you got more hits than expected.
I think it’s better to explain it as estimated "luck".

Well it depends on many factors but "eliminating" your way of thinking that it’s "just" luck, would probably create backlash from people who are very critical about details.....

It still depends on what you want to do with it, I feel that the possible consequences are quite heavy to ignore.

I’ll admit it’s fun and funny to be spoiled that I was "lucky" .

Humour can probably add something, to make it really funny .

It’s a balance between professionalism and fun.
josteph
Developer
Posts: 741
Joined: August 19th, 2017, 6:58 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

I have a prototype. With the attached patch, whenever you open the statistics dialog, chat messages will be printed that show the histogram, that is, for each chance-to-hit value how many strikes were attempted and how many succeeded. For example, the screenshot shows that four strikes were made with 70% CTH (the Silver Mage attacked once) and three of them hit.
patch:
This is just a prototype of the functionality. If this is to be merged the values should be displayed in the stats dialog, not in the chat area. But I am posting it as it is for feedback.
Mawmoocn
Posts: 138
Joined: March 16th, 2019, 3:54 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

I think the one you mentioned overall average hit count would work well on small screens.

I guess <stats_by_cth> should be inside of a tab as an advanced statistics, I think it may add clutter to the screen, especially on mobile.

Thank you for testing if it can work!
josteph
Developer
Posts: 741
Joined: August 19th, 2017, 6:58 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Yeah, I'm not sure yet if I'd add the full histogram, or the one line with the value of (number of hits / expected number of hits) averaged across all CTH values. (Weighted average, of course) The latter would be easier to implement and as it'd be computed over a larger population, the confidence interval should be narrower.

About your previous post, I don't see how anything would grow "exponentially" in the hit count, what problem do you see? About the "very unlucky" labels, point taken, maybe there's a better way to present these.

Created https://github.com/wesnoth/wesnoth/issues/4066 for this.
Developer
Posts: 503
Joined: April 24th, 2016, 4:18 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Depending upon the actually implementation, the only thing I could see growing (but linearly, not exponentially) would be an accumulated error. And that can usually be made to hold at 1/2-bit with a proper implementation.
I forked real life and now I'm getting merge conflicts.
Mawmoocn
Posts: 138
Joined: March 16th, 2019, 3:54 pm

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

josteph wrote: May 9th, 2019, 9:20 am About your previous post, I don't see how anything would grow "exponentially" in the hit count, what problem do you see?
It wasn’t a problem but not sure.

It depends on units like Fencer, having more hits and low damage, how long a scenario would be, and how many units are participating in battle.

I estimate it could give you a minimum of 401+ hits done by the player on large scenarios. Small scenarios probably won’t cause similar issues.

Average hit count, would most likely benefit from high numbers, though I can’t say for certain.

Percentages probably won’t grow exponentially but hit count will, confidence interval would probably make it inaccurate if it’s calculated by multiplication.

Different hit chances would need different interval due to their nature. I think it would cause some oddities once the final tally for the whole campaign is done.
Tad_Carlucci wrote: May 9th, 2019, 12:11 pm Depending upon the actually implementation, the only thing I could see growing (but linearly, not exponentially) would be an accumulated error.
My basis exponential growth is multiplication by itself, grows numbers quick.
It won’t be a problem, probably ..........