A brief discussion on odds and random number generators

[mxz]

I'm going to try to explain how the odds work in these games. It may not be accurate. It is based on my currently held beliefs through Gree gaming and looking at the available data and datasets. I'm also tying in my own experience (albeit minimal compared to some) with software algorithms, and what I would do if I was writing a game structured this way.

Why would I do it this way? Because it's simple, easy and is essentially random-enough.

When you perform an action that requires a probability (such as a job with a loot drop or opening a collect-10 box) a random number must be generated.

Random numbers cannot be purely random
They have to start from somewhere
This starting point is known as a seed
The seed is mixed with various things (time, memory usage, name of the device, pretty much anything) to spit out a random number
Random number generators are usually built into the operating system or development environment
Gree probably uses one of Apple's (edit: and Google's) RNG's, possibly rand() but there are also random() and arc4rand()



After getting the random number the app needs to know what to do with it. Say we have a loot drop. The odds of it dropping are 15%. If the random number generated is 1,2,3,..,15 then you would get the drop. If it's 16, 17,..,100 - you wouldn't get the drop.

How would this work for something like a box opening where there are 8 possible outcomes?
Say big money is 8%, RP is 4%, little money is 4%, Enhanced Bike 5%, EU Security Baton is 4%, Sledgehammer 3%, Armored Vest 2%, and the special item 70%.
If the number was 1-8 you'd get the big money, 9-12 the RP, 13-16 the little money, and so on, such that 31-100 would get you the item.

See a real example below:
http://img252.imageshack.us/img252/5995/oddsrng.jpg

I'm sure Ram could add some insight to this and let me know where it may be lacking/wrong.

[montecore]

You obviously know enough to know that there are no truly random numbers in computers, although for us mere humans pressing on a touch screen, suffering through interminable network delays, software lag, poor server response times, and disgruntled Gree employee sabotage, it might as well be truly random.

Some anecdotal and entirely unscientific evidence from me: The one time I got box 10, I got box 9 one open before. Last night in some dreamlike hallucination I robbed someone with double my attack, I spent all 158 bullets on him and his really-not-that-highly-ranked buildings. Failure rate was easily over 90%, but when I got cash from one of his pirate taverns, it was back to back. I'm talking after about 80 or 90 OCD failures in a row, getting two in a row. Part of this may have been the slow destruction of his snowballs and turkeys (which I felt sort of sad about in the sober rush of morning), but they were gone well before the back to back hits. It then took a long time to hit his other PT and the RCs.

I've seen this elsewhere as well, which leads me to share in your implied hypothesis: The "random" programming Gree uses isn't really random, and in fact sucks quite a bit more than the "random" programming we see in other programs.

[Ericinico]

Is it true that if you don't close the app then every box you open is as easy as number one?

[mxz]

I've seen this elsewhere as well, which leads me to share in your implied hypothesis: The "random" programming Gree uses isn't really random, and in fact sucks quite a bit more than the "random" programming we see in other programs.I've often preached the golden timing approach to things. Likely, their random seed is using a time-based algorithm. When it rains it pours.
Is it true that if you don't close the app then every box you open is as easy as number one?No, that was pretty easily disproven this last even as 4 or 5 of us tried a variation on that principle. It appears as though the odds recalculate after each successful item opening. Those that used all gold opens/resets still spent a decent chunk of gold to get it. If that was actually true everyone could do it for 285 gold.

[Tony 432847666]

a time-based algorithm
???time based? Does it mean it matters what time of an hour you open the box?

[BOS]

???time based? Does it mean it matters what time of an hour you open the box?

And here lies the key to Pandora's box :cool:

[Tommy Two Toes]

???time based? Does it mean it matters what time of an hour you open the box?
Unfortunately, it's not that easy. As soon as the algorithm starts, it cycles through all the possibilities at the clock speed of the machine it's running on. Even events a thousandth of a second apart, should produce a different outcome.

[RijilV]

doubtful it is time based, but without looking at their code you'd never know what approach they picked.

http://iphonedevelopment.blogspot.com/2008/10/random-thoughts-rand-vs-arc4random.html


I'd be shocked if they weren't using arc4random, its by far the easiest and produces reasonably random results. I'd be even more shocked if they invented their own, time based, random number generator. Like why would they do that?

[Tommy Two Toes]

More food for thought...
For collect ten events, is the item determined at the time the case is opened? Or when it is obtained?

I'd argue the former would be easier to code, but only the developers probably know for sure.

Or on local device? AgainOr on your own local device?

[dudeman]

???time based? Does it mean it matters what time of an hour you open the box?

Sounds possible. What about time of day/night? Or calendar date? Or alignment of the planets?

http://preview.images.memegenerator.net/Instance/Preview?imageID=305303&generatorTypeID=&panels=&text0=Collected%2010%20without%20gold%3F&text1=Aliens!&text2=&text3=

[Tommy Two Toes]

doubtful it is time based, but without looking at their code you'd never know what approach they picked.

Agreed.


I'd be even more shocked if they invented their own, time based, random number generator. Like why would they do that?
For online gambling, it makes sense, but for a free game, it would be like hitting a fly with a sledgehammer. I'm sure it's a simple open source algorithm. Programmers are by nature efficient (read lazy) and will find a snippet before they try to reinvent the wheel.

[foxtrekker]

Theres no way for a computer to pick a random number. You need a physical elment of unpredictability to create a random event. Theres no way a computer can duplicate that. It can simulate it ok, but if you're going thru a process to create it it's not random. I actually accidentally proved this true by writing a program to choose random numbers for picking my lottery numbers. I let it run all night, which gave me millions of selections, and it highlighted the numbers that came up more frequently. Out of the 50 or so numbers, there were a handful of numbers that came up much more than others. Obviously its random enough for CC's purposes but unless theyre using ping pong balls, its not truly random.
No, i'm not giving out the numbers! :D

[zwiswoo]

Theres no way for a computer to pick a random number. You need a physical elment of unpredictability to create a random event. Theres no way a computer can duplicate that. It can simulate it ok, but if you're going thru a process to create it it's not random. I actually accidentally proved this true by writing a program to choose random numbers for picking my lottery numbers. I let it run all night, which gave me millions of selections, and it highlighted the numbers that came up more frequently. Out of the 50 or so numbers, there were a handful of numbers that came up much more than others. Obviously its random enough for CC's purposes but unless theyre using ping pong balls, its not truly random.
No, i'm not giving out the numbers! :D

I am highly skeptical your random number generator is so bad there are statistical deviations that you can see simply by eyeballing the output. Sometimes there are really subtle effects like maybe some bit of the output is (say) more likely to be a one. Or some really fast generators have low cycle periods. But if you're using a decent generator and seeding it sensibly, I really doubt there are effects of the sort you describe - extremely smart people do pseudorandom number generation for a living, and there are honest to goodness mathematical theorems about the statistical properties of the most commonly used ones.

More likely you're over interpreting statistical fluctuations in your output.

[name]

Gree wants to control all aspects of the game (see nerfing guns etc.). To control this random thingy it probably isn't random for them, but only seems random to us. They will probably control how many total number 1 items get distributed over the total install.base of customers (10% or so). To do so a bucket system would work out perfectly.

If I have 10.000 players, and I want to reward 1000 items I could award 500 the first day, 300 the second day, 100 the third and so on. Each day sliding the odds lower by minimizing the succesful % based on the number of boxes I have left from the previous day. For you it would seem random, for gree it would be totally controlled.

It seems unlikely that Gree uses Google or Apple's random number generator; The reason I think so is that I don't think the numbers are generated on the client side, but are more likely to be generated on the server side. This would be far more in control of Gree's hands and would prevent hacking. That would also explain why people get BLNT if their internet connection is failing.

[mxz]

It seems unlikely that Gree uses Google or Apple's random number generator; The reason I think so is that I don't think the numbers are generated on the client side, but are more likely to be generated on the server side. This would be far more in control of Gree's hands and would prevent hacking. That would also explain why people get BLNT if their internet connection is failing.Loot drops whether you're connected to the server or not. There is no server call during that chain of events.

Now, the opening of a box is done server side - so they can control whether you get a BLNT or a prize. However, once you get a success response from the server its up to the client to 'pick' the prize.

[Tommy Two Toes]

Loot drops whether you're connected to the server or not. There is no server call during that chain of events.

Now, the opening of a box is done server side - so they can control whether you get a BLNT or a prize. However, once you get a success response from the server its up to the client to 'pick' the prize.

How did you come to know this? Or are you speculating, like the rest of us?

[Ramshutu]

I actually use RNGs a lot, because I deal with software that performs complex data processing, and RNGs are nice for demos, or to write a lot of the software before the algorithms are finished.

I have also implemented by own RNGs, or actually pseudo random bit sequences in mobile telephony, you need a sequence of bits that is gaurenteed generate all possible combination of data bits, but is also recreateable so you can detect transmission errors.

Rand and rand functions are hackable, but it takes more effort than other simply and off the shelf ways. It's not complicat but is long winded and a pain in the arse.

In terms of coding, there are many different ways you can implement these calculations, and most give pretty much the same results in terms of what a user would see. And to my mind, there isn't really much to discuss here, I can give. You 10 different ways to generate a number between 1-10 and then decide what happens as a result. You wouldn't be able to tell which one was being used without decompiling the software.

More importantly, even the most basic rand function is only hackable simply if you know the seed and number of times the rng has been invoked. For complex versions this is pretty difficult, and even in the most basic versions, unless you can do weird things with system time, a number of which are derived from registers on the physical hardware, deriving the exact millisecond the rng was seeded is pretty hard. Even harder if gree, say, performed a seed prior to each calculation.

In reality, the odds will be pretty much the same regardless of implementation, provided that no fundamental mistakes are made. You need to understand the way the programming language knows how to convert values from one to another. For example:

Float ratio = Rand()/RAND_MAX which should give you a random number between 0 and 1 in c, can sometimes only ever give you 0 because the compiler subtly converts what should be a floating point number to an integer (as they are both integers) but always floors to the first integer lower than, rather than the rounded value).

Normally, most errors in the implementation of randomness are like this and have the result of reducing the odds of the top end comparison: for the given example the random number can be reduced if such a bug exists so that instead of between 1-100 it is actually clipped to 1-99. If you don't account for that, it can either mean that your 8% chance becomes 7, or your 70% chance becomes 69.

[Ramshutu]

How did you come to know this? Or are you speculating, like the rest of us?

You can find out all the data exchanged between client and server.

[AppleMacGuy]

How did you come to know this? Or are you speculating, like the rest of us?

If you'd been here long enough you'd know by now that mxz isn't given over to speculating in my experience - the majority, if not all, of his observations are based on real-world knowledge gained by exploration. All IMHO of course - I don't personally know mxz, but he seems like a straight up top bloke.

[AppleMacGuy]

You can find out all the data exchanged between client and server.

Ram answer is more succint than mine...

[dudeman]

... provided that no fundamental mistakes are made.

I read/paid attention until there. Come on. This is Gree.

:cool::p

[mxz]

How did you come to know this? Or are you speculating, like the rest of us?I have a very peculiar interest in networks. As Ram suggested, this is not difficult to check. Gree has obfuscated, to a degree, some of the server-client messaging in recent updates. I won't speculate as to the cause of this obfuscation, but some of the information they were sending was unnecessary and potentially embarrassing. I brought this to their attention as there were some serious vulnerabilities. Even with the newer clients, you can tell when and what sort of data is being passed very easily.

Almost obviously, most people would never even think to check this. I think I've run into only one other forumite who has done similar trials, though I suspect allhail (one of the Godfathers of data reading) was also using the available information when he was around and doing his testing. I wish he'd come back :(

[Tommy Two Toes]

I have a very peculiar interest in networks.(

Very cool, and not at all peculiar, IMO. I work in InfoSec with a background in networks, but became a paper-pusher at some point, and lost most of my (limited) technical ability.

[murf]

No, that was pretty easily disproven this last even as 4 or 5 of us tried a variation on that principle. It appears as though the odds recalculate after each successful item opening. Those that used all gold opens/resets still spent a decent chunk of gold to get it. If that was actually true everyone could do it for 285 gold.

mxz, I tried this, and got my first 9 items, in only 15 attempts. Then went on wasted the rest of my vault on trying to get the 10th without anything and never got the 10th item. But that's a different discussion.

[Killshot-CC]

I'm talking after about 80 or 90 OCD failures in a row, getting two in a row.

I'd like to add my two cents as both a programmer and an occasional gambler. First off, it's entirely plausible that the payout algorithm is "fixed." By this, I mean that it may not be purely random and would function similar to how another poster theorized: a sliding scale of payout odds based on actual payout history. The odds could get worse the more an item has been paid out or there could even be a finite cap: no more than 10,000 free-money Box 10 drops, for example. If I were to write the game, that's how I would cause it to function. I would also have alerts to check payout values and amounts and trigger an alarm if something appeared amiss and to give the operators a chance to adjust the variables. Remember, currently there is no oversight for these algorithms in the way that the gaming commission ensures that Las Vegas slot machines are "fair." With games like these, everything is fairplay until it starts to affect customer reactions. If it were unfairly rigged, but GREE still meets their cash goals, there'd be no incentive to change it, and in fact, would most likely ensure that it continues.

Second, random doesn't mean what people usually think it does. When we tend to think of random numbers, such as values from 1 to 6, many would expect results of, say, 3, 6, 4, 1, 2, 5 - an even distribution of numbers. However, if you roll a die 6 times in a row, you'd have very low odds of getting anything like this. More likely, you'd get values along the lines of 4, 4, 6, 1, 4, 2 - where there are streaks and repeats. This is the reason many gamblers use progressive betting systems. They know that if they just won, they're more likely to win again and again, than to win, lose, win, lose. This is also why Apple builds a manual adjustment into Mac's iTunes shuffle function. If it were truly random, you would often hear the same artist back to back and even the same song back to back. They know that most don't want to listen this way, so they have a safety which can reject a randonly selected song when this occurs.

Based on anecdotal evidence, I suspect that GREE routinely changes the payout variables based on the success or failure of prior events. Likewise, I suspect that they have clear analytics on which types of events and items are most successful, so they know what to do to boost revenue when numbers slack off.

[AppleMacGuy]

I'd like to add my two cents as both a programmer and an occasional gambler. First off, it's entirely plausible that the payout algorithm is "fixed." By this, I mean that it may not be purely random and would function similar to how another poster theorized: a sliding scale of payout odds based on actual payout history. The odds could get worse the more an item has been paid out or there could even be a finite cap: no more than 10,000 free-money Box 10 drops, for example. If I were to write the game, that's how I would cause it to function. I would also have alerts to check payout values and amounts and trigger an alarm if something appeared amiss and to give the operators a chance to adjust the variables. Remember, currently there is no oversight for these algorithms in the way that the gaming commission ensures that Las Vegas slot machines are "fair." With games like these, everything is fairplay until it starts to affect customer reactions. If it were unfairly rigged, but GREE still meets their cash goals, there'd be no incentive to change it, and in fact, would most likely ensure that it continues.

Second, random doesn't mean what people usually think it does. When we tend to think of random numbers, such as values from 1 to 6, many would expect results of, say, 3, 6, 4, 1, 2, 5 - an even distribution of numbers. However, if you roll a die 6 times in a row, you'd have very low odds of getting anything like this. More likely, you'd get values along the lines of 4, 4, 6, 1, 4, 2 - where there are streaks and repeats. This is the reason many gamblers use progressive betting systems. They know that if they just won, they're more likely to win again and again, than to win, lose, win, lose. This is also why Apple builds a manual adjustment into Mac's iTunes shuffle function. If it were truly random, you would often hear the same artist back to back and even the same song back to back. They know that most don't want to listen this way, so they have a safety which can reject a randonly selected song when this occurs.

Based on anecdotal evidence, I suspect that GREE routinely changes the payout variables based on the success or failure of prior events. Likewise, I suspect that they have clear analytics on which types of events and items are most successful, so they know what to do to boost revenue when numbers slack off.

A thought provoking post...thanks!

[Killshot-CC]

A thought provoking post...thanks!

Sometimes I get lucky.

[mxz]

Based on anecdotal evidence, I suspect that GREE routinely changes the payout variables based on the success or failure of prior events. Likewise, I suspect that they have clear analytics on which types of events and items are most successful, so they know what to do to boost revenue when numbers slack off.I tend to agree with this, but only so far as whether the box successfully opens or not. The datasets, at least all I've compared, have the same item/money/RP/crappy equipment odds. Since we can't look into server-side decisions, there's really no way for us to confirm either way. It's also supported by CCM's admission that boss health is determined by the top x% of players within a given bracket and set for each event.

Of course the support folks have never been forthcoming when I've asked about such things. (not too surprised)

[PawnXIIX]

To add my two cents into this matter...we have exact percentages defined in the data that is right in front of us. It is determined by the server what we get through some convoluted algorithm what we get, but i think it's defined right in front of us how it's decided:

Here's an excerpt from loot.json in the dataset from 20121102_03 dataset:



{"loot_group_id": 204, "loot_id": 0, "loot_weight": 1, "tag": "Common", "loot_type": "money", "is_available": "true", "id": 626, "quantity": 25000},
{"loot_group_id": 204, "loot_id": 0, "loot_weight": 1, "tag": "Common", "loot_type": "respect", "is_available": "true", "id": 627, "quantity": 500},
{"loot_group_id": 204, "loot_id": 0, "loot_weight": 1, "tag": "Common", "loot_type": "money", "is_available": "true", "id": 628, "quantity": 125000},
{"loot_group_id": 204, "loot_id": 672, "loot_weight": 1, "tag": "Common", "loot_type": "item", "is_available": "true", "id": 629, "quantity": 1},
{"loot_group_id": 204, "loot_id": 408, "loot_weight": 1, "tag": "Common", "loot_type": "item", "is_available": "true", "id": 630, "quantity": 1},
{"loot_group_id": 204, "loot_id": 410, "loot_weight": 1, "tag": "Common", "loot_type": "item", "is_available": "true", "id": 631, "quantity": 1},
{"loot_group_id": 204, "loot_id": 431, "loot_weight": 1, "tag": "Common", "loot_type": "item", "is_available": "true", "id": 632, "quantity": 1},
{"loot_group_id": 204, "loot_id": 1740, "loot_weight": 1000, "tag": "Common", "loot_type": "item", "is_available": "true", "id": 633, "quantity": 1},


This is the rewards available to you. Notice the loot weights - I think these are what are determining the odds. Back when I began programming, I started doing things where probability was decided by picking a number between 1 and x, then depending on how high the number was it'd fall into a certain if/else bracket. This would be like making 1-15 common, 16-25 uncommon, and 26-30 rare (inclusive). This is what I believe is being used here. They sum up all of the loot weights for that particular bracket, then they generate a random number. After that number is chosen, they compare it with the loot weights somehow and then it determines a loot. In this case at 0 event items you will get an event item 1000 out of every 1007 successful opens. At 1 event item, you will get an event item 90 out of every 100 opens. This path continues until the 9th open, when you should be expecting an event item 20 times for every 1000 opens. That runs at about 2% for the top bracket in this particular event. That event was the Pendant Lockbox Event.

Even better, is that the 10th item is scaled so that the lower bracketed players DO get better odds. The lowest bracket have a 30.5% chance of getting the 10th item compared to the 2% chance the top bracket has.

This pattern seems to be the current pattern for the events of today. It is the frustration of us all. I know I posted this somewhere before...


???time based? Does it mean it matters what time of an hour you open the box?

#incoming java
I'm pretty sure that Math.rand() is a time based algorithm. I'm pretty sure that accesses System.currentTimeMillis() to determine the seed value on the random table.

Disambiguation - For those of you who don't know, random numbers aren't truly random. They all for all intents and purposes PREDICTABLE because it reads off a finite table of numbers that have been specifically chosen to keep as close to the random bell curve model as possible. Random values aren't random - the randomness is chosen based on the seed that is placed for the table location where it is being read off of. When a call is made to the random function it uses the current time to seed the table to give a seemingly unique value. This is why for instance you can see the table to null in order to give predictable results in c++ for uses in testing for instance to make sure every program gives the same results every time. When I say predictable, I don't also mean that you can just simply go into a computer program and predict the outcome every time. It just means that every once in a while the pattern will repeat.

[cooch]

To add my two cents into this matter...we have exact percentages defined in the data that is right in front of us. It is determined by the server what we get through some convoluted algorithm what we get, but i think it's defined right in front of us how it's decided:

Here's an excerpt from loot.json in the dataset from 20121102_03 dataset:



{"loot_group_id": 204, "loot_id": 0, "loot_weight": 1, "tag": "Common", "loot_type": "money", "is_available": "true", "id": 626, "quantity": 25000},
{"loot_group_id": 204, "loot_id": 0, "loot_weight": 1, "tag": "Common", "loot_type": "respect", "is_available": "true", "id": 627, "quantity": 500},
{"loot_group_id": 204, "loot_id": 0, "loot_weight": 1, "tag": "Common", "loot_type": "money", "is_available": "true", "id": 628, "quantity": 125000},
{"loot_group_id": 204, "loot_id": 672, "loot_weight": 1, "tag": "Common", "loot_type": "item", "is_available": "true", "id": 629, "quantity": 1},
{"loot_group_id": 204, "loot_id": 408, "loot_weight": 1, "tag": "Common", "loot_type": "item", "is_available": "true", "id": 630, "quantity": 1},
{"loot_group_id": 204, "loot_id": 410, "loot_weight": 1, "tag": "Common", "loot_type": "item", "is_available": "true", "id": 631, "quantity": 1},
{"loot_group_id": 204, "loot_id": 431, "loot_weight": 1, "tag": "Common", "loot_type": "item", "is_available": "true", "id": 632, "quantity": 1},
{"loot_group_id": 204, "loot_id": 1740, "loot_weight": 1000, "tag": "Common", "loot_type": "item", "is_available": "true", "id": 633, "quantity": 1},


This is the rewards available to you. Notice the loot weights - I think these are what are determining the odds. Back when I began programming, I started doing things where probability was decided by picking a number between 1 and x, then depending on how high the number was it'd fall into a certain if/else bracket. This would be like making 1-15 common, 16-25 uncommon, and 26-30 rare (inclusive). This is what I believe is being used here. They sum up all of the loot weights for that particular bracket, then they generate a random number. After that number is chosen, they compare it with the loot weights somehow and then it determines a loot. In this case at 0 event items you will get an event item 1000 out of every 1007 successful opens. At 1 event item, you will get an event item 90 out of every 100 opens. This path continues until the 9th open, when you should be expecting an event item 20 times for every 1000 opens. That runs at about 2% for the top bracket in this particular event. That event was the Pendant Lockbox Event.

Even better, is that the 10th item is scaled so that the lower bracketed players DO get better odds. The lowest bracket have a 30.5% chance of getting the 10th item compared to the 2% chance the top bracket has.

This pattern seems to be the current pattern for the events of today. It is the frustration of us all. I know I posted this somewhere before...



#incoming java
I'm pretty sure that Math.rand() is a time based algorithm. I'm pretty sure that accesses System.currentTimeMillis() to determine the seed value on the random table.

Disambiguation - For those of you who don't know, random numbers aren't truly random. They all for all intents and purposes PREDICTABLE because it reads off a finite table of numbers that have been specifically chosen to keep as close to the random bell curve model as possible. Random values aren't random - the randomness is chosen based on the seed that is placed for the table location where it is being read off of. When a call is made to the random function it uses the current time to seed the table to give a seemingly unique value. This is why for instance you can see the table to null in order to give predictable results in c++ for uses in testing for instance to make sure every program gives the same results every time. When I say predictable, I don't also mean that you can just simply go into a computer program and predict the outcome every time. It just means that every once in a while the pattern will repeat.

Thanks. I think your real world experience and evidence matches our anecdotal and expensive experience. Was waiting for someone to weigh in with experience that made better sense.

[dudeman]

...

So basically the declining odds seen for event item drops (collect-10 events) applies similarly to level vs. event success.

Each level you gain decreases your odds of winning an event. The way Conzio/Gree(d) see this is, the longer you play, the more you have to pay. Don't pay and they almost entirely cut you off. You could get lucky, but they don't want you to.

[mxz]

So basically the declining odds seen for event item drops (collect-10 events) applies similarly to level vs. event success.

Each level you gain decreases your odds of winning an event. The way Conzio/Gree(d) see this is, the longer you play, the more you have to pay. Don't pay and they almost entirely cut you off. You could get lucky, but they don't want you to.No, not exactly. The level only determines your bracket (just like bosses). The difference between, say, 77 and 99 does not change your odds. 99 and 199, though...yes - because you're in different brackets. If I remember correctly there's like 5 brackets for collect-10, but the first 3-4 are pretty much the same. The main difference is the crappy equipment and amount of money/respect.

And YAY, Pawn's back!

[realsavior]

@mxz any ideas on how collect ten events compare to leader board events like the race engine one going on now? You see players on the leader boards with 100+ items does that mean that after getting 20 the odds stay consistent?

[mxz]

Leaderboard events have different odds, though fairly similar for the first bunch. They're more in line with the LLP collect-10 odds.



Items

Odds of special item



0

99.3%



1

90%



2

80%



3

70.11%



4

60%



5

50%



6

40%



7

30.21%



8

30.21%



9+

30.21%

[PawnXIIX]

The boss item events work in a similar way. Once you defeat a certain number of bosses the rares increase to a point where they are more common than the common rewards, but at the point the uncommon rewards are so much more likely that you have a better chance of getting those still. By about 20 defeats the chance of getting a rare is about equal to an uncommon, and is also equal to a common for the top bracket.

I'm going to go through the latest data and see if I can find out how they're doing the leader board events. This was something I never really looked into.

A quick look - at 9 items the leader board event has a permanent item rate of 30.5% if the box is opened for the top tier.

[mxz]

A quick look - at 9 items the leader board event has a permanent item rate of 30.5% if the box is opened for the top tier.I'm getting 30.21%...

http://img27.imageshack.us/img27/7326/leaderboardg.jpg

Maybe it's different for Android?

[PawnXIIX]

Oh, nope you're correct I was somehow taking the 96 that it amounted to and was somehow I accidentally rounded it to 95. Rather than making a data entry program I was just smashing it into a calculator :p

30.21% it is. Now we just need to figure out where the threshold is for these. Honestly it could be until 10 then those last lines stay constant all the way, or it could jump up a loot number every other item so that way it goes all the way to 20.

[mxz]

You need to start using that app I sent you :)

Feel free to modify it so it does ^^^ that automatically. Spending 5 minutes doing the =cell/sum is a drag. Then send it back ;)

[Tommy Two Toes]

Leaderboard events have different odds, though fairly similar for the first bunch. They're more in line with the LLP collect-10 odds.


Are your percentages based on Gold, Cash, or Free opens?

[Ramshutu]

Are your percentages based on Gold, Cash, or Free opens?

A succesfull open.

[Tommy Two Toes]

A succesfull open.

Guess I should read back a little further than a couple of posts :o

[Ramshutu]

As a side note, I have checked out the rand() function at least under windows; and there doesn't seem to be any appreciable deviation on the odds versus theoretical for a purely random function.

I've checked this against both streaks, and overal occurance :)

[PawnXIIX]

As a side note, I have checked out the rand() function at least under windows; and there doesn't seem to be any appreciable deviation on the odds versus theoretical for a purely random function.

I've checked this against both streaks, and overal occurance :)

Yeah I've checked deviation a few times and rand() is pretty solid on staying close to not deviating far from the random bell curve