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

Dave Bacher DaveB at battlebazaar.com
Tue Jan 20 20:44:07 CET 2004


On Fri, 16 Jan 2004 08:06:13 -0700, Ted L. Chen wrote:
> On Jan 8 2004, Sean Kelly wrote:

>> I'd argue that we first need to determine that these are the
>> player expectations before managing them becomes an issue.  Are
>> there games where players have argued "but I should have won, my
>> strength was 5 points higher!?"

> The most uncluttered example I can think of is the game RISK.
> Invade a 3 army territory with 6 pieces and you'd think you'd win.
> Experienced players know better than to rely on this assumption
> since the 3 defenders might easily pick off the 6 pieces.  But
> what about novice players?  They're the ones to most likely
> complain, but generally do keep it in check since they do realize
> they're novices.

> Luckily, RISK is a board and die game where it's readily apparent
> that probability is in the mix (die being thrown and all that).
> That helps reinforce to the novice player that "this is
> probablisitic" when his six attackers die horribly.  But in a
> MMORPG, the die is usually hidden.  The only thing left is the 3
> vs 6 on the board.

I'm going to use D&D as an example.

  1 consecutive rolls of "1" -- 1 in 20
  2 consecutive rolls -- 1 in 400
  3 consecutive rolls -- 1 in 8000
  4 consecutive rolls -- 1 in 160000
  5 consecutive rolls -- 1 in 3200000
  6 consecutive rolls -- 1 in 64000000
  7 consecutive rolls -- 1 in 1280000000
  8 consecutive rolls -- 1 in 25600000000
  9 consecutive rolls -- 1 in 512000000000
  10 consecutive rolls -- 1 in 10240000000000

To put it in Risk terms...

If I attack 6 on 3 once and lose, I'm likely to complain a little,
but write it off as chance.  If I fail twice, I'm likely to complain
a little and write it off as chance.  If I fail 20 turns in a row,
then I probably have a valid complaint -- either your dice are
rigged or you are impossibly lucky.

If every time I play with you the fights go like this, I'm going to
believe strongly the dice are rigged.  If every time I play, you are
impossibly lucky, the simplest explanation is that you are cheating.
And so, I will call you on it.

If a player is complaining, it makes a lot of sense to look at the
problem.  It makes a lot of sense to look at logs and perform log
analysis, and to determine if the complaint is valid or not.

The C PRNG is a LCG.  If you don't replace it with your own
generator, it is useful for only short series of numbers before it
starts having cycles and streaks.  There are a lot better
generators, even PRNG, out there -- ones that are many times better
than the C one, and any good book on Computer Simulations will have
code for several, including the C one, and an explanation of their
strengths and weaknesses.

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.

Assuming low rolls are bad (they generally are in most systems), if
you are using the modulus operator you're skewing results towards
failures.

If you show me the results of the rolls, then you have to be
confident there isn't actually a problem, because if I perceive a
problem, the first thing I'm going to do is run the logs through an
analyzer and see what numbers come out.  In the most probably case,
I'll find out there really is a skew, and I'll proceed to post it on
a web site and it will become a much bigger issue than if it had
been owned up to in the first place, especially on a large game.
_______________________________________________
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