Start a new topic

New Dice Algorithm / True dice rolls

Game does not use true dice roll probabilities. Many, many times I've had 97-99% chance to win and dont.

HOW TO VOTE FOR THIS FEATURE? Tap the 'Do you like this idea?' below

91 people like this idea

There is DEFINITELY something bugged with the new dice algorithm. I installed the game on a different device, created a new game account, and here was the dice stats after one single-player game with 5 AI: 1 - 27% 2 - 14% 3 - 14% 4 - 14% 5 - 14% 6 - 14% There surely is something bugged here.

1 person likes this

There is a common misunderstanding about how probabilities (dice, coin tossing, roulette) work.  Randomness with equal probabilities does not guarantee that we will see an even distribution in a game.  In the REALLY LONG run (many thousands and thousands) of trials, we would expect to see virtually even distribution, but not in the short run.  

The dice have no memory.  They do not know what numbers came up on the previous toss.  They don't take notes and monitor the history of tosses over time so they can tell #1 to show up more.  They just get what they get.  You can count cards at poker, but that's because there is a fixed number (52) and the probabilities change based on what cards have been dealt and which remain in the deck.  In cards, this is "sampling without replacement".  In dice, it's "sampling with replacement".  If you roll a 1, that doesn't change the probability of getting a 1 on the next roll.  It's still 17%.  

It's like you draw a king of hearts, then put it back and reshuffle.   The probability of drawing a king of hearts the first time was 2% (1 out of 52). If you put the cards back in, then the chance of drawing the king of hearts remains 2%. The odds don't change.  

Enough Gramps, you are not imparting some great wisdom. Probabilities of dice rolls are a simple concept that most people here clearly understand, and that's NOT the issue. Maybe YOU listen and learn: Emulating dice rolls in software is easy and straightforward. This begs the question, what was changed in the algorithm? How was it "flawed" to begin with? It's a FACT that SMG changed the algorithm, therefore it's a FACT that this modification has a demonstrable effect. We are, at a minimum, owed an answer to these questions from SMG. And if they really wanted to end all debate they could (and should) just post the source code for the dice roll functions on GitHub for all to see. Stop telling people they are wrong, YOU are wrong by failing to understand the issue.
I would also like to know what was changed with the new algorithm. My guess is its just a new PRNG which shouldn't make much difference if any in the results. Would love to see an excerpt of the source code or basic explanation of the changes and motivations for them.
Something happened recently with the rolls to greatly favor the attacker. It's very frustrating. That's not how it really is in Risk.

1 person likes this
"we would expect to see virtually even distribution, but not in the short run." ...which is exactly why the dice stats in my previous post are so out of whack. That was ONE single player game. And agreed with what Justin Burt posted... SMG already stated that they changed the dice rolling code/algorithm: "We rewrote the dice rolling algorithm several times to arrive at a more balanced dice simulation, just released in v1.9.36." "We feel this algorithm is much more balanced than our previous algorithm." SOOOO... what was wrong with it to begin with, and what exactly was changed? I mean, what in the world is SO difficult with coding a simple and accurate random number generator??? I myself have coded ancient QuickBasic v4.5 programs for DOS (as well as ones coded in NeoSoft's "NeoBook Professional" for Windows) that WERE WAY MORE accurate and random compared to SMG's algorithm. I mean, Folks: this game is PREDOMINATELY a DICE game... if the SO-CALLED "random" dice code is bugged, this TOTALLY RUINS the ENTIRE game.

Thanks for the life lesson Justin.

My post was in response to Richard's post immediately before mine.  Has nothing to do with your demand to see the algorithm. There is more than one issue here.  But I appreciate the feedback.  

The dice algorithm isn't the problem and is very realistic actually. For those of you who don't know how a dice roll works with computer programming it's just a random number that is generated from 1-6 for each individual dice roll
I've took coding classes so ik there is nothing wrong with this dice roll for the blitz option the dice probability doesn't change depending on how many troops u have it only changes with how many dice they would technically roll. The computer generates that number itself so... buh if they have more than 2 troops versus your 3 or more troops the dice roll probability that you'll win is 3/5
Another thing is y'all are all very dumb probability is just what it sounds like probable not I repeat NOT impossible. Just because you might have a 1/6 chance of rolling a 6 does that mean it's impossible to roll a 6 all 6 times?? Your answer should be NOOOOO!!! While it might be very unlikely it isn't impossible. And if you want to talk about being realistic there is nothing more real than that. The same applies to a 6vs3 or even a 15vs6 just because in these situations I'm more likely to win does it mean the game is flawed if I don't NOOOO!!!! No matter how many times I might loose in those situations it has nothing to do with the coding being flawed I would just be super unlucky

The only idiots here are the ones "explaining" that probabilities don't preclude long-tail scenarios… You also going to tell us the sky is blue and poop smells bad?

The issue is that SMG changed the algorithm (hence this thread) and they should explain how and why, and open-source the code. I have actual data demonstrating that the "fix" does indeed produce unrealistic results:

  • Prior to the update (v1.9.36) I had 162 games on record, and the in-game statistics showed an even 17% distribution among dice rolls, as one would expect with such a large data-set.
  • I have played 76 post-update games and despite those games representing less than ⅓ of total games played on my account, they have already impressively skewed my roll statistics which now report 19% for 1's, and an even 16% for all other numbers.
  • This is irrefutable empirical evidence that the "fix" is flawed. We are talking about a sample size of hundreds of thousands of rolls, so people can shut up about freak improbabilities.Furthermore, the fact that the latter ⅓ of post-update games so heavily skewed what was previously an even distribution among pre-update games, and that the skew was entirely toward only a single number (1 in this case), proves beyond any reasonable uncertainty that the new algorithm biases rolls specifically toward 1 for some reason, and does so in a very consistent manner.
  • There are also several anecdotal accounts in this thread further suggesting a bias specifically towards rolling 1's since the update.

I agree with Glenn's observation that the "fix" is likely a modification that intentionally disadvantages rolls for small armies being attacked by dramatically larger ones, much more so than the attacker's advantage inherent in the natural probabilities. When I have seen large armies attack post update they almost always win, and usually by a gigantic margin. You would expect to see large armies have a completely failed attack on occasion, even to much smaller forces.

This was probably done to shut-up people complaining about the algorithm being broken in the first place (which my data suggests was never the case, as the statistics were perfectly even pre-update) just because they had large armies destroyed by blitz-attacking smaller ones as on a few occasions. 

Also, any programmer knows that the pseudo-random generation of numbers is a function built into the framework of the programming language itself. Therefore, the "roll algorithm" is a very simple feat of building out the 1/6 per die probabilities, there should be absolutely no way for such a simple thing to be flawed in the first place. Ergo, no "fix" should have been required, suggesting that the "fix" was actually a modification that made the probabilities far LESS realistic so that people wouldn't get as upset when chance did not favor them.

So there you have it, I have presented very strong empirical, logical, and anecdotal evidence that the algorithm was never flawed to begin with, and is now flawed as of the "fix." People should stop arguing about probabilities and demand that SMG explain what they have done, why they have done it, and make that portion of the code open source already so people can stop with the asinine complaining.

(316 KB)
(376 KB)
There is some kind of defect in the code which is causing 1's to roll more often than other numbers. My account of 160 or so games with only maybe 25 games under the new version went from 17% across the board to 18% 1's and the rest 16% evenly. I have other accounts which have experienced the same issue. Does this affect gameplay? Not if the bug works for all rolls. But it could result in a few more extreme results since players are more likely to roll a 1 than anything else, thus eliminating more of the ties that should be happening (wins to a defender). However, I disagree that this has caused an advantage to large armies. My complaint is seeing a lot of large armies getting destroyed by very small defenders, something that doesn't happen often. But recently things have felt about normal, other than the more often rolling of a 1 which I do think is actually fair for all players.


I agree. I have a new account that in 5 games has a 23% for one and 15% for everything else. My main account which has maybe 500 games has developed a 17% on the one and 16% for the others. I suspect there is a bug in the algorithm for selecting the dice roll results.

Good news guys. I have been in contact with support about the heavily biased 1's issue and they have acknowledged that this was a glitch in the 1.9.36 release. They say they have remedied it as of the latest release that came out today, so hopefully this should no longer be a concern.

Login or Signup to post a comment