Sign in to follow this  
Sindusk

The Gaussian Roll - Mathematical Analysis

Recommended Posts

10 mil samples, 50 skill, and 30 difficulty. In addition to the Gaussian roll code from WU lets make another algorithm that doesn't do the bounding rerolling stuff. And in summary, WU roll Gaussian bounding code fails a K-S test for normality.

private static double rollGaussian1(double skill, double difficulty) {

  double slide = (FastMath.pow(skill, 3) - FastMath.pow(difficulty, 3)) / 50000.0 + (skill - difficulty);
  double w = 30.0 - FastMath.abs(skill - difficulty) / 4.0;
  double result;

  return random.nextGaussian() * (w + FastMath.abs(slide) / 6.0) + slide;
}

 

Here is math using WU's guassian roll

skill gain(0-40): %52.1E0  |  100+: %0E0  |  failure(-100 - 0): %22.5E0  | <-100: %0E0
K-S test Pvalue: 3.33E-11  |  mean: 20.996105  |    SD: 27.747330
PDF function for skill gain: 5.29E-1
----------------------------------

Here is math uses that above modified roll
skill gain(0-40): %51.2E0  |  100+: %32.3E-2  |  failure(-100 - 0): %22.2E0  | <-100: %9E-4
K-S test Pvalue: 0.797670  |    mean: 21.958174  |  SD: 28.659330
PDF function for skill gain: 5.14E-1

 

 

If we do this same experiment but instead with 95 skill and 10 difficulty it becomes clear that WU's bounding Gaussian roll doesn't always produce normal distributions.

skill gain(0-40): %1.83E0  |  100+: %0E0  |  failure(<0): %87.7E-4  | <-100: %0E0
K-S test Pvalue: 1.2E-9  |  mean: 78.965237  |    SD: 15.057343
PDF function for skill gain: 4.83E-3
----------------------------------
skill gain(0-40): %79.2E-2  |  100+: %53E0  |  failure(<0): %34.3E-4  | <-100: %0E0
K-S test Pvalue: 0.900393  |    mean: 102.117265  |  SD: 25.771359
PDF function for skill gain: 7.93E-3

 

This normality stuff is important to me because it decides on whether my skill calculator tool can use stream or cumulative based math instead of generating giant random samples.

Edited by joedobo

Share this post


Link to post
Share on other sites

Log for the past day;

 

You prune the grape bush. x654

 

You make a lot of errors and need to take a break. x291

 

That is nearly a 50% failure rate, 94 forestry, 93ql sickle, 63 in sickle skill, not sure if that makes much difference.

 

 

Share this post


Link to post
Share on other sites

@Roccandil I was hoping more people would chime in on the pruning thing. My best guess is Rolf (back in the day when he was doing more) has always gone the extra mile to remove 100% chance outcomes or add in diminishing returns style outcomes. If we stopped pruning failures a large share of outcomes when skills hit 90+ would produce mostly 100 ql outcomes.

Share this post


Link to post
Share on other sites

It's approximately normal when the difference between the skill and the difficulty is not very high. The non-normal distribution only becomes really significant when the mean is approaching 100 or -100.

 

Here's a demonstration (again, done by a mathematician). You can see that when the result mean is close to zero, the distribution is approximately normal. It's only when the difficulty and skill are very far apart (60+) that you begin to see issues with the glaring issues with distribution.

 

There is a potential solution, but it would change the results pretty significantly.

dJl0VLF.png

4YE25JA.png

cat436B.png

Share this post


Link to post
Share on other sites

Again, K-S test for normality says it's not normal (even a mean of 0 returns a super small K-S pValue). It may look kinda normal but its not "kinda-enough". The only relevant issue here is if we are using stats algorithms that assume the data is normal to test or predict outcomes it kinda falls apart if the data isn't actually normal. And for my purposes, it would need to always be normal, not just some of the time. Of note, who you are or what piece of payer you hold doesn't suddenly make something right. 

 

Here is what I did. I may have made a mistake in its use or interpretation. But like I said, not normal enough to pass K-S test for normality. In it, rollGaussian is a copy of the method form WU. All those math class objects are from org.apache.commons.math3 library.

doublesOriginal = Arrays.stream(doublesOriginal)
		.map(value -> rollGaussian(skill, difficulty))
		.toArray();
DescriptiveStatistics descriptiveStatistics = new DescriptiveStatistics();
Arrays.stream(doublesOriginal).forEach(descriptiveStatistics::addValue);
double mean = descriptiveStatistics.getMean();
double sd = descriptiveStatistics.getStandardDeviation();
NormalDistribution normalDistribution = new NormalDistribution(descriptiveStatistics.getMean(),
		descriptiveStatistics.getStandardDeviation());
KolmogorovSmirnovTest kolmogorovSmirnovTest = new KolmogorovSmirnovTest();
double pValue = kolmogorovSmirnovTest.kolmogorovSmirnovTest(normalDistribution, doublesOriginal);

 

Share this post


Link to post
Share on other sites

It's never going to be normal if it's returning values between -100 and 100. A normal random variable must have nonzero probability for intervals which are arbitrarily far to the left or right.

Share this post


Link to post
Share on other sites

sorry I'm confusing things jumping between my need for finding an approach to make a useful skill gain calculator tool and the idea of understanding why wurm thought the bounding re-roll approach was a good idea.

Edited by joedobo

Share this post


Link to post
Share on other sites
1 hour ago, joedobo said:

@Roccandil I was hoping more people would chime in on the pruning thing. My best guess is Rolf (back in the day when he was doing more) has always gone the extra mile to remove 100% chance outcomes or add in diminishing returns style outcomes. If we stopped pruning failures a large share of outcomes when skills hit 90+ would produce mostly 100 ql outcomes.

 

From a gameplay perspective, I'm very much opposed to actions -ever- failing. Having to do the same thing over and over again to get a "good "result feels broken.

 

Rather, I think "failure" should be abstracted into a successful process. A simple example is action timer length quickening as skill improves, or creation QL increasing as skill improves. Those changes aren't random at all, and reflect less "failure" as you get better.

 

Another way of looking at it is how things like walls imp. The game takes your skill plus the QL of the material to decide if you can imp, and if so, how much increase you get. I -love- that system, and I wish all Wurm imping systems used it. I never get a random imp failure, and it feels -right-.

 

Any reason why pruning shouldn't just work, and simply get faster as you get better or use better tools? (Note that I'm coming from Epic where all successful actions provide chance for skill, not the 1-39 oddness of Freedom.)

Share this post


Link to post
Share on other sites

Failures could completely be removed from the game in all aspects and the result could be basically the same as it is now.

 

--If you have a 50% chance to make a plank the creation process just take 2x longer and is a 100% success. Thier needs to be compensation for the skill rolls here.

--For improving they could remove failures and damaging items and instead simply either decrease quality gain or increase action timer.

--oh, enchanting. Although, even this one may work out too. We'd have to have a system that would say for x skill and y power would take appropriate favor and time. Then the priest would need to spend a lot of action-time and some way of contributing small amounts of favor over time into the project. The final result would be whatever power cast the priest wanted. And before someone complains, keep in mind a priest might have to spend thousands if not tens of thousands of favor and days of action time to get 90+ power spells at low skill levels.

 

In the case of pruning, it seems it was an oversite by the devs missing the fact there their better-skill-gain system also meant players could never achieve a 100% scenario. A simple fix might be to add a different system to determine a failure. Perhaps, forestry skill is your success chance, at 95 skill you'd on average succeed 95% of the time. And still keep using the skill gain way.

Share this post


Link to post
Share on other sites

I don't want to discourage anyone from making other tools, but I would like to mention here that I'm now hosting a mirror of the Wurm skillgain/skillcheck simulator I've previously mentioned:

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this