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

The much delayed Welcome to the Island, a collection of four scenarios for Over the Edge, will be releasing later this month. If you’re looking for scenarios that embody the design principles I talk about here on the Alexandrian, then this is the book you’ve been waiting for. Jonathan Tweet and I have collaborated on a scenario built around the party-planning game structure. The rest of the team, many of whom I originally recruited for Infinity, have created some really fantastic adventures featuring revelation lists, node-based scenario design, and a lot more cool stuff.

Welcome to the Island also features a small selection of what I now refer to as “scenario tools.” I first started developing these back around 2000 or 2001, early in my freelancing career, and have been slowly refining and adding to them ever since. If you’re just prepping notes for your home campaign, these are not things that you’d need (or want) to include. But published scenarios, they help bridge the gap between the author’s imagination and your gaming table. This often takes the form of giving you the tools to integrate a published scenario into your campaign: As writers there’s nothing we can do to avoid making a published adventure generic, but we can make it easier for you to take our generic plug-‘n-play module and make it a seamless part of what you and your players are creating.

These tools usually appear in sidebars. This intentionally segregates them from the main text of the scenario so that they don’t muddy up the presentation of the essential information you need at the table.

GROUNDWORK

Groundwork sidebars are used in scenarios to give examples of how a GM can incorporate elements of the scenario into their campaign prior to running the scenario. The idea is that you can make the scenario feel like an organic part of your campaign by properly laying the Groundwork for it.

We tend not to include anything that’s blatantly obvious. For example, you don’t need us to say something like, “This adventure features NPCs. You could have one of them show up before the adventure begins!” (Unless we have a particularly clever or relevant example of how that might work.)

SCENARIO THREADS

Scenario threads are the mirror image of Groundwork sidebars, suggesting ways in which elements of the scenario could be revisited in later scenarios.

In your home campaign, of course, this is something you should be doing organically: Pay attention to the people or places that particularly resonated with your players. If something interests them or is clicking for them, finding ways to reincorporate it into the campaign is an almost guaranteed success.

PLAYTEST TIP

By the time you’ve finished running a scenario, you’ll often have learned a lot about how you could have used it better. Some of these lessons can be applied in future scenarios, but it’s rare for a GM to have an opportunity to run the same scenario a second time. In published scenarios, though, we have the opportunity to share the insights we’ve gained during out playtests. These Playtest Tips are the “best practices” and offer suggestions for how particular encounters can be handled, alert you to potential problem areas, and try to provide other insights gleaned from our playtesting.

INTERSECTION

This is the newest addition my scenario toolkit and one that I picked up from previous editions of Over the Edge. Intersections reference other published scenarios and suggest how the material in that scenario could be tied to the material in this one. (For example, there’s a strange paranormal gadget in one scenario and a mad scientist in another scenario. When describing the mad scientist’s laboratory, we might include an Intersection that points out you could include a prototype or design notes for the paranormal gadget here, suggesting that this mad scientist was the one who developed it in the first place.)

For Welcome to the Island, these Intersections are limited to other scenarios in the same book. But future anthologies can include references between books, too.

FINAL THOUGHTS

The description of scenario tools in Welcome to the Island also includes revelation lists, which have been discussed here on the Alexandrian as part of the Three Clue Rule. I’d have included adversary rosters, too, but they aren’t used for any of the scenarios in this book. This material, along with the other tools described above, will be repeated in future adventure anthologies for Over the Edge because they weren’t included in the core rulebook. You can contrast this approach with Infinity, where I made sure these tools were described in the core rulebook specifically so that I wouldn’t have to explain them in every adventure we wanted to use them in.

(Which would be all of them, because they’re useful tools.)

I encourage other authors and publishers to also make use of these tools when writing scenarios for publication. They’re incredibly useful and I don’t feel like they should be put in a lockbox.

And if you have any suggestions for other useful tools I could be including in my published scenarios that would make them more useful for you to use at home, please let me know!

Momentum in 2d20 is generated when you roll more successes on an action test than required by the difficulty of the check. These points of Momentum can be spent to either immediately improve the result of the current check or saved to be used in the future, allowing you to build Momentum over the course of several lesser actions until you can accomplish big things.

Momentum can be spent to do stuff like:

• Add +1d20 to future skill tests
• Create obstacles for opponents (generally increasing the difficulty of their skill tests)
• Improve the quality of success
• Increase the scope of success
• Reduce the time required to accomplish a task
• Perform a normally noisy action stealthily
• Take an extra action in an action scene
• Boost damage on an attack
• Get a called shot
• Trigger program effects in Infowar

And so forth.

In Infinity we also specifically emphasized that Momentum is best seen as a creative tool for empowering the players. The GM is also given several structures for making complex rulings around Momentum (see p. 407 of the core rulebook).

One of these is using Momentum to model preparation. If the PCs want to take one action to set up or create advantage on another, the GM can call for a test on the first action (even if it normally wouldn’t require an action test) and then any Momentum generated on that test represents the advantage gained on the primary task.

One of the limitations to this approach, however, is that Momentum ablates over time. At the end of each scene, the team’s pool of saved Momentum is decreased by one. This means that if you want to set up an advantage in one scene that will benefit you for the next scene, it’s difficult to do that.

This problem can be solved by adapting a cool mechanic from Trail of Cthulhu: dedicated pools.

DEDICATED MOMENTUM POOLS

A dedicated Momentum pool can only be used in a given circumstance or in relation to a given subject. For example, you might hack the security cameras in a megacorp’s headquarters, creating a pool of Momentum that can be spent on things like Stealth and Observation tests when the PCs go to infiltrate the HQ.

GMs might also rule that certain resources simply grant a pool of dedicated Momentum. (Perhaps the patron who hired the PCs to steal the megacorp’s new research into captured Tohaa technology simply hands them the access codes to the security cameras as part of their briefing packet. They get the same dedicated Momentum pool even though they didn’t make any skill tests to obtain it.)

There are two advantages to a dedicated Momentum pool.

First, the dedicated Momentum pool does not ablate. The dedicated Momentum pool is separate from other saved Momentum and does not decrease at the end of each scene. This makes a dedicated Momentum pool a great model for preparations that play out over multiple scenes or which are made long before their intended use: The PCs lose some of the utility of the Momentum (since it has to be used for a specific purpose), but in exchange the Momentum becomes more durable.

Second, the dedicated Momentum pool can also create unique vectors that allow the PCs to take actions that they otherwise couldn’t. If you have access to the security feeds, for example, you can check them for activity in other areas of the building. If you have a copy of the religious text of an extremist Morat cult, you can reference it for information about their rituals that you would otherwise have no way of knowing.

These vectors can cut both ways, though! When the Momentum from the security camera pool runs out for example, it could easily justify the GM spending Heat to generate a complication in the form of the megacorp’s hackers realizing their system has been compromised and launching an Infowar attack on the PCs.

On page 33 of the Infinity roleplaying game, there is an “Advanced Rule” in a box:

As an advanced rule, instead of using a group pool for saved Momentum each PC can save Momentum and use it later individually. Players who have saved Momentum can spend it at any time to assist the actions of other player characters (or NPC allies) and otherwise influence the scene. At any given time, a player can save a maximum of six Momentum. In addition, any single action can benefit from a maximum of six saved Momentum. (For example, if two players had both saved four Momentum each, they still wouldn’t be able to spend all eight Momentum on a single action.) During Momentum depletion, each character loses 1 Momentum.

This is presented as an optional rule, but the truth is that, in my opinion and based on countless hours of playtesting, it is the only way that people should be playing the 2d20 System.

Let’s back up for a second and talk about how Momentum works in the 2d20 System, which was created by Jay Little for Mutant Chronicles and then also used in Infinity, Conan, John Carter of Mars, and Star Trek Adventures. When you resolve an action test in 2d20, you determine a target number based on Attribute + Skill and then you roll a pool of d20 dice — generally starting with 2d20, but expandable to 3d20, 4d20, 5d20, etc. You generate one success per die that rolls under the target number, plus an additional success if the roll is under the pertinent skill’s Focus. (So even if you’re only rolling 2d20, you’re often capable of generating up to four successes.) You succeed on the check if you score a number of successes equal to the difficulty of the task — so if the difficulty is 2, you need to generate two successes to succeed.

Here’s the final wrinkle: If you score MORE successes than you need to succeed at the task, those extra successes are converted into Momentum, which can be spent to enhance the current action or saved and spent later to gain bonuses to future checks, create obstacles for opponents, and other special effects.

At first glance, this seems fairly unremarkable. But in actual practice, it’s a really interesting system to GM for. As I wrote in the GM advice section of Infinity:

…setting a precise difficulty level is not a significant feature of the game. In fact, at least 95% of the time you will basically be deciding whether a task is of Average (D1) difficulty or Challenging (D2) difficulty. (The higher difficulty ratings of Daunting, Dire, and Epic obviously exist, but can be incredibly difficult or even impossible for some characters to achieve under normal circumstances. As such, they should be rare in their application.)

The reason for this is because the Infinity system is far less interested in the simple binary of passing or failing a check, and is instead intensely interested in the quality of your success, which is measured and leveraged through the use of Momentum.

So whereas a GM running D&D or Numenera or Feng Shui 2 is often giving a lot of thought to what the specific numerical value of difficulty for a particular test should be, the GM of a 2d20 game is instead generally just asking, “Is this check unusually hard?” If yes, then difficulty 2. If no, then difficulty 1. The mechanical focus of the game is (or, at least, should be) all in how Momentum is used after the check.

GROUP vs. INDIVIDUAL MOMENTUM

This brings us to saving Momentum. As noted, any Momentum generated by a check that isn’t immediately spent can instead be saved to be used in the future. The mechanical difference we’re talking about is whether you:

• put your saved Momentum into a group pool, from which any player can pull Momentum to spend; or
• put your saved Momentum into a personal pool which you control

The distinction between these points has little or no impact on game balance. Personal pools can theoretically allow a group to save more total Momentum, but in practice this rarely happens, it’s counterbalanced by the fact that every pool ablates a point of Momentum at the end of each scene (so the group loses saved Momentum faster), and the amount of saved Momentum that can be spent on a single check is capped at the same amount.

(We also playtested a variant which was completely equivalent mechanically: Total saved Momentum in the group is capped at 6 and the group collectively chooses which saved Momentum is lost during scene ablation. This makes bookkeeping more complicated and also tends to result in a pointless little “Momentum dance” where players spend their saved Momentum in order to open up cap space for the current player to save their Momentum.)

So if it’s basically mathematically equivalent, what’s the big deal?

Primarily, off-turn player engagement.

Consider a typical combat system: Everybody rolls an initiative and, when their initiative comes around, they take their turn. What happens when it’s not their turn? They just wait for it to be their turn again. The longer the wait, the more likely it is that they will become bored or tune out.

You can counteract this by giving players off-turn engagement. I discuss one example of this in The Design History of Saving Throws: D&D saving throws mechanically engage a player (i.e., let them roll dice) when it is not their turn. It’s a very basic form of engagement and doesn’t involve player agency, but it is physically engaging and that’s enough to break up the routine “it’s not my turn” cycle of tuning out.

When you used a group pool of saved Momentum that anyone can pull from, the player generating that Momentum gives up ownership of it. The only player engaged when the Momentum is used is the active player who is choosing to pull from the pool.

But if you use personal pools, then the player who controls the saved Momentum has off-turn engagement when they spend it to help the active player. This is off-turn engagement with the dial turned all the way up, because even when they’re not actively spending Momentum, the player is constantly looking for the opportunity to do so.

The other factor here is ownership. When a player dumps Momentum into a group pool it is almost immediately anonymized. When that Momentum is later spent by another player, the original player doesn’t feel any ownership over that; they don’t feel the direct connection between the thing that they did and the thing that the current player is doing. When Momentum is spent from a personal pool, on the other hand, the player has immediate and visceral agency. This usually also bleeds into the game world, with the player spending the Momentum explaining how their character is actually contributing to the current action.

This sense of collective contribution to success creates a group camaraderie that, once again, tends to transcend the specific moments in which Momentum is spent: The group is mechanically encouraged to view their successes collectively and take action collaboratively instead of focusing on individual accomplishments.

DESIGN HISTORY

So if I feel this strongly about personal pools being the correct approach for Infinity, why is it pushed off into an optional sidebar?

That’s a complicated question.

When I first became the Lead Developer for the Infinity RPG, the only 2d20 game in print was Mutant Chronicles. I was handed a mechanically complete lifepath system (that needed setting content slotted into it, but should otherwise not be touched) and a half-finished system that needed to be finished. So I spent a couple of months doing that and then turned my attention to developing the setting material for the core rulebook and the scenarios for Adventures in the Human Sphere, Quantronic Heat, and other supplements.

It was at this point, however, that the development process hit several problems. Basically, right around the time that I was declaring Infinity to be “system locked” (like picture lock for a film, I think of system lock as being the point where the mechanics are nailed down to the point where you can confidently develop supplementary material) there was a simultaneous project inside Modiphius to develop an internal 2d20 SRD that would create consistency between all published versions of the game.

In developing the Infinity version of the 2d20 System there were a couple key design principles I had established.

First, because we were going to be developing full-fledged systems for Warfare, Infowar, and Psywar, I felt it was important to streamline and simplify the core of the system. The complexity of the game would come from having these robust scenario/game structures, and therefore other sources of complexity in the system should be smoothed out.

Second, the 2d20 System in Mutant Chronicles — like the pre-Genesys system Little had designed before it — features a set of core mechanics designed to empower players and give GMs tools for making powerful, robust rulings, but then surrounds those mechanics with a ton of mechanically crunchy specificity. The core mechanics of the Momentum system, for example, are beautifully designed to empower player creativity and improvisation, but then the system works relentlessly to lock that down by providing a laundry list of specifically defined ways that you’re allowed to spend the Momentum. My own design predilections, on the other hand, lean the other way: Ditch all the hand-holding and just leave the powerful core structures.

These two principles worked well with each other: Focusing on cruft-free core structures simultaneously simplified the mechanical core so that it could be developed through the new functionality of Infowar and Psywar rather than a lot of situational rules.

But the principles didn’t work well with the new guiding principle of unifying all 2d20 System design to match the new SRD. The result was a tug of war for the heart and identity of the game, complicated immensely because we had a dozen freelancers working on supplemental material that had to be constantly revised every time the core mechanics were violently yanked in a new direction.

I won some of those battles. I lost others. In the end, the only way I could keep the personal Momentum pools that I felt so passionately about in the game was as an optional rule, and even that was a fight.

But, seriously, if you’re running a 2d20 game — any 2d20 game! — swap to personal Momentum pools.

Buy!

I’ve talked about Numenera and the Cypher System it spawned quite a bit in the past, both here on the Alexandrian and elsewhere. Often what I’m talking about are the GM intrusions, which are one of the best and most innovative elements of the system.

When saying that intrusions are innovative, however, I’m not infrequently confronted by people demanding stuff like, “Have you ever read any Fate game at all?” It’s an ironic comment because it’s an accusation of ignorance which is, in fact, born from ignorance. But it’s happened often enough that I feel a need to just write up a definitive explanation that I can reference in the future.

First: Yes, I’m familiar with and have played (and run) Fate.

Second: Yes, both games feature a mechanic in which the GM offers a point of meta-currency to a player to achieve an effect which the player can cancel by spending their own meta-currency. But the similarity is superficial, in much the same way that saying “in Magic: The Gathering you play cards from your hand and in Dominion you also play cards from your hand” is a superficial comparison of those games.

Let’s break this down.

GM INTRUSIONS

I discuss the GM intrusions of the Cypher System in much more detail in The Art of GM Intrusions, but the short version is that the function of a GM intrusion is for the GM to say, “I’m going to do something that the rules don’t normally allow me to do.”

GMs will, of course, do this from time to time in any system. But there’s generally a limit. For example, if a GM’s response to a successful attack in a typical RPG was to say, “Yeah! And you hit the mammoth-saur so hard that your axe actually gets stuck in its side! And then it rears back and rips the axe right out of hands!” the players would generally say (or at least think), “This is bullshit.” Because punishing people for making a successful attack is bullshit; it’s a violation of the rules we’ve all agreed to abide by.

But hitting something so hard that your weapon gets stuck in it is actually pretty fucking badass. And what the GM intrusion mechanics basically let the GM say is, “Wouldn’t this be cool?” (by offering XP) and for the players to say, “Fuck yeah!” (by accepting the XP) or “No, I don’t think so,” (by spending an XP to cancel the intrusion) within the rules we’ve all agreed to abide by.

We could, of course, just chat this out without the mechanic, but (a) you can really say that about any mechanic in an RPG and (b) in practice, making it an explicit mechanic lubricates the interaction so that play doesn’t bog down on these points.

This simultaneously lets Monte Cook, the designer, keep the system streamlined by binning all the special case rules. The example he gives in the book basically boils down to, “The reason other games have attack of opportunity rules is to eliminate weird edge cases where turn-based combat creates odd and undesirable outcomes like being unable to stop someone from running past you because it’s not your turn. Instead of having a whole heap of special case rules trying to weed out those corner cases, the GM should just use the intrusion mechanic to deal with them when and if they’re important.”

Basically, any time the rules would discourage something awesome from happening or result in one of these weird edge cases due to their streamlined abstraction, the GM instrusion provides a mechanism for resolving it.

FATE COMPELS

Let’s compare this to Fate in which the GM can identify a specific Aspect belonging to a character and compel it by paying a Fate Point to the player. (And the player, in turn, can cancel the compel by instead spending a Fate Point of their own.)

As we’ve noted, the form of the mechanic is superficially similar. But the function of the mechanic has a completely different feature set.

I’ve been spending a lot of time with the Dresden Files RPG lately, so we’ll use that as our primary example. It includes two types of compels: Limitations and Complications. Limitations are the GM forcing the player to take a specific type of action (which, you’ll note, is not something that GM intrusions do at all). Complications are similar to one variety of GM intrusion (by introducing elements that are disadvantageous to the PCs during play), but note how the actual execution of the mechanic is almost completely inverted: Compelling an Aspect isn’t providing mechanical support for unanticipated edge cases; they’re explicitly the core rule by which Aspects (which are one of the primary ways of describing your character mechanically) are mechanically implemented.

Here’s one way to clearly perceive the distinction: If you took GM intrusions out of the Cypher System, nothing on your character sheet would change. If you took compels out of Fate, you’d have a whole bunch of negative-leaning Aspects on your character sheet without any mechanical hook for using them.

WHY DOES THIS MATTER?

Because the misapprehension that GM intrusions are supposed to be used like compels in Fate appears to be causing a lot of Fate players to misuse and dismiss one of the most useful innovations in RPG design in the last decade.

If you believe that GM intrusions are just “watered down compels from Fate” (as one Fate player told me), it means that you’re not only limiting your use of GM intrusions to one very tiny part of what they’re capable of, you’re also saddling the GM intrusion mechanic with an entire ethos (being the primary mechanism for leveraging character traits into play) which GM intrusions are not mechanically capable of robustly supporting (because, again, that’s not what they’re designed to do).

The opposite, of course, would also be true: If you tried to use Fate compels as if they were GM intrusions, the result would almost certainly be a very sub-optimal use of the Fate system. However, I don’t think I’ve ever seen this in actual play or online discussions, which is why my discussion here is primarily focused in the opposite direction.