There are roleplaying games in which the Game Master can prepare a dungeon, populate its rooms, establish the opposition, anticipate several likely routes through the adventure, and arrive at the table reasonably confident that somewhere within those preparations lies most of what the players are going to encounter. There are other games in which preparation remains important, but the players possess enough freedom that the person running the game must be prepared to improvise when they inevitably wander beyond whatever boundaries were imagined beforehand.
Then there is Star Trek Adventures.
After spending considerable time running it, I have come to believe that one of the most interesting things about the game is also one of the things that made it surprisingly difficult for me to learn: when it is working properly, Star Trek Adventures moves. It can move astonishingly quickly, not necessarily in terms of combat rounds or dice rolls, but in terms of ideas. A conversation on the bridge becomes a sensor investigation, which becomes a scientific mystery, which becomes first contact, which becomes a diplomatic problem, which suddenly becomes an engineering emergency because one of the players has just suggested doing something that never occurred to me when I prepared the adventure.
And now everyone at the table is looking at me.
What happens next?
That, I have discovered, is where Star Trek Adventures really lives.
I did not learn that immediately. In fact, it probably took me a good six months before I felt that I genuinely understood how to run the game, and that was after spending roughly three months on the other side of the screen as a player in another GM's campaign. Those months playing were important because they allowed me to experience the rhythm of the system without simultaneously worrying about every NPC, every rule, every complication, and every narrative possibility. I could watch what another Game Master did, see how scenes flowed into one another, and begin to understand how the machinery underneath the game supported the fiction.
Even with that experience, however, running it was another matter entirely.
I have been running roleplaying games for a very long time, and one lesson that experience repeatedly teaches is that familiarity with one game does not automatically translate into mastery of another. There are certainly universal skills involved in being a Game Master—pacing, description, characterization, improvisation, understanding one's players—but every good roleplaying system has its own rhythm. If you try to force it into the rhythm of another game simply because that is what you already know, you can technically run it while completely missing what makes it special.
With Star Trek Adventures, I eventually realized that I had to stop thinking so much about adventures as sequences of events and start thinking about them as situations possessing momentum.
That distinction changed everything.
I can prepare the mystery. I can know what happened before the Enterprise—or, in my own campaign, the USS Azimuth—arrived. I can know what the alien civilization wants, what the Romulans are attempting to conceal, why a Federation ship disappeared, or what terrible mistake an archaeological expedition made before the opening scene. I can understand the motivations of the important NPCs and establish what will happen if Starfleet does absolutely nothing.
What I cannot reliably know is how the crew will respond.
Nor should I.
That is Star Trek.
The Captain Says, "Open a Channel"
Consider something as simple as encountering an unknown vessel.
In another science-fiction game, I might reasonably expect the players to begin discussing weapons, armor, relative velocity, firing solutions, and tactical positioning. Those things certainly exist in Star Trek Adventures, and combat can become very important, but Starfleet officers possess an enormous range of alternatives before anyone fires a phaser.
The captain might open a channel.
The science officer might perform a detailed sensor sweep.
The communications officer might notice something peculiar hidden inside the transmission.
The engineer might determine that the other vessel's apparently hostile behavior is actually the result of a failing propulsion system.
The medical officer might realize that something detected aboard the ship suggests an epidemic.
The tactical officer might recognize that the vessel's movements are inconsistent with an attack.
Then one player asks a question that changes everything:
"Can we modify the sensors to separate the two signals?"
That question may not exist anywhere in my notes.
It exists now.
The entire adventure can pivot around it.
As Game Master, I have perhaps thirty seconds to decide whether the idea is plausible, what combination of Attribute and Discipline seems appropriate, how difficult the Task should be, what information success reveals, what Complications might mean, and—most importantly—whether this wonderful idea has just exposed a possibility in the story that I hadn't considered myself.
Sometimes the answer is yes.
Those are often the best moments of the game.
Starfleet Officers Are Extremely Capable People
One reason Star Trek Adventures demands so much flexibility from the GM is that the player characters are not wandering adventurers waiting for someone to hand them a quest.
They are Starfleet officers.
They have a starship.
They have laboratories.
They have sensors.
They have transporters.
They have a sickbay staffed by highly trained professionals. They have engineers capable of solving extraordinary technical problems. They have computers containing enormous quantities of information. They can consult specialists elsewhere aboard the ship, call senior officers into a briefing, launch shuttlecraft, modify equipment, analyze strange particles, perform orbital surveys, and contact other civilizations.
And, perhaps most dangerously for a Game Master's carefully prepared plot, they can talk to one another.
A table full of intelligent players discussing a mystery from the perspectives of command, science, engineering, medicine, security, navigation, and diplomacy is an extraordinarily effective problem-solving machine.
They will think of things I didn't.
I've learned to hope that they do.
My job is not to defend my solution from them.
My job is to determine what happens when their solution meets the universe.
That realization was probably one of the major milestones in learning to run the system.
The Rules Eventually Become Invisible
During my first months with the game, I was understandably conscious of the mechanics. Which Attribute applies? Which Discipline? What is the Difficulty? How does Momentum work here? Should this create Threat? Is this an Extended Task? What Trait is currently affecting the situation?
Those questions matter, particularly while learning the system, but concentrating too heavily on them can make a Star Trek story feel strangely mechanical.
Eventually something clicked.
I stopped beginning with the rules.
I began with the fiction.
What is happening?
What is the officer trying to accomplish?
What makes it difficult?
What would success actually mean?
Only then do I reach for the mechanics necessary to resolve the uncertainty.
The 2d20 system works remarkably well when approached this way because so much of it can be interpreted through the circumstances of the story. Traits, Advantages, Complications, Momentum and Threat provide a vocabulary for turning fictional developments into mechanical consequences without requiring the fiction to stop while everyone consults a completely separate tactical reality.
Once I became comfortable enough with that vocabulary, the game became much faster.
More importantly, it became much more like Star Trek.
I Prepare Problems, Not Answers
This has changed the way I prepare episodes.
I still prepare extensively. I enjoy preparation far too much ever to become one of those Game Masters who arrives with three sentences scribbled on an index card and trusts entirely to improvisation. I want to know the history behind the episode. I want to understand the location, the antagonists, the mystery, the scientific problem, and the people involved.
But I increasingly resist preparing the solution.
If an ancient installation is producing a dangerous phenomenon, I need to understand what the installation is doing and why. I do not necessarily need to decide that the players must reach Engineering Room B, recover the control crystal, decipher three inscriptions, and shut down the reactor.
Perhaps they will.
Perhaps the chief engineer will propose reversing something through the deflector dish, in the finest Star Trek tradition.
Perhaps the science officer will realize the phenomenon can be neutralized rather than stopped.
Perhaps the captain will discover that the apparently abandoned installation is not abandoned at all and decide that shutting it down would constitute an act of aggression.
Perhaps someone will ask a question that transforms my understanding of the situation.
When that happens, the prepared background doesn't become useless. Quite the opposite. Because I know why the situation exists, I can extrapolate what happens when the players interfere with it in ways I never anticipated.
Preparation gives improvisation something solid to stand upon.
That may sound contradictory, but I think it is one of the central skills of Game Mastering. The more deeply I understand a situation, the less I need to predict what the players will do.
Keeping Up with the Crew
There are sessions when running Star Trek Adventures feels almost like trying to keep pace with the bridge crew while they are operating at full speed.
"Sensor sweep."
"What do we detect?"
"Can I analyze that?"
"Does the computer have any record of this phenomenon?"
"Can Engineering compensate?"
"I want to hail them."
"Can we beam through the interference?"
"What happens if we reverse polarity?"
"Captain, I think they're trying to communicate."
And all of this can happen in minutes.
The GM is moving between physics, characterization, Starfleet procedure, game mechanics, established Star Trek lore, the prepared episode, and whatever completely unexpected direction the players have just discovered.
I find it exhilarating.
It is also exhausting.
When the game is really working, though, there comes a moment when I stop feeling like the person presenting an adventure and start feeling as though I am watching an episode of Star Trek emerge spontaneously around the table.
Nobody wrote this episode.
Not completely.
I established the situation. The players brought their characters. The rules provided uncertainty. Then all of us discovered the story together.
Writing the Star Trek Stories I Dreamed About
There is another reason running this particular game means something to me.
I loved Star Trek long before I understood how stories were constructed. As a kid, I could watch those ships disappear into the stars and imagine that somewhere beyond the television screen there must be thousands of other stories that simply hadn't been filmed yet. I wanted to tell some of them, although at that age I didn't really understand how someone went about doing such a thing.
Much later in life I even reached out toward that professional world, including a very brief conversation with Rick Berman during the era of Enterprise. Nothing came of it, but the desire to tell Star Trek stories never really disappeared.
Now I get to do it every time we play.
There is no television production budget. I don't have to worry about whether the alien planet set is available this week or whether the episode can afford another visual-effects sequence. If I want a shattered planet surrounded by the remains of an ancient civilization, it exists. If the Azimuth needs to encounter something no Federation scientist has ever seen, then somewhere beyond the next star it is waiting.
The only real budget is imagination.
And my players have an unlimited line of credit.
Six Months to Understand Something Simple
After roughly three months playing the game and another six months learning to run it, I eventually arrived at a principle that sounds embarrassingly simple:
Don't try to control Star Trek.
Set it in motion.
Understand the situation well enough that it can react honestly to whatever the players attempt. Know the people involved. Know what they want. Know the scientific mystery well enough that reasonable questions produce reasonable answers. Understand the starship and the crew. Know enough about the rules that they support the moment rather than interrupting it.
Then listen.
Players will tell you what they find interesting by what they investigate.
They will tell you what they care about by whom they try to save.
They will tell you what kind of Starfleet officers they have become by the decisions they make when phasers would be easier than diplomacy.
And occasionally they will invent a solution so wonderfully Star Trek that the only appropriate response from behind the Game Master's screen is to smile, consider the consequences for a moment, and say:
"All right. How are you going to do that?"
Perhaps that is why it took me months to really learn how to run Star Trek Adventures. I was learning the rules, certainly, but I was also learning when to get out of their way. I was learning that preparation does not mean predicting the story, that improvisation does not mean being unprepared, and that giving players freedom does not mean surrendering structure.
It means knowing your universe well enough to let people explore it.
After all these years of Game Mastering, there aren't many things more satisfying than realizing that the players have just taken an episode somewhere I never expected it to go—and discovering that I can still keep up with them.
Most of the time, anyway.
And when I can't?
Well, Captain, that's why we have commercial breaks.

