Stupid or unlucky?

[piranha]

I've been working like crazy on this today. I find it quite difficult but now things are starting to look better and better.

There are some results that made me a bit puzzled. Most of them looks good but I have to show you two attacks.

First 1 dragon vs 6 light infantry


[5] => 0
[6] => 0
[7] => 0
[4] => 0
[3] => 0
[0] => 0
[2] => 0
[1] => 618
)
Array
(
[7] => 0
[0] => 0
[6] => 24
[5] => 53
[4] => 67
[1] => 72
[2] => 75
[3] => 91

618 times that dragon win with 1 survivor.
On the light inf side the peak is at 3 survivors. Is this really possible?
5 and 6 survivors on the light inf side would cause a re run in this case.

My other test that is even more strange.

This is one unicorn with STR 8 vs 8 archers with STR 3
(
[0] => 0
[1] => 44
[2] => 72
[3] => 98
[8] => 108
[4] => 123
[5] => 144
[6] => 157
[7] => 169
)
Array
(
[5] => 0
[6] => 0
[7] => 0
[4] => 0
[3] => 0
[0] => 0
[2] => 0
[1] => 85

In this case we would re run when the archers win with 1 or 2 units left only. But we would accept that the unicorn wins the whole thing.

Is this a possible result?

[KGB]

Piranha,

Unicorn battle:

You don't organize the results like that (sorting them and separating by stack). As I mentioned to Zajoman a couple of posts back the results really should look like:

Unicorn 85 | 44 72 98 123 144 157 169 108 Archers

In other words 1 unit left for the archers is the result that sits next to 1 unit left for the unicorn (ie the closest you can get to each other because after the last archer dies you get 1 unicorn left).

Then you go left to right counting to 100 AND right to left counting to 100 (taking out the extremes at both ends of the result).

So on the left you'd throw out the 85 unicorn wins. On the right you throw out nothing. The final result is you accept any number of archers remaining and rerun any unicorn win.

If this looks strange, just change the combat to be 1 archer (3) vs 1 unicorn (8). When I run just this combat the unicorn wins right about 90% (sometimes just over, sometimes just under). So in that 1-1 attack we'd accept all results as valid. So that's why the case of losing no archers in the 8v1 battle is valid because even in a 1-1 an archer wins about 10% of the time.


Dragon battle:

618 times that dragon win with 1 survivor.
On the light inf side the peak is at 3 survivors. Is this really possible?
5 and 6 survivors on the light inf side would cause a re run in this case.

Again you should group the results as:

Dragon 618 | 72 75 91 67 53 24 Lt Infantry

Then do the left-right and right-left exclusion. The final result you posted is right, you drop re-run the 5 and 6 light infantry cases and take all other results.

Now, why it looks strange. I ran this multiple times at 10000 tries. What I found is that those wins around 1-3 units left are so close that sometimes 1 unit was the most likely, sometimes 2 units and sometimes I got 3 units as you did. So my guess is those 3 are roughly equally likely and we are just seeing a minor statistical fluctuation.

KGB

[KGB]

Zajoman,

Stack 1 survivor distribution: 10 20 250 250 250 170 35 15
Stack 2 survivor distribution: 905 85 10 0 0 0 0 0

Stack 1 always wins, but the question with how many men. Soft method goes like 15 + 35, since adding 170 to that is more than 100 you don't include the 170 result. All the rest of the results are taken.

So stack 1 (10 20 250 250 250) can end up with 1, 2, 3, 4 or 5 men left. The problem is that even though it should never end up with only 1 or 2 men, it can, according to the soft method, because it takes everything what is after reaching 100.

In short, the soft method does not handle the minimal survivors, only the maximal.

Your made up numbers add up to more than 1000 I am going to assume the Stack 2 numbers are a misprint and that it should be all 0's for stack 2 (or a really small number)

Again you organize the results as:

Stack 2 0 0 0 0 0 0 0 0 | 10 20 250 250 250 170 35 15 Stack 1

Then you go left-right (dropping the 10+20 cases) AND right-left (dropping the 15,35 cases)

So you end up with 250,250,170 which is 3,4 or 5 men left for stack 1. So it never ends up with 1 or 2 men in stack 1.

KGB

[Zajoman]

Aha, I didn't get that part that I should go from both ends and throw out bad results. It makes perfect sense to me now.

[piranha]

I wonder about removing 100 from both sides. Wont we remove 20% if we do that?
200 from 1000?

[KGB]

Piranha,

In theory yes, in reality the numbers won't ever add up to exactly 100. In other words if you get to 75 and adding the next number jumps to 105 you only drop 75 or 7.5% from one side instead of 10%.

So I'd guess you'll end up removing about 15% on average (7.5% a side). In many battles you won't remove anything at all because the first outcome will be 100 or greater.

If you wanted to get *really* fancy, you could write some logic to search the left and right sides and include the most numbers that added together were closest to 100 and just drop those.

Eg 5 10 40 50 100 150 | 200 150 100 90 45 10

Then start with 5,10,10,40=65. The next number is 45 which takes you to 105. Since 105 is closer to 100 than 65 is you drop 45 too for a total of 10.5% excluded. Ironically this example is exactly the same as simply taking 100 from each side. But in some (many) cases getting as close as possible to 100 would be different than 100 from both sides.

KGB

[KGB]

One more thing I want to talk about. That is the effect of fight ordering.

Example 1:

Stack 1 consists of a dragon and 4 bats. Stack 2 consists of 8 giants.

When I do a traditional fight ordering I end up with {3,3,3,3,10} vs {5,5,5,5,5,5,5,5}. Running this 10000 times gives results of:

Dragon Stack won 1489 battles with an average of 0.595900 units left
Giant Stack Stack won 8511 battles with an average of 3.422100 units left
Dragon Stack Distribution: 1486 3 0 0 0 0 0 0
Giant Stack Distribution: 811 1102 1454 1621 1599 1233 561 130
The Dragon Stack winning percentage is 0.148900

So dropping results (in my case up to 1000) gives a final result of: 1 dragon or 1-6 giants left.

Now if I instead decided to put up dragon up front I end up with {10,3,3,3,3} vs {5,5,5,5,5,5,5,5}. Running this 10000 times gives results of:

Dragon Stack won 1503 battles with an average of 0.921300 units left
Giant Stack Stack won 8497 battles with an average of 3.431600 units left
Dragon Stack Distribution: 351 262 226 169 495 0 0 0
Giant Stack Distribution: 763 1125 1435 1618 1626 1241 562 127
The Dragon Stack winning percentage is 0.150300

So dropping results (in my case up to 1000) gives a final result of: 1-2 bats or 1-6 giants left.

Note that the winning percentage does not change in the least (makes sense). Nor does the number of giants killed change. But what does change is how the dragon stack results play out. In this case the exclusion now says that you can get 1-2 bats left and this is borne out by the fact the avg number of units left in the dragon stack goes from .59 to .92. Again, not unexpected since the dragon is the key unit in the battle and he alone can defeat all 8 giants and obviously does most of the damage.

Overall nothing too radical has happened. It's a bad decision to risk the dragon up front due to only getting 1-2 bats left when you win vs the traditional way of getting just the dragon left (a much better unit).

Example 2:

Stack 1 consists of a dragon and 4 bats. Stack 2 consists of 8 pikemen.

When I do a traditional fight ordering I end up with {3,3,3,3,10} vs {4,4,4,4,4,4,4,4}. Running this 10000 times gives results of:

Dragon Stack won 3302 battles with an average of 1.329500 units left
Pikeman Stack Stack won 6698 battles with an average of 2.266700 units left
Dragon Stack Distribution: 3235 49 16 2 0 0 0 0
Pikeman Stack Distribution: 1061 1254 1335 1249 961 600 212 26
The Dragon Stack winning percentage is 0.330200

So dropping results (in my case up to 1000) gives a final result of: 1 dragon or 1-5 pikemen left. Again about what you'd expect.

Now if I instead decided to put up dragon up front I end up with {10,3,3,3,3} vs {4,4,4,4,4,4,4,4}. Running this 10000 times gives results of:

Dragon Stack won 3307 battles with an average of 2.057800 units left
Pikeman Stack Stack won 6693 battles with an average of 2.272600 units left
Dragon Stack Distribution: 699 576 495 364 1173 0 0 0
Pikeman Stack Distribution: 1080 1242 1301 1226 978 617 229 20
The Dragon Stack winning percentage is 0.330700

So dropping results (in my case up to 1000) gives a final result of: 1-4 bats + 1 dragon or 1-5 pikemen left.

Again note that the winning percentage does not change in the least (makes sense). Nor does the number of pikemen killed change. But what does change QUITE radically is how the dragon stack results play out. In this case the exclusion now says that you can get the entire dragon stack left. This is because again the dragon is the key unit in this battle.

Here it's a good decision to risk the dragon up front due to the possibility of getting every unit left if the dragon slays the entire pikemen stack by himself.



So, the question is do we have a problem?

After thinking about it some, my answer is no, we don't. My reasons are that:

1) Changing fight order is strategic (I do it all the time to put archers/wizards up front against gryffons/pegasi cities). If you get to know the odds there should be rewards for that. Players should be encouraged to try/do different things.
2) Putting your strongest units up front should lower your losses on average when you win because those units do the real damage. The risk being that they are likely also lost in the battle due to fighting first (and facing first strike skills which are not accounted for here). So there is a balanced risk/reward for trying to lower your losses (get it wrong and you end up with the giant example where all that's left are the 2 bats, get it right in the pikemen example and you may end up with all units left).
3) Regardless of how YOU change your fight order you don't affect the other players results/avg men left/his cut off points. This IMHO is the most important thing. Changing your fight order should affect you but not your opponent. Likewise your opponent changing his order should affect his numbers and not yours.


Anyone see this a different way?

KGB

[piranha]

I have to think a bit about your question but my first impression is I agree. This should not be a huge problem and I think most good players realize that putting a good unit first can save those behind but its also risky.


I have another question. I looked back at the dice function and I see that your model that you posted earlier gets me a different result compared to the system I use.
I know the system I use will get me the same numbers as bob heeters site so I would like to double check before I start changing anything.

The system I use.
Example Attacker STR 6, Defender STR 4, Dice 20 sided.

6/20 = 0,3
4/20 = 0,2

1 - 0,3 = 0,7
1 - 0,2 = 0,8

0,2 * 0,7 = 0,14
0,3 * 0,8 = 0,24

(0,14 / (0,14 + 0,24)) * 100 = 36,8%
(0,24 / (0,14 + 0,24)) * 100 = 63,2%


Same example, but the way I understand the model you posted.
6/20*14/20 = 0,21
4/20*16/20 = 0,16

0,21/(0,21+0,16) = 56,8%

Am I reading your post the wrong way or do you think I'm I doing something wrong in my calculation?

If I use my system to calculate a kill, not just a hit I get the same numbers as on heeters diagram.
http://www.heeter.net/warlords/info/details/battle.html

[piranha]

I have another question.

When I keep the array instead of sorting it like I did.
If I attack with two armies that are quite even. This is 7 4 STR vs 8 4STR

Array
(
[0] => 0
[1] => 142
[2] => 99
[3] => 66
[4] => 26
[5] => 13
[6] => 2
[7] => 0
[8] => 0
)
Array
(
[0] => 0
[1] => 166
[2] => 154
[3] => 134
[4] => 107
[5] => 67
[6] => 19
[7] => 5
[8] => 0
)

If I start counting from the 0 side of the array I will end up with strange results. On the first array I will remove [2]->99 and then nothing else.
If I sort the array by the thing that is most rare I would remove 4, 5 and 6 units left but keep the rest which is probably the correct thing to do?

What I mean here is that in some situations the most common result is 1 unit left and then counting down towards 8 units, but in other situations it will be the reverse. Thats why I sorted them in the order so that I always remove the result that is most rare.

After some testing it seems to me that sorting the array and removing the lowest numbers must be the correct way to do it?

[KGB]

Piranha,

Same example, but the way I understand the model you posted.
6/20*14/20 = 0,21
4/20*16/20 = 0,16

You (and Bob) are right and I am wrong.

I made a typo. It should have been:

6/20*16/60
4/20*14/20

Those give Bob's numbers. I accidentally transposed the numbers so that it was saying 'chance you hit*chance you missed' . In any case, you are using the correct formula to determine a hit and I just wanted to make sure you were doing so and not just using ratio's of strengths on their own.

KGB