Aug 30, 2016

Running Technical Plots

The technical plot is the type of plot where the resolution of the problem relies on the characters' technical knowledge of futuristic science, or magical knowledge, or something of that ilk. A good way to determine if the story or problem you're thinking of can be resolved by defeating a specific person or creature. If so, it's probably not a technical plot. If it requires you to somehow dissipate or prevent the build up of magical (or weird science) energy, stop an environmental or ecological problem, or change some feature of the world using a level of knowledge that only your character possesses, it's probably a technical plot.

These sorts of plots are very common in science fiction media like Star Trek. The Enterprise or whatever discovers a strange phenomenon, the stakes are established, the main cast debates what to do, and then acts. The most high-profile one in a fantasy module that I can think of is Dreams of Ruin by Geoff Grabowski, where you're trying to deal with a fantastical ecology that's trying to invade your home plane. The villain responsible for setting up the ecology is long-dead, or at least missing, and defeating them won't actually stop the Dreams of Ruin from colonising your world anyhow.

Despite how common these sorts of plots are in the media that serves as inspirations for many games, I rarely find these sorts of plots set up or run well in published modules. The core challenge of a technical plot is how to maintain player agency in a plot that relies upon the characters' technical skills. Badly done, these sorts of plots turn into a railroaded series of skill rolls that are even more frustrating when characters don't have all the necessary technical skills.

I would therefore propose the following mental model of how to run technical plots in a way that maximises player agency.

First, there is a Problem with some Effects. The Problem must undergo an Examination. The Examination suggests one or more Apparatuses to resolve the problem. The Apparatus must be assembled / collected / stolen and then undergo an Activation. The Activation either resolves the problem, or the Effects grow worse.

Let's look at each of these in turn.


Problems should be simple enough to be stated in 1-3 sentences. Much more than that, and you start getting overly complicated. A problem should avoid vagueness and ambiguity. In fact, one extremely common mistake in technical plots is to make figuring out what exactly the problem is the main task of PCs.

For example, a few weeks ago I played in a game where the problem was "Our supercomputer predicts this world is going to blow up" without any further information about how or why (except for the location where this was likely to occur), and much of the actual playtime involved piecing together the clues about how and why. The actual problem was "The bad guys are beaming psionic energy from an entire city at a transdimensional object while causing a multiversally unique event. They hope to use this to blow open a portal in reality and escape." But the route to this was convoluted enough that no one actually figured it out until the debrief after the scenario (which we failed).

A clear concise statement of a problem should state a few (2-5) possible elements which suggest immediate lines of investigation or action. Using the above situation as an example, one might ask "Can we stop them from beaming the psionic energy? Can we destroy the object or prevent it from channeling the energy? Can we stop the multiverally unique event?" It can even be useful to write out the problem on a sheet of paper, underline each one of the elements of the problem, and hand it to the PCs. I prefer this method to the most common alternative I've experienced, which is to push them to make guesses about what's relevant, then skill rolls to determine if those guesses are correct.


Examinations are one of the three main areas that I prefer play to focus on during a technical plot. An examination is where the PCs investigate some element of the problem, and determine whether they can deal with it, and how.

The challenges of an examination typically involve getting close enough to the problem's element to examine it (for example, sneaking past guards, or going on a long journey or flying your starship near enough to the phenomenon to suffer some of its effects, etc.), and getting enough time to study it (having to make hasty readings of your instruments while the alarm is blaring, or rip files from the server before ICE takes your avatar down).

Typically, this is where you bring in one or more of the effects of the problem, possibly even staging them so that each examination the PCs make is tied to the occurrence of another effect. This can be used to force PCs to prioritise which elements they want to examine, rather than being able to find out about all of them.

After completing the examination, the PCs should have some data or information about that element, and what's going on with it.

It's only really at the end of an examination that the PCs' skills come into play. The role of the skills is not for interpreting the data they got (just give the necessary conclusions to them), but rather for determining what kinds of solutions they can figure out to deal with this element of the problem. Let the players roll whatever skills they have to determine what apparatus they need to solve the problem. If they fail all the rolls, they have to examine another element of the problem to try again. Skills can be mainly technical, but it's useful to allow a few others - usually social skills - so that if the PCs don't have the right skill set, part of their solution to the problem can involve recruiting people with them (e.g. the problem is a build up of psionic energy, so they're going to need to recruit a bunch of psychics to help).

You can increase the scope of relevant technical skills or tighten it up as one way of controlling the genre-fidelity of the game - fewer skill possibilities tend to feel more like hard science fiction or low-magic settings, while being able to use your biology skill to figure out how to stop the black hole from consuming your home planet puts you firmly in science fantasy and epic fantasy.


The apparatus is the combination of gear, resources, allies, and other stuff the PCs need to be able to stop the problem.

The apparatus the PCs need is generated from their skill rolls after the examination, and should fall within its domain. A bunch of physicists might try to solve the problem with a weird ray apparatus, a wizard might need to assemble a bunch of artifacts and cast a special ritual, etc. The challenge at this phase is to assemble the apparatus. It might be as simple as a few skill rolls (if you wanted to gloss over it and focus on other parts of play), it might be some fetch quests to grab the rare materials, it might be the case that someone has already built the necessary bits and you just have to steal it from them, or any other option you can think of.

Regardless of how difficult the apparatus is to assemble and how complicated you want this part of the adventure to be, I do recommend that any apparatus contains at least 1-2 flaws. These don't necessarily prevent it from working, but they represent hindrances and risks associated with activating it. For example, a weird ray gun might be extremely short ranged, and require you to get dangerously close to zap the hole in space and time with it. Or the artifacts might only be one-use with a low chance of functioning.

To compensate for these flaws typically requires further examinations as above, but of different elements of the problem. Each time the PCs complete another examination, they can either try to create another apparatus (which will have different flaws, perhaps more easily ameliorated), or eradicate some of the flaws in their existing apparatus (adding more uses, a longer range, a better chance of working, etc.). As mentioned above, by increasing the effects of the problem with each examination, you can prevent the PCs from being able to completely trivialise solving the problem by examining things over and over until they have a flawless apparatus.


The activation is the part where the PCs go to use the apparatus and try to resolve the problem. Typically, you're trying to ameliorate or avoid the flaws of the apparatus, without being overwhelmed by the effects of the problem. You might be trying to get your spaceship close enough to the black hole to fire the graviton bomb without being torn apart, you might be trying to insert the virus into the command terminal, you might be trying to overcome the field of blight energy to get close enough to bless the unholy altar, etc. Enemies might be trying to stop you, but the referee and players should understand that defeating them is only a secondary goal (avoiding, bribing or otherwise neutralising them should be fine). Usually at this point, the effects of the problem are ramping up in severity. They may not climax (especially if the PCs are unsuccessful and need to try again with a different apparatus) but they should be enough to significantly affect almost any action characters are taking.

A successful activation resolves the problem. There might be consequences, but the problem will not get any worse from this point on.


You typically need multiple effects for a good technical problem (2-5). Effects should drive decision-making, and should start off mild, able to compensated for with minimal effort. As time goes on, the effects worsen, until much of the final activation's success is driven by how well you can deal with the conditions.

One common problem I've found in technical plots is to escalate too rapidly or slowly. In the first case, you go from everything being fine and normal, to the sudden, imminent, looming destruction, with very little in between (sometimes there's some atmospheric description, but mechanically, nothing changes). The second option often involves getting lost in book-keeping, with something like "You get a cumulative -1 to all stats per day" (or whatever) which then goes wonky the first time the referee fudges on time. I suggest designing your effects as clearly distinct phases which replace one another, rather than simply being cumulative. Cumulative stuff is harder to keep track of (for very little thematic pay off).

Not all phases should be fatal if you fail a roll (in fact, most shouldn't be) but instead should require the PCs to expend resources, whether in-game ones like oxygen, rare materials, spells, etc. or metagame ones like friendship points or whatever as the crisis takes a mental toll. One big non-fatal effect at a time lets you run a scene or two where the PCs notice and compensate for it, while clearly indicating the progression towards the final crisis, as phases gradually grow more severe.

Anyhow, this is just a mental model, but I find it's a useful one that has helped me run technical plots without missing essential details or focusing on the least fun parts of such plots.

No comments:

Post a Comment