When I designed The Lost Hunt for Fantasy Flight Games, I launched the scenario by having an elven village attacked by a kehtal (a servitor of the demon gods of Keht). The idea was pretty simple: The PCs could then follow the trail of this murderous creature, which would lead them to the interdimensional rift in which the demon gods were imprisoned.
The tricky part was the actual tracking. Although I wasn’t thinking in terms of game structures back in 2001, I knew that this section of the adventure needed more weight to it than a simple skill check. The experience of the adventure couldn’t be, “Fight a monster, make a Wilderness Lore check, and – ta-da! – you’ve found the interdimensional prison of an ancient god cult!”
So what I ended up doing was crafting a custom game structure for tracking: Following the trail required five successful Wilderness Lore checks (DC 20). Each failure would force the PCs to backtrack (requiring an additional success in order to find the trail they lost). Each successful check would bring them to a “pit stop” along the trail, which was described in boxed text: One established the creature’s prodigious leaping ability; another brought them to another scene of carnage wrought by the creature; and so forth.
Nothing too complex here: I was basically adapting the concept of complex skill checks (as found in numerous RPG systems) and tweaking it a bit. But it did take a little bit of thought and a little bit of experimentation to nail down the details. Once I had tucked this custom “pit stop and backtrack” game structure into my mental toolkit, though, it proved useful time and time again: I’ve used it probably a dozen times since then.
This is, obviously, a very simple example of how you can create custom game structures to organize your prep and affect your players’ experience with the game world. In fact, it’s so straight-forward some of you are probably saying, “Duh.”
So let’s tackle something a little more complicated.
BETWEEN THE STARS
Campaign Concept: The PCs are the crew (and possibly owners) of a starship plying the interstellar trade routes. Although some planet-side activity might croup up, the focus of this campaign is going to be on the voyages of the ship itself.
Macro-Structure: For the macro-structure of the campaign, I’m going to use Traveller. As discussed in Part 10, Traveller has a well-developed system for handling interstellar travel and trade. This system empowers the PCs to make decisions about where they’re going; what they’re trading; and so forth.
Scenario Triggers: As we also discussed in Part 10, however, this game structure is incomplete. It has a closed resolution loop (go to starport, deliver goods, pick up goods, go to starport), but it lacks vertical integration. So the first thing we need to figure out is the trigger we’re going to use for transitioning from the trade-and-travel macrostructure to the scenarios that will probably fill most of our actual playing time.
I’m going to propose that, just like a dungeon has rooms and a wilderness has hexes, this campaign has voyages. In other words, just like we fill a room or a hex with content, we’re going to fill each trip from one star system to another with content. (Of course, some dungeon rooms are empty and some of our voyages may be uneventful. We’ll come back to that later.)
BETWEEN THE STARS – KEYING VOYAGES
We all know how to key a dungeon room or a hex: You write a number on the map and then you use that number to reference a description of the content of the room or hex. How do we key voyages? In other words, when the PCs leave a starport how do we know what this voyage will contain?
Linear Sequence: A simple solution would be a linear sequence. You prep a scenario for their first voyage (no matter where they’re headed); then you prep a scenario for their second voyage; and so forth. The obvious disadvantage of this approach is that it doesn’t include meaningful choice for the PCs.
Space Hexes: We could key each hex on the subsector map with content. Couple of problems, though: First, any given voyage will actually contain multiple hexes. Second, because the campaign isn’t exploratory in nature there will be a lot of hexes they’re unlikely to visit (since they’ll probably be sticking to direct routes between planets). We could, of course, limit our prep to hexes near established trade routes and then implement a system for randomly determining which hex’s content on the flightpath gets triggered for any particular voyage. But doing that actually suggests what might be an easier approach…
Routes: What if we just key each route with content? When the PCs take a particular trade route, we trigger whatever content we keyed to that route. A potential problem here would be PCs who settle down into servicing a regular route: Once they’ve used up the keyed content for the route, there’ll be nothing new to experience the next time they take it. We could mitigate this by randomly determining cargo destinations (so that the PCs would be less likely to settle into a regular pattern) or by keying multiple scenarios to a single route (this would increase the prep load, but make it harder to completely “burn out” a given route).
BETWEEN THE STARS – SPICING THE STRUCTURE
So our basic structure looks like this: We key each trade route with an encounter or scenario which is experienced when the PCs take the route. In addition, we randomize cargo destinations to discourage the PCs from wearing a groove into a particular trade route.
That, by itself, would give us enough structure to run a campaign: We could draw up the local subsector, map out the trade routes, key them, and start play. But what could we do to spice things up – adding flavor, complexity, and/or detail to the campaign?
Random Chance: Instead of a route’s encounter happening automatically when the route is taken, we could have a randomized scenario check. Since the players won’t know whether there will be complications on a particular voyage, this will make the campaign less predictable (and also possibly less frustrating). Setting the right probability of experiencing a route scenario will probably require some experimentation: Will the PCs end up taking multiple routes on most journeys (getting from planet A to planet C via planet B)? How interested are the players in the actual trade mechanics of the game (as opposed to using the trade mechanics as a mere method of delivering content)? And so forth.
For the sake of argument, let’s say that we want roughly a 1 in 3 chance of triggering a scenario. (A roll of 1-2 on 1d6.)
Scenario Sources: Now that we’ve randomized the occurrence of scenarios, we can use that same mechanic to include encounters from non-route-based sources.
First, we’re going to seed our cargo and passenger tables with scenario triggers. For example, carrying a shipment of positronic brains makes it more likely to be targeted by rogue robotic hijackers. Or a particular passenger might be targeted for assassination.
Second, our scenario check (which is performed once per route) is now revised: On a roll of 1 we trigger a route scenario; on a roll of 2-3 we trigger a passenger scenario; on a roll of 4-5 we trigger a cargo scenario. A roll of 6 indicates no encounter.
Scenarios are theoretically being triggered on rolls of 1-5 on 1d6, but our practical odds of experiencing a scenario on any given route will remain roughly 1 in 3 because the PCs may not be carrying cargo or passengers with scenario triggers.
Weighted Route Tables: Instead of just keying a unique encounter (or a set of unique encounters) to each route, we could instead key each route with a weighted scenario table: So in the Black Expanse you’re more likely to get hit by pirates, while in the Inner Systems you’re more likely to get hit with a random audit.
(Alternatively, we could rebuild our scenario check and include “region scenarios” as a fourth type: So each route would be keyed with a unique scenario; each region would have a random scenario table; and we’d also have cargo/passenger scenarios.)
“Empty” Voyages: As noted above, we’ve now created “empty” voyages (i.e., voyages on which no scenarios will be triggered). In order to spice these up, I’m going to take a page from Ars Magica, combine it with the character creation rules for Traveller, and create a game structure for handling “down time”: Improving your skills. Improving your ship. Working on research projects. And so forth.
Dockside Encounters: Another possibility would be adding structures for dockside encounters and/or scenarios. But I’m actually going to deliberately eschew this sort of thing: I want this campaign to be focused on the ship.
While it’s certainly possible that the players will get tangled up in some planet-side intrigue, by specifically excluding this content from the campaign structure I’ll be steering the focus of the game away from it: Docking will generally be the boring bit that bridges the gap between the exciting stuff.