My work on After Next (and this blog in general) has been completely side-lined this semester, and I apologize for that. Hopefully I’ll have more time to devote to it in the future, but until I’m more sure, I’ll try to keep posting shorter things that arise out of what I see on forums or my thoughts on network TV shows or who knows what.
Today I want to talk about Save or Die/Lose spells in games like D&D; an ability (often a spell) which takes out a target in one shot, usually with a lower probability of success than a less lethal ability. In D&D the target rolls a Saving Throw to try to avoid some or all of the effects of spells, hence the name. The classic example is the Medusa’s gaze attack which turns on-lookers to stone. These tend to be somewhat controversial in game circles. I want to briefly consider some different implementations thereof and talk about the issues they raise for designers and some theoretical implementations that would address some of those issues.
In older editions of D&D as I have come to understand it*, powerful magic, including SoD spells, had a chance of backfiring or otherwise harming the caster. This dramatically increases the risk associated with using such magic, with the payoff being dramatic, powerful effects like instant death or petrification. In addition, due to their lower save DCs and higher save bonuses for many classes, SoDs were a large gamble to cast and likely to fail regardless of the risk of backfire. This about evened-out their utility to casters, PC and NPC alike.
D&D 3.5 ported over the spells from AD&D 2e without much alteration, but changed both the way spell DCs were set (now based on the spell level and caster’s stats) and the risks associated with casting powerful magics; namely, it was all removed. Casters in 3.5 had the risk removed and the chance of failure increased so that SoD spells were superior to almost any other choice of spell.
So, many people advocate simply going back to the AD&D paradigm, where casting spells was risky and the enemy made their save and negated the attack entirely more often than not. While that would be a step forward, balance-wise, I think it’s kind of missing the point. Casters didn’t like how that worked in AD&D, hence 3rd Edition changed it. By focusing on just the spell’s odds of success/backfiring, we’re either putting arbitrary mechanical frustrations on the caster, or, by removing them, on the targets of those spells. There’s an alternative way of looking at this problem, which I believe solves all of those problems while simultaneously making the game actually more interesting to boot.
The inspiration for this train of thought came from Extra Credits, which did an episode on a relevant topic a few weeks ago, called “Counter Play.”
The main thrust of the idea is this:
When designing an ability or a mechanic, you can’t only be thinking about how to make that ability or mechanic interesting for the player who gets to use it, you also have to think about how its interesting for the players its used on. And on a more rigorous level, it’s the idea that a mechanic or ability in a multiplayer game should increase the number of meaningful choices available both to the player using it and the player its being used on.
TTRPGs are not considered multiplayer games, but the psychology and importance of this principle is true because at the combat round level, they function exactly like one; the DM is one player controlling a single monster on any given turn (mostly), and the player is controlling their one character, and they are slinging these abilities back and forth in a way that is essentially indistinguishable from a competitive multiplayer game.
EC goes on to make the point that abilities that are an interesting tactical option for the user but not for the target is a good way to create frustrated targets. However, when you consider both sides of that equation, you create a richer play experience for both. So the question of whether or not SoDs are cool for the SoD-user is not the only consideration we have to take into account when designing SoDs. We also have to account for the SoD receiver’s experience and what options SoDs provide to them. Obviously, the only tactical implication of a traditional SoD for a target is “jack up that save modifier in your build!” That is one-dimensional (it’s not really a choice if it’s the only way) and irrelevant in combat (the decision is made outside of combat and nothing in combat will change it). This is not an enriching option as-is.
So SoDs need to be counter-able by the party, whether that’s by beginning an SoD at the end of one turn and then casting on the next and where taking any damage in-between either negates or greatly diminishes its effect if cast, SoDs only working on targets below a certain HP threshold, or something else that gives the opposing party/character an actual tactical option it can take in the midst of combat to attempt to prevent or counter it.
A third consideration for these mechanics in a TTRPG, I would say, is how it interacts with the user’s allies. You want abilities that interlock with the roles/actions of others, and gives them interesting options on their turns, too. The mundane half of the party’s contribution to the battle can’t be meaningless with one successful SoD. The mundanes have to contribute to SoDs somehow, whether that’s as simple as protecting the caster from having their concentration broken during casting, or contributing to meeting the necessary HP threshold for the spell to work, or some other combination of tactics.
Also, giving mundanes SoD abilities certainly couldn’t hurt, either. At some point a rogue should be able to just sneak up and stab a guy through the heart, and the fighter should be able to cut off the monster’s head with one mighty blow, so long as those have tactically interesting mechanics backing them up.
I’ll come out with some samples, but first I think I want to talk about the tactical mini-game. Grid-less tactical mini-game, as has been described previously.
*My understanding of the specifics of older D&D editions, I admit, is pretty lacking, so this is going off of what I have come to understand from others.