« WISH 79 Response: Ideal Cast Size | Main | The “Perfect” Size for Modern Games »

January 04, 2004

Causality and Choice in RPGs, Part 1: Getting rid of the {TECH}

Posted by Neel Krishnaswami on January 4, 2004 at 06:21 PM

This is a tutorial article on how to create and use causal influence diagrams as a general-purpose technique to enable players to make consequential decisions for their characters. It's the first in what I think will be a series of articles on causality, and how to manage it and use it for best effect. It's also the first time I've ever put any version of these ideas into print, so any and all commentary and corrections will be gratefully accepted!

I am told that the writers of Star Trek scripts do not usually come up with all of the jargon that the characters use. Instead, they just make the notation {TECH} wherever the characters should say something technical, and someone else will come along to fill in each such instance with some chunk of technobabble. This has an important story consequence: since the science is completely arbitrary, it's necessarily the case that the plot can't really hinge, in a compelling way, on the technical and scientific choices the characters face. It's all just {TECH}, and at best technobabble can provides sci-fi color, and at worst it's an excuse for a deus ex machina resolution.

The same thing is true in most roleplaying games, too. When a character needs to do some noncombat activity, the process of doing so usually boils down to scrounging up all the available bonuses and then making a die roll. The player never gets to make a real choice: since bonuses are always good and penalties always bad, there's never a compelling reason to ever reject one. And what is merely amusing in a television series is essentially fatal to a roleplaying game.

We can still be entertained by an episode of Star Trek, because part of the ritual of watching TV is going along with the conceit that the characters are making meaningful decisions. But roleplaying games are games in which the players' choices stand in for their characters' choices, and any game in which the players can't make meaningful choices for their PCs is in deep trouble.

I believe this is why so many roleplaying games are based in violent genres; we know, thanks to our primitive ancestors' wargame heritage, how to put together combat systems that offer players some modest scope for meaningful choice. But when it comes to anything outside of combat, very few game systems offer any help in this regard. At best, you can play collect-the-bonus, and if the designer was really daring there's a game of rock-paper-scissors glued on top of that, so that the player can choose a "strategy" (the scare quotes are deliberate).

Thus far, I don't think that I've said anything really unusual -- I'm sure everyone reading this has seen some rant or another along these lines before. So I'll try and break free of the pattern, and actually offer a technique that can help. I'll use a space opera example as the running example in this essay. Let's suppose that we have a space opera game, and we want to give the player of the ship's engineer some consequential choices to make about how he can fix his ship's hyperdrive. (Note that a hyperdrive is deliberately not "realistic"; I want to be able to make anything into a focus of consequential choice.)

The technique I suggest is called the causal influence diagram; it's a tool from machine learning and analytic philosophy that I think can be profitably applied to solving one of the hardest problems in roleplaying games: reliably enabling the players to make meaningful, consequential choices.

So, first: what is a causal influence diagram? A causal influence diagram is basically a bunch of boxes with arrows connecting them. Each box represents some thing or situation, and the arrows leading into it are the causes that directly determine what state the situation can take, and the arrows leading out of it point to exactly the boxes which it in turn causes. So the state of a box is the cause of all the boxes it points to, and it is the effect of all the boxes that point to it.

For our hyperdrive, let's take each of the boxes to be some component of the hyperdrive. I'll just make up some a technological-sounding name for each component:

  • Hyperwave detector
  • Flux Amplifier
  • Antimatter Grid
  • Plasma Coils
  • Phase Lock Controller
  • Safety Interlocks
  • Graviton Shunt

That's a fine list of technobabble terms, but we haven't gotten past {TECH}. The trick to doing so is to put them into a graph, so that you can see which components depend on which others.


So our diagram says that what the flux amplifier does depends on what the hyperwave detector and the phaselock controller are doing. What does this mean? To answer this, we need to make a small story for each box, explaining what its states can actually be, and how they depend on the causal factors. Since we have seven pieces, we have seven such things to write.

For the four boxes with no inputs, our task is basically trivial: we can just enumerate each the possible states that the box can be in. For example, let's suppose that the hyperwave detector is a sensor device, and the sensor can be either up or down. If it's up, it's detecting hyperwaves properly, and if it's down, then it's not -- perhaps it is damaged, or turned off, or removed for repairs, or something.

Hyperwave Detector
Hyperwave Detector
Sensor Up
Sensor Down

Likewise, the phaselock controller can either be synchronizing the phase, or it's broken:

Phaselock Controller
Phaselock Controller

An antimatter grid sounds like a power source. Let's say that it's either generating full power, or it's not. Note here that there are a lot more possible states we can imagine putting the grid in, like reactor overloads, a core breach, and so on. My choice not to include that is arbitrary: I am just trying to keep the example small.

Antimatter Grid
Antimatter Grid
Full power
No power

Every hyperdrive needs safety interlocks, if only so the engineer can disable them to resolve an emergency -- or a saboteur can disable them to create one.

Safety Interlocks
Safety Interlocks

Much more interesting are the boxes that depend on causes -- the states that they can take on are conditioned on their causes. We can represent this with a table, in which the state of the box depends on the states of its causes. So our flux amplifier's state depends on the hyperwave signal and the phaselock controller. The story we make up here is that the flux amplifier is amplifying the hyperwave signal, and the phaselock controller keeps the signal in tune with the plasma beam from the plasma coils. If everything works right, then we get an in-phase plasma signal, and if not, things can break in interesting ways.

Flux Amplifier
Hyperwave Phaselock Controller Flux Amplifier
Sensors Up Synchronizing In-phase flux signal
Sensors Up Broken Out-of-phase flux signal
Sensors Down ... No flux signal

The plasma coils depend on the phaselock controller and on the antimatter grid. Antimatter and plasma sound highly energetic, so let's say that the plasma coils generate a plasma beam for the graviton shunt. Naturally, the phaselock controller guarantees that the plasma beam is properly in phase with the flux signal.

Plasma Coils
Antimatter Grid Phaselock Controller Flux Amplifier
Full Power Synchronizing In-phase plasma beam
Sensors Up Broken Out-of-phase plasma beam
No Power ... No plasma beam

The biggest table is the graviton shunt table. It depends on the safety interlocks, the plasma coils, and the flux amplifier. This is the thing that actually makes the hyperjump, and it needs the plasma beam for power and a flux signal to direct it properly. Since this is dangerous, there are safety interlocks that will shut down the shunt any time that the flux signal and plasma beam are not in-phase.

Graviton Shunt
Flux Amplifier Plasma Coils Safety Interlocks Graviton Shunt
In-phase flux signal In-phase plasma beam Enabled Accurate hyperjump
In-phase flux signal Out-of-phase plasma beam Enabled No hyperjump (safe failure)
Out-of-phase flux signal In-phase plasma beam Enabled No hyperjump (safe failure)
Out-of-phase flux signal Out-of-phase plasma beam Enabled No hyperjump (safe failure)
In-phase flux signal Out-of-phase plasma beam Disabled Inaccurate hyperjump -- overshoot or undershoot
Out-of-phase flux signal In-phase plasma beam Disabled Inaccurate hyperjump -- wrong direction
Out-of-phase flux signal Out-of-phase plasma beam Disabled Wild hyperjump -- could be anywhere!
... No plasma beam ... No hyperjump (can't generate gravitons)
No flux signal ... ... No hyperjump (can't make hyperspace transition)

So now we can tell a story about how the hyperdrive works. What does this get us? Does it really give the players of an RPG the ability to make consequential choices? I think it does, because we now have the ability to answer the question, "What if?"

I'm going to (very briefly) talk about the philosophical underpinnings of causal influence diagrams. They are inspired by a view of causality called interventionism. In this view, to say that A is the cause of B, is to say that if you change the world so that A becomes true, then B will become true also. So we say that the sight of dawn causes the rooster to crow, because if we kept a rooster from seeing the dawn, it wouldn't crow, and if we showed it an artifical dawn it would. Conversely, the rooster doesn't cause the sun to rise, because if we prevented the rooster from crowing, the sun would still rise. You can see how this idea applies to gaming. We can work out the causal relationships in a situation, and then the actions of the players constitute interventions -- and then we can use our knowledge of those causal relationships to infer what has happens as a consequence.

So, how would a causal influence diagram work in play? The basic idea is that events in the game affect the state of the various components of the hyperdrive -- for example, a neutron torpedo hit might damage the phaselock controller. That, in turn, will have a forseeable consequence for the PCs -- their spaceship can no longer make a hyperjump. The player of the engineer can, in turn, suggest different options -- he can cut the safety interlocks and the ship can make a wild jump, or if the pilot can evade the enemy long enough, then he can replace the controller. And he can make these improvisations without having to {TECH}.

Now, I'll make some pragmatic observations on using causal influence diagrams. First, and most obviously, let the players look at them. They can't play the what-if game without knowing what the consequences might be. This is a form of prep that's intended to be shared with the players; it's an efficient way of encoding lots of information about the setting. Second, less is more. Causal diagrams exist to make playing what-if games easier, but extremely complicated causal relationships will still be opaque. Even relatively simple relationships -- like the workings of the graviton shunt -- form fairly unwieldy tables. Third, aim for causal relationships at about the granularity you want the game's action to focus on -- the diagram encodes the causal relationships the players can see, and so that will be the level at which the players will hypothesize and reason.

Finally, roleplaying games reach their highest pitch when the player is making a meaningful, consequential decision that they care about. It has to matter in the story, and it has to be a story the player cares about, and it has to be a decision the player makes, not a die roll. A causal influence diagram can help you with the last part of that, but the first two are still up to the group.



TrackBack URL for this entry:

Listed below are links to weblogs that reference Causality and Choice in RPGs, Part 1: Getting rid of the {TECH}:

» Choices in RPGs from Ed Heil's Weblog
Jim Henley writes The 20' By 20' Room: Causality and Choice in RPGs, Part 1: Getting rid of the {TECH}. He proposes a complex method for creating recipies for meaningful choices for characters to make. It seems good, but I'd [Read More]

Tracked on January 5, 2004 08:09 AM

» Choices in RPGs from Ed Heil's Weblog
Jim Henley Neel Krishnaswami writes The 20' By 20' Room: Causality and Choice in RPGs, Part 1: Getting rid of the {TECH}. He proposes a complex method for creating recipies for meaningful choices for characters to make. It seems good, [Read More]

Tracked on January 5, 2004 11:56 AM


Very interesting stuff.

In a diceless game, narrative decisions are certainly based on PC expertise --and this kind of homework could make for a very immersive game.

Posted by: Arref at January 4, 2004 07:58 PM

I think Amber players may have a bunch of relevant experience. Amber is not as impressionistic as Nobilis or as mannered a genre as superheros (MURPG), and there's no dice, so causal relationships come to the for for decision-making.

Posted by: Neel Krishnaswami at January 5, 2004 08:41 AM

I both hate you and love you now, Neel. Now I see how to use UML to build decision trees for RPG design. Damn you and your applications of known and well-documented techniques!

This article reminds me very much of Bruce Schneier's Attack Trees for determining the route of least resistance in a security scheme. Attack trees are beautifully applicable to RPGS very much the same way as causal diagrams. There's an ultimate goal, N number of possible routes to the goal, and each route has a cost. You figure ahead of time the possible routes to the ultimate goal and the difficulty associated with each route. How someone trying to achieve that goal falls out of the diagram fairly quickly.

If you think about it, the standard Kill the Foozle adventure is exactly an attack tree situation. You have a goal, you have a set of obstacles, and now you just run with it.

If you combine your causal diagram with the attack trees, you can build a fairly solid scenario using standard tools. The causal diagram lets you build what pieces rely on what, and the attack diagram makes it clear how, using those pieces, you can achieve your goal.

So I'm going "Hmmm."

I'll spend all day now thinking about building a set of on-screen tools to put together coherent frameworks for adventures all day long. I'll blather on more after the information has sat in my head for a while and banged around.

Posted by: Emily Dresner-Thornber at January 5, 2004 10:00 AM

A caveat: decision trees are a very attractive and very flawed idea for gaming. The reason that decision trees are attractive is because they put decisions right into the diagram. But this is just why they are flawed, too -- each time you add a binary decision to the diagram, you double the size of tree, and that kind of exponential growth becomes unmanageable very quickly.

Causal diagrams, on the other hand, don't grow exponentially: to add a node, you just add a single node. So you can add options without doubling the size of the whole network for each one. The fundamental reason this all works is that the sequence of the players' decisions is not baked into the diagram. What the tree tells you is how the situation will change in the face of any interventions, so you don't have to explicitly plan for what the players will do ahead of time.

The part of this that I'm least happy with are the tables. Machine learning people like them, because tables are easy for computers to handle, but they are obviously the least readable part of the article as written. I'm looking at the attack trees article as a way of more concisely representing this information.

Posted by: Neel Krishnaswami at January 5, 2004 11:49 AM

Are there any good references (books, webpages, etc) that go into causal diagrams? I'm not an AI guy, I'm an Operating Systems guy, and I work on a less abstract level.

Posted by: Emily Dresner-Thornber at January 5, 2004 12:32 PM

There's a bunch of stuff, but not much of it at the sort of level that's useful for gamers. Most of the literature is about learning models from data. This is useful, but what we're trying to steal is just the tricks for representing models concisely. If you are really interested in the mathematics and philosophy, then Judea Pearl's Causality is the best place to look. It's a rather subtle book, though -- even though the math is straightforward, it uses many very sophisticated arguments. Also, Bayesian networks are very closely related to causal networks, so any web page about that will be applicable. (I like http://b-course.cs.helsinki.fi/depend.html.)

You might have the best luck actually playing with a program like MSBNx, which is a program that lets you write down models and make inferences from them. The math is the least important thing for rpgs.

Posted by: Neel Krishnaswami at January 5, 2004 01:20 PM

This is just what Geoff Skellams did for community behavior in the new Gamma World, and I love it. The engine example works very well, too, and it seems like you can give this kind of treatment to anything that'll be significant in play. The hard part is generalizing it rather than getting mounds and mounds of special cases.

Posted by: Bruce Baugh at January 6, 2004 07:50 AM

Hi Bruce, some disjointed comments:

One of the biggest influences on me is Aaron Allston's Dungeon Master's Design Kit. His step-by-step breakdown of high fantasy into a collection of charts and checklists was really what set me on the road away from hack-and-slash and towards the sorts of games that I really enjoyed. Even as a thirteen year old newbie, I knew that I wanted my games to be less like dungeon crawls and more like the novels I read. I just didn't know how to move from intention to execution, until I read that. So I want to offer something in the same spirit.

I think this technique lives a little uncomfortably in the space between game design and adventure design. I came up with it partly because I want to run games which aren't focused on combat, and I want a way to make the interesting non-combat parts of the game contain space for player choices. (Even the phrase "non-combat" is biased!) I probably need to work out in more detail how to use the mechanism of causal relationships to do scenario preparation -- it seems like you should be able use it to make adventures that don't have a single plotline.

Posted by: Neel Krishnaswami at January 6, 2004 01:34 PM

Hey, cool. Dungeon Master's Design Kit is available as an electronic download for five bucks:


Posted by: Bryant at January 6, 2004 01:55 PM

Bruce, a quick note on the "generalization" part. I agree that this is a desirable goal and that it is also hard. The problem, as I see it, is that sometimes an approach cannot be easily generalized or the generalization strips away too many distinguishing elements of the underlying structure.

One interesting approach of dealing with problem domains that don't have a uniform and generalizable structure are design patterns and pattern languages. While currently popular for software design, the idea originated in architecture (invented by Christopher Alexander) and is applicable to other domains as well.

For example, I have a library of "conflict patterns", which I use for scenario design. One example is the Equilibrium pattern:

Name: Equilibrium (also Balance, Balance of Power)
Roles: Two entities (groups, actors, places, impending events). A metric with which to measure these entities.
Interaction: Weakening one entity strengthens the other, and strengthening one entity weakens the other.
Variations: Weakening/strengthening either entity may be irreversible. Weakening/strengthening either entity too much may lead to catastrophic side effects or destroy the equilibrium. An equilibrium with more than two interdependent entities.

Examples of the Equilibrium pattern are two crime families competing for control over a territory or a magical artifact that can only protect one of two places against a catastrophe.

Conflict patterns are defined by roles that certain entities assume as part of the conflict that is being modeled, and how the entities can interact in the course of the conflict. That in itself is not particularly interesting (beyond the benefits of having a handy catalog of templates).

The interesting part is that one can combine patterns to form more complex structures. For example, I can combine the Equilibrium pattern with the Unforeseen Consequences or the Countdown patterns (whose names should be self-explanatory). The ability to combine pattern creates a vocabulary and grammar (a pattern language) to express and talk about complicated conflicts in a structured way.

It should be possible to create pattern languages also for other problem domains with a non-trivial structure.

Posted by: Reimer Behrends at January 7, 2004 10:20 AM

Oh, wow. Very cool. Thanks!

Posted by: Bruce Baugh at January 8, 2004 08:59 AM

Reimer, any chance you'd share the rest of your library, preferably with examples? I'd love to see that.

Posted by: Matt Snyder at January 8, 2004 09:39 AM

I'll third the request. Also, if it isn't too large (and I clearly have bunker-busting standards in this regard :), I'd be happy to post on the front page here as a guest post.

Posted by: Neel Krishnaswami at January 8, 2004 10:21 AM

Matt, Neel: I'd be more than happy to share, but it'll require some effort on my part to make the "library" (which currently is just a fairly unstructured TeX file) readable by others. I'll see if I can get around to cleaning it up during the next couple of weeks.

Posted by: Reimer Behrends at January 12, 2004 09:30 AM

Post a comment