Posted June 13, 2018 (edited) 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 June 13, 2018 by joedobo Share this post Link to post Share on other sites
Posted June 13, 2018 delet this stop expose rngesus Share this post Link to post Share on other sites
Posted June 13, 2018 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
Posted June 13, 2018 If it were my game, I'd just remove pruning failures. Share this post Link to post Share on other sites
Posted June 13, 2018 @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
Posted June 13, 2018 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. Share this post Link to post Share on other sites
Posted June 13, 2018 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
Posted June 13, 2018 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
Posted June 13, 2018 (edited) 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 June 13, 2018 by joedobo Share this post Link to post Share on other sites
Posted June 13, 2018 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
Posted June 13, 2018 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. 2 Share this post Link to post Share on other sites
Posted June 29, 2018 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