This is an archive of the Smiley Productions website. Our games are still available for download, but this site is no longer maintained, and the forums do not function. A Smiley Productions Google Group has been started for anyone who would like to stay in touch. Thanks to everyone for the many years of support!

Dice not Random!

Somewhat annoying, but what logic is used to ramdomize the dice thrown?

I find myself for example regularly losing 10 units to my opponents 2. Even when attacking with three high dice and thus gaining a significant statistical advantage, often I will lose 5/6 units in the process.

I understand the AI is poor and as such defenders should be given some advantage, but when I have 20 units v 10m, often I fear I won't be able to hang on to my units.

Hey.. .first post in 4 months... awesome.

Re: Dice not Random!

The implementation uses the standard Java pseudo-random generator. No undocumented bias was added to the program; mathematically, the model is identical to a set of real dice (unless you don't trust java.util.Random either).

The game is called Risk for a reason :) Having more armies doesn't guarantee a crushing victory, or even victory at all. For example, with 10 armies attacking 2 using normal dice, the defender has 1% chance of annihilating the invading force. Life is like that. Now think about how many invasions are performed in an average game; there is a significant probability that some of the outcomes will be perceived as "unfair" (good rolls for the side with fewer armies, usually the defense). You can't force a win in Risk, you can only make a move that yields the highest probability of a win.

Re: Dice not Random!

Harvy, you make it sound like all Java class libraries are perfectly-engineered. As someone who spent *a lot* of time playing with random numbers in BASIC as a kid, my sense is that pseudorandom generators aren't impressive enough to be really fun.

Here's what one Java website has to say about util.Random:

...the quality of random numbers produced by this method varies between "unbelievably disastrous" and "OK for casual applications". XORShift so simple that the code to generate numbers can often be inlined where you need the numbers generated....In Java, good candidates for using this generator include J2ME games.

What piqued my interest was when the OP said he was losing 10-2 multiple times. Like you said, that's about a 1% chance, so what's the likelihood that it would happen more than once?

A good way to verify util.Random would be to let it run all day and see if the results are statistically even.

Re: Dice not Random!

There are people who get paid a lot at Sun to verify the randomness of java.util.Random. I'm not one of them ;) I'm just saying I didn't bias the dice in favor of either humans or AI.