“Houston, we have a problem:” running “technical” sci-fi RPGs

Someone asked on Reddit for space-survival RPGs in the vein of Apollo 13 or The Martian – RPGs rooted in hard technical details. I gave them a few suggestions, and they followed-up asking for additional advice on how to even run that style of game. To quote:

The varied obstacles and malfunction-based obstacles are exactly what attracts me about this sort of game.[…]
But implementing this in an RPG is gonna be difficult. Each obstacle would have to be unique in some way so as not to become stale. But as I was analyzing these space films… well, none of the conflicts looked like they’d translate very well.
Any advice on how to translate those intense, terrifying scenes from these space films into an RPG?

u/Gicaldo, April 2022

After giving it some though, I shared three broad approaches that could help produce those “intense, terrifying scenes.” For posterity, I’m also going to share those ideas (and other important thoughts) here.

The Appeal of “Technical” Sci-Fi

Apollo 13 (film, 1995)

For a lack of a better term, I will call this desired style of play “technical” sci-fi. Movies like Apollo 13 or The Martian root their conflicts and drama in the technical details of the circumstances, and that has two broad appeals.
First is the simple fantasy of competency in the face of intense challenge: it’s exciting to see an expert use their skills in a difficult situation, and there aren’t many places that are as dangerous as outer space.
Second is the verisimilitude of the technical reality. Hard science fiction works are measured based on how “scientifically accurate” they are because that “scientific accuracy” lends an authenticity and a credibility to those stories. The Martian is appealing partially because it’s (mostly) plausible, and Apollo 13 is appealing partially because its conflicts are entirely rooted in a scientific and historic reality.
When you combine these two desires together – the fantasy of expertise being tested and a scientific verisimilitude – you get “technical” sci-fi. So someone that wants to play a “technical” sci-fi RPG is someone that wants to root themselves in a technical fictional reality and test some sort of technical or scientifically-framed problem-solving skills.

Understand Conflict

Before we actually discuss how to run “technical” sci-fi, we need to talk about conflict. Conflict is the beating heart of most of fiction, including interactive media like video games and tabletop roleplaying games and the media that inspire “technical” sci-fi. For most roleplaying games, conflict takes a martial form: one faction wants one thing, another wants an exclusive thing, and both sides will physically fight each other until the conflict is resolved. In less martially-focused games, the conflict may be economic, or social, or political, or one of identity.
Fortunately for most game masters, many of these conflicts are easily-relatable – players understand resource issues, or questioning one’s identity, or navigating a tangled social web. Unfortunately, that doesn’t include conflicts of “technical” sci-fi. While Apollo 13 and The Martian are classic “humans vs nature” stories, the core details of those conflicts are rooted in scientific principles. Unless you have a table of scientists, mechanics, technicians, or engineers, your players will likely face troubles relating to technical conflicts.
Therefore, game masters need to make sure that the conflict is obvious to the players and to themselves. What could go wrong if they salvage parts from one TVC to repair two other TVCs? What is meaningfully different between performing a single hard burn vs multiple softer burns? What do the PCs want, and what is at stake?
Now that we have a focus on conflict and stakes, and that “technical” sci-fi RPGs need ways to communicate and generate clear conflicts and stakes, we can discuss the three methods game masters might use to facilitate these conflicts:

Method 1: Survival Meters

Essentially-speaking, Apollo 13 and The Martian are stories of survival and resource management. Video and tabletop games love resources management systems, so we can look to those for inspiration.
In the most simple configuration, this method would make the central technical conflict about managing resources – fuel/delta-v, heat, hull integrity, oxygen supply, etc – while trying to accomplish a mission. A dungeon crawl is a great example of a resource management scenario, with torches, HP, rations, and spell slots as the resources directly managed.
The consequences of poor management are usually clear with the selected resources: no more fuel means you can’t change your movement, no more hull integrity means the ship has broken apart, no more air means you can’t breathe. Likewise the ways to restore those resources are clear: purchase/mine more fuel, use spare parts to repair the hull, and roll Engineering to fix the life support system.
However the challenge with this approach is that, quite frankly, balancing meters (especially shared meters) isn’t fun for most people. The act of optimizing the expenditure of resources is enjoyed by only a few people, and these games of resource optimization can slow to a crawl as one player tries to calculate all possible results six turns into the future.
Another challenge is a possible lack of variety. There are so few combinations of meaningful parameter states, which might result in encounters feeling repetitive as players try to solve small variations of the same situation.
As a result, this method is recommended for players that like resource management, or in games where more varied scenarios are possible and can be combined with these survival puzzles. Good examples of this style include Traveller/Cepheus Engine, Mothership, Diaspora, and (I believe) the licensed Alien RPG.

Method 2: Narrative

The destruction of the airlock in The Martian is a good example of a “narrative” approach – The Martian (film, 2015)

As mentioned in the Understanding Conflict section, the biggest problem with running this style of game seems to be narrative-level, so perhaps we can use a narrative-level solution. This method involves using some sort of narrative resolution system, like those found in PbtA or FitD games, to generate additional challenges and drama.
This solution has a few advantages. First, it operates on the same level as our problem, since it uses the language of narratives and storytelling to engender the danger and thrills. This means we can address the problem directly. Worried about having too few dramatic complications? Well, your player just rolled a Despair and three Threats, so some dramatic complication will definitely happen. In addition, this is easy to implement on a system level via non-binary or multi-dimensional resolution systems. If the implementation is part of the core task resolution system, you can extend it out to any arbitrary scenario without having to create specialized bespoke systems for each scenario.
However, this might move away from the actual act of solving those problems, in favor of using dice rolls and narrative cliches/techniques to determine whether or not more complications occur. The game doesn’t meaningfully recognize technical details (as those details would be too complicated to be explicitly mentioned in those resolution systems), and the game instead uses the technology to flavor narrative-level complications and boons. You can come up with a “perfect” plan, but it’s still possible to roll a miss, or all 1s, or only five Advantages. You might like this, but there are some players that would be unsatisfied with this solution.
Ultimately, this solution works well for those only interested in the narrative-level complications of “technical” sci-fi, the feeling of each solution revealing three more problems. The Genesys RPG and the two-paged Jovian Despair RPG are good examples of this method.

Method 3: Investigation

For people that run investigation-focused games like Delta Green or Night’s Black Agents, this might seem like an obvious solution. Meanwhile for everyone else, this might seem like an odd and unintuitive suggestion.
Essentially, Apollo 13 and The Martian are just a string of STEM-focused (Science, Technology, Engineering, and Mathematics) investigations, with the answers determining the possible courses of action. In real life, investigations are a good way to describe the troubleshooting and problem-solving of engineering and scientific work. Therefore, mapping and running a technical problem like an investigation (using techniques like the Three Clue Rule, Node-Based Design, Relationship Maps, and Progress Clocks) actually makes some sense.
If we want to take it as step further, we can also procedurally create these investigation challenges with technical schematics. Much like we can map out a mystery as a series of conclusions connected by clues, we can map a technical challenge as schematic of equipment nodes connected together (via power, intranet, thermal, or some other system). This makes the game about understanding those various nodes and how they connect to everything else, with players traversing the schematic in search of the “problem node” to “fix” it.
Unfortunately, this can be somewhat difficult to invent on your own. Most people aren’t electrical or astronautical engineers, and therefore are unable to read technical schematics of real-life equipment and facilities or produce their own plausible schematics. Most sci-fi RPGs provide deckplans for spaceships that could be converted into schematics to be investigated, but otherwise there is no existing example for this type of method. The closest this gets would be video games like Kerbal Space Program’s build phase (especially after your mission just failed) or Hardspace: Shipbreaker.

A Note on Scientific Accuracy

I have worked on space-bound equipment, so I know a thing or two (and only a thing or two) about space hardware. However, most of the people I play with don’t have a lot of knowledge and are aware they don’t. What I have learned through years of running hard sci-fi games is that this conscious scientific “ignorance” makes players feel uncomfortable and less daring in their adventures. My advice is two-fold:

1. First, meet your players halfway on the technical details. As long as they’re putting in the effort to think technically and scientifically, it’s fine to gloss over or affirmatively correct some minor inaccuracies in their plan.
2. Make the game more “interesting” where you can. Binary resolution systems (like those found in D&D and most “trad” RPGs) can be deployed more usefully in “technical” sci-fi than just “you succeed” and “you fail” via multiple fail states. If dice do need to hit the table, make sure all possible results are both “interesting” (in that they don’t completely terminate the conflict, i.e. avoid “oh you failed, so you died” and “great you succeeded, crisis completely averted”) and the stakes are clearly communicated to the players. This guarantees both intentionality on the side of the players (they know they’re taking a risk and what the risks are) and lets the game continue without an unceremonious end.

Coda

Ultimately, there are a few key takeaways:

1. “Technical” sci-fi is appealing for material “realism” in a fantastic setting and the fantasy of being an expert in a difficult situation,
2. Game masters need to be conscious and explicit with conflict in “technical” sci-fi games,
3. There are three methods of facilitating conflict in “technical” sci-fi: resource management, narrative conflicts, and investigations,
4. Game masters should go easy on players for any “scientific inaccuracies,” erring on the side of the players and focusing on their intention rather than their details.

If this sparked your own ideas on how to run “technical” science fiction, I’d love to hear them. This seems to be an under-explored sub-genre, and I want to make sure that prospective game masters have the ideas and tools they need to make this style of game work.