RNG (Random Number Generator)

I was originally going to title this post the problems with Splinterlands RNG. But I don't know that is fair to Splinterlands and the fact I don't know exactly what they are doing to say what is the problem with the RNG. During Splinterfest one of the biggest battle had 3 stuns in a row to win the fight. During a townhall Aggy mentions the RNG gods said not today about the battle. Though I thought to myself that is just Splinterlands RNG.

I have gotten to the point where when a battle happens once the first miss or hit on a flying, dodge, or blind creature happens I start to call what will happen. Definitely after two hits. Is the RNG sitting around 25% so I'll miss or hit. Is it just below 25% so I hit once but the rest are missing. As the battle plays out I can call it. Granted this doesn't mean I'm right, say I hit once with a 25% miss chance then miss 3 more times that doesn't mean it was 26, 25, 24, and 23 like it is in my mind. It could have been 99, 15, 3, and 24.

But is this RNG?

We routinely see fly a 25% chance, dodge a 25% or even blind with a 15% see you cards missing 3, 4, 5 or more time in a row. Is this bad RNG? Is a 50% chance to stun or retaliate that never happens in a match when you have 2, 3, or 4 chances bad RNG? I've had game where all 6 of my cards miss a flying cards for two straight turns 12 misses out of 12 chances the probability of that happening is very low but we see this consistently though out game play from streamers and our own matches. Now Splinterlands does what millions of battles so our own matches and streamed matches is what 1% or likely a lot less than 1%. So do we just happen to have the bad luck or this consistently happening.

Overall across battles I'm convinced the RNG is "equaling" out but within a battle it doesn't and in fact is horrible.

RNG will eventually equal out?

One thing you hear from people a lot when talking about games and artificial RNG is eventually the RNG equals out. Now if you are talking about natural RNG this is 100% true. But when you are talking about artificial RNG no this isn't the case. Lets take 4% chance for a GF (or with Lux 2%). You can get 100 card does this mean you'll get 4 gold foils? No. You may get more or you may get less. Or if you are Hive account@moookiller you may get 2 gold foil Lux's.

Okay you get 100 cards and no gold foil... so if you get 100 more cards you should get 8 gold foils right? No. Even in natural RNG there is a chance you can get 1000 cards and never get a gold foil the chances are low but the probability is there. So the only way to "guarantee" the RNG is for say if Splinterlands says it's a 4% chance for the card to turn gold foil and a guarantee 4 in 100. So if you haven't gotten 4 by the time card 97 comes up then 97, 98, 99, and 100 are made gold foil by Splinterlands. Because it is artificial RNG it will never equal out on it's own. It will more than likely come close to equally out but the number of times the RNG has to happen for it to equal out could be small for some players and very large for other players.

Code based RNG

When dealing with code based RNG there is usually a function provided by the programming language used to produce a random numbers. Then when you use this function you can provide a seed or not. On one of the THs during the Q&A the question was asked about Runi, if you look all the Runi minted generally have a block of three that all three share a very similar traits. Aggy answered it means the seed was probably every close together. So what is this seed and why is it important. Well most programmers if they use a seed for the RNG function will typically use time in milliseconds this is because it's the easiest piece to use and changes every time the code is run and changes drastically over time.

Okay so this sounds good since normally most programmers don't care about the functionality the seed provides they care about the randomness of the number generated. No we enter the block chain where you'll hear Aggy talk a lot about a transaction being validated. Well if they are generating numbers how can they be validated. This is where the seed comes into play. If you seed the RNG function the next time you run that RNG function with the same seed you'll get the same results. What this allows for both Splinterlands battles and Runi is the transaction for the battle or creation of the Runi can be validated by anyone else no matter when they process the transaction.

So I've thought to my self many times that SL isn't doing enough to randomized it's RNG, it's base line RNG, or possibly even bad usage of RNG. But once you start to think about the need to validate a transaction on the block chain the issue may not be that they aren't doing enough to randomize the RNG, using base line RNG, or even bad usage of RNG it's likely tied to the seed and the need to validate the transaction.

Normally in a centralized environment you'll have some server sitting somewhere that hold data. Now this is where I don't know enough about blockchain, what Splinterlands is doing, and overall de-centralizing the environment. I know Matt talking about licenses at one point said the code that will be packed up to run the licenses will create the database it needs. So if each validator node has it's own database how does the sharing of information happen, when someone get or buys a new card that card is added to the account that has to live somewhere for it to be used?

So for now in my assumptions I'm going to take any form of database out of the equation. So if a Splinterlands battle or Runi mint needs to be validated how can they do this without having the seed stored somewhere? My assumption here is going to be they use the transaction time. Ever transaction has date / time associated to it. If this date / time is used as the seed then anyone process that transaction down the line can reproduce the same results using the same seed at any point in time after it happened.

Visually RNG

So what I have done is randomly generator a bar chart with 100 entries, generating the background color which is actually using the RNG function 3 times; one for the Red, one for the Blue, and one. for the Green color used when producing a color to display usually called RGB. Then I generate 1 number for each bar which determines the height of the bar. So I am generating 400 numbers to create a bar chat and that generation happens in less than a millisecond. Why is that important? Well if the transaction time is used as a seed and we hear a lot that blocks on hive are 3 seconds that is 3M milliseconds per blocks. The odds of two battles coming in at the same millisecond is very low. So overall this seems like the RNG from battle to battle will vary nicely. But the issue is the RNG in the battle because it happens so fast.

Reproduceable charts using the same seed

So below you'll see 4 bar charts (I did 10 but showing the other 6 is pointless) they are all the same. This is because for this run of the bar chart I set the seed to a singular value. So if I run this same code in a week I will get the same charts then as I got now. This means it can be validated.

Overall the first thing you'll notice is the background. The one thing I noticed producing the background using 3 RNG calls with a seed is the background colors all become very similar or the same.

The second thing we is the clumping or grouping of values. If you look at 50 - 62 you can see a very low set of numbers... here is your 6 flying misses in a row. Or a high / low, high / low grouping if the RNG is alternating that could mean you miss and your opponent hits.

The bar high is 0 to 99 basically representing percentage rolls but as you can see there are bars in the chart that are the same and even 3 or 4 of the same number in 100 rolls. You'd expect to see more of a spread on the bar height but it could also be randomness. This dilbert cartoon explains it the best.

Seeded RNG

Here I used a seed but it was time the call was made to produce the chart. So as you can see the they are all different but again we end up with the background colors similar or the same per chart with a couple that switch part way though. The there is still some very strong grouping going on within each chart for the bar height.

No Seed RNG

The first thing you will notice is the bar colors while there are some similar colors next to each other are are no where near what the first two bar charts were for bar colors. You have some grouping with the height of the bars but overall the bar heights have more variance.

Take away

With RNG you'll get some grouping it is bound to happen with "artificial" RNG. Then when you start needing to make it reproduceable to be validated the grouping seem to happen more frequently. While this explains the RNG we see what does this do to help us?

Overall I think Splinterlands needs to move away from seeded RNG and if they have the ability or if it's possible the results for percentage roll is then saved somehow for the later validation. So when the battle happens there is no saved RNG so the code creates and saves it. Then when the validation happens the RNG is save then the code uses the saved values to validate the battle happened as reported.

IDK know if this is possible or even the level of effort or work required to do it but overall Splinterlands needs to do something about increasing the variants of the RNG used with in a battle. Again it is probable to miss a 25% chance to hit 6 out of 6 times or even 12 out of 12 times but the frequency these are happening is far to frequent.

Signing off

Come join the Splinterlands community.