Visualizing probabilities in player defense rolls

Many crunchy, combat-focused roleplaying games (including various editions of Dungeons & Dragons) run combat by having the attacker roll some dice to attack, add some sort of modifiers and compare the result to a defense number (usually calculated by some formula, but typically a fixed in value for the duration of a combat). This is part of the fun for players, rolling dice and seeing how you do. It can be a bit of a chore for the game moderator, though. If, for example, four protagonists (one for each player) are fighting, say, eight antagonists (all controlled by the GM), that’s a lot of rolling for the GM when the antagonists follow the same system as the protagonists.

To alleviate this you can find suggestions for a lot of these games for breaking this symmetry and putting the players in charge of seeing if the antagonists damage their characters. The idea is usually that, instead of the antagonists rolling an attack, the protagonists roll a defense. This involves a bit of shifting some numbers around in most cases but, ideally, when you invert the control like this, you want to make the probability of the protagonist getting hit remain the same. This is especially true if you have a complex combat system with a lot of interlocking parts, as small probability changes can accidentally mess the system up.

A typical example of a house rule to give the players defense rolls comes from the Players Roll All the Dice variation suggested in the d20 SRD. I say “typical” because this example contains two large flaws that seem to be present in every other variation that does this that I have seen.

The first problem is adding needless complication. Let’s look at the d20 suggestion to illustrate. In normal rules in this game, an attacker hits when:

1d20 + attack bonus ≥ target AC

The two main traits used in this formula turn out to be derived in a somewhat complicated way. The target AC, for example, is calculated like this:

target AC = 10 + various armor modifiers

…which complicates even further to something like this:

target AC = 10 + armor bonus + dex bonus + size bonus + natural bonus + etc.

This turns out not to be that big of a problem in play, however, because the AC is pre-calculated and written on the character sheet. (Some sheets might also list some or all of the bonus individually, too, but all of them will list AC.)

The variation in the SRD, however, undermines this, attempting to invert the math and ending up with a defense roll where the protagonist avoids getting hit if:

1d20 + various armor modifiers ≥ 11 + attack bonus

What happened to the nice, pre-calculated AC number, that every player already knows how to use? Fortunately, this is easy to fix, given the definition of AC above, by adding 10 to both sides of the equation:

1d20 + 10 + various armor modifiers ≥ 11 + 10 + attack bonus

1d20 + AC ≥ 21 + attack bonus

This may seem like picking nits, but this actually makes a huge difference at the table, because it allows players to use numbers they already know, without modification. (If you use software character sheets and such, it also means that you don’t have to customize the software to display some new number, but can just use what is already there.)

The second problem, however, is a lot worse: the formula suggested doesn’t preserve the probability of being hit. It’s off by five percent.

Now, while the probabilities involved are not that complicated, this is sort of hard to see. The point of this post is provide a visual way to illustrate what is happening. The key, as is often the case in probability, is to focus on the number of outcomes that result in a hit. That is, of the numbers on the die being rolled, how many cause a hit?

Let’s look at an example of what we are trying to model, the probability of the original rules. Lets say an antagonist with an attack bonus of +5 is attempting to hit a protagonist with an AC of 15. This would mean the attacker adds 5 and has to get a 15 or higher to hit. It would look something like this, with the outcomes shown in bold text with a red background indicating a hit:

d20 roll 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
attack result 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
outcome miss hit
9/20=45% 11/20=55%

Now, lets create a mirror to the table showing the suggested house rule. Remember that succeeding on this defense roll means that attack misses, so the defender adds 15 to a roll and needs to get 26 or more to defend (21+attack bonus 5). Let’s still color the results such that bold, red background numbers show cases where the protagonist is hit (meaning a roll of 25 or less). To line up the results, lets display the numbers running the opposite direction:

d20 roll 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
attack result 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
outcome miss hit
9/20=45% 11/20=55%
10/20=50% 10/20=50% outcome
miss hit
35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 defense result
20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 d20 roll

By laying out the numbers like this, it is immediately obvious that the defense formula has a problem. Granted, that problem is in favor of the players, so it could be worse. To match the probability of the original rules, however, you need an adjustment of +1 to the target, so:

1d20 + AC ≥ 22 + attack bonus

This kind of “off by one” mistake is easy to make in systems that use “equal to or greater than” resolution. When inverting an “equal to or greater than” rule, the result must be “greater than” or you have to adjust the numbers. For example, instead of adding +1 to the target, we could have adjusted the comparison operator:

1d20 + AC > 21 + attack bonus

In this particular game, this would be a bad idea, though, because all the rest of the mechanics use “equal to or greater than” style checks. Better to have one slightly odd constant than to have a divergent comparison.

Some additional scenarios comparing the original probability to the “players roll defense” variation can be found in this spreadsheet.

Murky Dealings

Dealings mapI am entering Murky Dealings into the One Page Dungeon Contest 2014, even though it turned out a lot different than I had original intended it. As with my prior entries, I’ve left specific details deliberately vague. When I actually use a published dungeon (one page or otherwise), I usually only make use of the skeleton anyway, and replace the rest with campaign-specific stuff. I assume everyone else does the same thing, so just try to provide a feel to a place and let the reader fill in the blanks with stuff specific to their own game. (In the past, this approach has irritated some judges, but so be it.)

I also think this is more in keeping with the system neutrality which supposedly governs the contest, making it easier to, for example, use the map in a sci-fi game. Settings which don’t allow flying will make this dungeon significantly more difficult (would work well as a final challenge for a modern tomb raiding type game, for example). Another variation is to play with just how dark is “dark”. If you ran it in the Ptolus setting’s Utterdark, for example, everyone would basically be totally blind between the rooms. Even if it is normal darkness, the “see in the dark” magic of most fantasy systems will (intentionally) only be able to see one or two rooms nearest to the one you are in, sometimes none.

I continue to use vector software for maps, though this one also made use of a 3d modelling system to get the shapes right. This dungeon is significantly shorter than what I’ve done in the past, and better suited to a single night’s play. Like my 2012 entry, this is also another attempt to build a dungeon that is not a directional graph.

Giving LPub an ability it should already have

The open source LPub is an application that lets you publish instructions for LEGO models from LDraw data, primarily as PDF files. One of its nice additional features is the export of pages as PNG files. While functional, this export doesn’t properly support transparency. Since PNG files do support transparency, this is a bit irritating.

There is UI to set the background, and it has a “none” choice, but using it results in a solid white background instead of a transparent (or, worse in older versions, to a solid black background). Another choice is to use a background image, so you can try to fake out the application by setting the background image to a PNG that is nothing but transparent. The program allows this, but when you export the result, you see the art for each page layered on top of each other (clearly, the app is not clearing a buffer between pages).

Over a year ago, I submitted bugs for both of these problems to the LPub team (here and here). As of this writing, neither of them have been assigned to anyone, much less fixed.

So, I decided to fix it myself. Getting the code downloaded and built in XCode took several hours, and would have taken even longer had I not found the very useful “Compile LPub4 using XCode on Mac OS X” post by Mark from More than just bricks. I had to tweak a couple other things to get it to work, but nothing too drastic.

Knowing nothing about how the code worked and very little about Qt, the GUI package it uses, it took a couple of hours figure out where to make the fix and getting it working properly. The main trick is to add QPixmap.fill(Qt::transparent) in a key place in Gui::exportAs. The rest of the changes are just slight alterations to the UI. Not many changes needed, and maybe I missed something, but seems to work for me.

A patch containing my changes was made against the current head of the project’s CVS tree. I have submitted it to the LPub team. I will update this post if it gets included in a release.

Giving Skim an ability it should already have

I like Skim, an OS X PDF reader, enough to have listed it in my software recommendations. Skim is based on Apple’s PDFKit, just as Apple’s Preview application is. It offers a bunch of note-taking abilities as well, but I don’t use those. The main reason I use Skim over Preview is exactly one feature: in “two page” mode, Skim offers control over treating the first page as a “cover page” and Preview doesn’t. Skim calls this “book mode”.

I read a lot of roleplaying PDFs. Most of these are created using “facing pages”, where there is a clear right and left in the layout. When you read a PDF in two page mode, you want the right page to be on the right and the left on the left. Here is an example, from the Eclipse Phase rulebook:

Two page correct

This particular document has a coverpage, so the above image shows the display of a two-page layout in book mode. If I turn book mode off, I get this:

Two page incorrect

On the other hand, there are many similar roleplaying PDFs that are formatted with more “cover” pages, such that their layouts look correct when book mode is off and incorrect when it is on.

So, Skim can handle all this and Preview can’t. Great. But, while Skim allows you to set a global option for, say “Two Page layout, Book mode on”, it as no facility to remember what settings you selected for a particular document and restore them when you open it. So, I’m constantly readjusting the book mode setting every time I open something. (And, since some rpg documents are built to be single landscape pages, I often have to change two page to single page and back as well.)

Skim does have a feature that remembers what page a document was on, and restores that when you open it, but this fails in two page cases. For example, suppose my global default is “Two Page, Book mode off”. When I open the document pictured above, the layout is off, so I have to turn book mode on. Once done, I move to a particular page (171 in this case) and it looks good:

Two page correct

But, if I turn on the “remember what page I was on” setting, then close this document, when I reopen it, it opens using my global defaults so shows me this:

Two page incorrect

In a tight technical sense, you might consider that the “remember what page I was on” actually worked, but clearly the result was not what I intended. I was viewing pages 170-171 when I closed the document, why did it reopen the document to pages 171-172? The reason is pretty obviously because it does not remember the layout context along with the page.

So, I submitted a feature request to the Skim team to add an option to remember the layout and book mode. Given the existence of the “remember my page” feature, surely building something like this would be trivial. Within about four hours, this bug had been summarily closed, unimplemented, by one of the developers, who gave the following message (in its entirety):

This is not consistent with the current behavior, and not an improvement over it, because it is not consistent with the nature of PDF documents. This was rejected long ago, so I won’t go (again) into more details.

Hmmm. In only two dismissive sentences, this developer managed to sour me on Skim as a whole. Not even a link to this, apparently tortuous, past discussion of the idea. Something.

(I should also mention something else here. When PDFs are created in Acrobat, they can be given properties that instruct a viewer what layout and “book view” to give them on opening. Skim ignores these settings. I submitted a feature request to support these as well. This request was also summarily closed, though for a slightly more legitimate reason: PDFKit apparently doesn’t make those settings visible. On the other hand, its a PDF, not Sanscrit; you could read those settings yourself…)

Anyway, once upon a time, when a developer told you to piss off that was the end of it. Fortunately, Skim is open source. So…

This diff file contains a hack that, when the “remember my page” option is turned on, instructs Skim to remember the book mode and display choice in the same place as the page number (in ~/Library/Preferences/net.sourceforge.skim-app.skim.bookmarks.plist) and restore it next time the file is opened. It seems to work OK in my limited testing.

Having never seen the code before, it took me about 90 minutes to hack the code in this way, which means that someone who actually knows the product likely could have done it (and done it more correctly) in about 15. (For comparison, writing this post took about twice as long.) Normally, I would submit this hack as a patch to the project, but it is pretty clear they are not interested in it. Hopefully it will help you.

Seed: Bladechapel battlemap

Bladechapel is the headquarters of a knightly order dedicated to fighting evil threats from other planes in Monte Cook’s urban setting, Ptolus. Since no detailed plans of this fictional building seem to exist, and I wanted to confront my players with devils and demons ransacking the place during a zombie plague (long story), I set about making maps of my own. While I have progressed reasonably far, I’m to the point where I likely won’t be updating it any further. The map is functional, but not what I’d call “done”. As such, I’m releasing what I’ve got as a DivNull seed.


When it comes to maps, I prefer using vector tools like Illustrator over raster tools like Photoshop. This makes me a bit of the odd man out when it comes to making battlemaps, which is largely a raster pastime, but one of the reasons I wanted to make this map in the first place is to see how far I could push the vector tools. I posted progress notes for this map to a gaming cartography forum, if you are interested in more step-by-step stuff. My take aways from this project are:

  • One big goal was to learn how to use Illustrator’s mesh tool. Mission accomplished there. It is powerful and capable of doing things you can’t do any other way, but a bit clunky. I didn’t get really great at using this tool, but I least I understand what I’m doing now.
  • Live tracing seamless textures can build decent fill brushes that give objects more depth. (Vector maps are often very flat and blocky.)
  • Really decent textured fill brushes push Illustrator CS5 to the breaking point. On more than one occasion, I used up all the memory that Illustrator’s 32-bit limit could handle, causing it to die a horrible death. This transformed the project from learning about vector mapping to tiptoeing around the limitations of the software I was using, and is a big contributor to my not finishing the map. The newer 64-bit version might not have this problem.
  • Illustrator has the ability to print by tiling the output across multiple pages in an easy to understand way, but doesn’t extend this functionality to exporting PDFs. If you want to export to a multi-page PDF, you have to create individual artboards, and overlap them manually. The artboard tool makes this possible, but could be easier (allowing selection of multiple boards and editing, say, the X position of all of them at once would be very helpful, for example). I didn’t know any of this before starting this project, so learning it has been useful.
  • I also mostly just ran out of time. My desire to run a game using this map, and the pace of the game itself, overshadowed the need to do the map “right”.

I wound up with maps of five different “floors” of the building, in the end. They are big, as battlemaps go (roughly 50 squares by 60 squares, at an inch per square). Maps are available in two different formats. The PNG files contain the whole floor as a single image, at 150 pixels per inch. The PDFs divide the map onto pages of legal sized paper (the largest paper that the majority of home printers can handle), with a bit of content overlap. Note that all of these files are huge. You might want to look at the bladechapel-key.pdf file first. It gives a decent overview of the building layout and such.

Sources for this map are a bit tricky. I’m not going to post them, because the Illustrator sources are gigantic (the ground floor is over a gigabyte); however, if you are really want to play with them, drop me a comment to this post and we’ll figure something out.

Many of the objects on these maps (tables, chairs, etc.) are bitmaps intended for use with Dundjinni, and credit for them goes to their creators. Likewise, the name “Bladechapel”, “Knights of the Pale” and other aspects of this map are ©2006-2007 Monte J. Cook, used with permission. The textures originated from Seamless Pixels. Everything else should be considered released under a Creative Commons Attribution 3.0 Unported License:

Creative Commons License

The Pandemonium Deck

The world doesn’t really need another variation of the deck of many things, but I built one anyway. I wanted to add something like it to my Ptolus/Pathfinder campaign, but had some slightly different objectives than I’d seen from other variations:

  • based on the Decktet deck
  • focus on individual cards instead of the whole deck, somewhat like Madness at Gardmore Abbey does
  • make assembling and drawing from the deck something the players would have to go out of their way to accomplish, instead of just lobbing the full-power, completed deck into a campaign
  • make drawing cards more difficult, but even more campaign altering than the original deck of many things if the players buy into it.

Though I requested some assistance with the deck from Story Games, I didn’t expect this to bear much fruit. My expectations were met.

If you have read this far, you probably know the deck of many things has a well-deserved reputation for breaking campaigns, where the result of one card would could derail all the action into some odd (and, to the group, inconvenient) place. There have been a number of variations of the deck, most of which seek to solve this problem by gimping the effects of drawing cards.

I wanted the pandemonium deck to go a different direction: rather than avoid the campaign derail, embrace it, but set things up so that everyone is expecting, even demanding, the derail. In broad strokes:

  • No one ever finds the ”deck” whole. People find individual cards.
  • If cards are present at a battle, one of them exerts an “influence” on the battle providing a moderate benefit that moves at random around the battlefield. (There are other assorted tricks, like forcing your card to be the influencing one, etc.)
  • Gathering more cards provides the owner with bennies.
  • If the players decide to make tracking down cards a thing they care about, at a certain point, mechanics kick in that accelerate this process (abilities to locate cards, communicate with those that have them, etc.)
  • Once the entire deck is assembled (presumably after quite a bit of effort), a ritual allows the more classic “drawing a card from the deck” major mojo. There is a slight bit of player control here (draw three, but choose the one that takes effect, etc.).
  • Drawn cards disintegrate and reform at random elsewhere, so must be collected again before another draw can be made.

The resulting deck can be found here: Pandemonium Deck

DivNull Seeds

With the new year comes reflection and resolution. This post is a bit of both. For most of my adult life, I’ve had a tendency to start new projects, but never finish them. This begins to weigh on me, as more and more unfinished stuff accumulates. Last year, however, I realized something about the way I work, and it is going to change what I release on this blog a little bit.

Often, what excites me about a project isn’t the final product, but what I’m learning when I do it. When the learning stops, so does the whole point in doing the project in the first place. Knowing this, I’m going to start suppressing the urge to “finish” some projects before releasing them. Rather than have them sit, untouched, on my to do list forever, I’m just going to throw them out there, as is, and check them off the to-do list. I’ll be referring to projects that follow this process as “seeds”: not really done, but someone could pick them up if they want to. I’m assuming that most of these seeds will just sit there, which is fine. But, on the off chance that they provide some use to someone, I’m going to post them anyway.

I’ll try to say a bit about what I was trying to do, and what I learned with each seed I publish.

So far, here are the published DivNull seeds.

My favorite review of ’inkadia

Johathan Lavallee reviewed every Game Chef 2012 entry, giving each game four paragraphs about “the good”, “the bad”, “the other” and “would I play it”.

He said this about ’inkadia:

The Good: *stares at the work in shock, jaw on the floor* This is art imitating game.

The Bad: *stares at the work in shock, jaw on the floor* This is at times avant guard art imitating a game.

The Other: *stares at the work in shock, jaw on the floor* This is a dinner party, right? Also, moderately price game for a one time thing.

Would I play it? *stares at the work in shock, jaw on the floor*

I reply:
Totally nailed it.

Seven Spindles… named a winner in One Page Dungeon 2012 contest

Seven Spindles and a McGuffin was named one of the 24 winners of the One Page Dungeon Contest 2012. I appreciate the honor, even more so than last year, because my entry this year wasn’t as good and the competition really kicked up a notch. Thank goodness they named more winners this time around!

At the time of this post, the main site for the contest seems to have fallen down, but there is a PDF containing all the winners on a different site. (And this guy reviewed them all, mentioning this entry as “bereft of flavor or charm”. Hoo-rah!) Once the site comes back up, though, check out all of the entries (over a hundred, I think). People really brought it this year.

In honor of this win, I’m releasing the source files for this dungeon (under the same CC licence as the PDF). This zip file contains one Adobe Illustrator file with the dungeon map and one InDesign file that links to the map and contains the text and other stuff. If you use these sources for something, drop me a link to the results in the comments.