Fix your random number generator

I get this often when chopping a tree. 100% to chop but fail two or three times. Same with mining and skinning. I agree the random generator needs some work. But its something i have gotten used to. Hate to have to be that way but oh well

 

Interesting. This is purely for knowledge if you are interested.

From: http://www.atarimagazines.com/compute/issue90/The_Beginners_Page.php

Rolling Dice

Let's try another example. In rolling one die, the possibilities are numbers from 1 to 6. To simulate a roll in BASIC, we use the statement

D - INT (6 * RND(1)) + 1

Now let's shake two dice. Your total number will be a number from 2 (one dot on each die) to 12 (six dots per die). The formula is INT(11*RND(1))+2. In general, to choose a random integer number from A to B, inclusive, the formula is N=INT((B-A+1)*RND(1))+A.

Now let's try a short program that prints ten random numbers in the range 1–10:

100 FOR N = 1 TO 10
110 PRINT INT(10 * RND(1)) + 1
120 NEXT N

Run the program several times. If you are using an IBM PC, Atari ST, or Amiga, you get the same sequence of ten numbers each time you run the program. Knowing this sequence may help when you are debugging a program, but if you use the same sequence for a game, the game soon loses its appeal. So, for the IBM PC, Atari ST, and Amiga computers, you'll need to add the RANDOMIZE statement. RANDOMIZE needs to appear before any use of RND. To add it to the program above, add this line:

90 RANDOMIZE

Now, each time you run the program, you will get a different sequence of ten random numbers.

Different versions of BASIC use RANDOMIZE differently. You may need to specify a seed value that tells the computer what value it should start with. If your computer requires a seed, and you use RANDOMIZE by itself, the computer stops the program and asks you to enter a number. This number is used to generate the random number series. Having to enter a number can be a nuisance, so RANDOMIZE lets you specify a seed value like this:

RANDOMIZE X

or

RANDOMIZE 0

or

RANDOMIZE 532

However, if you use a constant number as the seed, the numbers will still be the same every time the program is run. On the Atari ST, RANDOMIZE 0 (that's a zero) makes the computer provide its own random seed. On the PC and Amiga, the statement RANDOMIZE TIMER tells the computer to use its internal clock value as a random seed. The TIMER value is almost always a different number each time the program is run.

The RND(1) function in the versions of BASIC for the Apple II and Commodore eight-bit computers does not return the same sequence of numbers each time a program is run, but it does always start with the same sequence after the computer is turned on or is reset. Although these computers do not have a RANDOMIZE command, you can still reseed the random number sequence. For the Commodore 64, a statement of the form X = RND(-TI) is equivalent to the RANDOMIZE TIMER statement described above.

In Atari eight-bit computers, the RND function returns random values generated by a hardware counter in the POKEY sound chip. Atari BASIC's RND function is therefore more truly random than in other BASICs, and no special randomization steps are required.

 

Here.

 

Thank you @GreyMouser Skye we've attempted to explain this a few times and theres a number of ways to achieve the result but you just did a much better job, kudos !

This discussion kind of reminds me of the Are we a MMO thread... lol... so much arguing about the fact that its working, its the right definition !!!

Well what if its not fun, or equally people perceive its being unfair.

3 fails in a row with 100% ? common... its a game.

Either make it work more often, or reduce the numbers listed so at least people know there is a great risk of loss.

 

So this has been up for discussion about every 6 months or so over the years.

I think I've started the topic a couple of times before persistence since I was getting regular long chains of improbable results.

Chris has looked into it and investigated the seeds and the rng on at the very least 3 occasions over the last years. The statistics in the db as given by the results of gathering and crafting confirms that the RNG works like it should.
So statistically @Arlin seems proven right by Chris' investigation. When compiled with a big bunch of data the % slightly favor the player, although I think it is way less than the 1% Arlin got.

With that said though there are a couple of caveats:

1. They don' fudge the dice, thus the experience doesn't feel like it is random, like Net pointed out above. Most games with critical RNG fudge the dice like in the Apple example above.
2. The statistics is the AVG(SUM) type so doesn't detect long strings of fail/success. So it might be that some days are lucky and some days are unlucky - but that it evens out over time.
3. They use many many many seeds. It is not just one pseudo random seed and that is it.
4. At start they used a unity plugin randomizer but after same big data testing didn't like it, so they wrote a hack to make a better homebrew solution.

So that is the info we've got from the devs.

My personal opinion is that I deal with programming all the time at work and I'm a superstitious old geek, so when I hit a too long fail streak I reload the client.... but don't tell Chris.
Also I don't think that the value that is written on the screen is the same value which is used in the actual roll. Rather that is the base without interference, but the interference isn't listed.

 

Just think about it for a moment, the biggest online casinos have spent millions on their RNG which is a sophisticated setup with multi physical RNG seeding multi pseudo-RNGs...

well guess what even with all that, if the casino does not reach the minimum amount of money returned as allowed by the law, it needs to also seed winners AGAINST the rng.

And its a money game where fairness is even more important. Yet every once in a while, the "winner" rng will overrule the main RNG, because even when "it works" what if the sample required to prove it works is 1 in 10000, well that means over a whole month many players could get unlucky.

 

If the roll is done client side that means there is an exploit that would allow you to bypass the RNG roll entirely, so I would be very surprised if reloading the client did anything.

 

Hahaha, I do beleive they came up with a homebrew solution, but the fact is the game should list a number that fits with what is being percieved, not the pure math, and once in a while it should override itself, heck we realised that about 10 years ago when programming a heavily scripted freeshard for UO.

When we realised people fell into superstition as you said, we programmed an AI script that would even out the results, much like the online casinos use.

Most players aren't going to wait until they get a sample of 10000 before they decide if the system is fair enough for them to spend time on it, and we WANT them to spend time on it.

 

It is not... the devs are PARANOID about being hacked... somedays I wish they listened to us freeshard devs instead of just using us for free publicity.

 

In a game that is supposed to be based on skill and where people have for years suggested excellent mini game ideas that would make it less dependant on RNG... it seems awful that its all luck and no skill.

A grandmaster smith does not fail at making platemail... and they do NOT lose their materials if they do because they were looking at the woman in the red dress instead of their hammer (aka NOT luck).

 

superstitious != logical || superstitious =! working

It is just a ritual which makes me feel better about it.

Although some of the rolls are client side - just not the ones which matter, so things like gathering or crafting are indeed server side. But the pseudo random needed for the graphics view for instance is of course done client side which means you could potentially hack it to get all your plants to seed in neat straight rows but there would be no point.

Agreed.


Hence why one of the caveats I used was that they don't fudge the dice.
Which in my book is a mistake since perception eats reality for breakfast.

 

Fair enough.

If the basic crafting system wasn't an unfinished mess no one would care about this. Which is why I would prefer we talk about that instead.

 

I can't handle this.......I'm still trying to figure out if we are an MMO or not!!

 

I think that there is good chance that the behind-the-scenes calculations are correct, and that the problem is what they are showing us.

 

Since the early days of the UO forums, there have been threads complaining about random number generators.

They are always entertaining.

 

I don't think anyone thinks its your fault Chris, but lets just find a solution that relies less on pure math

What do you mean by numbers being displayed ? The % chance of success ?

 

A "shufflebag" system is quite possibly the only way to satisfy users while still keeping the unpredictability of randomness. It's not rocket science; I wrote a script that did that in an afternoon.

Here's a simpler (crude-er) version of it:

Code:

private <vector2, int[]> shufflebag = new dictionary<vector2, int[]>();
//the key is the type of bag, array[0] is the clean counter, array[1] is the cursor and the rest are the values

public int Draw(int min, int max)
{
int[] theBag = null;
if (shufflebag.TryGetValue(new vector2(min, max), out theBag)) {
if (theBag == null) {
//no bag found.  create it.
theBag = new int[max-min+2];

for (int i = min; i < max; i++)
{
shufflebag[i+2] = min+i;
}
shufflebag.Add(new vector(min, max), theBag);
} else {
theBag[0] -= 1;
}

//move the cursor
if (theBag[1] < 2) {
theBag[1] = theBag.length-1;
} else {
theBag[1] -= 1;
}
//take random element up to the current position of cursor
int num = Random.Range(2, theBag.length);
int tempData = theBag[num];

//swap the drawn number with the number the cursor was pointing to
if (theBag[num] != theBag[1]) {
theBag[num] = theBag[1];
theBag[1] = tempData;
}

//clean unused data
int numOfTimesBeforeClean = 10;
list<vector2> deleteBag = new list<vector2>();
foreach (KeyValyePair<vector2, int[]> hash in shufflebag) {
int[] theArray = hash.Value;
if (theArray[0] > numOfTimesBeforeClean) {
deleteBag.Add(hash.Key);
} else {
theArray[0] += 1;
}
}
if (deleteBag.Count > 0) {
for (int i = o; i < deleteBag.Count; i++) {
shufflebag.Remove(deleteBag[i]);
}
}

return theBag[1];
}
}

It uses whatever "random" algorithm you want and then controls it for a more balanced experience.

 

Yeah, sorry.

It is funny, though, that no matter how well you explain it and prove that everything is working correctly, there are those who will insist that it's broken.

 

Many values in this game are being rounded for display. The chance of success displayed in the crafting window is one example.