• Dear forum reader,
    To actively participate in our forum discussions or to start your own threads, in addition to your game account you need a forum account. You can
    REGISTER HERE!
    Please ensure a translation in to English is provided if your post is not in English and to respect your fellow players when posting.

Discussion Inno math

This is why it should just be a flat rate every time and the fight % only goes up after 1 point passes, no more complaining. :p

20% attrition chance becomes +0.2 attrition each battle. 40% = 0.4, ext, cap at 100% = 1.0.
 

Emberguard

Overlord
without having an adequately large sample size?

And adequate accuracy of tracking. If you're aiming for 20% you need to know you're either always hitting 20%, or keep track of which sectors are hitting at what % rates so you can properly analyze the results

This is why it should just be a flat rate every time and the fight % only goes up after 1 point passes, no more complaining. :p

20% attrition chance becomes +0.2 attrition each battle. 40% = 0.4, ext, cap at 100% = 1.0.

Oh I'm sure there'd be complaining xD It just wouldn't be about randomness
 

Deleted User - 57457

Guest
I've experimented with a d6 dice and a predictive program for dice. Counting the deviation off and on the average estimate to obtain an expected range, for a set number of rolls of the dice. Using predicted deviation to correct the average gave a more accurate estimate for results.
I've cross checked it with 10x 10 rolls, checked the individual results with the estimated range. In 70% of the time the range was correct, in 30% of the time off by 0,6-1,6. At 100 rolls of the dice, it was completely accurate. However more experimentation is needed, due to the small sample size.
While the sample size is small and the experiment for my hypothesis was done with a d6 dice, as where GbG's randomness comes from an virtual RNG, I'm confident that it's quite representative for more accurate estimates.
I think it would be greatly beneficial for the community if someone with greater probability mathematical knowledge and excel skills than I have, could create an excel spreadsheet for this. In which excel calculates the deviation and giving a range of estimated attrition. Based off the given number of fights, calculated estimated deviation for the given number of fights with the X% attrition risk. Alongside an % of accuracy of the estimate.
This maybe complex to setup but at the user level is should be quite straightforward. Just insert number of fights and X% attrition risk. Giving an estimated range for attrition the user can expect. This should be vastly more accurate than going off the expected average and than being surprised the resulted attrition is off.
 
And adequate accuracy of tracking. If you're aiming for 20% you need to know you're either always hitting 20%, or keep track of which sectors are hitting at what % rates so you can properly analyze the results



Oh I'm sure there'd be complaining xD It just wouldn't be about randomness
Oh no I can only do 500 fights in 30 minutes daily of gbg, this isn't any better than gvg at all!
 

Dessire

Emperor
You could literally hace 99% attrition reduction, do 100 battles and have 100 attrition. . . That is how probabilites work.
 

Deleted User - 244520

Guest
You could literally hace 99% attrition reduction, do 100 battles and have 100 attrition. . . That is how probabilites work.

Out of curiosity I checked, the chance for that to happen to anyone is 0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001%.

Assuming a I managed to correctly put 198 (?) zeroes here.
 
Out of curiosity I checked, the chance for that to happen to anyone is 0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001%.

Assuming a I managed to correctly put 198 (?) zeroes here.
Are you sure you didn't miscount the number of zeros after the decimal point?
 
Top