I think probability is off

[General Jelly Jiggler]

I have been doing some probability calculations related to this game, and I think that the probability determining engine for some reason ends up triggering much less than might be expected. Any sort of 1 in 4 or 1 in 2 chance etc. Hits for much less, and very consistently for much less. As an example, the probability of a 1 in 4 chance of something occurring at least once in 3 attempts is about 60%. Even with brainstorm on space joker, it seems to hardly ever trigger. I almost always have gros michel for many many antes, Although I sometimes think lucky card triggers more often for some reason than it ought to. Is there some way to look at the game code to determine how the game rolls these random chance type cards?

[Zelakon]

There is a way to view the code to determine probabilities, and I'm sure Goblin can/will tell you how.

However I can confirm they're all fine, and you'll just be judging inaccurately due to using too small of a sample size.

[Scrub]

plural of anecdote isn't data, can you share your findings?

[Astroooooooo]

All I know is, that stupid banana that gives +15 disappears WAY more than 1-in-4, and the Wheel of Fortune Tarot card works WAY less than 1-in-4.

[Scrub]

Originally posted by Astroooooooo:

All I know is, that stupid banana that gives +15 disappears WAY more than 1-in-4, and the Wheel of Fortune Tarot card works WAY less than 1-in-4.

I cannot get my banana to die, it lasts 6-7 rounds the 3 times I've bought it

[A bear]

I got one at the beginning of the run and thought my luck was legendary that it lasted to the end. Then I finally noticed it was eternal.

[Goblin]

Originally posted by Scholar Asleep:

There is a way to view the code to determine probabilities, and I'm sure Goblin can/will tell you how.

I was away yesterday, no one else can tell people to unzip the executable?

From what I've seen from the code the probabilities should be fine, and the numbers aren't cooked (i.e. they don't claim 1/4 then have different odds in for gros michel vs glass breaking and wheel hitting). Someone else also did a number crunch on about ~150 cards and got 29% hit rate with roughly the same number split for resulting editions as in the code: https://steamcommunity.com/app/2379780/discussions/0/4293691221506323823/?ctp=3#c4293691425577911584

I could do a bigger sample size using developer mode, but it'd take longer than whatever method Cosmic used to get 30 wheels at once - I'd have to go to the collection, spawn two wheels, go back to use them, repeat. Plus giving myself new jokers when they all have editions. So since I'm not the one who thinks there's an issue, I'd rather not spend hours doing that.

[Jam Warrior]

I got the 1/1000 banana and it broke on the next blind. Chance gonna chance.

[Petey]

My glass cards always break but I never win the wheel

[snakeskip]

What people should realize is that screwing up probabilities is not a common game programming error. Programmers rarely implement their own RNGs. Instead they're using well tested and widely used RNGs. Using such RNG to produce certain odds like 1:4 is a most trivial programming task.

[Zelakon]

Originally posted by Goblin:

I was away yesterday, no one else can tell people to unzip the executable?

I just assumed you'd prefer to xD

[Apo]

Originally posted by snakeskip:

What people should realize is that screwing up probabilities is not a common game programming error. Programmers rarely implement their own RNGs. Instead they're using well tested and widely used RNGs. Using such RNG to produce certain odds like 1:4 is a most trivial programming task.

More importantly, human beings are horrible at judging probabilities from experience. I don't think there's anything off with it in this game.

[bigcat]

Just a note that programmers can mess up odds very easily. A range soccer game i play has a huge number of 0s and 1s that is wildly out of whack with what you would expect. Its like rolling a 100 sided dice and coming up with a 0 or 1 25% of the time. When you randomize and take a random number, the first one will always be very low and you need to throw away the first three or four before you get something close to random. At least that is the way it used to be when I was in college programming in C.

[JudgeTy]

Originally posted by bigcat:

Just a note that programmers can mess up odds very easily. A range soccer game i play has a huge number of 0s and 1s that is wildly out of whack with what you would expect. Its like rolling a 100 sided dice and coming up with a 0 or 1 25% of the time. When you randomize and take a random number, the first one will always be very low and you need to throw away the first three or four before you get something close to random. At least that is the way it used to be when I was in college programming in C.

Does anyone know what the variance in seeds are?

Example: Two runs based on the same seed. Both have a wheel to buy in the shop. Are the randomized outcomes for using the wheel independent of each other with the same jokers owned?

I.E. Does the seed each run is based off of - set the initial random values?

[ruki]

the wheel is a solid 1/10 everyone knows

[Draco18s]

Originally posted by bigcat:

Just a note that programmers can mess up odds very easily. A range soccer game i play has a huge number of 0s and 1s that is wildly out of whack with what you would expect. Its like rolling a 100 sided dice and coming up with a 0 or 1 25% of the time. When you randomize and take a random number, the first one will always be very low and you need to throw away the first three or four before you get something close to random. At least that is the way it used to be when I was in college programming in C.

Lua depends on C's rand() function, which is defined as (though this does vary from system to system):

static long holdrand = 1L;
...
int rand() {
  return (((holdrand = holdrand * 214013L + 2531011L) >> 16) & 0x7fff);
}

It's a linear congruential generator[en.wikipedia.org] class pRNG, which while it's not great, it's good enough, and it's already discarding the low-order bits (the typical LCG issue) and has a sufficiently large m value.