Battlegrounds - Possible Result Error (should have been a draw)
François88
Member Posts: 17 ★
Hi Kabam,
Please could you explain why this match-up didn’t result in a draw:
As you can see, we both ended at 96.8% health in 43 seconds.
But I ended up losing.
I’ve had match-ups end in draws before, so this feels like it is an error of some sort in the coding.
Or I’m entirely missing a key process of the result-generating mechanics.
Any explanation would be very much appreciated.
(And before someone says it’s because a R2 Chavez has a higher base health pool than a R2 Ham, that explanation won’t fly, as points are based on percentage of total health. A 3* champ finishing at 100% health should get more points from health compared to a 7* finishing at 90%, even though the 7* has a higher base HP).
Please could you explain why this match-up didn’t result in a draw:
As you can see, we both ended at 96.8% health in 43 seconds.
But I ended up losing.
I’ve had match-ups end in draws before, so this feels like it is an error of some sort in the coding.
Or I’m entirely missing a key process of the result-generating mechanics.
Any explanation would be very much appreciated.
(And before someone says it’s because a R2 Chavez has a higher base health pool than a R2 Ham, that explanation won’t fly, as points are based on percentage of total health. A 3* champ finishing at 100% health should get more points from health compared to a 7* finishing at 90%, even though the 7* has a higher base HP).
2
Comments
Also, until we hear from Kabam (which we haven’t) that it’s actually to 2 or 3 decimal places, yours is just a hypothesis. Kabam need to confirm this and change the result screen to reflect it, if it is indeed true.
at 7r2, Chavez boasts a base health pool of 60801
Spam, however, boasts a measly base pool of 53201
the 2 numbers have a roughly good gap of being vastly different. with that said, Chavez can easily squeeze out 6 more points at being 96.8% health than the pig because of this gap. the reason is simply display to reality.
what you could be looking at isn't so much of it being 96.8% to 96.8%, but rather 96.82% to 96.83%. they both still round to 96.8% accurately, but they are still different numbers. it is wild the number of ties I've seen pop up in the last few months and that is people getting lucky. this shows it more like catching lightning in a bottle than we though it was.
If the result is being determined by an undisclosed 2nd or 3rd decimal place, that’s fine. But Kabam should make that clear on the result screen.
As they are just showing one decimal place now, it should be rounded and judged on that metric.
So 96.8% in this instance, should result in the exact same number of points.
I get why some of you may be defending Kabam here, but if/when this happens to you, you’ll be equally perplexed as to why the results system is this misleading.
It's always been based on HP and time (If the attacker KOs the defender)
One finished with 6 more HP.
Therefore they finished with 6 more points.
You fixating on the % is bananas when you have the numbers right in front of you.
My point is that, if Kabam is using more than one decimal place in their results-generating processes, that needs to be shown to us in the results screen to avoid issues like this.
If this had happened in the Battlerealm Brawl, for example, this would have been a really contentious and controversial issue. Because it’s not at all clear how the points are actually being accounted for.
The 15,000 isn’t the HP stat, it’s the max available points for the HP component of the results.
So they got 6 more points for finishing with the same % of HP. That makes no sense.
But thank you for demonstrating that, like so many on this forum, you’re incapable of entering into logical discussions (and thank you also for allowing me to stoop to your level with this comment).
And they scored more points than you.
You lost 0.04% more health and tied on everything else. Therefore you lost.
Stop being a sore loser.
If you have, say, 63192 base health and you end with 61201 health, then that means you would score 61201/63192 * 15000 = 14527.39 points. This will be displayed as 14527 points. The health bar will show 61201/63192 = 0.96849 which will display as 96.8%. There's no way to actually show everything with exact precision, because then the game would have to show the points as 14527.39, and then for the percentage to be accurate the health bar would have to show in the general case up to eight significant digits (because 14527.39 contains seven significant digits) which the devs are not going to do.
Again, the visual health bar in the scoring screen is not involved in the calculations directly, it is just there to show the player approximately where they ended the fight. The actual points are calculated directly from the player's health bar.
Not in this case. The fact that scoring is done with more precision than displayed has already been well-established. Your case isn't even a case of a display tie. The screen clearly shows the opponent scored more points than you. There have been actual display ties where both sides appear to score the same amount of points when rounded to whole numbers, but going through the calculations shows that one side did in fact score more points in the first decimal place. Your case shows both sides ending with roughly the same health, but that doesn't mean you both actually ended with the same health ratio.
All I was looking for was a logical explanation, and that was provided. Apologies to those who felt I was being a sore loser - that wasn’t the intention behind the post.
DNA3000, thank you for the great breakdown there 👍🏽
I can't at the moment verify the game calculated the percentages correctly, but I have no reason to doubt the calculations at this point and it all seems to line up correctly.
Incidentally, I've been told the game does scoring calculations to a lot of significant digits, almost certainly to try to avoid ties. Ties are the bane of competitions like this. You don't want players to spend time and resources, and have *both* of them come away with nothing.