Skill Challenge success calculator

[baudot]

..and I look forward to reading your code in the morning, once I'm rested enough to make sense of it.

 

[Chris_Nightwing]

So, does making the number of failures needed equal to the number of successes fix it? It seems that way, with a 50% chance on any check you have 50% success overall. Too early to do the maths on other situations..

 

[baudot]

So, does making the number of failures needed equal to the number of successes fix it? It seems that way, with a 50% chance on any check you have 50% success overall. Too early to do the maths on other situations..

It's a 50/50 if the party's chance of success per roll is 50/50. If the per-roll odds are better, then this gets stronger as the complexity rises. Conversely, if the party's odds are less than 50% per roll, then the odds get worse as the complexity rises. I like this so long as the base skills are +9 or under before level modifiers for skills, and you make the party fight for each +2 they get past that to swing the odds in their favor.

 

[DemonLlama]

It would also be a very nice feature if you added the ability to set the number of successes and failures in order to test your own "complexity" levels.

 

[DClown]

The previous code snippet appears to be a dart thrower algorithm from a cursory glance. To be honest a dart thrower was the first thing I coded just to get a general idea, so I'm not saying anything derogatory besides the fact that its inaccurate and has a more complex implementation then the recursive solution. The original poster got around a recursive solution by forcing all of the skill values to be the same. This makes the processing time dependant on a few factoral calculations for the corresponing number of combinations. The recursive solution allows entry of varying DCs, varying skill combinations, and varying number of successes with varying number of allowed failures.

I had two assumptions about skill challenges since i've only sat down with the PHB and havent cracked the DMG yet.

Do 1's and 20's still count as auto fail/success on skill challenge checks?
Are the skill challenge roll pattern primary/secondary/primary/tertiary repeat?


If so here is the complete algorithm. Its c++ but its easy to port since it really only has a single line of code that isn't setup, i/o, or proceedural. ( double probFail = (DC - skills[skillIndex%4]-1) * .05; )

With a little bit of work you can use this algorithm to vary the parameters so that you can enter a target success rate and spit out a reasonable number of success to fail ratios for a given DC.

#include <iostream>

// globals for use with the recursive function
double successRate = 0;
int numToSucceed;
int numToFail;
int skills[3] = {0,0,0};

// function declarations
double calcSuccessRate(int successes, int failures, int DC, int skill1, int skill2, int skill3);
void recurseProbability(int successes, int failures, int DC, int skillIndex, double cummulativeProb);

// main
int main(int argc, char** argv)
{
    int reqSuccesses = atoi(argv[1]);
    int allowedFailures  = atoi(argv[2]);
    int DC = atoi(argv[3]);
    int skill1 = atoi(argv[4]);
    int skill2 = atoi(argv[5]);
    int skill3 = atoi(argv[6]);
    calcSuccessRate(reqSuccesses, allowedFailures, DC, skill1,skill2,skill3);
}

// wrapper for the recursive function, sets up globals
double calcSuccessRate(int successes, int failures, int DC, int skill1, int skill2, int skill3)
{
    numToSucceed = successes;
    numToFail = failures;
    successRate = 0;
    // do skill checks alternate primary / secondary/ primary / tertiary repeat?
    // if not adjust the skill matrix accordingly
    skills[0] = skill1;
    skills[1] = skill2;
    skills[2] = skill1;
    skills[3] = skill3;
    recurseProbability(0,0,DC,0,1.0);

    std::cout << " successRate = " << successRate << std::endl;
}

// calculates the chance of success
void recurseProbability(int successes, int failures, int DC, int skillIndex, double cummulativeProb)
{
    if ((successes+failures) >= numToSucceed+numToFail)
    {
        if (successes >= numToSucceed) successRate += cummulativeProb;
        return;
    }

    // determine chance to fail
    double probFail = (DC - skills[skillIndex%4]-1) * .05;
    // are 20 auto success and 1 auto fail?
    // if so then keep this, otherwise change .95 to 1, and .05 to 0
    if (probFail >= 1) probFail = .95;
    if (probFail <= 0) probFail = .05;

    // this roll is a success
    recurseProbability(successes+1, failures, DC, skillIndex+1, cummulativeProb*(1-probFail));
    // this roll is a failure
    recurseProbability(successes, failures+1, DC, skillIndex+1, cummulativeProb*probFail);
}

 

[baudot]

Detailed explanations of results are up.

When I first started this, I figured I'd stop there, but seeing as people are asking for the ability to tweak the challenge system overall with manual DC and success/failure requirements/allowances, I'm thinking I'll throw that in next.

Running probabilities for a party of mixed skill levels requires a whole other style of calculation. I may get around to it eventually, but it's definitely not what I'm hitting next. I'm thinking to do that and do it properly, I'd end up generating Markov chains. It could be a fun problem.

 

[ravenight]

The previous code snippet appears to be a dart thrower algorithm from a cursory glance. To be honest a dart thrower was the first thing I coded just to get a general idea, so I'm not saying anything derogatory besides the fact that its inaccurate and has a more complex implementation then the recursive solution.

Well, the purpose of it was to allow the user to fool around with mixing in certain types of bonuses at random. I see that yours gets the exact solution given a progression of particular skills vs. a single DC, but I was trying to just get a sense of the usefulness of applying the DM's Best Friend bonuses and varying the amount of risk-free checks that could be made for the reward of a bonus to a risky check. So each program has its own use, basically (it would be difficult to have the recursive algorithm track a potential cumulative bonus to the next risky check).

I do like the idea of spending something to balance more complex challenges with less complex ones. I wonder if the best implementation of that would simply be to make max failures equal to max successes but then add a cost for how long it takes, so winning in 4 checks is significantly better than winning in 7. The cost could be any number of things, from a once-per-round Endurance check to avoid losing a healing surge to a monetary cost for each check, or suffering from an attack after each failure. It actually seems like doing that would keep it pretty close to what they were aiming for: each level of complexity would be about as tough as that many monsters of whatever level the DC was set for.

 

[DClown]

Detailed explanations of results are up.

Running probabilities for a party of mixed skill levels requires a whole other style of calculation. I may get around to it eventually

The algorithm i presented should do this ( unless I'm misinterpreting what you are saying ). If however you just want to break out the fancy pants math ( and get the chance to earn geek cred by saying 'Markov chains' ) go for it, nobody is gonna stoping you

 

[Ulthwithian]

Did someone say 'Markov chains'?

... but you know, you're right. A Skill challenge could be modeled with a Markov process, but I think it would get a bit unwieldy quickly. I think also that a Markov process analysis is a bit too much work, considering that the underlying probability distributions are well-known.

 

[baudot]

Did someone say 'Markov chains'?

... but you know, you're right. A Skill challenge could be modeled with a Markov process, but I think it would get a bit unwieldy quickly. I think also that a Markov process analysis is a bit too much work, considering that the underlying probability distributions are well-known.

Which approach did you have in mind, for a party with mixed skill levels? I'm certainly no fan of making work for myself. Markov is just the first place my sleep-deprived mind headed.