The Alexandrian

From one point of view, the playing of a roleplaying game can be described as the organized exchange of information between players. Particularly numerical information.

GM: Give me an attack roll.
Player: 17.
GM: You hit.
Player: I do 18 points of damage.
GM: The orc falls dead at your feet!

The player generates a number (rolling their attack skill plus a d20 roll) and gives it to the GM. The GM performs a mathematical operation on that number (comparing it to the orc’s armor class) and the result of that operation causes him to request an additional number from the player. The player generates that number (by rolling the damage for their weapon) and reports it to the GM, who once again does an operation on that number (comparing it to the orc’s remaining hit points) and determines an outcome (the orc dies).

This seems simple and intuitive. And, in this case, it largely is.

But it turns out that how we process and pass numerical information around the table can have a big impact on play. For example:

GM: The orc’s AC is 17. Give me an attack roll.
Player: I hit. 18 points of damage.
GM: The orc falls dead at your feet!

By passing a piece of information (and the associated mathematical operation) over to the player, this GM has significantly improved the efficiency of their communication. If the orc hadn’t died (or if there are other identical orcs), this efficiency compounds over time because the GM doesn’t have to keep passing that piece of information to the player.

Of course, efficiency is not the be-all and end-all of a roleplaying game. There are any number of reasons why a GM might want to keep the orc’s armor class secret from the players (either as a general principle or due to specific circumstances). My point is not that these other considerations are somehow “wrong,” but rather simply that in choosing those other things the GM is sacrificing efficiency.

In many cases, however, the GM isn’t aware that this is a choice that they’re making. And often there are no reasons that might justify the inefficiency; the flow of information (and the impact it’s having on play) just isn’t something the GM is thinking about.

For a long time, this wasn’t something that I understood, either. I’d have discussions with people complaining that such-and-such a system was super complicated and a huge headache to play, and I would be confused because that didn’t match my experience with the game. It would have been easy to pat myself on the back and think, “Well, I guess I’m just smarter than they are,” but I would also have players say to me, “I’d played such-and-such a system before and I hated it, but you really made everything make sense. Can’t wait to play again.” And I’d scratch my head, because I really hadn’t done anything special in terms of teaching how the game worked.

The difference was in the flow of information. Not only can the flow of information around the gaming table be inefficient, it can also be confusing and burdensome.

ECLIPSE PHASE

We think of game mechanics primarily in terms of numerical values and how those values are created or manipulated. But in actual practice, many mechanical Eclipse Phase - Posthuman Studiosresolutions are performed by multiple people at the table. If you think of the resolution as a ball, it often has to be passed back and forth. Or you might think of it as a dance, and if we — as a table of players — don’t coordinate our actions in performing the resolution we’ll end up stepping on each other’s toes.

This efficient passing of information is an example of system mastery. Often, as a table gains experience with a particular RPG together, they’ll intuitively find the patterns of behavior that work. But this doesn’t always happen, and when it doesn’t we can benefit from consciously thinking about:

  • What numbers we say
  • Who is responsible for saying them
  • How we say them

Let me give a simple example of this, using Eclipse Phase.

Eclipse Phase is a percentile system. You modify your skill rating by difficulty and then, if you roll under that number on percentile dice, you succeed. In addition, your margin of success is equal to the number you roll on the dice. If you roll 30+ (and succeed) you get an excellent success; if you roll 60+ you get an exceptional success.

Here’s how things often go when I’m introducing new players to Eclipse Phase (particularly those new to roll-under percentile systems entirely):

GM: Give me a Navigation check.
Player: I got a 47.
GM: What’s your skill?
Player: 50.
GM: Great. That’s a success. An excellent success, actually, because you rolled over 30. Here’s what happens…

The players don’t know what numbers to give me, and so I need to pull those numbers out of them in order to perform the necessary operation (determining if this is a success or failure and the degree of success.) As players start to master the system, this will morph into:

GM: Give me a Navigation check.
Player: I got an excellent success.
GM: Great. Here’s what happens…

They can do this because they’ve learned the mechanics and now know that their roll of 47 when they have a skill of 50 is an excellent success. (In this, the exchange mirrors that of a player attacking an orc in D&D when they know it has AC 17, right? They don’t need to pass me the information to perform the mechanical operation because they can do the operation themselves. In fact, many people like roll-under percentile systems like this specifically because they make this kind of efficiency intuitive and almost automatic.)

But there’s actually a problem with this because, if you recall, Eclipse Phase also features difficulties which modify the target number. This disrupts the simple efficiency and we would often end up with discussions like this:

GM: Give me a Navigation check.
Player: I got an excellent success.
GM: There’s actually a difficulty here. What did you roll?
Player: 47.
GM: And what’s your skill?
Player: 50.
GM: Okay, so you actually failed. Here’s what happens…

This creates all kinds of friction at the table: It’s inefficient. It’s frequently confusing. And either the outcome doesn’t change at all (in which case we’ve deflated the drama of the resolution for no reason) or the player is frustrated that an outcome they thought was going one way is actually going the other.

The reason this is happening is because there is an operation that I, as the GM, need to perform (applying a hidden difficulty) but I’m not being given the number I need to perform that operation. The player has learned to throw the ball to a certain spot (“I got an excellent success”), but I’m frequently not standing at that spot and the ball painfully drops to the ground.

What I eventually figured out is that the information I need from the player is actually “XX out of YY” — where XX is the die roll and YY is their skill rating. I could catch that ball and easily carry it wherever it needed to go.

GM: Give me a Navigation check.
Player: I got 47 out of 55.
GM: An excellent success! Here’s what happens…

And I realized that I could literally just tell players that this is what they needed to say to me. I didn’t need to wait for them to figure it out. Even brand new players could almost instantly groove into the system.

ADVANCED D&D

As you spend more time with a system, you’ll frequently find odd corners which require a different flow of information. In some cases you may be able to tweak Dungeons & Dragon 3.5 - Players Handbookyour table norms to account for the special cases, but usually it’ll be more about learning when and how to cue your players that you all need to handle this information differently (and the players gaining the mastery to be able to quickly grok the new, sometimes overlapping, circumstances).

Let’s go back to D&D, for example.

When I’m a DM and I’ve got a horde of orcs attacking a single PC, it’s not unusual for me to roll all of their attacks at once, roll all of the damage from the successful attacks, add all that damage up, and then report it as a single total to the player. It just makes sense to do a running total of the numbers in front of me as I generate them rather than saying a string of numbers to a player and asking them to process the verbal information while doing the running total themselves.

And, of course, it works just fine… right up until a PC gets damage reduction. Now it’s the player who needs to perform a mechanical operation (subtracting their damage reduction from each hit) and doesn’t have the information they need to do that.

Even PCs with multiple attacks usually resolve them one by one for various reasons, so the reverse (players lumping damage together when the GM needs to apply damage reduction) rarely happens. But two of the PCs in my 3rd Edition campaign have weapons that deal bonus elemental damage, and they’ve learned that sometimes I need that damage specifically broken out because creatures are frequently resistant against or immune to fire or electricity damage.

When we first started running into this difficulty, the players defaulted to always giving me the elemental damage separately. But this was an unneeded inefficiency, and we quickly figured out that it was easier for me to simply tell them when they needed to give me the elemental damage separately.

These are simple examples, but they hopefully demonstrate that this sort of mastery is not an all-or-nothing affair. There’s almost always room to learn new tricks.

FENG SHUI

Let’s also take a look at one of these systems that’s fairly straightforward in its mechanical operations, but which can become devilishly difficult if you don’t pass information back and forth cleanly.

In Feng Shui 2, the dice mechanic produces a “swerve”: You subtract a negative d6 from a positive d6 in order to generate a bell curve result from -5 to +5. (Sixes actually explode and are rolled again, so the curve is smeared out at the ends, but that’s basically how it works.)

When you want to make an attack, you do two things. First, you check to see if you hit:

Roll Swerve + Attack Skill – Target’s Defense

If you hit, you then calculate damage:

Margin of Success + Weapon Damage – Target’s Toughness

Looking at those two equations on the page, there doesn’t seem to be anything particularly exotic about them. In practice, though, I’ve seen players and entire groups get completely tangled up in them. There tend to be two major problems:

  1. The attacker feels as if they should be able to complete one full step of this process and then report the result… except they can’t, because neither step can actually be completed without information that the defender posseses.
  2. Upon completing the first step, players want to report a flat success/failure outcome (“I hit”), but if they don’t pass the margin of success to the damage equation they can’t actually calculate damage.

What frequently happens in the latter case is:

GM: The target’s Defense is 17.
Player: (does math) Okay, I hit!
GM: So your damage will be equal to the margin of success plus your weapon damage. What was your margin of success?
Player: Uh… crap. I forgot? Three? Maybe four? Hang on… (does the math again)

Another interesting thing that will happen in this kind of situation is that the players — who don’t like being confused or frustrated! — will try to find ad hoc ways of routing around the problem. In Feng Shui 2, for example, I’ll frequently see players basically say, “Well… I know what this guy’s Defense value is because I attacked him last round. So I’m just going to attack him again to keep it simple.”

The important thing to take away from this is that the players want to solve the problem just as much as you do. But often this kind of ad hoc pseudo-solution just shifts the frustration: They’ve figured out how to make the mechanical resolution flow more smoothly, but they feel trapped by the system into making choices that they don’t necessarily want to make. The insane, over-the-top Hong Kong action of Feng Shui 2, for example, has been compromised as they attack the same guy over and over again.

So let’s say that you find yourself in this situation. How can you fix it?

  • Identify the sequence in which mechanical operations must be performed.
  • Identify who has the necessary information for each operation.
  • Figure out how to pass the information to the necessary person at each stage of the opration.

For example, in Feng Shui 2 who has each piece of information used when resolving an attack?

  • Outcome of the swerve roll. (Attacker)
  • Attack Skill (Attacker)
  • Target’s Defense (Defender)
  • Margin of Success (whoever calculated the outcome of the attack roll)
  • Weapon Damage (Attacker)
  • Target’s Toughness (Defender)
  • Wound Points taken (Defender)

If you look back up at the mechanical equations, it should be fairly easy to identify the resolution sequence and the numbers that need to be said:

  1. Attacker rolls swerve and adds their attack skill. (The game actually calls this the Action Result.) Attacker tells the Defender this number.
  2. Defender subtracts their Defense from the Action Result. (This is the margin of success. The game calls this the Outcome.) Defender tells the Attacker the Outcome.
  3. The Attacker adds the Outcome to the Weapon Damage. (The game calls this the Smackdown.) The Attacker tells the Defender the Smackdown.
  4. The Defender subtracts their Toughness from the Smackdown. (This is the number of Wound Points they take.)

You can see that Robin D. Laws, being a clever chap, identified the significant chunks of information in the system and gave them specific labels (Action Result, Outcome, Smackdown). Other games won’t necessarily do that for you (and even the Feng Shui 2 rulebook, unfortunately, doesn’t specifically call out how the information should be passed back and forth), but you should be able to break down the mechanical processes in any system in a similar manner.

PIGGYBACKING IN GUMSHOE (AND BEYOND!)

Let me close by talking about a mechanical interaction that has multiple players participating simultaneously (which, of course, makes the “dance” of information Trail of Cthulhu - Pelgrane Pressmore complicated to coordinate).

In the GUMSHOE System (used by games like Ashen Stars and Trail of Cthulhu), some group checks are resolved using a piggybacking mechanic:

  • One character is designated the Lead.
  • The difficulty of the test is equal to the base difficulty + 2 per additional character “piggybacking” on the Lead’s check.
  • Those piggybacking can spend 1 skill point to negate the +2 difficulty they’re adding to the check.

The mechanic is very useful when, for example, you want Aragorn to lead the hobbits through the wilderness without being detected by Ringwraiths: The more unskilled hobbits there are, the more difficult it should be for Aragorn to do that, but you still want success to be governed by Aragorn’s skill at leading the group.

Many moons ago I adapted this piggybacking structure to D20 systems like this:

  • One character takes the Lead.
  • Other characters can “piggyback” on the Lead’s skill check by making their own skill check at a DC equal to half of the DC of the Lead’s check. (So if the Lead is making a DC 30 check, the piggybackers must make a DC 15 check.)
  • The lead character can reduce the Piggyback DC by 1 for every -2 penalty they accept on their check.
  • The decision to piggyback on the check must be made before the Lead’s check is made.

On paper, this system made sense. When I put it into practice at the table, however, it wasn’t working out. It seemed complicated, finicky, and the players weren’t enjoying using the mechanic.

I gave up on it for a couple of years, and then came back to it and realized that the problem was that I had been sequencing the mechanic incorrectly. One element of this was actually a slight error in mechanical design, but even this was ultimately about the resolution sequence.

The way the mechanic was being resolved originally was:

  • The GM declares that, for example, a Stealth check needs to be made.
  • The players decide whether they want to use the Piggyback mechanic for this.
  • The GM approves it.
  • The players choose a Lead.
  • The other players decide whether they want to piggyback or not.
  • The Lead chooses whether or not they want to lower the Piggybacking DC.
  • The Lead would roll their check.
  • If the Lead succeeded, the other players would roll their piggybacking checks. (The logic being that if the Lead failed, there was no need for the piggybacking checks. But, in practice, players would see the Lead’s result and then try to opt out of piggybacking if it was bad.)

Here’s what the actual resolution sequence needed to be:

  • The GM declares that there is a piggyback check required.
  • The players choose their Lead.
  • The other players make their piggybacking checks. If any check fails, the largest margin of failure among all piggybacking characters increases the DC of the Lead’s check by +1 per two points of margin of failure.
  • The Lead makes their check.

You can immediately see, just from the number of steps involved, how much more streamlined this resolution process is. The only actual mechanical adjustment, however, is to shift the adjustment of the piggybacking DC from a decision made before the piggybacking checks to an effect of those checks.

The take-away here is that while our passing of mechanical information at the table is often numerical, it can also include other elements (like who’s taking Lead in a piggybacking check) which can also be streamlined and formalized for efficiency.

17 Responses to “Random GM Tip – The Numbers That We Say”

  1. Odontodactylus says:

    The flow of information is why Symbaroum is my favorite. The player knows their skill roll and you adjust up or down, just like the Eclipse example. Symbaroum does not have the GM rolling any dice, which is amazing and frees up my mind to think of more interesting things.

    You’re probably aware of Pathfinder 2e’s “Follow The Expert” which allows untrained characters to roll as if they are trained on group activities as long as someone in the party is an expert: sneaking, climbing, general physical feats.

    Blades in the Dark also has a smooth skill sharing system where the leader takes stress for each other character that fails their roll. Unfortunately d20 systems don’t lend themselves to such beautiful simplicity.

  2. Leland J. Tankersley says:

    I like the revision to piggybacking for D&D. But it seems difficult to implement if the players don’t know the DC being attempted. (Particularly in the case of, say, an opposed roll or roll against passive Perception or whatever.) Has that come up in your experience, and how’d it go?

    In my current game I’m starting to experiment with a way that (during exploration specifically — say for stealth or perception) one character can assist other characters by letting them add the square root of the assisting character’s ranks in the skill to their check. (So, it’s trivial to grant a +1 bonus by assisting, and even +2 is achievable at level 1, but +3 and +4 bonuses are much more difficult to reach.) I’m not sure this is really what I want, or not — it hasn’t seen enough actual use yet for me to have a good feel.

    In both approaches, every PC gets to roll a check. Which … is maybe good? But the more dice that get rolled, the more likely you’ll get an extreme failure somewhere. I’ve thought about doing combined checks in different ways, like only rolling at most two checks for any group, one with the highest net modifier and one with the lowest net modifier. That gets more complicated when you have modifiers that vary from PC to PC, though (e.g. distance modifiers when the group is somewhat spread out). And if only two PCs are rolling checks, are they always going to be the ones to succeed (or fail) at a given task?

    (I know you could concoct schemes to randomly determine characters that are affected by a success/failure, but it seems somewhat arbitrary. Maybe everyone rolls, but you only consider the results of the highest/lowest modifiers for purposes of success/failure, and then use everyone else’s result to figure out who actually made the noise/noticed the thing. Hmm, sorry, I’m rambling.)

  3. Alien@System says:

    This is an interesting topic, and I’ll see if I can spot any ways to make my table more efficient in that regard. Unfortunately, since Savage Worlds uses the “Roll above threshold” thing even for damage, you can’t really lump numbers together: Taking 4 damage thrice is very different from taking 12 damage at once.

    To me, the most hard to process numbers being shouted over the table are group perception rolls (or similar). Party enters a room, I call for Perception rolls, people start rolling, somebody asks me something specific, I answer, somebody else declares an action, I tell them to please wait until I have narrated their perception, last person announces their number finally, and I have already forgotten what the other 3 results were.

  4. Tyler H says:

    @Alien@System

    Your specific example jumps out as something to house rule. I recommend turning those Perception rolls into a pseudo-initiative system for exploration. When you call for the Perception results, write them all down without narrating anything yet. Take the highest result, narrate what that character sees, and then ask that player if they want to take immediate action. If they don’t, you can narrate the next highest result if they see anything different, and so on down the list. Once everyone has had a turn, I think you’ll know where to take the procedures next based on the circumstances.

  5. Justin Alexander says:

    @Leland: Handling hidden DCs is pretty straigthforward, actually. One check is a group check with one player abstaining (easy to do a hidden DC for that, right?). The lowest outcome of that check modifies the DC of the second check, but it can still be a hidden DC as easily as any other check.

    @Allan: One mental trick I use for group tests is to only keep the relevant number in my head. If I’m looking for the lowest check, then I just keep the lowest number I’ve received in my head. I don’t care about the other numbers and just let them go.

    Another example of this is Initiative checks. I’ll straight up train tables to wait until I’ve called for their Initiative result to give it to me. (By which I mean that I’ll call on a specific player, write down their result, and then call on the next specific player.) It’s a non-onerous process of simply saying, “Hang on,” the first time they start shouting numbers and then calling on people. Do that two or three times and the smart tables will just pick up on what the expected procedure is.

  6. Leland J. Tankersley says:

    I guess that’s true. I was thinking more in the context of streamlining the interaction, such that you would announce “ok, here’s the DC” and the party would choose a Lead and make their piggybacking tests and tell you “ok, worst failure was by 3” and then you know to add +2 to the Lead’s DC. The GM has to remember/calculate the DCs for each party member, but as you say you can throw away all results unless it’s the new largest margin of failure.

  7. Rob says:

    Everything written here goes double for online games. A single back and forth confirmation between a GM and a player can add minutes to a single character’s turn, and that adds up really fast. And once it starts adding up, players will start finding things to distract themselves, which only increases the latency. And that’s how you end up with online-unfriendly combat systems with rounds that last an hour each. In my experience, it’s never worth keeping a statistic like Armor Class (or the equivalent) secret, just let everyone know so you can keep things rolling.

    A friend of mine designed a tabletop system with this problem in mind. There is only one accuracy roll and damage is a fixed value announced along with the roll. And, most importantly, all active defenses / reactions only modify the damage, there are no forced rerolls or abilities that interrupt the action in any way. So the attacker rolls and throws out their damage, no confirmation needed. The target gets the damage and can use certain defensive actions to reduce it, no confirmation needed. This works especially well in online play, where the damage recording is often done parallel to the next turn beginning, allowing all the defense math to play out while someone else starts taking their turn.

  8. Tyler H says:

    @Rob

    That system sounds fun and interesting. Is it published?

  9. Alien@System says:

    I think there’s a math mistake in your explanation for the D20 Piggybacking. For the second procedure being equivalent to the first mathematically, the Lead DC has to be adjusted by -2 per point of margin of failure, not -1 per two points.

    Take for example the following situation: Base DC 30, thus Piggyback DC 15. Lead result is 38, lowest PB result 9.
    First procedure: Leader takes a -8 penalty, succeeds on their check. Piggybacker gets a +4 to their 9, giving 13 total, still below DC. Total result: Failed.
    Second procedure: Margin of failure is 15-9=6. Leader DC is increased by 3 to 33, which is still below result of 38. Total result: Success.

  10. Rob says:

    @Tyler H

    Yes, it is. It’s a Zelda fangame, so it’s free and online.
    https://reclaimthewild.net/

  11. Justin Alexander says:

    @Alien: You’re correct. I inverted the numbers there.

    In actual play, I’ve actually evolved into a different approach entirely where each failed piggybacking check applies a penalty to the Lead’s roll. Not mathematically equivalent, but seems to be conceptually cleaner.

  12. Tyler H says:

    @Rob

    Ah, yeah, I’ve played the Zelda game. It’s pretty great, and captures a lot of the feel of the video game surprisingly well. I guess I was expecting something with more deviation from D&D.

  13. Alien@System says:

    @Rob

    By pleasant coincidence, you’ve immensely helped me with a project of mine, which is converting a different video game to the table (Thea resp. its sequel). I’ve been searching for a good rule system for crafting and resource gathering, and yours is a perfect base.

    In fact, it’s a really good example of how a rule structure can be integrated to make a scenario structure. Unlike basically every other example of rules specifying crafting I’ve seen, Reclaim the Wild makes those rules complete by providing a clear structure of how to acquire materials, with guidelines where to find what and how to gather it. This puts the whole system out of the realm of GM fiat and into the hands of the players.

    And more (which hit me like a revelation last night in the small hours), the system gets actively integrated into the proceedings by the simple rule systems of weapon durability and merchant price margins. You can’t ignore the crafting and gathering, because you need new weapons regularly, and making them yourself is cheaper than buying them.

    So I tip my hat to your friend and all other designers involved in the creation of the rule book. It’s a quality product, and shows how important the principles are that Justin keeps going about.

    (If there is a small snag with it, it’s that the rulebook doesn’t provide clear overland travel procedures to make the searching of a landscape for resources a scenario. Also, I think a dungeon chapter might not go amiss.)

  14. Tyler H says:

    @Alien@System

    The zelda game does a great job of what it sounds like you’re after. If you would like some advice on running it, I suggest a point-crawl. To prep, just come up with a bunch of small encounters that offer a risk in order to acquire new resources.

    One of the best features of the resource system is that it is proactive to use the items. In many games, travel is limited by rations or other resources. In this game, travel is more about being presented with a bunch of opportunities for risks to acquire more materials. Each time you present the players with an opportunity, they weigh the use of their current resources against what they think they’ll get out of it if they proceed.

    Groups often skip content, but that’s fine. The content isn’t wasted, because it’s going to come up again when the group travels the same route again later.

    In fact, one of the best features of the system is that content is so re-usable. Players enjoy recognizing areas where they know they can try to acquire stuff with reduced risk. Play into that, allow it, even by sometimes playing the exact same encounter as a repeat. But then every once in a while you can change something up in a familiar encounter in order to surprise them.

  15. Colin R says:

    @Alien@System: Dungeon World has entirely trained me out of group perception rolls, initiative rolls, and pretty much group-anything rolls. 95% of the time at least, there’s no need for them and they just slow things down.

    In Dungeon World and other PBtA games, every roll is a risk. If you fail, something actively bad happens, so that makes players much more cautious about wanting to pick up the dice, and it means it should be their choice to do so. It’s kind of aggressive for the GM to tell them they have to roll, and so I do it only when there’s active danger for them to avoid.

    For perception rolls and the like, the D&D custom is generally that everybody gets a chance, but it’s not really necessary. Often there’s one obvious character to make the roll — the first one through the door, or the one who mentioned looking at the statue, or the one who’s actually visited the Shadowlands before. If it’s an ambush situation, it often makes sense to pick the one with the best chance of noticing it, or the one who’s currently supposed to be on watch, or the one who’s last in line. Sometimes I just pick the character who hasn’t had much to do lately, maybe they’re looking around because they’re bored.

    Having a cost to saying “I search the room too” is usually good. It avoids the kind of confusion Alien describes. It makes everybody care a little more when the dice are picked up. It keeps the story moving along, and lets individual characters have spotlight moments.

    Implicitly this is a form of piggybacking, because often one player’s roll gets to stand for the whole group. You can make it explicit with the kind of system Justin describes above, but often it’s fine to handle it entirely narratively. Just ask the expert how they handle guiding the party up the cliff, and let the good sense of their plan and their degree of success determine how it goes. Maybe assign a modifier for difficulty depending how many handicaps there are in the party. Methodically having everybody roll to see how much difficulty they add sometimes is fun if the action is really super important, but sometimes it’s just unnecessary complication.

  16. Justin Alexander says:

    There are a couple of drawbacks to only asking for the character with the highest skill modifier to make a check that may not be immediately obvious:

    1. It prevents other characters who exist in or adjacent to that niche from feeling that they’re able to contribute to that niche. If you have one PC with a +27 Stealth and another PC with a +25 Stealth, the player who made their character with +25 Stealth is still signaling that they want their character to be stealthy. If they’re never (or only rarely) allowed to make a Stealth check because it always defaults to the guy with the +27 skill, the mechanical distinction between them and the character with +3 Stealth is lost and that can be frustrating.

    2. It encourages hyper-specialization. Nobody needs to put points into Stealth if Bob has +27 Stealth. In many systems this can create balance issues that don’t exist if you encourage more well-rounded builds. It will also discourage splitting the party (since the party is only functional as a whole), which I find limits game play in an undesirable way.

  17. Jin Cardassian says:

    Hmm. I’m currently using a simpler approach for piggybacking in a “roll-under” d100 system (Delta Green). If half succeed, they all succeed. That has the problem that odd numbers of participants really skew the probably curve up or down, depending on their skill.

    I might adapt your d20 option instead. It lets the players clearly see which one of them is a drag on the lead, and for the lead to feel that effect. In this case, the worst failure imparts a -10% penalty for every 20 points below 100, to a max of -40%.

    This would make a nice synergy with my current rules for Collaborative Action (everybody working on a single task). The best success adds +10% to the lead for every 20 points above 0, to a max of +40%.

    Thinking this over, in the broadest possible terms we could define piggybacking as “more bodies are a hindrance”, which makes perfect sense for Stealth, while collaboration is “more hands are an asset”.

Leave a Reply

Archives

Recent Posts


Recent Comments

Copyright © The Alexandrian. All rights reserved.