[MUD-Dev] [DGN] The psychology of random numbers

Kirinyaga lanjk.ro at laposte.net
Wed Jan 28 11:20:15 CET 2004


From: Hans-Henrik Staerfeldt [mailto:hhs at cbs.dtu.dk]
> On Wednesday 21 January 2004 02:44, Dave Bacher wrote:

>> The C PRNG can be made worse by using modulus to scale results.
>> You can only properly scale results with a multiply followed by a
>> divide, assuming integer math.  Any other technique, particularly
>> modulus, skews the results.  Lets say the maximum number the LCG
>> can generate is 32767.  If you modulus that by 100, you'll see
>> that 68 through 99 occur less frequently than 0 through 67.  If
>> you modulus by 1000, 768 through 999 occur less frequently, and
>> if you modulus by 10000, 2868 through 10000 occur less
>> frequently.

> This is an interresting and very useful piece of knowledge!
> Usually, your standard I wonder though, if use the usual C PRNG
> are used, how many rolls do you have to make before you can
> determine this skew with any kind of statistical significance,
> using the usual C PRNG's, let alone notice this by playing the
> game?

> So i made a little program to test some of this;

...

> As you can see, by rolling 100 million times on a d20 (well a
> d20-1, not important), the modulus count of a given dice varies at
> most 0.067180% from the expected for the 11. I know, i should do
> this for several seeds, but i guess someone can contradict me if
> my numbers were just a fluke.

I copy-pasted your program and got similar results. However I
increased the dice size to 100 then 1000 and it gets worse (but
still under 10%).

As another poster, I think the gaussian distribution is what we all
"naturally" expect for random events. I don't think however
introducing a bias will make any good.

A random suit is by nature not predictable but statistically. If you
know, given a low percentage of success, that after a success you'll
never have another success, it is predictable, it is no longer
random. That's "why" you have sometimes suits of success : "for" you
not to be able to predict the result. To contradictate your
assumptions.

Indeed, if you know that, you'll be able to screw the carefully
chosen percentages. For example by switching to a serie of quick,
low-cost tests after you got a success on a long, high-cost
one. Designers will soon have to go through math courses to assigned
any percentage of success to a given skill, just to get the same
number of successes per unit of time that was initially
designed. And players will have very various overall successes/time
depending of the method they are using. This introduce a serious
design problem.

Also, if you choose the bias method, you have to keep the state for
every player, every mob, maybe even every skills per player, wich
may become a serious dev problem as well.

That's not the case with a gaussian distrib however. I think
gaussian may be the solution. The designers have to well understand
the implications however. For example the fact that doubling a skill
level doesn't always translate to a double chance of overcoming a
given difficulty. This may also cause another PR problem btw.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list