How to Solve Problems the Star Trek Way

A few times when Star Trek Adventures has come up, I have heard some concern that people may not know the ins and outs of Star Trek technology well enough to know what they can and can’t attempt. I wanted to post this because fixing problems in Star Trek is more about knowing tropes used in the show than knowing specific technology.

Star Trek Adventures itself has several structures for solving problems as either single skill checks or as an extended task, meaning the actual way to resolve just about any problem is to identify the problem, state what the PCs want to accomplish, and have the GM determining a difficulty. Star Trek is all about coming up with solutions in the moment, and it contradicts itself all the time when it comes to “this X can’t do Y.”

Mainly what this means is that for short term problems, characters are usually making something do a task that a system is not normally expected to accomplish. Modifying the phasers, probes, torpedos, shields, or warp fields are all common things to modify, but there isn’t an “absolute” for what kinds of problems these can or can’t accomplish . . . it’s more what “feels right” for the situation.

What usually happens in a more extended task if for one person to state “I’m going to make [thing] to fix [problem]. Then someone else usually says [thing] will have to compensate for [made up speed bump],” which explains why this is a multi-step process.

What I love about Star Trek Adventures is that having the structure for resolving short or long term problems means you don’t have as many absolutes. You have a process that you work through, that might generate successes and new twists and turns in the pursuit of solving the problem.

Usually, in a long term resolution of a problem, there is a B plot that is going on that is complicating the work on the long term project. If you are trying to prove that species A hasn’t caused a problem that has hindered species B. The B plot will be someone from the crew trying to keep A and B from going to war, and maybe dealing with the real culprit, while the other PCs are learning the real answer.

In addition to all of this, I can’t recommend enough the Operations Division sourcebook, which has a randomly table with multiple columns of “Star Trek” technobabble that someone can throw together to add “proper nouns” to the process that people are using to solve the problem.


This is a pretty interesting observation on structure. In a way it’s kind of an inverted McGuffin. Making X and then making X compensate for Y has a cost Z - you need the right materials, you need time, you need to be in the right place, etc. Basically the players come up with the X and Y part (maybe) and as the GM you get to make the shit hard for them by coming up with the Z. In a lot of Star Trek episodes the solution isn’t the hard part, right? It’s figuring out the solution to begin with, and then it’s not getting blasted (or whatever) while you apply the solution. Maybe you have to keep the aliens from figuring out what you are doing, or steal the parts, or evade the fleet of Klingons. In any case it’s a really different way of thinking about adventure building from the treasure is over there in the dungeon, go get it.