The Cumulative -1 Rule, Or Khadim tries to do Mathematics Options

[knasser]

I was going to post this on the Chemistry thread, but there have been a few threads recently about the cumulative -1 rule and this is a general query on all of them, hence a new thread.

In SR4 pre-errata, there was an optional rule stating that you could only roll as many attempts on an Extended Test as you had dice in your pool. This was to stop PCs being able to accomplish anything given enough time and was invoked according to GM judgement. Post-errata (SR4A), this has been amended to say that your pool reduces by 1 on each attempt until you obviously stop at 0.

There have been some issues with whether this actually makes some things impossible where they should not be. One query was on the Chemistry skill for making explosives. Another (a bit more robust) was on the Data Search rules.

I worked out the following chances of success in Shadowrun (both extended and non-extended tests). I think they'll be useful for GM's to judge exactly what they're asking of their players.

http://knasser.me.uk/content/shadowrun/sr_..._by_knasser.pdf

I would like someone who knows their mathematics to confirm my numbers are correct, please.

If the numbers are correct, then I think the above shows a bit of a problem. Basically, with either the older 'maximum number of rolls = size of pool' or the new 'pool reduces by 1 each roll', you have a quite narrow band in the middle of the range of dice pools where there is uncertainty of outcome (chance of success in the range of 30-70%) and with dice pools above or below that middle band, the chance rapidly becomes either near certain failure or near certain success.

For example: A person with a dice pool of 8 trying for a threshold 12 test has a 56% chance of success. Take them to dice pool 9 and it jumps to 87%. Drop them down to dice pool 7 and it plummets to 19%.

That's awkward from both a playability and a realism point of view. Essentially, the more times you roll a dice, the more your results are going to descend on an average. Roll three dice and you might get 3 hits or you might get 0 or anything in between and no result will be surprising. But roll a hundred dice (which is how many you can roll with a dice pool of 14 reducing by 1 each roll) and you're very likely to come close to a third of your results being hits.

So two three questions:

One: Can anyone see anything wrong with my maths?

Two: Does anyone else find this a problem?

Three: What ways can we amend this to work better?

K.

[pbangarth]

I haven't checked the arithmetic, but it would appear from the tables that you don't take into account glitches and critical glitches. These should interfere with success... perhaps even, in the more serious case, cause outright failure.

So, in effect, glitches should reduce the chances of success that appear in your tables.

[knasser]

I haven't checked the arithmetic, but it would appear from the tables that you don't take into account glitches and critical glitches. These should interfere with success... perhaps even, in the more serious case, cause outright failure.

So, in effect, glitches should reduce the chances of success that appear in your tables.

You're right - I have not taken into account either glitches or critical glitches. There are couple of reasons for this. Firstly, I'm not very good at mathematics. (IMG:style_emoticons/default/wink.gif)

Secondly, glitches are actually independent of success. If you succeed and glitch, you've still succeeded, and if you fail and glitch, you're still falling into the bounds of failure. So basically, we still have that narrow margin of uncertainty for success or failure. So addressing glitches separately...

You actually have a higher chance of glitching on an Extended Test than you do on a normal test due to repeated rolls. I'll work these out in a bit and add them to the results. It's of interest, but it doesn't actually change chances of success or failure.

[ShaunClinton]

I done some maths on this a while ago and whilst I don't have it here just now it looked pretty similar.

I suppose I didn't really see it as much of a problem. I'm not satisfied with either mechanism for limiting extended tests but understand that they have to be limited. I've rationalised it as "once you reach a certain level of ability you can reliably expect to succeed at a given level of task."

The kinds of things extended tests tend to be for it shouldn't impact your play experience too much. I find it unsatisfying mainly for things which should sometimes go horribly wrong like equipment availability, but overall it doesn't mess things up too bad.

What particular problems are you having with the mechanic?

[Draco18s]

For example: A person with a dice pool of 8 trying for a threshold 12 test has a 56% chance of success. Take them to dice pool 9 and it jumps to 87%. Drop them down to dice pool 7 and it plummets to 19%.

There's a perfectly obvious reason for this "phenomenon." If you have 8 dice and you're rolling for an extended test you get N total dice, approximately a third of which will be successes. When using the optional rule, when your skill (dice pool) goes up by 1 you're in effect gaining exactly 9 dice. When you lose 1 point you're losing exactly 8 dice.
See:
1+2+3+4+5+6+7+8+9
1+2+3+4+5+6+7+8
1+2+3+4+5+6+7

That "first roll" ends up being about 20% of your total dice (9 is 20% of 45, 8 is 22% of 36, 7 is 25% of 28, as your dice pool decreases the first roll is worth more), so increasing your total pool by 1 is an increase of 20% more dice. So you're also losing or gaining 20% of your successes. If you're at even odds and lose 20% of your successes, you're no longer anywhere close to even odds. At 12 successes needed, you need an additional 2-3 successes on 8 fewer dice (that looks wrong, by saying you need 20% more on 20% less, but you need 20% more in order to lose 20% and still succeed).

Under the original rules (N tests using N dice) when you add and remove 1 from the skill the overall effect is mitigated, even though you're losing more dice and those dice constitute the same proportion of the total dice pool (DP 8 to DP 7 is about a 23% drop: 64 dice to 49), you simply have more dice towards the same threshold. 49 dice taken 1:4 is 12.25, you're already that 20% above needed, so losing 20% has little effect on the outcome.

[ZeroPoint]

I havn't examined the math in depth at all, but from a glance I think your numbers are right, at least in that they point out the problem. I have been working on a solution of my own, though i havn't implemented it yet and maybe you guys can give me your input on it.

Basically, my idea is to use a sort of tiered system for extended tests. Rather than limit the number of rolls in any way (don't cap rolls based on dice pool or apply -1 to each roll), instead set a minimum threshold as well as a threshold for completion. In order to make progress, you must reach at least the minimum threshold in order for it to count toward completing the test. I would use normal threshold rules, (1, 2, 3, 5) but would in most cases only use 1-3, using 5 only for excedingly high thresholds (creating rating 7+ hacking programs for example). For example, for a software test to write a rating 6 hacking program (12, 1 month), you could set the minimum threshold at 3, and after the first interval, the player would roll (software+logic+bonuses) which, in this case lets say its 14 dice total. On the first roll, player gets better than average, and gets 6 hits. Second interval, he rolls again (again at 14), and rolls slightly below average, gets 4 hits for a total of 10 (6 + 4). third interval, he rolls poorly, and only gets 2 hits. He makes no meaningful progress since he didn't get more than the minimum threshold. Final interval he gets 3 hits, the minimum threshold and finishes the program.

The minimum threshold provides the barrier from the old system where anyone with 1 rank in a skill could eventually do anything (assuming they don't horribly glitch). It also means that those with moderate dice pools can eventually succeed, but it will just take a hella lot longer. For the most part I think using a system like this will be better for story telling and makes a little more sense than limiting your rolls. It would however require a GM to be able to make a judgment call on the difficulty of extended tests.

For most extended tests, like climbing, I would set the minimum at 1, meaning if they get hits, it counts. With rules as they currently are, Climbing is an extended test, and with each combat round that passes, the character would get a -1 DP penalty. Meaning after about 30 seconds or so nobody could climb a tall ladder, or a tree, or do any sort of rock climbing because if their dice pool didn't get dropped to 0, it would still be low enough that they couldn't make any progress or they would glitch and fall off.

Well, tell me what you think anyway.

[Draco18s]

That's not a bad system, really. Geomancy already uses something like it. It's minimum TN is the BC of the area, there's no listed "maximum" its just you have to reach the TN a certain number of times (based on the BC again)

[knasser]

I havn't examined the math in depth at all, but from a glance I think your numbers are right, at least in that they point out the problem. I have been working on a solution of my own, though i havn't implemented it yet and maybe you guys can give me your input on it.

Basically, my idea is to use a sort of tiered system for extended tests. Rather than limit the number of rolls in any way (don't cap rolls based on dice pool or apply -1 to each roll), instead set a minimum threshold as well as a threshold for completion. In order to make progress, you must reach at least the minimum threshold in order for it to count toward completing the test. I would use normal threshold rules, (1, 2, 3, 5) but would in most cases only use 1-3, using 5 only for excedingly high thresholds (creating rating 7+ hacking programs for example). For example, for a software test to write a rating 6 hacking program (12, 1 month), you could set the minimum threshold at 3, and after the first interval, the player would roll (software+logic+bonuses) which, in this case lets say its 14 dice total. On the first roll, player gets better than average, and gets 6 hits. Second interval, he rolls again (again at 14), and rolls slightly below average, gets 4 hits for a total of 10 (6 + 4). third interval, he rolls poorly, and only gets 2 hits. He makes no meaningful progress since he didn't get more than the minimum threshold. Final interval he gets 3 hits, the minimum threshold and finishes the program.

The minimum threshold provides the barrier from the old system where anyone with 1 rank in a skill could eventually do anything (assuming they don't horribly glitch). It also means that those with moderate dice pools can eventually succeed, but it will just take a hella lot longer. For the most part I think using a system like this will be better for story telling and makes a little more sense than limiting your rolls. It would however require a GM to be able to make a judgment call on the difficulty of extended tests.

For most extended tests, like climbing, I would set the minimum at 1, meaning if they get hits, it counts. With rules as they currently are, Climbing is an extended test, and with each combat round that passes, the character would get a -1 DP penalty. Meaning after about 30 seconds or so nobody could climb a tall ladder, or a tree, or do any sort of rock climbing because if their dice pool didn't get dropped to 0, it would still be low enough that they couldn't make any progress or they would glitch and fall off.

Well, tell me what you think anyway.

This is an interesting idea. I'll run some of your numbers when I get time and we'll see what sort of probability spread we get and what would be equivalent to the old system in difficulty (roughly). But I think you might have something workable. I dislike breaking from RAW unless I feel I must, so anything as a replacement, I place high value on simplicity.

K.

[Jaid]

it also has the advantage of not producing an increasingly more likely critical glitch as you go further along, which would scuttle the entire attempt iirc.

[The Monk]

You can also combine the two: if you don't get the minimum threshold then you lose one die.

[The Monk]

Hmm, actually I would make it -2 when you don't get the minimum, that way it works with the try again rule. And if you spend an edge you can get your dice pool back up to the full amount.

[ZeroPoint]

You can also combine the two: if you don't get the minimum threshold then you lose one die.

I kinda like that, makes it a bit more complicated, but its an interesting idea.

[Heath Robinson]

Sum the Net Hits of a series of Threshold Tests instead of having some increasingly complex systems. If some things should be impossible, then just say "yeah, you aren't going to reasonably achieve this" instead of something that you only find out about after starting and ends up needing the solution of a minor mathematical puzzle if you want to understand why you failed.

I originally had a couple of paragraphes exhorting the benefits of the Sum of Net Hits system over increasingly complex systems, but really the principle of making things simple to understand works best as an argument for this. Your players already have enough to learn - let's keep this small part of the game as simple as possible.

[The Monk]

The sum of a series of threshold tests is exactly what it is. And just like any threshold tests, if you fail, you can try again with a -2 to dice pool.

[Heath Robinson]

The sum of a series of threshold tests is exactly what it is. And just like any threshold tests, if you fail, you can try again with a -2 to dice pool.

For example, for a software test to write a rating 6 hacking program (12, 1 month), you could set the minimum threshold at 3, and after the first interval, the player would roll (software+logic+bonuses) which, in this case lets say its 14 dice total. On the first roll, player gets better than average, and gets 6 hits. Second interval, he rolls again (again at 14), and rolls slightly below average, gets 4 hits for a total of 10 (6 + 4). third interval, he rolls poorly, and only gets 2 hits. He makes no meaningful progress since he didn't get more than the minimum threshold. Final interval he gets 3 hits, the minimum threshold and finishes the program.

[Draco18s]

I fail to see the point, Heath. Sum of a series of thresholds.

6 + 4 + 3 = 13 > 12.

[The Monk]

Yeah, very cryptic Mr. Robinson

[Heath Robinson]

If it were the sum of the Net Hits gained on a Threshold Test, then they would have subtracted 3 (the example Threshold) from the number of hits rolled (in order to determine the Net Hits). First the character rolls 6 hits - which is 3 Net Hits with the Threshold of 3. Further rolling 4 hits (1 Net Hit) would create a total of 4 (3 + 1), not 10 (6 + 4), hits towards completion.

Therefore, the system proposed by ZeroPoint is not Sum of Net Hits on Threshold Test, but something altogether weirder. It adds to the bulk you need to memorise.

[The Monk]

seems to me the mechanic you propose is just as complicated if not more so.

[Heath Robinson]

Threshold is meant to indicate difficulty, and all difficulties in SR4 are subtractive if you use hits to determine effect strength (like spells). In fact, the approach I suggested is basically like casting a bunch of spells against Object Resistance, or summoning a bunch of spirits that buy successes on their resistance rolls. It's even similar to matrix perception iirc. Since the test is shared with other parts of the system, the marginal complexity is low.

[ZeroPoint]

But then what if someone meets the threshold without exceeding...in other words getting no net hits? Success tests in SR only require you meet the threshold, not exceed. Under your system, said person would need to get at least 4 hits in order to progress, and at a very slow rate at that...you would then have to modify existing thresholds to fall within the existing time parameters. For the example programming test, said person would have taken 4 months to code a rating 6 program under my system. Under yours, they would have spent 4 months and only got a third of the program done. If this were the trend, it would take him a year to code that program. The only way to reconcile that with the time frame that I think is intended for extended tests, would be to lower extended test thresholds considerably.

While I understand what your saying, and I think it would be a good system, using your system as is would require a more extensive change to all existing extended test thresholds. Comparatively, the system I proposed would work very much like traditional extended tests, only requiring that the players at least attain a certain level of competence which could be quickly ad hoced by a GM. Neither system is really as simple as the RAW systems of past or present or optional, but at least we are addressing the issue that many of us have noticed.

Its extremely late for me right now so if none of this makes any sense I apologize and I'll try to clarify later.

[TheOOB]

Hmm, what if instead you set a lower threshold, and instead said that the player needs x number of success before they get y number of failures, and apply net hits past the first as a bonus to your next test.

So lets say someone is doing some basic repair job, which is a logic+automotive mechanic(2, 3/2, 1 hour) test. First hour the player gets 4 successes. Second hour he gets one bonus die but only rolls 1 success. The third hour he gets zero successes and thus fails the extended test.

A little more complex, but would generate a difficulty curve that is more gentle.

[ZeroPoint]

Hmm, what if instead you set a lower threshold, and instead said that the player needs x number of success before they get y number of failures, and apply net hits past the first as a bonus to your next test.

So lets say someone is doing some basic repair job, which is a logic+automotive mechanic(2, 3/2, 1 hour) test. First hour the player gets 4 successes. Second hour he gets one bonus die but only rolls 1 success. The third hour he gets zero successes and thus fails the extended test.

A little more complex, but would generate a difficulty curve that is more gentle.

I'm not sure I understand your example completely. Can you explain what the shorthand for the test is supposed to represent? Are you limiting the number of rolls? just not sure what's going on.

I can't say for certain since I don't understand completely, but from what I understand of it I like it. It seems like it would have the same problem that Heath's system would have, requiring you to recalculate how many of the tests work, including many of the athletics skills like climbing.

[JoelHalpern]

One thing to keep in mind is that if you make the mechanic too complicated, folks just won't use it. So trying to track more than one number from roll to roll seems like a mistake.

That leaves us two related suggestions. They both center on the idea that efforts that do not contribute noticeable success should not count at all. One counts all of the success if it counts any, and the other subtracts a fixed amount from the number of success of each roll (but flooring it at 0 per roll.)

I have three problems with these ideas.
Firstly, it seems counter to my view of how projects proceed in reality. One may spend days making small improvements in ones understanding and the framework of something (assuming it is difficult), and then when it comes together, all that earlier work comes together. (Ever watch an artist draw? A random line. Another random line. A few strokes. And then with the next few strokes there is suddenly a picture out of that chaos.) Another kind of project just requires steady effort. It has a lot of small steps, but if you do them, you get it done. Each hour you may get more or fewer steps done, but each step counts. Neither of these match that kind of per-roll thresholding.

The second problem is that this approach interacts very badly with the revised extended test rules. If the first two successes don't count, then as your number of dice gets down, even though the rules would indicate plenty of room to add some incremental success, these modifications would truncate the series. No, this is not a big deal, but it is bothersome.

Finally, one would have to refigure the target numbers for all of the significant extended tests. The difficulty of writing programs, crafting spells, writing focus or ally formulas, etc. All are calibrated to give a certain likelihood of success over a certain range of dice pools. While I do not think the game designers tuned that to the last decimal place, I do think that they looked at the rough chances, and asked themselves whether this was right. If you start discarding successes in any meaningful fashion, you are going to change this very heavily. I will admit that the change in the extended test (essentially halving the number of dice available for such activities) suggests that the earlier balance may not have been right. (Or maybe it was right and it is now already too high a threshold?)
Part of the problem here is that giving the GM an extra knob (the difficulty threshold per roll) is only actually useful if the GM has some understanding of what it will do if he changes that knob off of the 0 position.

Yours,
Joel

[Darklordofbunnie...]

The math for the scalar difficulties looks solid. The margins I see altering the chart are mostly human, i.e. the DM's understanding of threshold and knowledge of player pools vs. party skill & knowledge. The difference comes into play in that a system designed to allow players to accomplish a goal (making explosives) will initially present accessible difficulties, while a system designed where every chump with a stove can't make enough c4 to level Seattle will make things harder. There are only to challenges I would posit to a hard mathematical interpretation of the rules: though I'm no statistician I do know that edge dice can turn any reasonable table on its head, and that sometimes d6s behave more like golf balls than random number generators.