Stupid or unlucky?

[piranha]

Code: Select all

<script type="text/javascript">

function WarlordsTest()
{
    var attwinning = 0;
    var defwinning = 0;
   const DIE = 20;
   var HITS_STACK1 = 2;
   var HITS_STACK2 = 2;
   const CYCLES = 100000;

    var strarrStack1 = new Array;
    var hitarrStack1 = new Array;

    var strarrStack2 = new Array;
    var hitarrStack2 = new Array;
   
   var hitsStack1;
   var hitsStack2;
   strarrStack1[0] = 5;
   strarrStack1[1] = 7;
    strarrStack1[2] = 7;
    strarrStack1[3] = 7;
    strarrStack1[4] = 8;
    strarrStack1[5] = 9;
    strarrStack1[6] = 11;
    strarrStack1[7] = 10; 
   
   strarrStack2[0] = 4;
   strarrStack2[1] = 4;
   strarrStack2[2] = 5;
   strarrStack2[3] = 5;
   strarrStack2[4] = 8;
   strarrStack2[5] = 8;
   strarrStack2[6] = 6;
   strarrStack2[7] = 12;

   hitarrStack1[0] = 8;
   hitarrStack1[1] = 8;
   hitarrStack1[2] = 8;
   hitarrStack1[3] = 8;
   hitarrStack1[4] = 8;
   hitarrStack1[5] = 8;
   hitarrStack1[6] = 8;
   hitarrStack1[7] = 8;
   
   
   hitarrStack2[0] = 8;
   hitarrStack2[1] = 8;
   hitarrStack2[2] = 8;
   hitarrStack2[3] = 8;
   hitarrStack2[4] = 8;
   hitarrStack2[5] = 8;
   hitarrStack2[6] = 8;
   hitarrStack2[7] = 8;
   
   
   var r = 0;
   var q = 0;
   var winsStack1 = 0;
   var winsStack2 = 0;
   var unitsLeftStack1 = 0;
   var unitsLeftStack2 = 0;

   for (i = 0; i < CYCLES; i++)
   {
   
      //hitsStack1 = HITS_STACK1;
      //hitsStack2 = HITS_STACK2;
      r = 0;
      q = 0;
    for(var p=0; p < 250; p++)
    {
        //window.document.write(r+","+hitarrStack2.length+"<br />");
       
   
   
      while (hitarrStack1[q] > 0 && hitarrStack2[r] > 0)
      {
        /*
         var strStack2  = strarrStack2[r];
         var hitsStack2 = hitarrStack2[r];
         */
         var rollStack1 = GetRandomInt(1, DIE);
         var rollStack2 = GetRandomInt(1, DIE);

         if (rollStack1 <= strarrStack1[q] && rollStack2 > strarrStack2[r]) hitarrStack2[r]--;
         if (rollStack2 <= strarrStack2[r] && rollStack1 > strarrStack1[q]) hitarrStack1[q]--;
      }
        //alert (hitsStack1+","+hitarrStack2[r]);
      if (hitarrStack1[q] == 0)
      {
        //alert("hello");
         q++;
         if(q == hitarrStack1.length) {break;}
         
         
         //unitsLeftStack2 = unitsLeftStack2 + (hitsStack2 + 1) / 2;
      }
      if (hitarrStack2[r] == 0)
      {
        //alert("hello2");
         r++;
         if(r == hitarrStack2.length) {break;}
         //winsStack1++;
         //unitsLeftStack1 = unitsLeftStack1 + (hitsStack1 + 1) / 2;
      }
     
      }
      if(r == hitarrStack2.length)
      {
        winsStack1++;
   hitarrStack2[0] = 8;
   hitarrStack2[1] = 8;
   hitarrStack2[2] = 8;
   hitarrStack2[3] = 8;
   hitarrStack2[4] = 8;
   hitarrStack2[5] = 8;
   hitarrStack2[6] = 8;
   hitarrStack2[7] = 8;
       
   hitarrStack1[0] = 8;
   hitarrStack1[1] = 8;
   hitarrStack1[2] = 8;
   hitarrStack1[3] = 8;
   hitarrStack1[4] = 8;
   hitarrStack1[5] = 8;
   hitarrStack1[6] = 8;
   hitarrStack1[7] = 8;
   
   var Defsurvivors = hitarrStack2.length - r;
   var Attsurvivors = hitarrStack1.length - q;
   
   defwinning = defwinning+Defsurvivors;
   attwinning = attwinning+Attsurvivors;
   
        }
      if(q == hitarrStack1.length)
      {
        winsStack2++;
   hitarrStack1[0] = 8;
   hitarrStack1[1] = 8;
   hitarrStack1[2] = 8;
   hitarrStack1[3] = 8;
   hitarrStack1[4] = 8;
   hitarrStack1[5] = 8;
   hitarrStack1[6] = 8;
   hitarrStack1[7] = 8;
         
   hitarrStack2[0] = 8;
   hitarrStack2[1] = 8;
   hitarrStack2[2] = 8;
   hitarrStack2[3] = 8;
   hitarrStack2[4] = 8;
   hitarrStack2[5] = 8;
   hitarrStack2[6] = 8;
   hitarrStack2[7] = 8;
   
   var Defsurvivors = hitarrStack2.length - r;
   var Attsurvivors = hitarrStack1.length - q;
   
   defwinning = defwinning+Defsurvivors;
   attwinning = attwinning+Attsurvivors;
        }
   }

    var Defsurvivors = defwinning / CYCLES;
    var Attsurvivors = attwinning / CYCLES;
   window.document.write("Attacker stack winning percentage is " + winsStack1 / CYCLES * 100 + "%. <br />Def survivors:"+Defsurvivors+" <br />Attack survivors:"+Attsurvivors+"<br />Def winnings:"+winsStack2+"");
   window.document.write("<br />Att winnings:"+winsStack1);
   window.document.write("<br />Att winnings:"+winsStack1);
   //printf ("6 Strength Stack won %d battles with an average of %f units left\n", winsStack1, unitsLeftStack1/10000.0);
   //printf ("4 Strength Stack won %d battles with an average of %f units left\n", winsStack2, unitsLeftStack2/10000.0);
   //printf ("The 6 Strength Stack winning percentage is %f\n", (float)winsStack1/10000.0*100.0);
}

function GetRandomInt(min, max)
{
   if (min == max || min > max)
   {
      window.alert("GetRandomInt(): Incorrect arguments!");
      return null;
   }

   return min + Math.floor(Math.random() * (max + 1 - min));
}

</script>

<div onclick="WarlordsTest();" style="width: 200px; height:100px; border:solid 1px;"></div>

You can take a look at the code if you suspect there are some errors. Could be for sure.

I agree that I want to get rid of those extremes, but what is a good way to do that. Having a sharp edge where if you have 90% to win you will always win seems wrong to me. Its kind of talks against the dice system that is making battles quite exciting compared to chess battles that are not so exciting .

I also realize what you say about the fact that being just slightly weaker than the other army will give you really bad odds of winning with more hits.
But these two things kind of work against each other. You want the more powerful army to win, at the same time you don't want the odds to be so much better.

As the system is now, if you have your best hero army and it has 75% chance of winning a battle and instead you lose pretty big, is that okay? When is it not okay to lose any more.
I find it really hard to draw some sort of line where the cut off should be.
I'm not too experienced in math programming, if you have some idea, could it not be tested with this simulation code? If you want some sort of ease effect or something?

[steff]

How about a -1 or -0.5 in strength for the winning unit?

Let's say a defending spider with a total of STR 9 meets a full army of Light cavalry.
The Spider would suffer a -1 for every killed LC it would be down on STR 2 for the battle agians the last LC.

It would help out against the crazy rolls and it would not be a big change in the battle system.......

Just a thought.

[kenc80]

yes, i agree with piranha. we need to cut out the insanity not the randomness. I dont want to go into battles knowing exactly what is going to happen and who is going to win when two armies meet.

[KGB]

KenC80,

No one is asking to cut out the randomness. Everyone wants less of it.

This is just a discussion of how best to do it.

KGB

[KGB]

Piranha,

Your code is fine. I know this because I modified my own program to do the same battle and I got the same results. Since I coded separately using different code and got the same results I'd say that verifies your results.

Then I realized that it's only the last 2 units in the attacker stack and the last unit in the defender stack that really matter because those are the ones with the outstanding strength. Hence that's why the survivors are never changing regardless of the hits.

Then I made one more modification to illustrate my point. In addition to calculating the avg number of units for 10000 combats, I counted the distribution of the number of times Stack 1 won with 1, 2, 3, ... 8 defenders. Same with Stack 2.

Using the 8 hits per unit I get:

Stack 1 won 8842 battles with an average of 1.608300 units left
Stack 2 won 1158 battles with an average of 0.116200 units left
Stack 1 Survivor Distribution: 2868 4794 1094 85 1 0 0 0
Stack 2 Survivor Distribution: 1154 4 0 0 0 0 0 0
The Attacking Stack winning percentage is 0.884200

Using the 2 hits per unit I get:

Stack 1 won 7391 battles with an average of 1.726800 units left
Stack 2 won 2609 battles with an average of 0.331100 units left
Stack 1 Survivor Distribution: 1859 2756 1642 786 267 75 6 0
Stack 2 Survivor Distribution: 2155 239 183 31 1 0 0 0
The Attacking Stack winning percentage is 0.739100

So what do we learn? Well basically if you use my idea of chopping off the 10% extreme results (I ran 10,000 times) then you chop off all cumulative results that are <1000. So you'd get:

8 hits
Stack 1 Survivor Distribution: 2868 4794 1094
Stack 2 Survivor Distribution: 1154

2 hits
Stack 1 Survivor Distribution: 1859 2756 1642 786
Stack 2 Survivor Distribution: 2155

Which is essentially one and the same result. The defender wins with only 1 man left or the attacker wins with 1-3 men left (in the 2 hits case the attacker can win with 1-4 men left so you actually get *slightly* more randomness).

In other words, you don't need to go to 8 hits. The other advantages are:

1) You don't have to dramatically alter the winning percentages. In the 8 hit/unit example the winning percentage jumps from 72% to 88% or roughly 7/10 to 9/10. If my hero stack was facing yours and I knew my chance to win was 90%, I'd attack without hesitation. At 70% I'm not likely to attack. Too risky for me so I'd only attack if I was far behind in the game and needed a big win to get back into it. Otherwise I'd wait and hope to improve my stack by adding in an even better unit to increase my winning chance or use another stack first to weaken yours.
2) You don't over power the assassination (first strike) skill.
3) You don't have to entirely re-do the cost to purchase units (with 8 hits, a 3 strength unit is now MUCH more powerful than a 2 strength unit so a Hv Infantry would have to cost 400 to be equivalent to Lt Infantry and units like Pegasi giving a +1 stack bonus would have to cost 3000 gold).
4) Low level / strength units still have some value.
5) Blessing at temples isn't going to be overly powerful
6) City walls bonus isn't going to have to start costing 300-400 gold to upgrade a level of walls.


KGB

[Zajoman]

I would also be very careful when fiddling with hitpoints of units. I just feel I need to underscore that that single number changes the power of a unit A WHOLE LOT.

Piranha, you said you wanted to avoid simulating one battle ten thousand times because PHP is slow, right? But really, it's a turn based game, and it doesn't matter if the simulation takes 0.1 seconds or 1 second. So I think you don't need to be afraid of that when thinking about a way to cut off the extremes. Besides, the number don't really need to be that huge.

[piranha]

Okay, lets drop the more HP idea and look for other ideas. Its already in place but I can just comment away the selector when hosting and set the default number to 2 HP.

Going for the 10.000 battle runs is the last resort in my book as it will require 2000 lines to be rewritten, perhaps not exactly that many but thats the amount of lines in the battle class that handles battles and I would have to rewrite a lot, and I'm not sure about the resource waste either, this solution may not just take 1-2 seconds extra, it could turn out that its simply to consuming. Its not like using the client computer. When you have one server serving thousands of users each 1 second can make a pretty big impact and I expect it to take more time than 1 sec. I don't want to sound negative but I want to avoid this. If there is no other good solution then I'll give it a try.

There is another idea that sounds pretty good to me. Let me present it first and hear you tear it down .
Instead of having a dice, we could use cards.
Lets say the card deck has 1-20, and that there is 4 cards of each number. Each unit get its own shuffled card deck (alternative is giving each side one deck).
When a unit have drawn a card its thrown away. This means that with each hit the chance to make another hit decrease. When both units hit or miss cards are also thrown away.
This would make it harder / impossible for one unit to be super lucky and kill unit after unit like the spider did.

The number of cards per number doesn't have to be 4, perhaps 3 or 5 is the perfect number.

Resource wise this should be really good and programing wise it shouldn't be very hard.
Any thoughts about it?

[piranha]

I've been testing this idea the whole day now. It does work to for example get the spider simulation to lose while still keeping the second simulation around 78% compared to 73% but there are other effects that might change the results in city battles for example.

I'll take a look at the run something multiple times and see what I can do.

[KGB]

Piranha,

Going for the 10.000 battle runs is the last resort in my book as it will require 2000 lines to be rewritten, perhaps not exactly that many but thats the amount of lines in the battle class that handles battles and I would have to rewrite a lot, and I'm not sure about the resource waste either, this solution may not just take 1-2 seconds extra, it could turn out that its simply to consuming. Its not like using the client computer. When you have one server serving thousands of users each 1 second can make a pretty big impact and I expect it to take more time than 1 sec. I don't want to sound negative but I want to avoid this. If there is no other good solution then I'll give it a try.

Why would you have to or want to rewrite 2000 lines of code. In fact you don't want to change a thing with your current battle code. The original War2 (and DLR) contained a built in combat simulator (called the battle adviser that you used by pressing the CTRL key with the mouse over the enemy stack). Basically that simulator ran 1000 actual combats and reported the results as advice (This battle would be as easy as butchering sleeping cattle, This battle will surely be very evenly matched etc).

What you'd want to do is run your actual 2000 lines of code 1000 (or 5000 or 10000) times to get the expected results. Then you'd run it one time for the actual combat and make sure it was in the 90% range and if not you'd run it again.

So assuming the 2000 lines can basically be wrapped in a function call there isn't much to change. Even if that 2000 lines includes the animations, you just need to break out the actual dice rolling part into a function and call it (no need to work out the stack strengths over and over since those are fixed and only need to be done once) for the simulation.

There is another idea that sounds pretty good to me. Let me present it first and hear you tear it down .
Instead of having a dice, we could use cards.
Lets say the card deck has 1-20, and that there is 4 cards of each number. Each unit get its own shuffled card deck (alternative is giving each side one deck).
When a unit have drawn a card its thrown away. This means that with each hit the chance to make another hit decrease. When both units hit or miss cards are also thrown away.
This would make it harder / impossible for one unit to be super lucky and kill unit after unit like the spider did.

The number of cards per number doesn't have to be 4, perhaps 3 or 5 is the perfect number.

Resource wise this should be really good and programing wise it shouldn't be very hard.
Any thoughts about it?

I've thought about this exact idea myself in order to reduce the 'randomness' of the rolls. Except it doesn't really work close to as good as I (and you) hope.

Lets take a simple example to illustrate why. Suppose 3 scouts (str 1) are fighting 3 light infantry (str 2). Assume the deck is set to size 4 (80 values total, 20 of each dice roll).

Case of each unit gets it's own deck:

The first 2 units step in to fight. The scout can only hit on a 1 (4 chances in 80) and the light infantry on a 1 or a 2 (8 chances in 80). So none of the other numbers in the deck matter.

If there is no canceling of hits (ie scout rolls 1 and lt infantry rolls 2) then things are fine. It's just a race to see who gets their 2 hits first. But if the canceling stays in place, then if by chance the lt infantry cancels out the scouts attacks then once 3 of the 1's are used up the scout has no chance for a kill until the deck is completely used. So at that point the lt infantry is now the only unit that can still get a kill. So that's obviously different than how combat works now. So maybe you'd have to 'put back' the numbers into the deck if there was a cancel roll.

Once a unit dies and the next unit steps are you planning to reset the deck or not? If you don't reset both decks you end up with the possibility the surviving unit had used up all it's hit numbers and there fore can't hit until the next time it's deck resets. If you do reset both decks then I'm not sure you are gaining anything from this method because you could have used only a few lucky rolls from the prior deck to get a kill then get a few lucky rolls from the new deck to get a kill and then you are basically just doing pure random again and can get skewed results.

The other thing this method appears (I need to test by modifying my simulation program) to do is ensure that you get a VERY smooth result with almost no variation. In other words if a combat result says stack A wins over Stack B with 3.2 men left then I imagine you'd literally get 2,3 or 4 men left in Stack A all the time and thus you'd have almost no variance unless you made the deck size much larger than 4.

KGB

P.S. I posted this after your post about running the spider battle. I'd suggest you try the hero/hero battle you set up or try 8 lt infantry vs 8 lt infantry (even battle) to see how it works when there are multiple units per side which is where I think the strange results will occur. I suspect the 5% difference you see if due to the deck size and what I wrote about the canceling effect. Increase or decrease it and the winning percentage will change. You might also try putting back the 2 numbers when a cancel roll occurs and see if that gets closer to the actual 73%.

[Zajoman]

Still, the solution with redoing the combat if the result is out of 90% range of 10,000 tests seems best to me after all the ideas. You don't need to communicate the 10,000 combat simulations between the client and the server, the server would handle that alone and only send the client the one final result. And I also do not see a reason for a major code rewrite.