| JLJac on April 08, 2016, 11:09:25 PM: |
I'd say they should give different results. In the first, each attempt can be a success but in the second, using power you lower the random value and thus the chance of success.
Nah I'm increasing the chance of success by lowering the random value, because it's a positive if the random value is lower than the chance!
BUT, using the code below while the average random value is indeed ~0.5, the power averages are very different:
average UnityEngine.Random.value ^ 2 = ~0.33
average UnityEngine.Random.value ^ 3 = ~0.25
Hmmmm is this true? Because if the average of Random.Value is ~0.5, the average of Random.Value * Random.Value should be ~0.25, to my mind? I might definitely be missing something, probability is so incredibly tricky! Something about how averages actually work, for example

Maybe I should manipulate the chance rather than the dice roll, to keep things a bit saner. I did try something along the lines of:
return Random.Value < Mathf.Pow(chance, 1f / time);
But that seemed to yield the same results as the other faulty setup. One thing that might be playing into this is that I never studied any math above the high school stuff and that's loooong ago, so I just don't have any idea about a lot of stuff.
In fact, TIL that a variable can be not idempotent in C# — that's a seriously scary WTF to me. 

Whaaaaat that's scary!
In my experience my Unity + C# setup has been perfectly deterministic so far (if that's what idempotence means) even when using Random, as long as the random is fed the same seed. I'm even relying on it to a pretty large degree with the randomized creature generation - all the critters save is a seed, and the next time they are to be brought up on the screen they generate their features from that seed... And they've been looking consistently the same so far, at least!
As for the two functions, I should probably have clarified - I understand that they won't return the same bool, because of the one UnityEngine.Random call versus the many - but I expected them to have the same probability of returning a positive.
Currently I just have the loop solution implemented, and it seems to be working - it just annoys me because I feel like repeating over the same line of code lots and lots of times should be unnecessary when there's probably some slicker and less performance heavy solution at hand. Then again I'm not actually experiencing any lag from this. The "time" variable is usually about 40-70 and this TimeInfluencedRandomRoll method is called a few times a frame, which might be fine? For loops should only really be a problem if they have something heavy inside of them, and this loop content seems pretty slim. Still though, rather inelegant!
—
So










