"Causality and Choice in RPGs, Part 1: Getting rid of the {TECH}" on The 20' By 20' Room blog by Neel Krishnaswami
It was a bit challenging to find this article. It took a search result pointing to a forum post linking to another forum post linking to a dead site (which I then looked up in the Wayback Machine), but I found it.
Here's the article. The article also seems to be mirrored on a non-dead site here. A summary from the opening paragraph:
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.
(I was unable to find any other articles in the "series".)
Going line by line on how it meets your criteria:
- The body of text included '[tech]' rather than just 'technobabble' [...]; the title probably did too.
Well, this one's obvious; it's right in the title! It's also repeated throughout the article.
- The article was not tied to a single system, and was written from a predominately system-agnostic point of view [...] I think it was fully self-contained and not part of any specific series of articles
It's a fairly self-contained article (it claims to be the first in a planned series, but I'm not sure whether any followups were written) and does talk about RPGs in general.
It described how on Star Trek sets, the people who wrote the scenario were not the ones who wrote the technobabble, and instead (allegedly) just wrote '[tech]' and asked other people to replace it.
It explained that this makes the dialogue less connected to the narrative.
To emphasise: for the purposes of the article, 'technobabble' referred specifically to meaningless, almost completely interchangeable terminology thrown around
Quoted from the article:
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.
And as for the main solution the author proposes:
It then offered an example on how to replace meaningless technobabble with superficial and fictional but narratively meaningful terms.
Its example of meaningful terms included a description of a drive [...] and its various components, each of whose names gave some hint as to what would go wrong if it were non-functional for whatever reason.
It then showed how the question of which tech part broke down [...] can in a meaningful and informed manner affect the story
Here's the basic explanation and the diagram in the article:
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.
I'll refrain from quoting the entire article here, but basically it goes on to enumerate the possible states of being for each of those nodes; some are dependent on the inputs they receive. Once these technical relationships are able to be understood (even if totally made up just for the purposes of the story), players can make meaningful choices around them:
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}.
And as for your last point:
- While the article was potentially applicable to fantasy too, I recall the focus being either exclusively or overwhelmingly on science fiction.
Seems pretty clearly demonstrated by the entire article focusing on technology and technobabble in particular. Similar logic could potentially be applied to "magic-babble" or its equivalent, but often fantasy RPGs will already set out the rules for how magic works rather than handwaving it, in which case this breakdown isn't necessary.
