You are confusing random independent values with âtrueâ values. It is not related to gambling outcome or estimation of âtrueâ probabilities which is the same as winning. The test simply tells you whether you have drawn your sample from random and independent pool and this hypothesis is rejected at 95% probability. Adding more samples will not change the nature of the pool you are drawing from. It will however approximate âtrueâ value better but this was not the purpose of the test. Adding more samples will just obscure the results due to Central limit theorem: Central limit theorem - Wikipedia . Iâve explained it quite a bit in the original thread but obviously, nobody bothers to read. And I understand that, the subject is not so trivial from common/general point of view.
There is no good or bad luck, âluckâ is just a set of numbers. There are also certain government and industry standards and the standards actually work well in this setup. So, we are talking about different things here.
Iâm not going to get reasonable mastery of those topics from the wikipedia articles, but I did notice the runs test only says âthe hypothesis may be rejectedâ.
Statistics and intuition do not usually go hand in hand, but I think what you are saying is something like:
The runs test looks at something like, âHow many strings of resurrections occur?â
The distribution blindly looks at the number of âhitsâ or âmissesâ.
So in a way weâre arguing two different things. Iâm saying, âIf you did 10k runs the resurrections wouldnât vary much from the 2,500 expectedâ. Youâre saying, âUsing more complex analysis we can predict how many 2-hits or 3-hits should happen and Iâve observed a bias.â
Thatâs an interesting suspicion, because I think most people arenât as bothered by 1-hits as they are 2 and 3. Those hurt, and if they happen âtoo muchâ players get real mad.
It still seems to me that if your sample set were larger, the Runs data would have more confidence. Taking 5 samples is obviously ânot enoughâ, I donât particularly see how that gets fouled up as the set gets larger. I have a feeling the more common problem is people tend to get swayed by âIs the distribution right?â once the data set gets âacceptableâ.
The Runs test sounds like one of many âproperties of randomnessâ you can test for and I hadnât considered those. At the very least I agree, âIf the RNG is unfair, it should unfairly favor runs of 1.â
It is, in fact, only one of a very large suite of tests that a RNG is evaluated against. That being said, it sounds like @akots believes the data is being tampered with, but the end result is that the distribution (and only the distribution, not the expected outcome in raw percentage) is affected. I would have to ask how one would go about writing this code, it seems like itâd be a lot of work for very little benefit.
Then again, perhaps itâs the fault of the underlying RNG algorithm itself. Considering the game is C#, the two most likely such engines are Monoâs implementation of System.Random, or Unityâs UnityEngine.Random. Perhaps they rolled their own, but most likely they chose to use one of these two approaches for generating their random sequences. I donât know how either one performs against Diehard or Dieharder, but I imagine theyâve both received some level of independent scrutiny.
I am pretty sure Microsoftâs System.Random had some well-known flaws, I wouldnât be surprised if Mono did as well. From what I gather âsmart peopleâ tend to copy/paste their own Mersenne Twister implementation and donât rely on the system RNG when writing a game.
It does not have to be âtampered withâ, IDK what that means. I am not a global conspiracy proponent by any means. At worst, it can be some coding inaccuracy (which we have a plenty as of recently) or unexpected association with something else due to complexity of the code. Finally, it can be just a non-randomness of meeting fully traited TDS and not stunning it which might not be really random events if I understand correctly. I just presume they are random over the course of many sessions. However, apparently, each session or series of sessions might have used different seed numbers, IDK how that works exactly and what triggers the reset. Might it influence the result? It very well might, all tests are typically run using continuous pRNG output. This one is impossible to run like that. It should have evened out, theoretically.
As you noted, the output of pRNG may be more complex than it actually seems and it might differ from uniform random as produced by Mersenne-Twister core pRNG (used by Unity/GoW and Excel and I used Excel to generate the simulation) depending on the call function. By itself, Mersenne-Twister pRNG passes most quality tests Mersenne Twister - Wikipedia and is considered a good industry standard. I used it for simulation and it works splendidly. And I used Excel 2010 which has âpatchedâ pRNG and the tests confirm that.
Keep in mind that Mersenne Twister is an algorithm and performs better or worse depending on the coefficients that are set. C# uses MT19937-64, Excel and Unityâs random coefficients are not published.
In general though, pRNG, being a predictable sequence given a known algorithm and seed, is by its very nature not independent. Any independence (as predicted by the aforementioned tests) is simulated independence, and while interesting when taken at face value, is hard to imagine a mitigation for.
It is acceptable to consider the output independent as long as it passes the required tests. It is a major regulatory issue with online gambling and especially cryptography.
However, all probabilities should ideally be calculated dynamically. So, strictly speaking, Gamblerâs fallacy principles are not applicable to relatively long pRNG sequences ( Gambler's fallacy - Wikipedia ) as they are not truly independent. That also justifies that small error estimation of average/expected typically requires extensive testing (thousands of samples) due to Law of large numbers ( Law of large numbers - Wikipedia ). The whole theory here is quite complex.
On the other hand, determining whether distribution is random and independent is not that difficult as long as the output sequence fails the test. If it passes the test, this does not prove much though.
In Microsoft applications, the seed number cannot be set or recalled. This is obviously done for added security as the same function is used to provide additional layers of system protection and might be used in encryption algorithms ( Randomness in Excel | Bit Wrangling ) . Apparently, it can be recalled/reset at will and might be used to generate predetermined sequences repetitively in Unity but IDK really.
Cryptography has very different requirements regarding randomness than your typical game pRNG, though. Cryptographic random generators are typically much more expensive and rely on sources of entropy that do not lend themselves to producing repeatable sequences (which is actually important to games, in order to reseed and replay events without having to store the results of each random event).
Indeed, cryptography becomes more and more advanced. Various services specialize in providing true random sequences for a fee like this one : https://files.random.org/ Some encryption algorithms can even get a set of dynamic random numbers and actually use random.org quite extensively. They might be more expensive to license but are not necessarily better or more advanced. However, they are usually certified or completely proprietary/protected to justify their costs. By all accounts, Mersenne-Twister is adequate for most purposes.
Without implying that this is what Gems does under the hood, a hypothetical benefit would be to enforce ârandomâ chances happening as often as they âshouldâ; i.e., upon noticing a longer-than-expected streak of misses, deliberately insert a streak of several hits such that the total from the beginning of the miss streak through the end of the artificial hit streak contains the âcorrectâ percentage of hits.
Itâs certainly more work than most games are likely to do, and I donât have any reason to believe that Gems does it - but to your point, there is a benefit there, in terms of funneling random events towards desired results.
I just want to say how much I enjoy reading threads like this one. I sincerely hope that I can grow smarter through osmosis. You all are very impressive mathematical minds!
You might be actually in quite a big surprise. A lot of games do tamper with their pRNG results. The video is Sid Meierâs talk and the part about pRNG starts around 18 minute. It might be considered to be a âproperâ approach to game design. I think I already posted this link, still kind of useful for the subject of the thread.
I managed to destroy a Dungeon Boss Umberwulf with Infernal King because my IK resurrected 6 times in that battle. Iâm pretty happy with those results and itâs why I can accept when a TDS or IK resurrects when I am battling them.
Itâs been almost two months since the start of this thread and today was the first time when my Dragon Soul resurrecting actually mattered and won the match for me.
In the long run resurrection rates are about the same for player/computer. The difference I notice is that AI is more likely to get a streak of several resurrections in a row and its resurrections are more likely to make an impact (combined with skull drops/cascades/loops).
Yea. This happens once a day, maybe one in 20 matches, where there are ~15 low probability luckboxes in a single match. Two resurrections, 5-10 extra turns and 5-10 super weak boards for âhumanâ to play with.
Itâs the state of the game. A lottery bang-bang.
This used to be an interesting game. A long time ago.
What about not using Infernus against TDS? Because its rather expected that when CPU gets TDS going and there is a storm in play that it will take fully advantage of it.
You can check wiki WaldâWolfowitz runs test - Wikipedia for simple explanation, real-statistics.com for mechanics http://www.real-statistics.com/non-parametric-tests/one-sample-runs-test/ and National Institute of Standards and Technology website on random definitions and testing Random Bit Generation | CSRC .
