Add 'FlxRandom' pseudo-random number generator

[IQAndreas]

The new FlxRandom class contains the following methods:

float(min:Number = 0,max:Number = 1):Number
boolean(chance:Number = 0.5):Boolean
sign(chance:Number = 0.5):int // Returns either 1 or -1
bit(chance:Number = 0.5):int // Returns either 1 or 0
integer(min:Number, max:Number = NaN):int
item(array:Array, startIndex:uint = 0, length:uint = 0):* // Pick a random item out of an array between 'startIndex' and 'length'
shuffle(array:Array, modifyArray:Boolean = true):Array

Any methods or properties that are replaced by this method get their own little @deprecated tag in the ASDoc, as well as a warning written to the console every time they try to use that method.

[IQAndreas]

Note that the shuffle() function does not have an iterations argument. This new method of shuffling will shuffle every item in the array at least once; calling the method multiple times isn't going to make it "more random". [citation needed]

In Adam's original shuffle() function (and the one currently used by Haxe Flixel) you manually specify how many items you randomly want to jumble into their new location, and it picks these items randomly.

I'm going to be honest, I'm a bit confused why Adam would include such a "programming noobish" array shuffler in the first place. The only reason I can think of is for performance (why waste processing power shuffling the entire array, when you can choose to randomly shuffle half of the items?) However, since he recommends shuffling 2-4 times as many times as there are items in the array, that's no excuse, so I'm just at a loss.

If anyone really wants that shuffle function back, we could add a shuffleSome(array, iterations) which determines how many random items you want to "shuffle around" instead of shuffling everything.

[IQAndreas]

I am quite proud of a few lines like these that became clearer as a result of FlxRandom:

(FlxG.random()*_fxShakeIntensity*width*2-_fxShakeIntensity*width)*_zoom;
randomFrame = uint(FlxG.random.float()*totalFrames);
particle.angularVelocity = minRotation + FlxG.random()*(maxRotation-minRotation);
particle.angle = FlxG.random()*360-180;

Which became (with no extra cost in performance):

FlxG.random.float(-_fxShakeIntensity, +_fxShakeIntensity)*width*_zoom;
randomFrame = FlxG.random.integer(0, totalFrames-1);
particle.angularVelocity = FlxG.random.float(minRotation, maxRotation);
particle.angle = FlxG.random.float(-180, 180);

[IQAndreas]

The final changes to FlxRandom and all affected classes have now been finalized.

If one of you guys could take a look and make sure I didn't do anything silly, it can hopefully be merged today so I can finish moving the rest of the methods tonight.

I also uploaded a test bench for playing with FlxRandom to the sandbox: https://github.com/FlixelCommunity/FlixelSandbox

[Dovyski]

This pull request is awesome, well done @IQAndreas ! :D

The API is much better and easy to understand (as you exemplified above). I've checked all changes and everything seems good to me. I loved the warnDepretaced() method (and I bet all developers out there using legacy Flixel code will love it too!)

Go ahead and merge it.

[IQAndreas]

particle.angle = FlxG.random.float(-180, +180);

I would go with 180 instead of +180.

I realize the + isn't strictly necessary, but I find it makes the purpose of that line of code a bit more clear: "Choose a value between negative 180 and positive 180."

I assumed it wouldn't have a performance effect (at least not noticeable), but I'm okay with removing it if it's more clear without the +.