I’ve recently been playing through Deus Ex: Human Revolution. I’ve been enjoying it so much that I’m virtually certain that there’ll be a replay of the original Deus Ex in my near future.

One of the really great features in both titles is your ability to hack dozens or hundreds of computer terminals throughout the game, revealing data – from the variety of electronic communications you eavesdrop upon – that can provide you with valuable operational intel, deeper insight into the conspiracy, and access to unique resources.

This kind of “information in depth” works wonders in terms of immersing you into the game world; it’s also a lot of fun. But replicating this kind of experience in a tabletop RPG is really difficult: Even if you don’t go so far as to prep individual handouts for every e-mail and chat log the PCs uncover, it would still require an almost insane amount of prep work in order to customize the contents of the dozens of computer terminals in a typical complex.

To solve this problem, I’ve thrown together a simple-to-prep game structure for tactical hacking. This system assumes a couple of things are generally true: First, the hacker is opportunistically targeting systems to compromise. Second, the primary goal of the hacker is to accrue information. (The structure includes some minimal support for other hacking strategies, but they’re not the primary focus of the structure.)

For the sake of simplicity, I’m going to assume a D20-style system with a single Hacking skill. But it should be fairly easy to modify these guidelines for any RPG with discrete action checks.

NETWORKS

Each network is defined by a Network Intel Table (NIT). Each entry on the NIT is a discrete piece of information with an associated difficulty class. (In practice, it looks very similar to a Gather Information table.)

Note that the term “network” is not necessarily being used in a literal sense, but rather as a convenient way of referring to multiple systems or accounts that are somehow meaningfully related to each other. (For example, the home computer of Sansasoft’s district manager may not be directly wired into the corporate infranet, but the e-mails on her computer could easily contain compromising information, so for the purposes of this system it would be considered part of the “Sansasoft Network”.)

TERMINALS

Terminals refer to any computer, cellphone, access point, or user account that the PCs can attempt to hack. Each terminal is rated with an access cap, an intel value, and a security modifier. Some terminals may also have special features.

Access Cap: The maximum DC that can be achieved on a Hacking check using that terminal. If a higher result is rolled, the excess is ignored. (For example, a hacker named Panda is using a terminal with an access cap of 15. Rolling her Hacking skill, she gets a result of 22. Despite that, the result of her check is treated as a 15.)

Intel Value: The intel value of the terminal determines the maximum number of entries that can be gleaned from the Network Intel Table.  (For example, Panda’s DC 15 result on her Hacking check is high enough to theoretically access the first six pieces of information on the Network Intel Table. But if the system she’s using only has an intel value of 2, she’ll be limited to two pieces of information.)

Security Modifier: Modifies the skill check made to hack the system. For example, a cellphone with a -4 security modifier applies a -4 penalty to a hacker’s skill check.

TERMINAL SPECIAL FEATURES

These special features (and any others you can imagine) can be added to any terminal. In fact, a single terminal might have several special features.

Communications Control: The terminal allows monitoring and/or control of local communication channels.

Data Tunnel: A data tunnel connects one terminal to another terminal. Each data tunnel is rated with a DC. With a successful Hacking check, a hacker can use the data tunnel to access the remote terminal. Some data tunnels might also grant bonuses when attempting to hack the remote terminal they link to.

High-Value Content: A high-value system grants a bonus to the hacker’s highest result on the Network Intel Table to date. (The more valuable the system, the higher the bonus.)

Specific Content: Although the point of this tactical hacking system is generally to avoid coding specific information to specific systems, in some circumstances it may still be valuable to do so. Specific content could also refer to security maps, data network maps, or other mission-valuable intel.

Systems Control: The terminal can be used to control surveillance cameras, robots, gun turrets, environmental controls, navigation systems, or any number of other “real world” systems.

PREP LIST

For the purposes of tactical hacking, think of each “network” as a body of related information. Each terminal on the network is a system or account which either houses part of that body of information or has access to it. It is assumed that there are a multitude of ways to discover each piece of information in the network. (For example, a hacker could discover Sansasoft’s illegal digital smuggling by reading compromising e-mails; performing forensic examinations on black book budgets; decrypting incriminating communication intercepts; discovering off-book shipping manifests; or any number of other possibilities.) If a piece of information can really only be discovered in a specific way, then that’s specific content that should be keyed as a special feature to a particular terminal.

When prepping a network for tactical hacking, you first need to prep the Network Intel Table. Here’s a sample:

(I’ve included a potential explanation for how the hacker could access each piece of information. You could expand on that by creating full handouts for each piece of information; or you could skip that and just improvise the details during play.)

Second, you need to prep a list of the terminals on the network. (Such a list could also easily be integrated into a location key or other reference as appropriate.) For example, you might stat up the customer service terminals at Sansasoft like this:

CS Terminals (access cap 15, intel value 1, security modifier +0): There is a 1 in 10 chance that any given customer service terminal will instead have no access cap (due to an unusually compromising internal e-mail). Otherwise, hackers can gain no more than 3 pieces of intel in total from all customer service terminals.

RUNNING THE SYSTEM

When a PC wants to hack a terminal, follow these steps:

(1)   The character makes a Hacking check.

(2)   Modify the check by the terminal’s security modifier.

(3)   Check to see if the terminal’s access cap applies and reduce the effective check result if necessary.

(4)   Use the character’s effective check result to determine the number of previously unrevealed pieces of information they can discover. If this number is larger than the terminal’s intel value, randomly determine which pieces of intel they receive.

Alternatively, you could randomly determine between all possible pieces of intel (which could result in them learning nothing new due to duplication from previous efforts).

Go to Part 2: Tools for Tactical Hacking

Go to Part 1

As a final rumination on the subject of game structures, I want to discuss player-known and player-unknown game structures and the differences between the two in actual play.

Let me demonstrate what I’m talking about by way of example.

THE UNKNOWN HEX

In the earliest hexcrawling structures, the players were supposed to be aware of the hexes. Volume 3: The Underworld & Wilderness Adventures for OD&D, for example, reads, “When players venture into this area they should have a blank hexagon map, and as they move over each hex the referee will inform them as to what kind of terrain is in that hex.”

In designing the structure I use for hexcrawling, on the other hand, I specifically eschewed this approach: Although I found the abstraction of the hex map useful in many ways, I didn’t want the players to directly interface with that abstraction. Instead, I wanted them to interact with the game world.

So while I used the abstraction of the hex map for its convenience in mapping and keying, my players had to figure out how to navigate the world purely from the view point of their characters.

The original version of hexcrawling is a player-known game structure: They can see, understand, and even manipulate the game structure that you’re using to represent the game world. Most combat systems are another excellent example of player-known game structures.

My version of hexcrawling is a player-unknown game structure: They perceive only the game world and don’t know exactly what structures you’re using to prep and run that world. Another common example of a player-unknown game structure are random encounters: Did they run into goblins in that hallway because the encounter was keyed there or because the GM rolled a random encounter?

USING PLAYER-UNKNOWN STRUCTURES

My decision to obfuscate my hexcrawling procedures is not unusual for me. As a GM, I’m generally trying to find simple methods of organizing my prep work so that it can be easily and efficiently referenced and used during play. But I don’t necessarily want my players to see the structure that I use: I want them to see the messy, chaotic world that their characters live in.

The method I refer to a “The Second Track” in Advanced Node-Based Design is an example of this: I organize two distinct and easy-to-manage groups of nodes, but then I mix them together in play to create a more complex reality.

I discussed another example as “Minor Elevation Shifts” as part of the Xandering Techniques: “When the PCs come to a staircase they may naturally assume that they are going up or down to a new level of the dungeon. But by including minor elevation shifts within the topography of a single dungeon level you can confound their expectations … These techniques aren’t just a matter of confusing the players’ mapping. You are disrupting their ability to intuit the organization of your maps by analyzing the reality of the game world. While maintaining clean and simple maps for your own use and reference, you are creating a world that not only seems more dynamic and complex, but actually is more dynamic and complex.”

More generally, if the players don’t know the structure you’re using then they can’t engage the structure: Instead, they have to propose actions in-character.

See if you can imagine for a moment what combat would be like if the players had no idea what the underlying structure of the game was. I don’t just mean a scenario in which the GM is keeping their hit point totals secret from them: I mean that the players don’t know what rounds are; they don’t know what attack rolls are; they don’t know what hit points are. What effect would that have on how combat is experienced at the game table?

On a similar note, running a new game structure in a player-unknown configuration can be a great method for diagnosing inadequacies, shortcomings, and dissociations in the structure. If you come to your players and say, “Here’s a system for Gee-Whizzing and it has rules for A, B, and C.” Then your players may focus exclusively on the options that have been presented to them.

But if you just come to your players and say, “Let’s do some Gee-Whizzing.” Then your players will be free to propose any action that occurs to them: If they stick to A, B, and C then you’ve done your job well. If they’re proposing D, E, F, and G then you’ve got some holes to fill.

Similarly, if you find that your structure keeps expecting the players to make decisions that they aren’t making (or that they can’t make without being aware of the structure), then that’s a huge tip-off that your structure is dissociated.

USING PLAYER-KNOWN STRUCTURES

This is not to say, however, that player-unknown structures are the be-all and end-all of gaming. On the other end of the spectrum, player-known structures are specifically useful because they allow players to make decisions informed by the game structures in play.

In my hexcrawling structure, for example, players must select their mode of travel: Normal, Hustling, Cautious, or Exploring.

(Normal movement has no modifiers. Hustling increases navigation DCs. Cautious movement is made at ¾ normal speed, navigation DCs are decreased, and the chance for non-exploratory encounters is halved. Finally, while exploring, characters move at ½ normal speed and the chance for encounters is doubled.)

For roughly a dozen sessions or so, I kept this structure hidden from the players: Instead, I applied the appropriate mode of travel based on the actions they proposed. (For example, if they said that they were going to start moving carefully through the woods in order to avoid encountering any of the orc warbands they knew were looking for them, then I would slot them into the “cautious” mode of travel.)

Eventually, however, I concluded that it made more sense to make this a player-known structure: First, because the players were assuming – in the absence of additional information – that these types of decisions were irrelevant in the game structure I was using. (And because of this false intuition of the game structure, they stopped feeding me the cues I was using to assign modes of travel.) Second, because choosing a mode of travel had a significant impact on the efficacy of navigation in the system. (Hiding this structure from them actually made them less competent than their characters.)

You can see a similar principle in the familiar debate of whether or not GMs should tell their players the target number for an action check.  (My opinion is that you should only obfuscate the target number if that obfuscation mirrors a lack of information on the part of the character. Otherwise, providing the DC is the quickest way to overcome the vast difference in bandwidth between the character’s perception of the world around them and the player’s perception of that world. For example, a character standing in front of a chasm can actually see the chasm. The player, on the other hand, is completely dependent on a very narrow band of audio communication from the GM.)

But I digress.

As a final point of consideration in player-known structures, consider the Point of First Contact in that structure. As described in an essay at D-Constructions:

For better or for worse, most RPGs have freeform moments and structured moments, and it’s a really good idea to think about how the latter start. […]

The first die does get a lot of focus in play because it’s the break moment. It’s the moment you start concentrating and reach for your first contact with the rules. So it pops up in your mind and yells “THIS IS IMPORTANT”. To an extent, therefore, it doesn’t matter what your CORE mechanic is because your first gets more attention. […]

It’s worthwhile, therefore, to make sure your first contact IS important to the kind of game you want to run. In Smallville your first die is your value – what you believe in, why you care about this struggle at all. In Marvel it’s what kind of team you’re in – are you the kind of person who performs better in a team, with a buddy, or solo. Right way we have something central to Marvel’s enduring dynamic.

What’s your first point of contact? In every sense?

IN CONCLUSION

This has been a very long series of essays. It’s touched on a lot of different subjects (which is perhaps unsurprising, given that the topic is one that lies at the heart of virtually every moment at your gaming table). But if you gain absolutely nothing else from it, I hope you can take away two important points:

First, I think a lot of the linear, railroaded scenarios that we see in roleplaying games are the result of GMs who have a limited (or nonexistent) toolset. Often I think GMs don’t even realize that these types of tools exist. But they do exist and there’s nothing complex or mysterious about them. Once you know they exist, they’re not even particularly difficult to master.

Second, if you’re a GM, I think you’ll benefit greatly from consciously thinking about the game structures you’re using: Innovate. Experiment. Create. Share. Playtest.

One of the most exciting thing about the Old School Renaissance for me has been its role in rediscovering highly effective game structures that had largely been forgotten by the mainstream gaming community. Over the past few years, we’ve seen how much fresh creativity and original gameplay can be generated out of tapping a robust game structure like hexcrawling that has lain dormant for years.

But I think that’s barely scratching the surface. If we can get stuff like Carcosa and Points of Light and Kingmaker out of hexcrawling, what else have we been missing out on?

Game structures are merely ornately-wrought keys. The really interesting stuff is what lies beyond the doors those keys will unlock.

FURTHER READING
Hexcrawls
Thinking About Urbancrawls
Gamemastery 101
Game Structures – Addendum: Katanas & Trenchcoats

Go to Part 1

The first RPGs had unique game structures for just about everything. In the original edition of D&D, for example, evading monsters in the dungeon had one mechanical structure and the process for evading monsters in the wilderness had a completely different structure. The earliest designers, when confronted with the need to resolve the outcome of a new situation, would simply create entirely new mechanics and new paradigms to handle it.

This didn’t last long: Systems that had worked well in the past got repurposed. Similar systems had their redundancies conflated away. Even more importantly, GMs looking to adjudicate unanticipated actions were quick to develop consistent methodologies. (“When you wanted to do X, we did Y. Now you want to do something that’s kind of like X, so we’ll use Y again.”) And this very rapidly evolved into the first universal, generic mechanic: Rolling either 3d6 or 1d20 and comparing it to the character’s ability score.

Shortly thereafter, the idea of modifying these rolls using character skills appeared. These modifications mutated rapidly and then generally settled into the system of “ability score + skill modifier” that has basically dominated RPG mechanics for the past three decades.

The advantage of having a generic, universal mechanic is that it provides the GM with a robust tool for making rulings at the table. With a properly comprehensive skill list, for example, making a ruling for the resolution of any discrete action is simply a matter of selecting the appropriate skill.

(By contrast, the process of making a ruling in many early RPGs often involved first inventing the tools. It wasn’t unusual to literally invent entire dice mechanics from scratch. It’s unsurprising that GMs in these systems almost reflexively create universal mechanics as quickly as possible.)

This is obviously good for the GM (for the same reason that carpenters like to have a toolbox instead of needing to reinvent the hammer for every new project), but it’s also good for the players: It creates a flexible environment in which any discrete action can be attempted within the structure of the game mechanics. This means that any action can be proposed without bogging the session down; it also means that there is no structural bias for or against any type of action. (There may still be a mechanical bias, of course, if certain actions are easier than alternatives, but that’s a separate issue.)

(When I say “structural bias” I’m referring to the fact that gameplay generally gravitates towards existing game structures. I’ve talked about this a couple times previously: If there’s a system for prospecting gems, for example, players are more likely to go prospecting. If a game includes a robust system for resolving riddle contests but has no mechanics for resolving combat, it’s likely that the game will see a lot more riddling with words than it will riddling with bullets.)

GENERIC SCENARIO STRUCTURES

If a generic, universal action resolution mechanic is useful, it’s not hard to see how much more useful a generic, universal scenario structure would be. With a tool like that, GMs could seamlessly transition their campaigns to be virtually anything and it would all be as robust, entertaining, and rewarding as a dungeoncrawl or a combat encounter.

Unsurprisingly, therefore, the history of the industry is studded with efforts to expand the generic, universal mechanic to include larger structures at both micro- and macro-levels. Many of these efforts have historically been little more than crude guidelines, often fumbling in the dark towards an objective that has been poorly understood. Others, however, have attempted to create more comprehensive and defined structures.

In recent years, the best-known example of this sort of thing has almost certainly been D&D 4^th Edition’s skill challenges.

And, unfortunately, skill challenges show all the characteristic failures typical of these systems: Dissociated mechanics (including emergent dissociated properties). A systemic blandness that often results in fundamental gameplay which is “not fun”. A prevention of meaningful choices by the players (or an outright forbiddance of such choices). And so forth.

In Part 11 I listed six properties of effective game structures:

1. They should be flexible (allowing players to make decisions not constrained by the structure).
2. They should have a capacity for meaningful decisions.
3. They should allow players to make decisions which are associated and in-character.
4. The default actions of the structure should be tied to the reward structures of the game.
5. They should be fun.
6. They should be easy to prep.

And while skill challenges satisfy some of these criteria (more or less depending on exactly which version of the skill challenge rules you’re actually using), they obviously fail to fulfill most of them (and arguably the most important ones).

Most of these problems seem to crop up due to the lack of specificity inherent in a generic structure. For example, while it’s possible to break almost any activity down into an abstract “action” which can be resolved with a generic skill check, the procedural and structural differences between, for example, negotiating a peace treaty, safely traversing a haunted forest, or prospecting for gems seem to defy a generic approach. And when such a generic approach is attempted, the result usually dissociates itself as the mechanical decisions divorce themselves from the decisions being made by the characters in those unique situations.

On the other hand, while Eurogames prove that abstract mechanical representations can still provide fundamentally fun gameplay, efforts to solve the dissociative problems with generic scenario structures tend to emphasize flat, bland mechanics that strive to be as “vanilla” as possible. And that results in gameplay which is mechanically boring.

Historically, this appears to be an insoluble balancing act: The more “interest” you add to the mechanics, the more specific they become and the stronger they dissociate from the game world. The more generic you make the mechanics, the blander and more boring they become. (Nor does there seem much success in solving fully for one or the other: Making the mechanics less specific seems to solve some problems of dissociation, but simultaneously introduces others.)

THE HOLY GRAIL

This would be an appropriate time for me to announce a dramatic cutting of this Gordian knot, unveiling an incredible generic scenario structure that would revolutionize your gaming table.

Sadly, however, this is not to be.

A truly successful, fun, and effective generic scenario structure would be the holy grail of roleplaying games. But, much like the holy grail, it may also be an unattainable prize.

On the other hand, at this time last year, I would have said that even generic structures at a level of complexity comparable to combat (i.e., generic structures for resolving conflicts in multiple steps) had largely failed. But as I recently discussed, Technoir has achieved a remarkable success in accomplishing exactly that (albeit in a form which I haven’t figured out how to reverse engineer successfully into other RPGs yet).

So there may be some breakthroughs lurking out there; just waiting for the right time and the right circumstances to emerge. Unfortunately, I won’t be the one to bring them into the limelight. (At least not today.)

I suspect that at least part of the problem with achieving these breakthroughs, however, is that our current range of robust, fully-developed scenario structures is so dreadfully limited in its scope and variety: If all you’ve seen is an apple and a couple of pears, it would be difficult to reverse engineer what the generic definition of “fruit” should be.

Personally, I think it would be great if we started seeing more unique, fully-developed scenario structures in the hobby and industry. It’s something that’s been consuming more and more of my own time (as this series of essays might suggest), and I think that broad experimentation in this area will begin to open up possibilities for dynamic gameplay that we can’t even really begin to imagine today. (Particularly as these robust scenario structures are mastered and recombined.)

Go to Part 16: Player-Known and Unknown Scenario Structures

This was originally posted as a response to a comment by Pasquale, but I thought it might interest a larger audience.

Transhuman Space has earned a reputation as a rich and magnificent setting… which is also almost completely impenetrable to players and incredibly difficult for GMs to run. Pasquale asks whether or nor the Between the Stars campaign structure could be used to crack open Transhuman Space.

The primary problem with Transhuman Space is that the complexity, depth, and density of the setting requires a heavy upfront investment from the players.

To give a basis of comparison:

My open table OD&D campaign relies almost entirely on common knowledge. If a player knows what an elf, dwarf, halfling, and wizard are, I can provide a functional basis for understanding the game world in about 60 seconds.

My dedicated 3.5 campaigns set in the Western Lands are a bit more involved: I have an 8 page handout (half of which consists of practical lists like “gods you can choose”, “languages you can choose”, etc.). It probably requires about 5-10 minutes from the players, with another 30 minutes or so dedicated to character creation.

Transhuman Space, on the other hand, doesn’t have a lingua franca of common genre tropes to fall back on. It is a very specific, very complex, and very deep setting. In order for most characters to function coherently in such a setting, the players need to have a specific, complex, and deep understanding of the setting.

Basically, a setting like that often requires that the players read most of the setting book for themselves. That requires hours of investment, and I’ve found that most players won’t commit it.

To make things worse, Transhuman Space was primarily designed to be an interesting setting for the sake of having an interesting setting, without any real consideration or focus given to the types of stories/games that can be told in that setting.

So, to answer Pasquale’s question at long last: Yes. I think you could use a structure similar to “Between the Stars” as a solution to both problems.

It’s been about 10 years since I read Transhuman Space, so take any specifics with a grain of salt, but the general approach I would take would look something like this:

(1) Set the PCs up as the crew of a tramp freighter. These vessels, due to their relative isolation and the difficulty of maintaining network connections and advanced tech on a mobile platform, end up being a lot more culturally conservative than the rest of the solar system. (In other words, their crews cleave a lot closer to early-21st century norms, so the players don’t have to “reach” as far to understand their characters.)

(2) The scenario structure needs to be tweaked somewhat to accommodate interplanetary travel instead of interstellar travel, but the basic principle of “key to the voyage” should still work.

(3) I would key each voyage to reveal some specific facet of the Transhuman Space setting. (Over time, therefore, the campaign would slowly introduce your players to its intricacies one chunk at a time.)

In terms of keying, this can actually be quite liberating. Flipping through the setting book randomly and just grabbing stuff off the page, for example, gives me:

A large group of executives from Nanodynamics is travelling to a base in the outer system to inspect the installation of zero-gee nanofabrication tools. But they’re being targeted by pro-union terrorists from the recently acquired Exogenesis Systems Technologies. (see page 95)

A poorly secured microbot swarm breaks loose in the ship’s cargo hold.

The crew is hired to make the long haul out to Miranda with 3HE mining supplies. There’s a spy onboard trying to figure out what China’s real intentions are for the Miranda colony. (see page 48)

A Felician combat bioroid sneaks onboard in an effort to escape her contract. A corporate hunting team, however, is trying to track her down. And since the Felician killed their captain, they may be more interested in vigilante justice than fulfilling their contract. (see page 116)

And so forth.

It might also be useful to check out “Getting the Players to Care“, which is primarily about how to parcel and structure exposition so that it’s not boring or overwhelming.

Go to Part 1

Now that we have a custom campaign structure for a “Between the Stars” campaign, let’s turn our focus to the scenarios that will be triggered by that campaign structure.

With quite a few of these scenarios, of course, we can use scenario structures that we’re already familiar with: Someone is murdered on board; grab our scenario structure for mysteries. The ship stumbles across a wandering asteroid studded with alien architecture; whip out the maps for an old-fashioned dungeoncrawl. We might want to give some thought to the types of hooks we can use to initiate each scenario narratively, but there’ll be no need to reinvent the wheel in designing the scenarios themselves.

(Random thought: If we’re looking for a semi-generic structure for constructing scenario hooks we could define them according to (a) when they’re triggered; (b) what officer will receive the trigger; and (c) what the hook is. For example, a scenario in which the PCs are approached to smuggle a cargo might be triggered in dock before the voyage starts; target the cargomaster; and take the form of a comm call asking for a meeting at a dockside bar. The “asteroid of alien architecture” might be hooked with the navigator making a Sensors check (on a success they detect the asteroid a fair distance away; on a failure they stumble too close to it and get caught in an automated tractor beam). A murder scenario might be hooked with the security officer making a Security check (success indicates they find the body on a routine sweep; failure indicates that a random passenger finds the body).)

For other scenarios, however, it may be useful to give some thought customizing new scenario structures. As an example of that, we’re going to look at the hypothetical example of hijacking scenarios. Before doing that, however, I want to make a couple of particular points.

First, we’ll want to remember that the default goal of the campaign’s macro structure is to successfully run a ship in order to maximize profit. Which means that scenarios and hooks that either threaten the PCs’ profit or offer them opportunities for more profit will be most successful.

Second, I want to note that this entire section of the essay is entirely hypothetical: If this stuff were to be put to a proper playtest, I have little doubt that we’d discover that some of it doesn’t work in practice and other stuff could be greatly improved. That’s just part of the process.

SCENARIO STRUCTURE: HIJACKING

What we’re looking at here is any scenario where passengers, stowaways, or members of the crew attempt to take control of the ship.

If the ship were relatively small in size, we could probably run this using location ‘crawl techniques. In other words, we could take a fully keyed map of the ship and then run the actions of the PCs and hijackers in “real time” so to speak. This would be appropriate for something like Air Force One.

But let’s assume that the ship is larger and that we want to create experiences that feel more like Die Hard or Under Siege.

Node Map of the Ship: First, for purposes of navigation, let’s create a node map of the ship. This abstract representation of movement aboard ship will allow both PCs and hijackers to make meaningful decisions about where they’re going and how they’re going to get there without getting bogged down in tracking things corridor-by-corridor and room-by-room. (Although for certain key areas – like the bridge of the engine room – we may still want to draw-up detailed maps for tactical purposes.)

With this map we can now key both nodes and the routes between nodes. We can also allow characters to secure and/or barricade specific nodes or routes. (So some routes to the bridge may be less heavily guarded than others, for example.)

We can also assign travel times between locations.

Shortcuts and Stealth Paths: Looking at our touchstones of Die Hard and Under Siege, we can see that a lot of the action is driven by protagonists seeking out alternative methods of moving around the structure (ventilation shafts, service corridors, burning holes through bulkheads, etc.).

We could try including these routes onto our node map of the ship, possibly by using dotted lines:

Or, for a simpler and more flexible solution, we could assume that the ship has sufficient structural complexity that secret routes can always be found: With a sufficiently high skill check, a character can either find a short cut (which reduces the amount of time it takes to get from one location to another) or a stealth path (which makes it possible to reach areas of the ship that have been blocked off in one way or another).

To this, let’s add a wrinkle: If effort is taken, certain locations can be secured. For example, in Aliens the last of the survivors attempt to seal up a portion of the colony so that they can survive long enough for a rescue ship to arrive. Of course, the aliens still managed to find a way in, so let’s make that an opposed check: If your effort to find a stealth a path into my area is better than my check to seal the area, then you’ve found something that I forgot.

Control of the Ship: For a simple structure, we could simply equate control of the ship with control of the bridge. But if wanted a more dynamic scenario, we could make it so that individual systems can be taken offline or supersede the bridge’s control from other locations in the ship. (For example, you might be able to gain navigational control from the engine room; knock communications off-line by getting to the receiver room; turn off life support from environmental control; or access the automatic security systems from the security center.)

Node Effects: On a similar note, we might want to define some specific game structures for special nodes. For example, if you can access the communications array and send a distress signal, what effect will that have?

Is gaining control of the automatic security systems something that can be automatically achieved in the security center? Does it require an opposed skill check? A complex skill check? If so, how much time do those checks take? (Would it give enough time for the bad guys to physically lay siege to the security center?) Do you have to do it compartment by compartment? Do we run the whole thing as a massive hacker-vs-hacker battle in virtual reality?

Do I prep the armory by simply having an inventory of available supplies? Or do we code something similar to a wealth check to see if a particular piece of desired equipment is available?

Random Encounters: Finally, I’m always a big fan of using random encounters to simulate the activity in complex environments. Whether it’s panicked pockets of prostrate passengers or roving hijacker enforcement teams, a well-seeded random encounter table can add unexpected twists and delightful chaos to the scenario.

OTHER SCENARIO STRUCTURES

Here are some other potential scenario structures for a “Between the Stars” campaign.

Bomb Onboard: Touchstones might include stuff like Die Hard With a Vengeance and Law Abiding Citizen. The actual mystery of identifying the bomber can probably use a standard mystery scenario structure, but what about the process of finding (and possibly defusing) bombs before they explode? What effect do bombs have on ship systems?

Plague: The Babylon 5 episode “Confessions and Lamentations” is a particularly poignant look at disease scenarios on spacecraft. “Genesis” from Star Trek: The Next Generation was a particularly stupid one. (On the other hand, TNG’s “Identity Crisis” shows the breadth of potential within the general idea.)

Lost in Space: Touchstones would include… well… Lost in Space. (Also, Poul Anderon’s Tau Zero.)

Collision in Space: Here you could probably lift some of the same structures for systems damage from the “Bomb Onboard” scenario structure to model collision damage.

Mutiny: We could probably lift large chunks from our “Hijacking” scenario structure

Smuggling: Both with the PCs engaging in smuggling and with NPC smugglers trying to use their ships to achieve their own aims.

If you’re feeling up for it, grab one of these and give it the same treatment we gave hijackings: Post it here in the comments or toss a link down there to wherever you do post it.

Go to Part 15: Generic Scenario Structures