Go to Part 1

Yesterday I rolled out some experimental rules for revising hydras and creating new hydroid creatures. Today we’re going to put them into practice with a few sample creatures.

Bear in mind that this is still an installment of an Untested column: The general rules for hydroids haven’t been tested and these specific monsters even less so. If you do find occasion to use them in your own games, please circle back and let us know how it went!

HYDRALING

Baby hydras — also known as hydralings – are two-headed serpents, only developing the legs of an adult hydra during adolescence. The mothers of hydralings have been seen to deliberately bite off one of the heads from their offspring, prompting the growth of an additional head. Some have hypothesized that this is because hydralings never truly sleep (since one of their heads is always awake), but it’s more likely an instinctual action which prompts (or is prompted by) the hydraling’s development.

HYDRALING
Medium monstrosity, unaligned

Armor Class 13 (Natural Armor)
Hit Points Special
Speed 40 ft., swim 20 ft.

STR 12 (+1)
DEX 15 (+2)
CON 12 (+1)
INT 2 (-4)
WIS 10 (+0)
CHA 6 (-2)

Skills Perception +3, Stealth +4
Senses passive Perception 13
Challenge 1/2 (100 XP)

Amphibious. A hydraling can breathe air and water.

Hydroid. The hydraling has two heads. For every 10 points of damage the hydra suffers, one of its heads dies. If all of its heads die, the hydraling dies.

At the end of its turn, the hydraling grows two heads for each of its severed heads, unless it has taken fire damage since the head was severed. A hydraling can have a maximum of five heads.

Multiple Heads. While the hydraling has more than one head, it has advantage on saving throws against being blinded, charmed, deafened, frightened, stunned, and knocked unconscious.

For each additional head beyond one, it gets an extra reaction that can be used only for opportunity attacks.

While the hydraling sleeps, at least one of its heads is awake.

ACTIONS

Multiattack. The hydraling makes as many bite attacks as it has heads.

Bite. Melee Weapon Attack: +4 to hit, reach 5 ft., one target. Hit: (1d4 +2) piercing damage.

TENTACULAR ABOMINATION

A dog-size creature with eel-like skin. It has no head, but its back is a writhing mass of tentacles.

TENTACULAR ABOMINATION
Medium monstrosity, unaligned

Armor Class 15 (Natural Armor)
Hit Points: Special
Speed 30 ft.

STR 17 (+3)
DEX 12 (+1)
CON 14 (+2)
INT 6 (-2)
WIS 13 (+1)
CHA 6 (-2)

Skills Perception +5
Senses Blindsight 60 ft., passive Perception 15
Challenge 3 (700 XP)

Pack Tactics. The tentacular abomination has advantage on an attack roll against a creature if at least one of the tentacular abomination’s allies is within 5 ft. of the creature and the ally isn’t incapacitated.

Hydroid. The tentacular abomination has five tentacles. For every 10 points of damage the abomination suffers, one of its tentacles dies. If all of its tentacles die, the abomination dies.

At the end of its turn, the abomination grows two tentacles for each of its severed tentacles, unless it has taken acid damage since the head was severed.

Multiple Heads. While the tentacular abomination has more than one head, it has advantage on saving throws against being blinded, charmed, deafened, frightened, stunned, and knocked unconscious.

For each additional head beyond one, it gets an extra reaction that can be used only for opportunity attacks.

While the abomination sleeps, at least one of its heads is awake.

ACTIONS

Multiattack. The abomination makes as many tentacle attacks as it has tentacles.

Tentacle. Melee Weapon Attack: +5 to hit, reach 10 ft., one target. Hit: (1d6+3) bludgeoning damage. The target is grappled (escape DC 13) by one of the abomination’s tentacles. Until this grapple ends, the tentacular horror can’t use that tentacle on another target.

LENGLIAN SERAPHIM

Wings. Dozens of wings clustered together as if shielding a central mass (although no such mass exists within the impossible dimensional toroid of the Lenglian seraph), with eyes opening and shutting between the wings. Some Lenglian seraphs are also known to emit smoke or aurora-like, multi-colored halos as their wings continue to fold and unfold, stretching, reaching, searching, beating the air around them.

(It is also not unusual for Lenglian seraphs to be confused for a swarm of winged creatures, particularly from a distance.)

LENGLIAN SERAPHIM
Large celestial, lawful good

Armor Class 17 (Natural Armor)
Hit Points Special
Speed fly 80 ft.

STR 22 (+6)
DEX 21 (+5)
CON 14 (+2)
INT 21 (+5)
WIS 16 (+3)
CHA 19 (+4)

Saving Throws Wis +7
Skills Perception +7
Damage Resistance Radiant; Bludgeoning, Piercing, and Slashing from Nonmagical Attacks
Condition Immunities Charmed, Exhaustion, Frightened
Senses Truesight 120 ft., passive Perception 17
Languages All, Telepathy 120 ft.
Challenge 12 (8,400 XP)

Innate Spellcasting. The seraph’s spellcasting ability is Charsima (spell save DC 17). The seraph can innately cast the following spells, requiring only verbal components:

• At will: bless, detect evil and good
• 1/day each: augury, commune

Hydroid. A Lengling seraph has thirty-five wings. For every 5 points of damage the seraph suffers, one of its wings is severed. If all of its wings are severed, the seraph dies.

At the end of its turn, the seraph grows two wings for each of its severed wings, unless it has been splashed with unholy water since the wing was severed or is under the effects of a bane spell.

Many Eyed. A seraph has eyes proportionate to its wings. While the seraph has more than one wing, it has advantage on saving throws against being blinded, charmed, deafened, frightened, stunned, and knocked unconscious.

For every five wings the seraph has, it gets an extra reaction that can only be used for opportunity attacks.

ACTIONS

Multiattack. The seraphim can make one wing attack for every five wings it has.

Wing. Melee Weapon Attack: +8 to hit, reach 5 ft., one target. Hit: (1d8+6) bludgeoning damage.

Radiant Gaze (Recharge 5-6). One creature that the seraph can see within 60 feet of it must make a DC 17 Constitution saving throw, taking 70 (20d6) radiant damage on a failed save, or half as much damage on a successful one.

LEGENDARY ACTION

Can take one legendary action. Only one legendary action can be used at a time, and only at the end of another creature’s turn. Spent legendary actions are regained at the start of each turn.

Buffeting Wings. The seraph beats its wings. Each creature within 10 ft. of the seraph must succeed on a DC 17 Dexterity saving throw or take 1d6+6 bludgeoning damage and be knocked prone. The seraph can then fly up to half its flying speed.

I woke up this morning with a cool idea for how to handle hydras in D&D. A quick check of the 5^th Edition Monster Manual, however, alerted me to the fact that 5^th Edition basically already did it that way.

Well played, 5^th Edition.

Upon further investigation, it became clear that my subconscious had dredged up a goulash of 3^rd Edition, 2^nd Edition, and OD&D mechanics and then regurgitated them.

Which, upon further consideration is a pretty good summary of the design methodology of 5^th Edition. (This is not a critique.)

Hydras, in D&D 5^th Edition, work like this:

Multiple Heads. The hydra has five heads. While it has more than one head, the hydra has advantage on saving throws against being blinded, charmed, deafened, frightened, stunned, and knocked unconscious.

Whenever the hydra takes 25 or more damage in a single turn, one of its heads dies. If all of its heads die, the hydra dies.

At the end of its turn, it grows two heads for each of its heads that died since its last turn, unless it has taken fire damage since its last turn. The hydra regains 10 hit points for each head regrown in this way.

The heads give a couple other advantages (extra opportunity attacks, it can sleep while still having one head awake to keep watch), but that’s the fundamental mechanic that models the classic hydra.

There are a couple of changes to this approach that I’d like to experiment with:

1. Eliminate the concept of “total hit points” entirely. You can’t kill a hydra unless you chop off all of its heads.
2. Tweak the mechanic so that you can eliminate more than one head per turn.

So if a fighter gets in there and deals 50 points of damage, his flurrying blades will have hacked off a couple of heads at once. Then maybe the rogue leaps onto its back, deals another 25 points of damage, and hacks off a third head. On the hydra’s turn, it will grow back six heads (two for each severed head).

REVISING THE HYDRA

Thus we can say that a hydra should be mechanically defined as:

• # of heads
• A damage threshold at which it loses a head
• At the end of its next turn or after X rounds it can regrow two heads if it has a severed head
• A sealing condition (usually a type of damage) that prevents
• Dies when it runs out heads.

The “Hit Points” entry of their stat block would be listed as “Special”: They only die if they run out of heads.

Here’s what our revised hydra special abilities would look like:

Hydroid. The hydra has five heads. For every 25 points of damage the hydra suffers, one of its heads dies. If all of its heads die, the hydra dies.

At the end of its turn, the hydra grows two heads for each of its severed heads, unless it has taken fire damage since the head was severed.

Multiple Heads. While the hydra has more than one head, it has advantage on saving throws against being blinded, charmed, deafened, frightened, stunned, and knocked unconscious.

For each additional head beyond one, it gets an extra reaction that can be used only for opportunity attacks.

While the hydra sleeps, at least one of its heads is awake.

CREATING HYDROID CREATURES

These mechanics can be used as the basis for other hydroid creatures. Here are some proposed guidelines for doing so.

Damage Threshold. This is the number of hit points required to chop off one of the hydroid appendages. These numbers are loosely based around the idea that a character of the appropriate level should be roughly capable of taking out one head per turn.

I’d recommend halving this value if the sealing damage type or other condition is an unusual one. (This would mean that the killing the monster would typically require killing the heads faster than they can grow back.)

# of Heads. Using the Creating Quick Monster Stats table on p. 274 of the Dungeon Master’s Guide, multiply the minimum hit points for your selected CR by 0.75 and then divide by the damage threshold listed above for its CR.

For example, a CR 10 creature would have 206 hp using the table above, so multiply by 0.75 (154) and then divide by 25 (per the damage threshold table above) to determine that your monster should have six heads.

(This is based strictly on reverse-engineering the existing hydra stat block and it’s unclear if it holds up in practice. It seems to pretty reliably give you 4-8 heads, so you could also probably just get away with slotting in 5-6 heads and not worrying about it.)

You can also use this method to very quickly adapt existing stat blocks. For example, if you wanted to have a hydroid warg (CR ½) you’d take the warg’s current hit point total of 26, multiple by 0.75 (19.5), and then divide by 10. The hydroid warg would start with two heads.

Variant: Maximum Number of Heads. In 2^nd Edition, Lernaen hydras could grow maximum of 12 heads. In 3^rd Edition, they were limited to no more than twice its original number of heads. You might consider doing the same for some hydroid creatures.

DESIGN NOTES

Hydras have a well-known gimmick: They regrow their heads unless you cauterize the stumps with fire. It’s a fun gimmick the can create an encounter which mechanically feels different from other encounters. The only problem is that, because the hydra still has a hit points that’s easier to wipe out than its heads, the mechanical gimmick is irrelevant: There’s often little or no advantage to pursuing it, so parties will just bypass it.

This is boring.

So we fix it by eliminating the bypass. Just like you can’t bypass a troll’s regeneration by just dealing lots of hit point damage to it, you can’t bypass a hydra’s heads.

And, just as regeneration mechanics were created for trolls and now underlie a whole bunch of creatures, these hydroid mechanics can also be used for all kinds of things. We’ll take a look at several examples of this tomorrow.

Go to Part 2

As described in The Art of the Key, the first published module for D&D was Palace of the Vampire Queen. It used a very simplistic, tabular key:

A year later, Judges Guild would release Wilderlands of High Fantasy, the first published hexcawl. This book keyed only a fraction of the hexes on its map, also using mostly tabular methods:

Different table formats were presented for Lurid Lairs (above), Villages, and Citadels & Castles.

These tablular entries are supplemented with short, one or two sentence entries like these:

1002-Above Ground Ruined Temple-3 Windwalkers

2822-Overgrown Antique Paintings-Copper Dragon

1418 Isle of Grath – Abode of four huge Ogres which relish human flesh. Every Ogre has three eyes, and flaming red hair. A pet giant crocodile follows them to feast on the leavings.

(“Overgrown Antique Paintings” is just a typo. Based on the format of other entries, it should be specifying an overgrown something in which antique paintings are the treasure to be looted from a copper dragon. The image it conjures of a copper dragon living inside magical antique paintings that one can presumably enter is just too fantastic for me not to call it out here. But I digress.)

But whereas the published presentation of dungeons has significantly developed and improved over the last 40+ years, the presentation of hexcrawls largely has not. If you pick up virtually any of the OSR hexcrawls released over the past few years, you’ll still find:

Incomplete keys, in which lots of hexes aren’t keyed at all. This is generally an indication that your hexcrawl is at the wrong scale. This creates two problems in actual play. First, it tends to create very poor pacing (with long spans of time in which navigational decisions are not resulting in interesting feedback in the form of content). Second, the lack of content equates to a lack of structure. One obvious example of this is that hexcrawls with vast spans of empty space lack sufficient landmarks in order to guide navigation.

Underdeveloped keys that aren’t ready for actual play. Telling me that there is, for example, a dungeon in a particular hex with “Hobgoblins 42” in it doesn’t actually give me any meaningful information for bringing that dungeon into play.

Perhaps the most egregious example of this sort of thing are products like Carcosa, which feature keys almost entirely generated by rolling on the random stocking tables found in the back of the book and jotting down the result. There’s zero value in such a key. Why? Because you could just as easily roll on the random stocking tables yourself.

Transitory keys, in which the content keyed to a hex is something you only encounter once and then the hex is functionally empty the next time you go there. (For example, from Isle of the Unknown, “A 9^th-level cleric… in a red surcoat with a white cross rides southeast to take ship upon a holy pilgrimage.”) Because this content effectively deletes itself from the key, over time this transitory content turns even a complete key into an incomplete one. It should instead be encoded as a random encounter (or similar structure).

SO WHAT?

Why is this a problem?

Well, imagine if we designed dungeons this way.

THE TOMB OF SAGRATHEA

Level 1: 12 skeletons.

Level 2: The original laboratories of the lich Sagrathea, now divided into a tribe of 17 ghost eaters and a kingdom of 46 skeletons locked in war with each other.

Level 3: The walls of the Bloodpool Labyrinth are of pinkish flesh which bleeds a grease-like substance if injured. There are many traps here. Patrolled by 2 flaming skulls.

Level 4: [intentionally left blank]

Level 5: [intentionally left blank]

Level 6: 121 skeletons + 4 ogre skeletons.

Level 7 – Sagrathea’s Gardens: A collection of 27 caverns each rendered as a miniature biome. Sagrathea has recorded his spellbook in these gardens, with each garden cavern recording a single spell of the 4^th to 9^th level of potency.

Level 8 – Sagrathea’s Manse: The lich Sagrathea sits upon a throne of black stone with his wight bride.

You can add in a side-view illustration of the dungeon showing each level’s vertical elevation, but if you can imagine looking at this dungeon “key” and being asked to run the Tomb of Sagrathea, then you know how I generally feel when I open up a typical hexcrawl and see the “key” inside.

There’s a real “draw the rest of the fucking owl” vibe to it.

WHAT SHOULD A HEXCRAWL LOOK LIKE?

Published hexcrawls are, in my opinion, providing a poor example of the value a hexcrawl structure is actually capable of providing.

At a basic level, I want to be able to pick up a hexmap and its key and have a fundamentally playable experience.

At a more advanced level, once you have a fully functional hexcrawl, there’s all kinds of cool utility that you can leverage out of that hexcrawl. For example, in Thinking About Wilderness Travel I looked at how the basic scaffolding for rich route-based travel basically just falls out of a properly designed hexcrawl key. Hexcrawls can also provide the context and tools for rapidly restocking empty dungeon complexes, as described in (Re-)Running the Megadunegon.

You can see the sample hex key I included as part of my longer series on hexcrawls.

If you’re looking for something like this on the market right now, check out The Dark of Hot Springs Island by Jacob Hurst, Gabriel Hernandez, Even Peterson, and Donnie Garcia. Every hex is keyed with content. Every lair and dungeon is mapped. And it’s paired to the incredible Field Guide to Hot Springs Island, an incredibly rich handout that’s designed to be given to your players as a kind of rumor table on steroids. It’s not just everything I want in a hexcrawl product; it’s more than that. And it’s the absolute gold standard to which any hexcrawl supplement should aspire.

Back to Hexcrawls

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 resolutions 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 your 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 3^rd 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 more 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.