Probabilities in Dice Wars

We've discussed the very-addictive game Dice Wars before. We used to have a tournament, which petered out.

The purpose of this post is to address the probability of an attacker victory given any given number of dice for both attacker and defender, as follows. The number of defending dice is along the top row. For example, if the attacker has 5 dice, and the defender has 4, the attacker has a 71.8% chance of winning.

Attacker	1	2	3	4	5	6	7	8
2	0.837963	0.443673	0.152006	0.035880	0.006105	0.000766	0.000071	0.000005
3	0.972994	0.778549	0.453575	0.191701	0.060713	0.014879	0.002890	0.000452
4	0.997299	0.939236	0.742831	0.459528	0.220442	0.083423	0.025450	0.006379
5	0.999850	0.987940	0.909347	0.718078	0.463654	0.242449	0.103626	0.036742
6	0.999996	0.998217	0.975300	0.883953	0.699616	0.466731	0.259984	0.121507
7	1.000000	0.999801	0.994663	0.961536	0.862377	0.685165	0.469139	0.274376
8	1.000000	0.999983	0.999069	0.989534	0.947731	0.843874	0.673456	0.471091

The next table considers the question of the greatest expected gain by number of dice. This is the expected number of armies you beat less the expected number you lose. For example, in the same 5 vs. 4 case, you can expect to gain 1.744624 dice relative to the enemy after the battle.

Attacker	1	2	3	4	5	6	7	8
2	0.675926	0.331019	-0.391976	-0.820600	-0.963370	-0.994638	-0.999432	-0.999955
3	0.918982	1.114196	0.267875	-0.849794	-1.575009	-1.880968	-1.973990	-1.995480
4	0.989196	1.696180	1.456986	0.216696	-1.236464	-2.249193	-2.745500	-2.929831
5	0.999250	1.927640	2.365429	1.744624	0.172886	-1.575510	-2.860114	-3.559096
6	0.999976	1.987519	2.802400	2.955577	1.996160	0.134041	-1.880192	-3.420409
7	1.000000	1.998408	2.951967	3.615360	3.486147	2.221980	0.098807	-2.158736
8	1.000000	1.999847	2.990690	3.884874	4.372772	3.970362	2.428384	0.066365

It is interesting to note that in an 8 vs. 8 battle, even though the attacker loses on ties, it is still a net gain to attack, because if you lose, you only lose 7 dice, because one is left from the attacking territory. Then again, the one army will likely easily be taken the enemy's next turn, but I didn't want to over-think it.

So, the greatest expected gain is attacking with 8 against 5.

Any other math questions pertaining to Dice Wars?

Interesting analysis, thank you.

There seems to be a strong belief around the internet that the programming suppresses the human's dice as compensation for its weak sense of strategy. Also, most people don't care enough to run the number of trials needed to test it.

I think that it suppresses the dice, and I don't care enough to check it.

I just tossed 3 against 3 four times in a row, with the defender being the last stack on the map. I lost all four. I rolled 3 sets of between 6 and 9, and on the fourth roll I rolled a 14 and the defense rolled a 17.

I know, I know. My mind invents a story. But I'd like the answer. I thought it was fishy enough to google it, and find that lots of folks agree.

There is a way to confirm or reject such claims: disassembling the Flash applet and analyzing the code. If I have the time and urge, I might try to do that.

I am quite attuned to how computer games cheat, for some reason really bothered about it. I have blogged about it.

The favored way a programmer will have the computer cheat is to manipulate the reinforcement phase and initial strength phase. It doesn't seem Dice Wars does that. I realize to say what I say next has no more weight than to say the opposite or anything based on what "it seems", but the frustrating luck the bots have in that game sometimes still to me seems to fit the pattern I see in other games that would seem honest. One thing for sure, as I have learned from one naval warfare game where combat can be resolved by same results each time [non-random], it is boring to set a game like that. Even when strategy is the goal and when you want to minimize luck.

My 2 cents.

I disassembled the Flash applet for the game. I believe the code which selects the dice rolls is located here (sprite 147):
...which looks innocent to me:

- dmax[0] contains the number of dice in the attacker's cell
- dmax[1] contains the number of dice in the defender's cell
- deme[][] contains the array of random dice (0 to 5) for both parties
- sum[0] contains the dice total for the attacker
- sum[1] contains the dice total for the defender

For each die in each party's cell, it picks a random number from 0 to 5 inclusive (and stores it in deme[][]), then adds 1 to it (to get a number from 1 to 6) and adds that to the running sum.

So, I think it's safe to say that it is picking the dice rolls fairly.

---------

However, I have discovered a flawed shuffling routine in another section (sprite 44), though I'm not sure what it is used for:
The first for() loop picks 8 positions at random to swap with the position indicated by the iteration counter. This produces a biased shuffle.

After running a simulation using this biased method, here are the 3 most common outcomes for the array after it has been "shuffled":

1. [ 1, 2, 3, 0, 5, 6, 7, 4 ]
2. [ 1, 2, 0, 4, 5, 6, 7, 3 ]
3. [ 1, 2, 3, 4, 0, 6, 7, 5 ]

The second for() loop uses the first 3 elements of it, and as a result of the shuffle's bias, those elements will almost always be [0, 1, 2] or [1, 2, 3]. Again, I'm not sure what this array is used for...but I don't believe it has anything to do with the dice rolls.

I think we had this discussion a long time ago about that method of shuffling. It seems to me that position x would have less than a 1/8 chance of having the number x (where x goes from 0 to 7).

Did you ever state a good shuffling method that minimizes both bias and time? The way I do it is to swamp two random positions in the array at least as many times as there are positions in the array.

About Dice Wars, I would hate to know how many hours, make that weeks, I've played that game, but overall I think the dice rolls are fair.

The shuffling method I use these days looks like this (assume that deck[] has 52 elements, with values ranging from 0 to 51):
That produces an unbiased shuffle. It was the prior discussion we had about biased shuffles that led me to this method (note that I did not invent or discover it).