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
Synchronizing
Broken

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
Enabled
Disabled

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.