We are about to start a Star Trek campaign and I'd like some suggestions on avoiding the obvious plot pitfalls that exist in canon Star Trek. I want the players to think through the plot points and focus on interactions.

Here are some examples of things I want to avoid:

  1. Using the transporter to save the day, like restoring the characters back to their original pattern, or putting the bad-guy directly in jail (or in solid rock, etc)
  2. Allowing the tricorder or sensors to give away everything
  3. Asking the computer for the answer to the issue at hand (parodied beautifully in Galaxy Quest)
  4. The Chief Engineer/Scientist/Doctor suddenly thinks up (i.e. rolls up) a brilliant solution from thin air.
  5. The non-human crew member suddenly finds a previously unknown special ability (Spock was the worst offender in this) that renders the plot point meaningless
  6. Time travel in any form

4 Answers 4


You can't prevent many of these. They're a major part of the genre. Taking them in turn...

1 Using the Transporter to Save the Day

You need to clearly define your allowed limit on transporters. "Decanonize" certain episodes to prevent "repaterning" people. But, once those limits are set, further nerfing simply makes you a bad GM, and is not indicative of bad roleplay.

I run trek with a pre-pattern-buffer timeframe and a "No messing with the matter within" caveat. It's not that I won't have malfunctions happen - I simply won't let players replicate them.

2 Sensors

Set your limits clearly. The shows don't, but don't need to; Gaming does need them set. Pick them, stick to them, and accept that within those limits, you as GM need to suck it up.

3 Computers

Simply enough — restrict to yes/no/maybe answers, or "which of the given methods works best" type questions, and "how long" type questions. And accept that general reference data and probability matrices are areas where they should be using the computer, and they should get valid answers out.

Nerf the computer too much, you lose the trek feel.

4 Brilliance Out of the Blue

If it's a good idea, it's a good idea. It's best to let them run with it.

You may need to have the appropriate character be blamed for it within the context of the fiction — not every brilliant idea put forward by the Doctor's player is suitable for the Doctor to think of, but if it is an engineering solution, and the Engineer's player thinks its the solution, then simply have the two play out the discussion where the Doctor and the Engineer come up with it together.

But also, keep in mind that, in theory, most PC's in Starfleet should be amongst the top 1% intellectually (and those are the dumb ones, Starfleet's top 1% are the IQ 200+ crowd), and many have extensive cross training. So, the "shouldn't be thinking of that" bar is pretty hard to cross, anyway.

5 Special Racial Powers

Stick to what's been established. If they come up with novel uses for those powers, great. LET THEM No "new powers" just new uses.

And make certain to note these new uses for future reference.

6 Time Travel

Is usually imposed by the GM. Just simply state ahead of time that you don't allow it. If they try it, kill them. "...harmonic reality vibration shatters the warp core - KABOOM!!!"

  • 3
    \$\begingroup\$ +1. Also, I'd suggest to allow for creative ideas from players... and to build up from there. Maybe if they consistently use the transporter's buffers to "save/undo", they'll run into an increasing chance of messing with their own personalities ("soul" is a fuzzy thing) ;) \$\endgroup\$ Oct 12, 2012 at 22:40
  • 2
    \$\begingroup\$ thanks for the good reminder to me to keep in mind the players' creativity. I want the creativity, but not the lazy tropes rehashed. \$\endgroup\$
    – SteveED
    Oct 13, 2012 at 1:12
  • 6
    \$\begingroup\$ Well, to play devil's advocate, if you didn't want "lazy tropes rehashed" you wouldn't be playing in a rich established milieu like Star Trek. Play a generic SF game if you want to be free of setting/genre expectations - by leveraging Star Trek you are setting the expectation that there WILL be these things. \$\endgroup\$
    – mxyzplk
    Oct 15, 2012 at 13:37
  • \$\begingroup\$ o.k. I'll accept this with thanks and thanks to the commenters too \$\endgroup\$
    – SteveED
    Oct 17, 2012 at 1:59

In the canon Trekverse, all of those brilliant things have risks and consequences associated with them. You never see any of the main characters fail catastrophically, but they do take those risks. The "always successful" rule in the movies should not necessarily apply to your characters. They should risk terrible outcomes when they attempt such things.

Montgomery Scott may be smart and bold enough to push the ship to Warp 11 but is your player's character the legendary Scotty? Probably not. Then he runs a serious risk of damaging the warp core, and dropping out of warp in the middle of nowhere with only the impulse engines to limp to the nearest piece of rock in about 40-100 years, assuming a core breach doesn't destroy the ship first.

So I'd say, let them try such things, but make success difficult and the risks great. And if they are bold enough to try, have no mercy. They will be much more careful with their next batch of characters.


Inventing convenient excuses for why the tech doesn't work this time is a time-honoured Star Trek tradition

This question has been answered already, but I'd like to add that there are numerous instances in the various Star Trek series where the writers encountered this very issue. Here are some of the ways they solved it:

1. Using the transporter to save the day

The transporter frequently doesn't work. We're out of transporter range. We can't transport without lowering our shields / them lowering their shields. We can't get a transporter lock. We can't beam through the planet's unusually strong ionosphere. Ambassador Odan's people refuse to use transporters. The plasma fire is interfering with the transporters. And, quite commonly, there's too much interference, Captain!

And when they can use the transporter, there's often some limitation that makes the adventure non-trivial. We can't beam directly to the site without being spotted by the enemy / due to interference from the thing at the target site / due to high concentrations of magnesite ore in the surrounding hills / due to the target being too far underground, so we have to set down fifty kilometers away in the jungle.

Star Trek is also inconsistent as to what magic the transporters can do. They can restore Janeway and Paris after they were turned into amphibians in Threshold, but can't restore Neelix's lungs in Phage.

2. Allowing the tricorder or sensors to give away everything

Sensors suffer the same limitations that transporters do. Sensors cannot penetrate the planet's ionosphere. The Jem'Hadar ship came from the opposite side of the anomaly, so we couldn't detect it. The Romulans must be using a new kind of cloak, one we can't detect. We can't scan through this much solid rock; we'll have to send an away team.

Dax has to configure the tricorders to break the enemy encryption, so she can't use them as tricorders in the jungle. Sometimes the tricorders just give inconsistent readings or don't work. We need to get closer to the anomaly to scan it. The enemies took / disabled our weapons and transporters when we landed. There's too much interference.

Often, the sensors have arbitrary limits. They can find the missing away team / runabout, but it will take 8 hours to scan the entire planet's surface / sector where the ship was last seen.

3. Asking the computer for the answer to the issue at hand

COMPUTER: Searching. Darmok is the name of a seventh dynasty emperor on Kanda Four. A mytho-historical hunter on Shantil Three. A colony on Malindi Seven. A frozen dessert on Tazna Five. A....

TROI: Stop search. Computer, how many entries are there for Darmok?

COMPUTER: Forty seven.

The computer usually gives clues, but it never solves the puzzle right away. Star Trek's computer isn't intelligent or creative, it can only tell you exactly what you ask for. That's assuming you're on a fully equipped Galaxy-class starship, and not a runabout, on an away team, or a Cardassian station.

As the GM, you have to have adventures which cannot be solved by looking it up in the ship's computer. Starfleet sends ships to seek out new life and new civilizations, not look up information that's already known.

4. The Chief Engineer/Scientist/Doctor suddenly thinks up (i.e. rolls up) a brilliant solution from thin air.

That one tweet jokes how often they'd do this in TNG:

The Enterprise is flung into the Delta Quadrant by an alien called the Caretaker. Geordi soups up the warp core and they're home by dinner.

As often as this happens, however, there's an excuse for why that won't work. There'll be some complication or reason why it's not so simple. How about we do X? We can't, because Y. Unless we first did / found / destroyed / obtained Z, but that would require an entire action-packed adventure...

Often, the complications involved with actually implementing the doohicky form the focus of the episode, or it's in the background while the real conflict is about how they'll survive for six hours until the engineering department can get the doohicky online / the ship's sensors can locate the away team / Starfleet can send a rescue ship.

5. The non-human crew member suddenly finds a previously unknown special ability (Spock was the worst offender in this) that renders the plot point meaningless

Spock does this all the time, but it's considerably less common from TNG onward. Usually, it's about clever use of existing defined abilities, which is an excellent mode of play for an RPG (watch Jojo's Bizarre Adventure for a show which revolves around conflicts defined by creative use of existing abilities.)

Simply define that you cannot simply invent new character powers, and your players will generally understand this. It's a commonplace rule in RPGs.

6. Time travel in any form

Time travel is usually impossible without some doohickey which is generally both unavailable to the crew and expressly forbidden by Starfleet. When they get one, they usually lose it or give it up by the next episode.

In short

There's always an excuse for why the solution that worked in the last episode won't work this time, or at least it won't solve the problem readily enough to to bypass the entire scenario instantly.


What system are you using? I agree with @aramis that you should embrace these tropes of the game, they're what make Star Trek - trekky. The set of Star Trek games from Last Unicorn Games embraced them - there was a holodeck sourcebook, a time travel sourcebook... The corebook had a Random Technobabble Generator. It was a great example of embracing genre emulation.

Now if you want to not embrace genre emulation, and run a "realistic game in the Star Trek universe," you should probably be prepared for more or less trouble (if playing Old Series, most...). ST is very much not hard sci-fi so some degree of fast and loose will be required. Let things work once but not again (transporter saved the day last time... this time there's some BS reason it doesn't).

  • \$\begingroup\$ we are using the original FASA rules, with a little home-brewing. Our group works well with 'fast-and-loose' as long as the plot stays more or less logical and we don't get trapped in cannon arguments. \$\endgroup\$
    – SteveED
    Oct 13, 2012 at 15:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .