Log in

No account? Create an account
May. 2nd, 2017 @ 11:44 pm Skill checks which are difficult even if you have a lot of time

It varies, but in several editions of DnD, the official way skills work is: if it matters if you succeed on a task (say, picking a lock) first time, the task has a difficulty assigned, and you roll a d20 and add your skill, and if your number is as big or bigger, you succeed.

If it seems just obvious your character can probably do this, the GM is encouraged to just let it succeed. If you care about mechanics, there's a very similar concept "take 10" which allows you to not roll and just assume you got 10 (provided you're in an everyday not hectic situation), ie. just assume you got an average level of competence most of the time.

Likewise, if you could do it *eventually* by exhaustively trying everything, the GM is encouraged to just assume you can do that, even if it takes a while. The mechanical equivalent is "take 20", ie. assume you take 20 rounds, but eventually get 20 on your check. That's what you'd guess, but it's what the rules actually say in several editions.

Since you can usually figure out what the "obvious" thing that happens is, there's not that much benefit to having those specific rules (they're only half there in 5e). They're far from always realistic. But they do the right thing some of the time, while giving a default to use if you're not sure if the mechanics matter or not.


Implicitly the way it works is you're *either* quite high variance, or perfectly consistent.

It's not quite like that, if you roleplayed a mundane day-to-day activity repeatedly N times, you would assume you'd SOMETIMES screw up, even if it was something you could usually do, even if not as often as when people are attacking you.

But some situations, I'm not really satisfied with it.

If you're trying to pick a lock, or checking to see if you spot a hidden door, etc, then:

* If you roll every time, the party effectively have the value of the character with the best skill rolling perfectly, because they'll get there eventually
* If you assume you use 10, then the result is always the same: the character who's best at it ALWAYS spots it first, and the GM knows in advance exactly which locks and doors they'll succeed at.

Both are too deterministic, which takes away some of the fun for me: I *want* it to be a bit random. This lock is a bit harder than it looked from the outside. You get a bit of lockpick jammed in it. The party wizard just happens to remember an obscure lecture on magically concealing doors and notices a clue the rogue missed.

I've sometimes thought of this as "you roll, but if it doesn't make sense you'd succeed better a second time, then you don't get to reroll". But that's confusing and hard to track. Has the rogue tried this door already? If they have, why can't they try again?

My idea

It turns out, I actually want the take 10 and take 20 rules to work as they are, but maybe the difficulty should be randomly determined on the spot. Eg. instead of saying "all these doors are difficulty 15", say, "are difficulty 10+d10". Or a smaller variation, or occasionally a larger one.

That way there's a random element. Which doesn't matter if they're in the heat of combat, but does mean, there'll be some where "I can't get this one, we have to smash it" or "would one of you useless louts like to try to help?".

I could even generate a slightly different difficulty for different characters or different parties, although I'd probably only do that if it seemed to matter (and might simulate that in a more streamlined way, eg. dropping the difficulty for each party member, but choosing randomly who succeeds, the expert or someone else). That way you'd occasionally get a meaningful variation. And most of the time they'd deal with the encounter right then, only if they came back to it and it mattered that it was consistent would you have to track what you generated the first time.

You can also comment at http://jack.dreamwidth.org/1027666.html using OpenID. comment count unavailable comments so far.
About this Entry