My house rules for B/X D&D

Howdy all!

I've got a few posts in the works I'm pretty excited about: my first #Dungeon23 project (teaser: Minotaur in a bow-tie), my system for handling magical research and other long-term projects, and at some point a detailed discussion of my personal remake of the thief (a rite of passage for old-school D&D bloggers).

However, I've also got a 3-week old baby and a 2-year old... so some of those are progressing slower than I'd like. In the meantime, I'd like to share the most recent version of my collected house rules for B/X D&D. These have changed quite a bit since last I shared them - I think for the better. :)

(Google Sheets link) Matt's B/X House Rules

The link above is to a Google Sheets document that collects modified race/class ability and progression tables into one place, and that always contains a link to the latest PDF of my house rules (v2.4 as of date of publishing). These tables have been really helpful for quick reference, as the accumulated changes to racial abilities and class progression were getting a little too cumbersome for my players to parse from lists of individual rules changes. 

My favorite rules in this updated version (each of which I could write an entire post on - and would like to at some point) are:

• Character advancement: I've developed my own take on how to split race and class while neither causing humans to be overshadowed by demihumans nor making demihumans much worse at higher levels.
• TL;DR is I ditch the demihuman level caps, preserve the class limitations (e.g. no Dwarf magic-users), and allow humans to take +1 to any ability score at the cost of -1 to a random ability score (no one need pick a demihuman ancestry purely for the stat bonus). 
• Humans are also slightly better at raising their ability scores with level (another major change, but one that has worked really well so far at the table especially given that my injury rules can cause ability scores to be damaged).
• Weapon tweaks: I filled out some "missing" items in the B/X weapon list (two-handed mace, small axe, etc.), and made some very very small mechanical tweaks to give axes and blunt weapons a little bit of love while still preserving swords as the "primary" weapon.
• Favorite is probably "imploding" dice for axes. When you roll a 1 on the damage die for an axe, reroll the die and add 1 to the result (stacks). This has the same average value as an "exploding" die that rerolls and adds on max value, which is to say slightly less than a +1 bonus... but avoids the wildly high potential results of the exploding die. Axes feel a lot more fun, even if swords still do more damage on average.
• Thieves (and their skills): As alluded to above, I've remade the thief. I've gotten great feedback on this from the one player who's played a thief in my campaign since I introduced it. 
• My thief has the same element of player skill progression choice present in popular revamps like LotFP's specialist, but instead of simplifying everything to d6 rolls I keep the d100s (I see their fiddliness as a thematically appropriate feature, not a bug) and add a few additional abilities on top that are picked from a "menu" as the thief levels up. 
• The goal is to make each individual thief a fairly customized character, though I've got on my to-do list a few "example progression" tables for players who don't want to deal with that element of choice.
• Narrative (simultaneous) initiative: This is my attempt to do the impossible - preserve the simultaneous feel of the AD&D initiative system while avoiding all the intense player-facing complexity.  
• I used the B/X combat sequence religiously for a while, but eventually my list of exceptions and rulings (especially regarding held actions and the like) got long enough that I decided I just needed to make my own system.
• TL;DR is everyone declares everything up front (as in AD&D), and combat is then resolved in 3 phases corresponding to whether characters' actions are happening before, during, or after their movement. The phases are largely just GM-facing, the players don't really have to mess with it.
• The initiative roll (still side-based d6 initiative) just breaks ties within a given phase, but if an orc is closing to attack an archer with a readied bow from 40 ft away, the archer can still get a shot off before the orc closes even if she loses initiative (as in Moldvay's example of combat where he breaks his own combat sequence, B28)

Additionally, I've made some significant QoL improvements - the whole document is much better organized (and now includes a ToC). Most grouped sets of rules now fit on a single page or a single two-page spread. It's not quite OSE "control panel layout" levels of nice, but I'm pretty proud of it.

Are there any of the 4 highlights above you'd most like to see a longer explanatory post on? Perhaps something different from the house rules doc? Let me know in the comments below.

In defense of the classic D&D saving throws

In a recent reddit thread from a self-described "trolly" poster asking for people to sell them on trying old-school D&D in addition to the more "rules-light" OSR games they've recently been enjoying, I offered to explain what I saw as the design principles behind the old-school saving throws*. As I started fleshing out my thoughts, I realized they would end up far too long for a reddit comment - and figured I might as well drop 'em here!

Fair warning, I'm probably not going to be saying a whole lot that's actually new in this post; most of my explanations are going to be familiar to anyone who has read a lot of blogs or other material focused on old-school D&D. There is nothing new under the sun, etc. (read Jon Peterson's The Elusive Shift if you want to see just how true this is in the RPG space). That said, I do hope some of what comes out of me putting these concepts in my own words ends up being helpful to you the reader (whether you be /u/vmoth or someone else who stumbled across this).

The question at hand: what are the design principles behind the old-school saving throws? I'm going to take a descriptive and/or revisionist approach to answering this question, rather than a historical approach. AKA I am not going to attempt to explain what Gygax, Arneson, et al were thinking when they wrote D&D. Rather, I'm going to look at the saving throw mechanic as it exists in old-school D&D and explain what I think the old-school idiosyncrasies actually add to the experience, as well as why I (as an amateur game designer - for all GMs are) choose to keep them in my game.

Throat-clearing and introduction behind us, let's dive in.

What are the classic D&D saving throws? 

Quick recap for anyone who's not familiar: a saving throw is a game mechanic whereby a character about to suffer some horrible fate has a chance to avoid said fate by rolling a die (usually a d20) and attempting to hit a specific target number. Oftentimes this target number is also itself referred to as a saving throw (or just a "save").

That's the basic idea behind saving throws. Old-school D&D saving throws then have a few defining characteristics that distinguish them from the saving throw mechanic as it appears in newer versions of D&D and in many newer OSR games and retroclones. My answer to our question of "what are the design principles behind the old-school saving throws?" then lies in a closer examination of these distinctive features that set the old-school saving throws apart from their successors.

In roughly descending order of how controversial these are to a "modern" RPG sensibility, the features that make old-school saves unique are that they:

1. Reference specific dangers
2. Are not tied to ability scores
3. Use static targets 
4. Vary between the classes

Each of these characteristics is, to a greater or lesser degree, often maligned by folks like /u/vmoth as "clunky" or outmoded in favor of the (assumed better) newer/modern/simpler way of doing saving throws. I disagree. I think the old-school saves are great! And while I'm not knocking other systems, I'd like to offer an explanation as to how each of these old-school D&D-specific saving throw characteristics acts to reinforce theme and to balance the game - and why removing any of them in an attempt to "streamline" the mechanics sacrifices something distinctive about the original game. 

My defense of the old-school saves doesn't mean I think they should never be tweaked, of course - but I do maintain that it's generally helpful to understand the reasoning behind a rule before dismissing it out of hand (see: my first two blog posts). 

Characteristic #1: old-school saves reference specific dangers

Perhaps the least liked aspect of the old-school D&D saving throw mechanic is that each of the saving throws is named after a specific danger characters can expect to encounter in their adventures. With some minor variations between editions, the old-school saving throws generally are broken out into the broad categories of Poison/Death, Wands, Paralysis/Petrification, Dragon Breath, and Spells.

A new player will first encounter these saving throw categories while creating their initial character. Think for a moment about the psychological effect of this. Somewhere between rolling up ability scores and choosing a character name, a new player is going to find out how likely their erstwhile hero or heroine is to survive encounters with 5 specific dangers, writing down those target numbers on their character sheet right alongside starting equipment and hit points. This is a fantastic way to set the scene for the type of game you're playing. Before even setting foot in a dungeon, we've established that old-school D&D takes place in a world in which one wrong turn might lead you to be dodging fiery dragon breath, avoiding dastardly rays from magic wands, or trying to survive the venomous fangs of a giant spider (crab spiders being a particular "favorite" of my group). 

"Crab Spider Attack" by Jacob Fleming (courtesy Gelatinous Cubism Press)

This scene-setting aspect of the old-school saves can also come in handy when running games not set in the proverbial "fantasy dungeon" setting. If I tell you to create a character for a one-shot and you're writing down targets for saving throws against Toxic Waste, Lasers, Panic, Grenades, and Gamma Rays, you already have a pretty good idea of what kind of world this is just from the dangers you have to save against.

One thing I'll note - just because the saving throws reference specific dangers does not mean those are the only dangers the saves can handle. One erroneous charge often leveled at old-school saves is that they are inflexible due to their specificity. Not so! There is ample precedent for using the classic saving throws for dangers not specifically falling into their nominal categories - including in the text of the Moldvay Basic D&D set itself, which references a falling ceiling block trap that requires a save vs petrify to avoid (B52). This seems very odd at first glance; dodging a falling ceiling block is not the same thing as a medusa's petrifying gaze. There is a logic to this, though...

The save vs petrify/paralysis, far from being only used for resisting petrification and paralysis, is generally used for any effect which requires a character to move quickly to avoid danger or which might restrict a character's free movement. This is not limited to Moldvay; AD&D 2e provides another example of this more liberal application of the petrify/paralysis saving throw by using it for resisting disarm attempts.

These (admittedly mostly unwritten/implied) rules for applying old-school saves to "off-label" uses exist for the other saving throw categories as well. If you wanted to rename the old-school save categories in a less evocative (but perhaps more descriptive) way that incorporates these implied uses a bit more explicitly, you might rewrite them as saves vs Instant Death/Poison/Generic Danger, Aimed Devices, Inhibition of Bodily Autonomy, Area of Effect, and Spells/Generic Magic. 

Rather than elaborate further here, I'll direct the interested reader to the best reference I'm aware of for this: LLBlumire's Which Saving Throw Should I Use?. I cannot recommend that post enough to anyone interested in learning more about how to apply the old-school saves. It's concise, too (unlike me)!

Characteristic #2: old-school saves are not tied to ability scores

The second idiosyncratic characteristic of old-school saves when compared to saving throw mechanics in similar and/or successor games is that they aren't primarily tied to a character's ability scores**. For players coming from newer editions of D&D (or rules-light OSR games like Into the Odd where saving against ability scores is one of the core mechanics), this seems quite odd. Why wouldn't you just use the modern convention of tying the saving throws directly to ability scores? Or perhaps the slightly older practice of splitting the saves into three general categories (e.g. Fortitude, Reflex, and Will) that are then each influenced by specific ability scores? Aren't both of those cleaner and more elegant than the clunky old-school saves that are disassociated from ability scores for no good reason?

Well, no. There are actually a few really good reasons to divorce saving throws from ability scores: namely, limiting the importance of ability scores and allowing flexibility for the in-fiction explanations of successful saving throws.

First, limiting ability score importance. Old-school games often feature character generation methods that generate ability scores with a significant element of randomness. There are many advantages to this approach (faster character creation, more varied characters, challenge of making the most of non-ideal characters, increased rarity of "optimized" characters making them more special, verisimilitude, etc.), but it also comes with downsides - namely, that some characters will have higher ability scores than others, which is unfair.

The degree to which this unfairness will be tolerated by players depends mainly on how invested they are expected to get in their characters (often correlated to campaign length) and on how important the ability scores are to the game mechanics. In a one-shot or very short campaign, players are a lot less concerned about having to play a character who's objectively worse at everything than the other characters... but if you're talking about a 20+ session campaign, people will start to get annoyed. Limiting the use of ability scores to providing a specific enumerated set of bonuses, but not having them define absolutely everything about a character's capabilities, is one of the core reasons why old-school D&D can get away with using highly random ability score generation methods.

This is also why 5e (a game where the core mechanic used for literally everything is the ability check) has point-buy or standard array as the default methods for generating ability scores, and it's one reason why some people describe Into the Odd (a game where ability scores are highly random but also have a huge amount of influence on almost every roll the players make) as great for one-shots or short campaigns, but not well-suited for long campaigns. But I digress...

Second, flexibility for in-fiction description. The other reason not to base saving throws on ability scores is that tying them to ability scores causes the saves to specify, in-fiction, how the character is avoiding the danger in question. Reflex saves are for dodging out of the way of things or diving for cover. Constitution saves are for "toughing it out". There's nothing inherently wrong with this of course - but consider the alternative. When a character passes a save vs poison, all I know is that the poison did not kill them. This could be because of his natural dwarven resistance to poison - it could be because the cleric's deity protected her - or it could be because the thief was just quick enough to suck the poison out of the wound before it entered the bloodstream. 

There's a significant amount of GM freedom that comes with this more "hands-off" approach to saving throws. For example, it is possible to have a villain wielding a spell that in-fiction always kills its target on a successful spell cast, but still allow the PCs to go up against a foe wielding such magic without it being a guaranteed instant-kill by allowing a saving throw (perhaps at a penalty). Any avoidance of the spell by PCs can be described as truly superhuman/heroic exploits or dazzling amounts of luck, without enforcing that the spell is resisted with a Will save and thus anyone who is strong-willed enough can just survive.

Characteristic #3: old-school saves use static targets

The next characteristic of old-school saves I'll discuss is that they use (nominally) static target numbers, rather than variable targets based on (e.g.) spellcaster level***, which is to say, a character's chance to save vs any particular danger does not change with the severity of said danger. This isn't quite as controversial, I don't think, so I won't spend as much time here. 

The main advantage of this approach is simplicity - fixed save targets are easier and quicker to use at the table than variable targets. You don't have to factor in a bunch of info as the GM when a character makes a saving throw - just decide which save to apply and go for it. There's no need to stat out every enemy spellcaster to determine their save DC. It's one less thing for players to deal with when rolling them. One could certainly protest that this it would be more realistic for various dangers to have variable ease in evading them - and this isn't wrong... but when adding any bit of additional complexity to any system, it's always worth asking if the benefit is worth the cost. 

Characteristic #4: old-school saves vary between the classes

Lastly - while the old-school saving throw targets are usually static with respect to the specific danger faced, they do vary between the classes. The main advantage of this approach is that it reinforces one of the central pillars of D&D, which is class-based play. In addition to varying abilities, hit points, and equipment training, different classes are just better at avoiding certain kinds of dangers. In a system that relies on differentiation between classes for a good deal of the implicit worldbuilding and archetype reinforcement, having one more knob to turn to add class differentiation is helpful. 

While this does add complexity, it's a front-loaded complexity. You write your saving throw targets down when you create a character or level up - they aren't going to change in the middle of an adventure, so it won't slow you down at the table.

Wrapping up..

That's probably the longest reply to a reddit comment I've ever written. Thanks, /u/vmoth, for the inspiration for my first blog post in a long while! I hope this was helpful.

I'll leave you all with this: I'm not knocking the saving throw systems in 5e, or WWN, or Into the Odd, or Swords and Wizardry, or any other RPG that does things differently than old-school D&D. All I'm saying is that the old-school saving throws should be viewed not as a primitive version of a mechanic that later evolved into a more fully realized, more streamlined descendant... but as a game mechanic designed with specific features to achieve specific goals.

May your saves vs death always succeed.

Midjourney AI's interpretation of "old-school D&D saving throw". I find this image oddly evocative, baffling though it is.

Further reading

I refrained from looking up similar blog posts while writing this, in an attempt to avoid any inadvertent rote repetition. All the same, here's some proof that there is nothing new under the sun:

• https://magickuser.wordpress.com/2019/08/01/old-school-saving-throws-are-rad/
• http://dungeonofsigns.blogspot.com/2014/09/why-i-use-tthe-classic-saving-throw.html
• http://grognardia.blogspot.com/2020/12/saving-throws.html

*The astute reader will notice I also promised /u/vmoth I'd explain the design principles behind THAC0, thief skills, and x-in-6 mechanics... we'll see.

**Yes, Wisdom does grant a bonus to saves vs magic in old-school D&D, but it isn't the primary source of saving throw advancement and that's basically all Wisdom does for most characters so I'm inclined to still say the saves are not primarily tied to ability scores. It's the exception that proves the rule, if you will.

***There are some exceptions to this, of course - especially surrounding poison (which sometimes varies based on monster strength) and spells (which often apply a save penalty when AoE spells are used on single targets). It's worth asking if the old-school saving throws might actually be better off just committing to fully static targets, as Chris McDowall advises here.

Save or Die! - a single-roll "death and dismemberment" system for old-school D&D

If there's one thing about old-school D&D people loooove to hack and houserule, it's the Thief.

...

But if there's two things about old-school D&D people loooove to hack and houserule, it's the Thief... and death/injury rules.

By default in most versions of old-school D&D (including B/X), a character is dead at 0 HP. That's it. They're done. Generally speaking, this works just fine at the table - but GMs generally being the rules-tinkering folks we are, many of us like to tweak this mechanic for a variety of reasons. Some find death at 0 HP a bit too punishing for the games they want to run, and introduce things like negative HP, death saves (in the 5e sense), that sort of thing. Many find it boring and/or overly simplistic, desiring the possibility of permanent character-altering injuries as a mechanical possibility for reasons of novelty or verisimilitude.

I've always had a soft spot for so-called "death and dismemberment" house rules, and I think the incredibly evocative picture below perfectly illustrates why. The party is beaten down, clearly barely escaped, and in 2 out of 3 cases has been permanently scarred... but in the end, they were victorious - and it shows! Together they overcame the (clearly significant) dangers in front of them and accomplished their goal. There's something about this picture that speaks precisely to the kind of feeling I really want my players to have after a really tough adventure.

"A successful adventure" by Jason Rainville (courtesy LotFP) 

My first ever foray into hacking my own RPG mechanics was building a comprehensive injury system for my Lost Mines of Phandelver (5e) campaign - the first RPG campaign I ever ran. To a large extent that's how I discovered the OSR... while I was searching for and reading up on houserules for permanent injuries, I found that most of the blogs I was reading were written by people playing older versions of D&D in a style I quickly came to admire. Taking inspiration from across the internet, I eventually wrote my own death and injury ruleset for 5e and implemented it in my campaign. My first ever PC death occurred under these rules, in which my wife's dwarf paladin was brought to the brink of death by a particularly grievous blow from an evil wizard's fireball.... but survived just long enough to cleave him in twain with her battleaxe before expiring. She still talks about that session..

In any case, if it's not apparent by now, I'm a big fan of injury rules for RPGs. I still think my 5e rules hold up really well, and I'd use 'em in a heartbeat... in a 5e campaign. Not so for a B/X campaign though - they're way too complicated for that. Still, I want the possibility of serious injury to exist as a mechanical middle ground between "perfectly fine" and "dead" - so I developed the system I call simply Save or Die!

Save or Die!

There's no denying that there are a lot of house-ruled death/injury rulesets out there for old-school D&D (and similar games). Rather than recapitulate the full list, I'll just link Lloyd Neill's "Death and Dismemberment" blog, which started out precisely as a series of deep-dives into the world of death/injury rules for RPGs, and includes a plethora of links to many of the most prominent ones. When it comes to death and injury rules, I certainly didn't come up with the concept and admit it is extremely well-trod ground.

As far as I know though, my particular take on these sort of rules is unique (at least I haven't seen it before - if someone's done it first though let me know!). Save or Die! combines the straightforward "make a save vs death" often favored by people looking for a simple way to inject some uncertainty (and a little extra PC durability) into the dying process with the "roll on a table of permanent injuries" favored by many, while avoiding some of the pitfalls of each - the fact that a high level Dwarf can save vs death on a 2 and thus becomes functionally immortal in the case of the the former, and the tendency to build overcomplicated multi-table roll token tracking minigames for the latter (man, if there's one place people just randomly decide they don't care about "rules light" any more it's death and injury rules).

My system is thus: when you reach 0 HP (or take damage while already at 0 HP), make a save vs death. If you fail, you die. If you succeed, you take the number you rolled on the d20 to pass the save and reference it to the permanent injury table below to find out what effect (usually a permanent injury) you suffered while avoiding death. And... that's it, basically. 

Save or Die! injury table

In my view, the major innovation here is linking the save vs death result directly to the injury table. Because lower level characters only succeed on saves vs death on certain (high) numbers, many of the results on the table are locked out for them. Thus your lvl 1 fighter isn't going to lose an arm first time down into the dungeon, he's just going to die or suffer some sort of minor-ish injury that reduces an ability score by a few points. I quite like this. Very few lvl 1 characters are important enough for their player to have any compunctions just dropping them if they take some significant injury, so in a system where that happens to a lvl 1 character, the character might as well have just died. However, placing the less severe injuries up at the top of the table and the more severe injuries (or weirder results) further down ensures that a character who loses an eye or an arm is going to by virtue of their higher level already be interesting enough for that to be a memorable story, and potentially a tough decision re: whether to retire or soldier on. This system also mitigates the "high level Dwarf never dies" issue because while a high level Dwarf may almost always make his death save, he's going to be taking attribute damage, losing limbs, etc every single time he does so. There's a significant enough cost to dropping to 0 HP that only an extreme risk-taker would willingly risk it.

A few extra rules

The above single-paragraph rule works just fine on its own, but for those who are a little more crunch-tolerant, here are a few extra wrinkles I add to the mechanic at my own table:

• Recovering attribute loss: a character who loses 1d8 points in an attribute from one of the results at the top of the table can spend 2 weeks recuperating to regain 1d4 points in the damaged attribute (yes, potentially making it higher than it originally was). 
• This changes the spread of attribute loss on injury to 0-7 (with a small chance of gaining 1-3 points; overall average is a loss of 2 points). I do this simply because I like the idea of characters' attributes changing somewhat over the course of their careers, both up and down. It also imposes a slight time tax for an injured character to fully recover (thus encouraging players to have multiple characters in the "stable").
• If I wasn't playing with this recovery rule, I'd probably reduce the attribute loss on those particular results from 1d8 to 1d4 points.
• Restoring loss of limb: loss of limb can be recovered with life-restoring magic such as Raise Dead, but doing so incurs a permanent loss of CON. I use the "OSE: Advanced Fantasy" chance of raising the dead table - roll on the table, lose a point of CON after each roll, continue rolling until a success is achieved. 
• I like this because it imposes a limit to powerful recovery magic. It stands to reason that in a world where people can be magically brought back to life, permanent injuries like missing limbs can also be magically healed - but I want permanent injury (and death) to still mean something. For that reason, the same loss of CON that applies to healing permanent injuries also applies to raising the dead at my table. At the same time, this isn't quite as harsh as (for example) the AD&D rules, where there's a chance for the resurrection to simply fail. With these rules it can't fail - it just always results in a loss of at least 1 point of CON.
• Massive damage: massive damage can still kill a character outright with no chance for a save. If the excess damage after reducing a character to 0 HP exceeds the character's max HP, the character dies instantly with no save vs death allowed.
• I cribbed this directly from 5e. It's a good rule.

Aaand... that's it! This is my personal contribution to the rich world of death/injury AKA "death and dismemberment" house rules for old-school D&D. Thanks for reading!

Variations on the Usage Die

One of the mechanical darlings of the OSR is the usage die, invented by David Black for his rules-light take on fantasy roleplaying The Black Hack. It's a simple and elegant mechanic - rather than tracking the exact number of rations, arrows, or any other other vaguely consumable resource remaining, these resources are assigned a "usage die" which is then rolled whenever the resource is used (aka when resting for rations, or after combat for arrows). On a roll of 1-2, the usage die moves down one step (d20->d12->d10->d8->d6->d4). On any other roll, the usage die remains as-is. When the d4 rolls a 1-2, the usage die is consumed and the resource is depleted.

Opinions on the original Black Hack version of the mechanic vary - some people enjoy the simplicity and insert the usage die as-written into their games at every opportunity, while others find the randomization of tangible resources such as rations and arrows to be a bit overly abstract compared to just counting them. Regardless of their opinions about the specific Black Hack implementation though, most people I've seen agree that it's an elegant mechanic with some serious potential. Personally, I don't use it for rations and arrows, but I think it works very well for resources that may be inherently a bit fuzzy and hard to precisely define - such as magical power, sanity, or fame.

In this post, I'd like to dig into the usage die mechanic a bit, then present a few variants that change the "feel" of the mechanic a bit, allowing for some different use cases. I'll also compare the expected value (aka average number of uses) resulting from each option, as well as a brief overview of the method I used to calculate it (discrete Markov chain analysis)*.

These are dice

OG (Black Hack) usage die: down 1 step on 1-X 

The original implementation of the usage die (henceforth Ud for short) uses a die chain that moves in only one direction - down, with a 2-in-(die type) chance of moving down a step each time the usage die is rolled. This produces a nice spread of average total uses ranging from 2 (for d4) to 30 (for d20), allowing for the modeling of resources with a wide range of "charges," but not so wide as to make the Ud irrelevant at the table.

One of the simplest tweaks that can be made to the usage die is changing the target number that results in a step down. Dropping it to 1 rather than 1-2 doubles the expected number of uses to 4-60, while increasing it to 1-3 drops the expected number of uses to 1.3-20.

Expected uses for variations of the OG usage die

The OG usage die mechanic has a number of distinctive features that makes it particularly well suited for modeling gradual depletion of an adventuring resource:

• It moves in only one direction: the inexorable march down the chain means that even if you get a lucky streak resources will eventually run out, necessitating a return to safety for rest and resupply - this puts a built-in "clock" on any expedition, which is often preferable for a dungeon-crawling or "expedition" focused game.
• Total depletion is predictable: you will have some warning before you completely run out of a Ud resource, because it only moves down a single step at once - this helps to limits frustration by allowing the players to feel like they have a measure of control and that their decisions matter, despite the randomness inherent in the mechanic. 
• Depletion events are unpredictable: while a player can relatively safely count on being able to have some advance warning before completely running out of a Ud resource, any given roll is still an unknown - this creates some dramatic tension each time the die is rolled, which is generally pleasing to human brains (there's a reason gambling is so addictive to many people and why we RPG players love tossing our shiny math rocks).
• Accelerating depletion rate: as your resources deplete, the chance of moving down on the next roll increases - this helps to build tension and fosters somewhat of a push-your-luck feel, as the players start out feeling relatively well-supplied but will start feeling more and more at risk as they continue to adventure.

Of the above features of the OG usage die, the unpredictability of depletion events and acceleration of the depletion rate are fairly baked-in - the whole beauty of using the mechanic is that it injects drama/tension to the depletion of resources while not requiring the players or GM to do any complicated math at the table or track anything other than the current die type. 

I'd argue any tweak that changes either the unpredictability of depletion events or the steadily accelerating depletion rate would fundamentally alter the mechanic such that it's not really a variation on the usage die any more, but something else entirely. That's not necessarily a bad thing, but it does provide a convenient dividing line for the purposes of this post. For now, I'll be sticking to the basic "die chain w/ consistent target number ranges" structure for the mechanic.

Unidirectionality and predictable depletion, however... those are relatively easy to change while preserving the basic structure of the mechanic - and changing either (or both) of them can greatly alter how the mechanic feels at the table. Let's dive in.

Bidirectional usage die: down one step on 1-X, up one step on highest value(s)  

The first variation I'll explore is the bidirectional usage die - that is, a Ud that steps down on low values, but steps up on high values. This version of the Ud models resources that usually tend towards depletion, but occasionally go the other direction.

We need to be somewhat careful here. Making the chance of a step down equal to the chance of a step up fairly quickly results in a situation where, pending a series of particularly unlucky rolls, the number of expected uses climbs very high, very fast. This is undesirable for a few reasons - not only is it extremely inconsistent (and thus difficult to use to create any sort of predictable gameplay experience at the table), but the high average number of uses means that unless the Ud is being rolled almost constantly, it will almost never be depleted in a typical adventure (and thus would be somewhat pointless as a resource tracking mechanic).

All the same, the idea of a usage die that steps both up and down has promise, especially if the step up frequency is limited. Infrequent but very good events feel really compelling at the table from a psychological perspective - there's a reason critical hit mechanics are so often hacked into old school D&D despite being (mostly) absent from the original rulesets. People also tend to disproportionately remember these unlikely good events; a gaming group will often talk for years about the time their character dealt 50 damage to one-shot the boss due to exploding damage dice in Savage Worlds, or saved vs the necromancer's death ray 3 rounds in a row before putting him down.

My preferred tuning of this variant is probably "3 down, 1 up" - that is, on a 1-3 the Ud steps down and on its highest value the Ud steps up. This results in a spread of average total uses of 2.5 (for d4) to 28.8 (for d20), which is surprisingly close to the 2-30 spread of the OG usage die. Note that despite the averages being similar this is still quite swingier than the OG usage die - particularly if you're starting at a d4, where you'll either deplete entirely or vault up to a considerably higher number of average uses on the first roll. I probably wouldn't use this variant of the mechanic for a resource that could start at d4 - it works better starting around d6 or d8. The average number of uses for a few versions of the bidirectional Ud are presented below.

Expected uses for various bidirectional usage die variations
*(3 down 2 up is 2 down 1 up on the d4)

In my opinion the bidirectional Ud works really well for modeling things like reserves of magical power (as a replacement for spell slots or mana) - particularly for something like a wild mage. It could also work well with a sanity mechanic, or (in a reversal of the resource depletion paradigm) for the severity of a wound or disease that gradually heals over time (but with the chance of suddenly worsening).

Jumpy usage die: down multiple steps on 1, down one step on 2-X

The other major feature of the usage die we can mess with is its (relative) predictability. By default, you're not in danger of fully depleting the Ud until it has been reduced to a d4. This is easy enough to change; simply change it such that rolling the lowest value results in moving down multiple steps - either 2 steps (for a little bit more unpredictability) or full depletion (for a lot more unpredictability). 

This change has a few effects. The most obvious effect is that the number of expected "charges" is  significantly reduced. This can be helpful if you're trying to model something with few charges, but still want to make use of a wide range of the dice chain. The other effect is that from a psychological perspective, the Ud is less "safe" - it is more prone to run out unexpectedly. This heightens the feeling of tension (or for a more high stakes resource, dread) promoted by the usage die. Obviously, this will be more appropriate for some applications than others - but it's a nifty tool to have in the toolbox.  The expected number of uses for both of the options mentioned above are shown below.

Jumpy usage die expected number of uses

This variant of the Ud is especially helpful for modeling situations where there's a steady decay, but always with a chance of everything immediately going off the rails. I'd use it sparingly, but it serves well in cases where you don't want the players to feel completely secure at any point. Example applications include magic spells that are unraveling in an unpredictably chaotic manner, or perhaps the attitude of a king whose appetite for extended conversation with the party is rapidly running out. 

Wrapping up

These variations can be combined, of course - one can imagine (for example) a usage die that depletes 2 steps on a 1, 1 step on a 2, and increases 1 step on the highest value. Below is a summary table of the various options discussed in this post, a few new combos, and (bonus) 2 versions of a reverse Ud  - aka a usage die that steps up instead of down, and "finishes" after d20, creating a decelerating (rather than accelerating) depletion rate.

Summary of all discussed usage die variations + a few
*(3 down 2 up is 2 down 1 up on the d4)

I said at the start of the post that I'd present a brief overview of the analysis method I used to derive the expected number of uses for each of these. This post has already run fairly long, so I'll keep it brief. Each of the usage die rulesets I examine in this post can be represented mathematically as discrete Markov chains with one absorbing state. That is to say - they are state machines in which the probability of the next state depends only on the current state. As it turns out, with a little matrix math (using your preferred programming language - mine is Excel :P), it's really easy to calculate all sorts of information about these state machines - including the expected number of cycles before "absorption" (aka depletion). 

For a more in-depth explanation of this analysis method, see my past post walking step-by-step through a Markov chain analysis of the "clock puzzle" from Xanadu. If anyone really wants a walkthrough of the method as applied to a usage die, though, feel free to leave a comment. It's hard to overstate how useful Markov chains are for analyzing of RPG mechanics - I expect to be returning to them not infrequently. 

Well - that's it! I hope this sparks some ideas regarding new ways to implement the usage die in your games! David Black did the OSR a major favor in popularizing the mechanic, and I think with some tweaking it becomes an extremely versatile mechanic appropriate for all kinds of applications. Please comment if you've got other ideas for innovative modifications to the Ud mechanic! 

*You don't really need Markov chain analysis to calculate expected uses w/ the "one-way" versions of the usage die, but it becomes much more difficult to do so ad-hoc as the mechanics get more complicated - the Markov chain analysis on the other hand makes this very, very easy with any arbitrary set of usage die rules as long as they actually do form a Markov chain. 

My house rules for B/X D&D (v1.6)

Howdy all!

I was planning to start a series on my emerging setting for my Old-School Essentials open table campaign, talking about 1) the process of creating a semi-sensible "kitchen sink" setting that allows me to toss in whatever dungeons I like from around the OSR, and 2) the interesting challenge I've set myself of incorporating certain B/X-specific mechanics directly into the worldbuilding (aka asking the question "OK, so a magic-user can only write down a set number of spells into their spell book... what does that mean for how magic works in this universe?) rather than building the world just out of whole cloth and retrofitting the mechanics to it.

Unfortunately, every time I started jotting down some coherent ideas, I found some great concept on Blood of Prokopius or Roles, Rules, and Rolls or some other blog and found myself rethinking things. Then I started Sanderson's Stormlight Archive. Then while waiting for book 4 of the former to come off of hold at the library I started The Silmarillion. And, well... my world's not done cooking yet - plus I'm still reading both of the above with much of the time I would otherwise be writing blog stuff.

The series mentioned above will come. Eventually. But for now, I'd like to share something just as good (or quite possibly better?) - my complete house rules for B/X D&D, as currently used in my open table Old-School Essentials Stonehell-meets-Dolmenwood-meets-anything-else-I-want-to-throw-in-there. They're linked below, and also on the sidebar.

(PDF link) Matt's B/X House Rules, v1.6

As the title implies, they're currently on their 6th iteration. Many of these could, and probably will, fuel entire blog posts on their own - but there's no use keeping them back and kicking them out piecemeal. If there's any you'd be interested in seeing some discussion of, feel free to comment below!

Simplifying Xanadu's clock "puzzle" using discrete Markov chain analysis

I recently picked up the Old-School Essentials adventure Xanadu by Vasili Kaliman, which garnered the coveted rating of "The Best" from Bryce at tenfootpole, as well as a favorable review from Ben over at Questing Beast. I haven't read it 100% through, but having skimmed it I tend to agree with them that it's a pretty great addition to the stable of R-rated "weird fantasy" adventures for Old School D&D. It features some freaky body horror stuff, a fun nightmarish take on the Tooth Fairy, and tons of treasure for intrepid adventurers to recover (if they survive). I probably would be cautious about throwing it into a long-term OSE campaign due to its lethality and a few "gotcha" moments, but it's a slam dunk for a one-shot with a group that will enjoy that sort of thing. Very fun pixel art-styled interior art, too.

Enough of that, though. This post isn't a review; the two reviewers I linked above are some of the best in the business, so go ahead and check their reviews out if you want to read more about the adventure overall. Nope, this post is... a math problem. Because I'm a mad lad who's been away from work for too long and needs to solve some equations to truly feel alive.

The puzzle that wasn't

Near the end of his review, Ben mentions one of his minor gripes with the adventure is that one of the marquee puzzles of the dungeon (required in order to escape the dungeon, so all groups will have to interact with it at some point) isn't so much a puzzle as a "randomized flowchart" where the players have essentially zero control over whether or not they succeed in solving the puzzle. 

This puzzle consists of the aforementioned flowchart (pictured below), along with instructions that when a player character attempts to solve the puzzle, they should repeatedly roll a d10, moving from node to node until they reach the "Start", "Uh Oh!", or "Solved" nodes. There are some additional caveats - each full attempt risks wandering monsters, bad things will happen if you hit "Uh Oh!", etc. - but that's the long and short of it. Ben concludes his critique by pointing out that there "really is just a statistical chance that you will end up here or here... so why not just... make them roll a die to see if they end up here or here?"

Xanadu's clock puzzle

Ben is, of course, completely correct here. The clock puzzle isn't really a puzzle, and the flowchart is functionally completely unnecessary - it's just a bunch of repeated die rolls to eventually land on "good thing", "bad thing", or "try again". With any given attempt, there really is just a statistical chance that you will end up at any given end state of the flowchart. The whole thing could be replaced by a table with 3 entries and a probability for each of the 3 possible results. Well... why not?

Today I'd like to answer the question Ben didn't ask: what actually is the statistical chance that on any given try, you will end up at any given end state of the Xanadu clock puzzle?

Quick note: the rest of the blog post is a bunch of math, albeit (hopefully) presented in a format most folks can more or less follow along with. It's worth noting though that the analytical method I present here isn't just useful for this Xanadu problem - it applies to most any "random flowchart" problem in any arena. That said, if you don't care about the math, scroll to the very bottom of the post for the TL;DR answer.

Markov-ifying Xanadu's clock puzzle

If you've dealt much with probability and/or random processes, you might have recognized (probably faster than I did) that the Xanadu clock puzzle is a textbook example of a discrete Markov chain. For anyone who's not familiar with the term, a discrete Markov chain is a mathematical model for describing a system that:

• Has a set number of possible states
• Transitions from the current state to the next state at regular intervals
• Only cares about what the current state is when deciding what the next state will be - the history is irrelevant, the only thing that matters is the current state

That's about it, for our purposes*. And indeed, our flowchart above is literally just a discrete Markov chain. There are a bunch of nodes, or states... each state (with the exception of the end states) transitions to another state with a set probability... and the state you go to next is entirely dependent on whatever state you're currently in. Let's make this a bit clearer - I'm going to rewrite the flowchart, but this time numbering the states and replacing the die ranges with probabilities (expressed as decimals rather than percentages).

Xanadu's clock puzzle, Markov-ified

Quick aside... before we go further, I'd like to answer a question I'm sure at least half of you are asking: "why bother with this? Even if you really want to know the answer you can just write a simulation to run 10,000 trials and figure it out." The answer is that math is cool and I think this is a lot more fun than brute-forcing it. As you'll see below, we can calculate an exact answer to the question posed. We don't need to run 10,000 simulations to be sure we have the right answer, we can just get the exact answer. How cool is that? This method is also much less time-consuming... at least if you're not also writing up a detailed explanation of how to do it.

Alright, back to the math. The observant reader will notice 3 major differences between the original flowchart and my Markov-ification of it above.

1. I split the "Start" node into two states. This is because when first starting the puzzle, you can transition from that "Start" node to states 2, 3, or 4 - but if you return to the "Start" node after that you don't just continue the flowchart, you have failed to solve the puzzle this attempt and the Referee gets to roll for wandering monsters before you can try again. Functionally, the "Start" node actually hides two different states - the actual start state and the "try again" end state.
2. I drew additional loopy arrows from each of the three end states (also known in the lingo as "absorbing" states) back to themselves, with probabilities of 1 (aka 100%). This is basically just a visual representation of the fact that they are terminal states that effectively end the chain. To be a valid Markov chain, every state has to have all the arrows leaving it add up to 1, so adding these loopy arrows satisfies that requirement.
3. The original flowchart has the "8" d10 result listed twice going out of state 6, once going up to state 3 and once going down to state 9 (aka "Uh Oh!"). I asked the author on DTRPG and he confirmed that this is a typo. I chose to resolve this typo in the "nicer" way, changing the die range for the transition from state 6 to state 9 from 8-0 to 9-0, aka a probability of 20% instead of 30% - and fortunately, that's what the author did as well, so I don't have to redo this whole post to match v3.1 of the adventure. Success.

The next step in Markov-ifying our state machine is to represent it in matrix form. Matrices are the building blocks of linear algebra, and they're amazing for solving a whole range of mathematical problems, especially those that involve multiplying specific sets of numbers in very specific ways. That's a woefully inadequate summary, but I'll leave the detailed further reading to anyone who's interested and for now will move on with the problem.

Turning this flowchart into a matrix is pretty easy. Each current state gets a row, each future state gets a column, making a square matrix. The value of any given element is the probability that the state in the given row will transition to the state of the given column. This is called the "transition matrix", and it is a complete mathematical representation of the Markov chain (aka it contains all the info contained in the flowchart).

Clock puzzle Markov transition matrix P

This probably just looks at first glance like a bunch of random numbers, so take a second to compare the matrix to the flowchart and see how we constructed it. Note that the (1,1) entry is 0, because state 1 cannot transition directly to state 1. The (1,2) entry is 0.3, because there is a 30% chance state 1 will transition to state 2. The (3,4) entry is 0.1, because there is a 10% change state 3 will transition to state 4... and so on.

OK. For those of you who have held on this long... here's the super cool part and the reason Markov chains are amazing. If we want to know the probability of being in any given state after N cycles (rolls), all we have to do is multiply the matrix by itself that many times (aka raise it to the Nth power). That's it. Then just look at whatever row corresponds to your starting position (in our case, the 1st row since we always start in state 1) and the column entries give you the probabilities that given that starting position, and after N cycles, you are now in the state corresponding to that column.

Here's an example. Say we want to know where we're likely to be after rolling the d10 5 times. All we have to do is first raise the matrix to the 5th power... (many programming languages and graphing calculators will do matrix math, you can also use one of the myriad of free calculators available online) 

EDIT: Microsoft Excel/Google Sheets will also do matrix multiplication and inversion, though you need to make a custom function for exponentiation.

Clock puzzle probabilities after 5 cycles

Now we look at the first row (since we started in state 1), and we see that after 5 die rolls we have a 46.9% probability of having looped back to the start (column 8), a 17.9% probability of having hit "Uh Oh!" (column 9), a 9.3% probability of having solved the puzzle (column 10), and that the rest of the remaining probability is spread out among the other nodes (aka we are somewhere in the blue nodes and are still rolling after making 5 d10 rolls).

Solving the problem (good enough)

Alright! We can now solve our initial problem, which was to answer the question "what is the probability that any given solution attempt will result in any of the three given end states?" Since we know that after enough cycles we must eventually end up in one of the three absorbing states (note that this isn't true for all Markov chains, but it is true for this particular Markov chain), we could just raise the matrix to some arbitrarily high power (aka until the probabilities of the non-absorbing states go to 0) and check the probability of each absorbing state. Aaaand.... yeah, that would work. It'd work just fine. Let's go ahead and do that.

Clock puzzle probabilities after 100 cycles

And there we have it. Looking at the 1st row of this matrix (because we always start in state 1), we see that on any given attempt there is a 60.8% probability of looping back to the start, a 25.8% probability of having to roll on the "Uh Oh!" table, and a 13.4% probability of solving the puzzle. In fact, if you are running this adventure and don't think your table would enjoy rolling a d10 over and over again until you spit out a random answer, you can replace the flowchart with a table containing the above probabilities (or an approximation using a d8, see the final section of the post) and get pretty much the exact same results with much less rolling.

Hold on though... I promised you an exact solution, with no need to do a large enough number of trials or whatnot. Haven't I just come up with a method that still requires some trial and error to see when you've gotten a "high enough" power? Well... yes. That's true. Funny story though... it turns out that for an absorbing Markov chain like this there is actually a way to go straight to the exact solution, no multiple tries or high power iteration needed. It's slightly more involved, but still pretty easy. Let's dive in.

Solving the problem (exact solution) 

In the interest of brevity (ha), in this section I'm going to more or less go straight through the solution steps without much explanation. For those interested in the details, the wikipedia article on absorbing Markov chains is a pretty decent high-level overview that basically just has the formulas, and this probability book chapter from Dartmouth gives a awesome undergrad-level detailed treatment of the entire subject of Markov chains (absorbing chain stuff starts on page 12 of the PDF).

Alright. Here we go... the first step in finding the exact solution is to make sure the Markov chain is constructed such that all of the absorbing states have the highest numbers, thus arranging our transition matrix so there are 0's in the bottom left quadrant, diagonal 1's in the bottom right quadrant, and some other stuff in the top two quadrants. Note that the quadrants aren't necessarily of equal size, just depends how many absorbing states there are. Fortunately, I knew this was coming so I numbered the states that way from the start, no re-arranging needed. Success! I'll repeat the transition matrix below, this time drawing little dotted lines to show the quadrants and with an additional term showing the names of the quadrants.

Clock puzzle Markov transition matrix P with quadrants shown 

The next step is to calculate something the called "fundamental matrix" for this absorbing Markov chain. Take the top left quadrant, also known as Q, and subtract it from a diagonal 1 matrix of the same size (also called an identity matrix because anything you multiply by it ends up the same - like multiplying by 1).

Step 1 of calculating fundamental matrix N

Now we take the inverse of the matrix above. The inverse A^-1 of any given matrix A is the matrix that yields an identity matrix (diagonal 1's) when you multiply the two together. Actually finding this inverse by hand can be quite tricky, so back to the calculators and... bam. We now have the fundamental matrix, also known as N, for this Markov chain.

Fundamental matrix N for this Markov chain

For a host of interesting reasons that you can read about in the Dartmouth paper, we can do some incredibly cool stuff with this matrix. For starters... what does this matrix even represent on its own? Well, each row still represents the starting state, and as it turns out, any given column entry is the expected (average) number of times you will visit the state given by that column number before being absorbed. So entry (1,4) tells us that if you start in state 1 (aka the "Start" node), you will on average visit node 4 0.515 times (aka roughly once every other try). Looking at the top row as a whole, we can see that most of the states are visited roughly once every other try, but that the start node and node 3 (aka the one in the middle) are visited roughly once every try. That makes sense given that node 3 is smack dab in the middle and that, well, we always start on node 1.

That's sort of interesting, maybe... but it's not what we wanted. We wanted the exact solution for the probability of ending up in any given absorbing state, and the absorbing states aren't even in this matrix! Right you are. Let's get that answer right quick. Easy. All we have to do is multiply the fundamental matrix N by the top right quadrant of the original matrix, also known as R, which yields an absorption probability matrix B.

Absorption probability matrix B

Same as always, the row indicates the starting state, so we'll look at row 1 here. The columns are the absorbing states only, which are in the same order as before. Hmm, well whaddaya know? This confirms that indeed, any given attempt has a 60.8% probability of looping back to the start, a 25.8% probability of having to roll on the "Uh Oh!" table, and a 13.4% probability of solving the puzzle - a nice double check for our earlier "good enough" answer. Math is great, yeah?

Last thing before we go... how long, exactly, does it take to solve the clock puzzle? Obviously there will be a lot of variance, but can we get an idea of the average number of rolls? Of course we can. The expected (average) number of steps (die rolls) needed to reach an absorbing state, given a certain starting state, is given by the row of the vector t that results from multiplying the fundamental matrix N by a vertical column of 1's, as seen below. Note that multiplying by a vertical column of 1's is the same thing as just adding together all the entries of each row, which makes sense because each entry is the expected (average) number of times you'll visit any given state before being absorbed - so of course the average number of total steps would just be the sum of those individual visits.

Expected # of steps vector t

And there we have it. On average, any given attempt takes 4.51 die rolls to reach an end state (though there is definitely very high variance here - a successful escape will almost certainly take more rolls than the typical attempt which ends in a return to the start). Since the probability of solving the puzzle on any given try is 13.4%, that means our expected number of tries is 1/.134 = 7.46 and that any given group will roll their d10, on average, 7.46*4.51 = 33.6 times trying to escape this dungeon.

Markov chains, huh... what are they good for? 

Alrighty. So what was the point of all this, beyond figuring out how to simplify a somewhat lame "puzzle" that's a fairly small part of an otherwise pretty awesome adventure as a flimsy excuse to give a math lesson on an RPG blog? There are a few reasons why I think this was a worthwhile endeavor:

Markov chains are everywhere

Markov chains, if you know where to look, show up fairly often in RPG products. Off the top of my head there's hex flowers, the innovation track progressions from Magical Industrial Revolution, and of course any sort of "random flowchart" system for randomly navigating between points in a chaotic landscape such as in Silent Titans or Xanadu. If it involves randomly determined travel between a predetermined set of nodes or states, it's a Markov chain.

With that in mind, I think having a bit of knowledge about how Markov chains work and how to do some basic analysis of them can aid any RPG designer who's implementing such a structure in their product. Mathematical literacy is an important tool in the RPG designer's toolbox. Granted, Markov chain analysis isn't quite as important as knowing (for example) that 1d20 gives you a flat distribution and 3d6 gives you a bell curve... but it's in that same ballpark, in the sense that you absolutely can do good RPG design without knowing it, but knowing it will almost certainly make anything you design better.

I don't know if Vasili Kaliman is 100% aware of the overall probabilities his flowchart results in, or if he just tuned it more by trial and error. Either way, I'd like to equip any future flowchart-makers with the tools to quickly and easily tune these sorts of mechanics without needing to do a ton of trial and error that will almost certainly not give you a great sense of how the chain will actually play (due to the small sample size). Instead, just change a few entries in your P matrix, recalculate, and you have your new probabilities - you can spend your playtesting time on something more important instead. 

I hope I've shown, too, that despite not being a topic commonly taught (I'm an engineer and I didn't even see them til an elective course in grad school), Markov chains aren't actually that difficult to analyze. While there's a lot of matrices and numbers above, everything I did ultimately just boils down to making a flowchart, moving numbers from that flowchart into a matrix, and plugging that matrix into a calculator. I didn't do any arithmetic in the "background" of this post other than the (I - Q) bit (which was subtraction), everything else was just plug 'n play.

It's fun to solve problems

As previously mentioned, I find solving this sort of problem fun. When I saw Ben comment in his review that there should just be a single die roll to determine which end state they end up at, I not only agreed with him, but was fairly confident I remembered a way to rigorously determine the exact die roll that would be equivalent to the flowchart... so... I did. It's always good to stretch the brain now and again, refresh one's memory on techniques and concepts long forgotten. Even better if that knowledge can be shared and potentially used by other people! 

Extra credit

1. Try solving the Markov chain with a different resolution of the typo in node 6 - perhaps by removing the arrow back to node 3 entirely. How does this change the overall probabilities? Does it make the flowchart "meaner", and if so, by how much?
2. Try solving the Markov chain assuming that you don't exit the chain when returning to Start, but instead keep going until you hit Uh Oh! or Solved. Can you infer what the new absorption probabilities should be before doing any additional matrix math? How does this affect the expected number of tries? What about the expected number of die rolls? The answer may surprise you.

TL;DR / Summary

The probabilities

In summary... the Xanadu clock "puzzle" flowchart takes, on average, about 4.5 rolls to reach an end state, will require about 7.5 tries to solve, and is equivalent (plus or minus half a percentage point) to a single d100 roll with the results and ranges shown below. If you want to cut all of the "make multiple die rolls before something happens" out, axe the flowchart and use the single roll instead for each attempt. 

Equivalent and approximate probabilities for Xanadu clock puzzle

If/when I run this adventure, I'll probably use the d8 table instead, it's surprisingly close to the base probabilities and having a d100 table with the uneven breakpoints shown above slightly unsettles me.

Improving the Xanadu clock puzzle

Also, one final note - while I've been fairly critical of the Xanadu clock puzzle in this post, that's mainly because as-designed, it really does boil down to a random determination of end state with the intermediate states having zero effect on gameplay (other than taking up more table time with additional rolls). My complaint isn't that it's a Markov chain - rather, it's that it's a Markov chain that doesn't leverage any of the properties of being a Markov chain and that really should just be a random table. 

If, instead, each of the blue nodes had some sort of specific property or effect every time it was visited, the flowchart could be otherwise identical mechanically but add much more flavor. Every die roll would mean something, rather than the players making 5+ die rolls in a row waiting for something to happen. If/when I run this adventure, I might write up an entry for each of the 6 blue nodes - or maybe even 6 separate random tables, one for each node! Project for another day, perhaps.

Thanks for reading! Let me know what you think below. Also don't hesitate to point out if you think I've made an error - I manually entered all of those numbers into the matrices after doing the math, so I absolutely could've mis-entered something (and/or made a fundamental error in the analysis, fingers crossed that isn't the case). 

*For any math teachers/profs in the audience, I apologize for my fairly streamlined way of presenting all of this. I'm sure there's all sorts of caveats I'm leaving out and some ways in which my language is less rigorous than it could be. Feel free to clarify if I got something wrong. :P 

Chesterton's fence part 2: idiosyncratic gems in B/X D&D

The strangeness of B/X D&D

Yesterday I began a discussion of how G.K. Chesterton's precautionary principle (to paraphrase: "don't tear down a fence until you understand why it is there in the first place") can allow us to run better games and write better house rules while not missing what the systems we run have to offer in their rules-as-written form. Today I'll continue by talking about a few ways in which this applies specifically to old-school D&D.

The RPG I'm currently running, Old School Essentials, is a much better organized but otherwise identical clone of Moldvay and Cook's 1981 Basic/Expert (aka B/X) D&D. It's a great system - considered by many to be the most concise and playable incarnation of D&D ever written*. 

B/X is also extremely idiosyncratic by the standards of newer editions, containing many rules that seem like oddities to someone who has mainly played 5e. To name a few: "Elf" and "Dwarf" are character classes (character racial heritage and vocation/class are combined instead of being picked separately, also called race-as-class), characters earn XP mainly from recovering/stealing treasure rather than combat or completing story objectives, different classes have different XP requirements to level up, and character attributes are determined entirely randomly rather than being picked by the players via point-buy or slotting an array of rolled numbers into the desired stats. 

Those familiar with newer editions of D&D will recognize that precisely none of the rules I name above have survived to 5e (in fact, none of them made it past 3e). Why is that? Were the original designers of Basic D&D just not quite sure what they were doing? Are the newer editions more perfectly evolved games and the older editions relics we can simply discard? Well, no. They're different games. In fairly stark contrast to some systems whose edition changes are more or less "upgrades" (see: Savage Worlds), each edition of D&D is very much its own thing, chasing a very specific sort of play experience. Different groups will prefer different editions, and each version of the rules tends to be good at running different types of campaigns.

In my (anecdotal) experience, few people who play B/X (I here include those who play the myriad of retroclones that are basically B/X with some house rules) play it entirely rules-as-written. Indeed, hacking the game is a favorite practice of the group of people (collectively known as the OSR, for Old-School Revival/Renaissance) who play these games, other "old-school" versions of D&D, and games inspired by them today. There are about as many versions of old-school D&D as there are GMs who run it, and it tends to lend itself very well to changing and hacking and experimentation. None of the rules I mention at the start of this section are sacred cows in the OSR (though XP for treasure comes close), and they are often bent, discarded, or molded to suit the user's taste. 

As someone who moved from 5e to B/X and has come to look at many of the latter's idiosyncrasies with fondness, I'd like to briefly discuss two of these odd rules, and why after understanding what they add to the gameplay experience, I've ultimately decided they're not only worth keeping, but a vital part of what makes the game special.

Race-as-class

As someone whose favorite D&D character has long been the doughty Dwarven Cleric, wielding mace and shield and holy magic, my first reaction to the idea of folding race and class into a single choice was to look at it as a simplifying design choice that may make things easier for new players, but doesn't really make for a better game. And indeed, both the original (pre-Basic) D&D and all editions of Advanced D&D allow players to choose race and class separately (albeit often with more restrictions than the current edition). 

However, on closer examination this mechanic offers more than mere simplicity in character generation. An underappreciated asset of the race-as-class approach is in the way it absolutely weaves archetype and worldbuilding into the core mechanics of the game. The reason you can't be a Dwarven Cleric in B/X rules-as-written is that Dwarfs simply aren't participants in the same organized vaguely-Catholic-with-the-serial-numbers-filed-off religion implied by the Cleric class in D&D. Dwarfs aren't just short bearded Scottish people, they're different, maybe even alien. In the world implied by B/X D&D, it's enough to just say an adventurer is a "Dwarf" or an "Elf". The melding of race and class has significant worldbuilding implications. 

Modern D&D settings almost always imply a cosmopolitan mishmash of a world where everyone is more or less fundamentally human, they just might be humans with pointy ears and a +2 to INT, or short bearded humans with a +2 to CON. Part of this is a chicken-and-the-egg change in the types of fantasy worlds we associate with D&D-type games, but part is certainly mechanically driven. There are no racial class restrictions or level caps in 5e, because as far as the mechanics are concerned, everyone is basically the same aside from bonuses to a few attribute scores.

None of this is to say that if you're running B/X you can't have a cosmopolitan setting. It's quite easy to separate race and class to get that "unrestricted" feel (Basic Fantasy RPG and Old School Essentials:  Advanced Fantasy both do this quite well), and many GMs who run B/X or one of its clones do exactly that. But if you want a setting, perhaps, where maybe the only Assassins are Elves, or maybe Dwarfs are the only people with Clerical powers? It's every bit as easy to just create an "Elven Shadowblade" class or a "Dwarven Stonesinger" class to tack onto the default B/X offerings of (essentially) "Elven Spellblade" and "Dwarven Fighter". You could also take the route I currently take, which is to allow demihuman characters (what B/X calls non-humans) to "multiclass" into human character classes, keeping some of their unique benefits (better saving throws and keener ears, mostly) in exchange for getting a slightly slower start on leveling.

Race-as-class, despite the name, isn't really saying humans are the only fantasy race with any variety in adventuring professions (even though that's true of the setting implied by the core B/X rules). Rather, it's a different way of setting up character creation that is, yes, simpler for new players... but also does significant worldbuilding work for you if you're willing to leverage it. 

XP for treasure

For as long as D&D has existed, players have wanted to gain XP. Throughout the editions, it's always been the main metric judging how they "make progress" in the game, and is thus one of the main incentives the GM has for motivating player behavior. Fundamentally, when designing incentive structures you should incentivize the behaviors you want to see. In the context of a game, you want to see players doing things that match with the theme of the game, so that's what you should incentivize... and here's where we get to B/X being a fundamentally different game than its successors. 

Since 3e (or so), D&D has been a game primarily about fighting monsters. That's what you earn XP for doing, that's how you make progress in the game, so that's what the game is about. At least until 5e where there's a bit of a "or you can just advance whenever the story says" loosey-goosey cop-out offloading that work from the game designers onto the individual GMs... but I digress. B/X is a game about treasure-hunting because that's how players gain XP. It's not like XP actually represents anything specific in the fiction of the game. Diagetically, it hardly makes any more sense for the magic-user to get better at casting spells by stealing a golden statue from a forgotten temple than it does for him to get better at casting spells by killing 100 orcs. 

Realistically simulating how an adventurer improves at their craft has never really been the point of XP as a mechanic (see Gygax's note on p. 85 of the AD&D DMG). The point of XP in D&D has always been to incentivize the behaviors the game is designed around. In new D&D, that's making progress in the story and/or killing monsters. In old-school D&D, that's recovering treasure from dangerous locations by whatever means is most effective - could be violence, could be subterfuge, could be convincing the leader of the goblins that the Great Green Goblin God wishes them to steal the orcs' treasure and bring them to the party, who are of course the emissaries of the GGGG. 

The 5e GM needs to make a special ruling for the players to be rewarded for such a cunning plan - "OK, I guess I'll give you the XP the module would've given you for killing the orc chieftain even though you didn't fight him". The B/X GM (and the B/X players) know that it doesn't matter how the party got the treasure, what matters is that they got it and they will be duly rewarded with the currency the players actually care about (XP, not ingame gold, if that wasn't clear). 

Ultimately, it's pretty easy to turn B/X into a combat-centric game or 5e into a plunder-centric (or anything-centric) game... but I find the starting point of B/X to make for a much more compelling game. XP for treasure does seem odd, at first glance, to the GM coming from a newer edition - but it serves a vital purpose in shaping the play experience.

Idiosyncratic gems

Both of those idiosyncratic rules (and several more besides) could probably (and probably will at some point) fuel a blog post on its own, but for now I'll leave it at this: Almost without fail, whenever I pick up the oddly shaped rock of some strange B/X rule, there's a gem underneath. (pearl? worm? not sure how well this metaphor is working...) Not always, mind you. There are certainly a few design decisions in the game I think are simply wrongheaded. I will never, ever use the "two-handed weapons always lose initiative" rule from B/X, for example. But the vast majority of the time - there's a reason for the fence, and once I see what that reason is I often find myself nodding thoughtfully rather than reaching for the Sawzall.

Of course, I still have my 6+ pages of house rules for B/X. Chesterton's fence need not be left standing forever - simply pondered for a time. :)

In conclusion...

First off, I want to apologize to my high school English teacher (should he read this) for the title of this heading. Won't happen again.

Phew! That was kind of a long one, huh? I don't anticipate most posts being quite this verbose, but I think the meandering took us to some interesting places, at least. While I definitely intend to try to share plenty of more immediately gameable content, I'd also like to put out a series like this now and again - bit more "thinky" and philosophical, still related to RPGs but synthesized with some outside concepts. At least, if people like this sort of thing. Let me know what you think down below!

Further reading on Chesterton's fence: https://fs.blog/2020/03/chestertons-fence/

*For more on the lost "Basic" (as opposed to "Advanced") line of D&D systems, see this rundown. The newer systems most will probably be familiar with - 5e, 4e, 3.5e, etc. - those are all descended from "Advanced" D&D, which ran parallel to the "Basic" version of the game for many years before TSR folded and Wizards of the Coast decided to end the Basic line and rename AD&D simply: D&D.