Join us in Outworldz at or follow us:

Best tools for Second Life and Opensim - Gausssian Random Numbers

Sometimes when you are programming you need "something" to happen randomly. Such as when shooting a gun at another player: you want it to not always hit and do it randomly. Maybe you want to have a physical thing happen, like a ball to fall onto a spot, but you don't want it to hit the same spot every time. There are lots of physical things that need some randomness. Flight of a bird, the waves that rock a boat, the aim of a gun; these things need a way to calculate the center around some value and then fluctuate randomly.

We have functions which gives you a random number. In Opensim/Second Life, it is llFrand(). It returns a random number. But it is too random! Let's say you want a coin flip odds, with a 50/50 chance of hitting the player to start with. A simple example would have the program check if the random number is > 0, then the bullet hits; and if negative or zero, then the bullet misses. Sounds simple, right? An easy way to target that gun. Well, you will get quickly angry players shouting at you that the gun is broken or the other player is cheating. Why?

Uh-Oh It's because its possible to never hit the other player! It is actually pretty likely to get a long run of random numbers that never make the bullet hit. Just like flipping a coin, you could flip a long run of heads, one right after the other. A run of 10 coin flips all being the same has odds of 1 in a 1024. If that happens, after shooting and shooting and shooting again and again, the player thinks that the game is broken. Or they believe someone is cheating, or that you suck as a game programmer. In games like Grand Theft Auto, with millions of players shooting guns, thousands of people would be thinking the game is broken all the time! Imagine what happens when people shoot at the other guy ten times in a row and every shot misses! It must be broken. But it is not. It's just randomly happening. It's like the odds of one in a million that is widely cited. But that still happens 6 times a day in my city.

Tune it! Another problem with random numbers is when the player gets better at shooting, or buys a better weapon, you want them to hit more often, but still miss sometimes. You need a tuneable random number generator.

One more problem: all the values of a random number range are equally likely. That's the very definition of a good random number. But that means that it is possible to pick a number far to one end of the scale, or the other end - all are equally likely to happen. Picking one number randomly Is just as likely to happen as any other pick. So youyr gun can shoot very widely off target - unbelievably widely.

Shooting a gun properly

So let's think of shooting a gun: we want the aim to be a little shaky, but not too shaky. We know that's a problem already as a truly random number would make the gun shaky all the time. So let's assume we are going to shoot a bullet at 90 degrees, and then chose a random number to jiggle the gun just a bit so they miss sometimes. A number like +/- 20 degree might mean a cheap, poor quality gun. we just program is so the bullet hits when near zero, and missing otherwise. And we need to fix the the problem where we could get a run of numbers, like 19 and 20, over and over well away from zero, and never hit.

Humans don't think a gun should do that, but random numbers like llFrand() can and will generate those unbelievable numbers . We expect out gun to mostly shoot in a circle, and rarely - if ever - shoot outside that area. A lot of physical phenomenon are like that: such as falling objects that we expect to fall near one spot, and it becomes less likely that they fall well outside that area. It seems like random number generator is the last thing we want.

So whats the fix? You need a random number generator that makes short runs of random data, with poor odds of a long run of heads or tails, and you need it to be able to get better or worse for better guns and better players. Ideally, it would return numbers 'centered' within a range around the guns ideal aim point, but usually not too far, and on rare occasions, allow the bullet to go far off. We need a 'less random' number.

What is needed is a "Gaussian" random number function. A Gaussian random number generates a curve that is humped around a value. It tends to be close to the expected value most of the time. You can make it to return a value near "something", some percentage of time. And we can make that error in the value be programmable, too. Like this chart:


So what? So I ported a common game function gauss(mean,deviation) from for Opensim/Secondlife gamers to use. It takes a center value and an error around it as parameters, and returns a "Gaussian" random number.

The script is at Gaussian Random in the free library and is free to use.

Lets look what happens when we use this random number in a game. Let us assume you are shooting a gun at a 90 degree angle with the new function. And we want a cheap gun, with a randomness of 20. When it calculates gauss(90,20) the value returned would be within 20 degrees (one standard deviation) of the desired direction (the 90) about 68% of the time, and within 40 degrees (two standard deviations) about 95% of the time. Each standard deviation is less and less likely to happen.

Now let's assume your game player buys a better gun. You change the number from gauss(90,20) to gauss(90,5) in this 'better' gun. Now the bullet will be within 5 degrees 68% of the time, and within 10 degrees 95% of the time! There will still be very rare but possible wild shots. And now it is clearly a better gun, worth more money now.

So how does it work? The charts shows a histogram test I ran of 300 "Gauss" numbers centered at 90 degrees, with gauss(90,5) as a parameter. You can see they center around 90 degrees, and are starting to hump up around 90, and tail off, just like a Gaussian curve should. The other graphs show what it would look like using 0, -2 and various error factors.

Back to the Best Free Tools in Second Life and OpenSim.