Boring Play

Recently I've been in a bit of a war with myself about game design.

I create a lot of prototypes - typically at least one a week. For a long time, they were mostly about exploring some gameplay idea - a particular tweak on poker rules, or a feel for the timing in a brawler.

As time passed, I became steadily more interested in themes. Pick a theme, then craft the rules out of the giant backlog of gameplay I explored. Fit them together.

In the end, there are only a few kinds of play that are considered "valid". If I come up with a theme such as "fluffy bunnies in the woods", it'll have to rely on the same challenges that every other game relies on.

Movement and timing. Pattern recognition/optimization. Choosing the right option out of an ever-changing crowd of options. Luck.

There are some games that people barely consider games. For example, Gone Home.

But Gone Home still uses these mechanics. You move around the house looking for things to click on. You put together the pattern of the story in your head. The least gamey game is still reliant on the same challenges as the most gamey game, just with very different pacing.

What about Animal Crossing and similar games?

Well, there's a lot of pattern recognition and optimization in Animal Crossing - gathering valuable things, hitting the parts of the town you need to hit, tending your crops, finding jobs and sidequests. Those are all pattern recognition and optimization.

There are some things peeking from the shadows, though. Creating your character involves picking from a list of options, but unlike an RPG battle or math-teaching game, none of the choices is right or wrong. Similarly, in Gone Home the challenges are all about movement and clicking just like in a shooty game, but none of the movement or clicks could really be considered "bad". You can't lose at Gone Home - the challenges just serve to to indicate which way is forward so you can control your own experience a bit more clearly.

In both cases, the "challenge" (picking an option, moving and looking) is there to allow the player to control their own experience. In both cases, the game tells you how to move forward specifically so you can linger or move on as your preferences and mood dictate.

OK, with that in mind, let's back up a little bit.

---

Gameplay is really boring.

Oh, it can keep your mind entrained. I play Kerbal and Skyrim and so on. The mechanics keep me thinking, keep me looking towards the next step.

But when I look at it, there's nothing to the mechanics at all. My outlook on life wouldn't be any different if I couldn't choose the right amount of fuel and thrust to land on a fake moon, or level up my sneak enough to stab a fake skeleton with a fake knife.

There is some value in these games, though.

Through Kerbal I learned a lot about the mechanics of space flight. While the lessons are stilted and simplified, they further my interest in and my understanding of real science, real space flight. By giving me a cartoonish version of something real, the game lets me hold it in my hands, twist it, hold it up to the light, and start to understand.

Skyrim is not so positive. The cartoonish thing Skyrim lets me hold is the culture that formed it. It's a very manly-man Tolkien fantasy with a lot of serious issues. But it serves: when I hold Skyrim in my hand and start gluing other people's pieces onto it, I can see all the weaknesses in that culture, and explore my steadily-increasing distance from it.

Even if you don't read into it as much as I do, Skyrim's strength is the setting, not the mechanics. High-fidelity fantasy world you can wander around in? That's what you'll remember about Skyrim. You won't fondly remember the lockpicking puzzle.

So, why do we do it?

Why do we slap useless gameplay into these things?

1) Pacing. By keeping the mind engaged, players can remain interested in the world even when their preferences aren't lining up and they aren't interested in the bit of setting they're currently looking at.

2) Engagement. By allowing players to choose how they approach the game, we also change how they approach the setpieces. This helps players grip the concepts in the world and hold them up to the light.

3) Synchronization. By giving all players the same emergent tools, we allow every player to have their own unique experiences with the same foundation. Sharing those experiences with other players (or themselves in the past), we allow players to have conversations about the concepts in the game. Even if it's just bragging about headshot counts.

Thinking about gameplay from this perspective is very freeing.

Instead of thinking "what kind of gameplay do I want in this game?" maybe we should think -

1) How do I pace the game so that the player remains interested even when their mood drifts out of synch with the setting?

2) How do I let the player explore the ramifications of change in this world?

3) What commonalities do I rely on to help players understand each other's experiences and choices?

...

I haven't gotten any further than that, yet.

Mechanics as Self-Expression

For the past week I've alternated between talking about mods and talking about collaborative content, but today I'd like to combine the two.

One of the things I like about Kerbal is that everyone has such different priorities, and installs a completely different set of mods. I think most moddable games are like this, but in Kerbal it's really really clear because the majority of mods are visible the majority of the time.

In the end, every high-level Kerbal player has very strong opinions on which mods are the most fun. In turn they have a game that plays completely differently, with very different mission objectives or methods.

Then I started to think about collaboration.

Most of the time, when I think of collaboration I think of players expressing themselves artistically.

When I think of mechanics, I think of cooperation. People working together to get a good statistical result. But that's not really the kind of collaboration I'm talking about, because it's normally just players trying to implement an ideal solution, not players expressing themselves.

But if we make the mechanics of the game part of their self-expression, that suddenly changes.

Previously, creating something in the game world was mostly about either expressing yourself OR accomplishing objectives. But if the players can choose the mechanics they include, now creating things is both at the same time, because your mechanical options are a result of your self-expression.

Collaborations can arise within this space. For example, in a fictional version of Kerbal, one player has the faster-than-light mod installed, and another has the karbonite resource-mining mod installed.

The two players can collaborate. Use FTL ships to move mined materials between distant planets. Restock your long-range transports at colonies that produce life support resources.

If the mods are created with the intent to help collaborate with people who aren't using the mods, there would also be additional parts. Set up an FTL beacon so ships without FTL-mod drives can travel faster than light. Set up an automatic waystation that can hurl goods into space without needing direct docking or control, to allow the other player to get resources from you even if your mods are incompatible...

Even in a game with no mods, this sort of collaboration is possible. However, it requires a certain approach.

Let's consider a tabletop RPG.

The issue with this kind of collaboration is that it requires the creation of long-term content. Classically, most of the collaboration in a tabletop game comes from social collaboration - telling stories together, acting out something together, choosing a path together. These don't require a long-term record of your choices, although you can certainly have one.

But with mechanical collaboration, I can't see any way aside from using a long-term record.

With that in mind, this is a tabletop RPG where the players do a lot of creating. You actually create a lot in every tabletop RPG - your avatar is a bundle of creative choices. However, you rarely collaborate with others regarding the specifics of your character sheet. Instead, it makes more sense to move those choices somewhere more convenient and shareable.

My thought is that the game could be about makers of some kind. Perhaps it's about mecha, or pokemon, or it's a hacker game, or maybe it takes place in dreams, or it's a Harry Potter game where you get to invent spells and enchantments...

The "classes" wouldn't be about the role these people play in combat. Instead, you would choose a few classes, and each class would contain an entirely different kind of infrastructure you would build with.

For example, if it was a Harry Potterlike, you might choose "potions". This would allow you to brew up potions, which in turn means you'll need to keep a stock of various potions. But you don't choose potions alone: you also have another class. Say, "botany", the study of plants. These get along well together, since plants provide many ingredients for potions... and there are potions that enhance plants. So as you build up your infrastructure for each class, you get synergy and they build each other up.

Potions and botany seem like they go particularly well together due to the fact that plants make good ingredients, but there's nothing mechanically linking them aside from the output of one going into the input of another. Which means that the two don't actually mix very well and aren't very interesting to combine. You have a garden, you have an alchemy lab, and never the twain shall meet.

To fix that, we use a "Kerbalish" system, where all our classes invest in shared infrastructure. In this case, you are allowed a certain amount of space in an environment of your choice. Like a Kerbal rocket launch, you design your rocket around all your mods. So our space would naturally try to combine botany and alchemy in one space when possible.

Each comes seeded with concepts that can help the other. The tools you would use for the extensive and prolonged brewing processes are also valuable in gardening: drip-feeding plants, hydroponics, delivering magical fertilizer, and so on. Gardening concepts are valuable in your alchemy lab: leeching from still-growing plants, using gentle sunlight, soil-filtered modules, fermentation, mold - all of these can be used in an alchemical setup. And, in any given setup, it might be difficult to see where one kind of lab ends and another begins.

It's not that botany and alchemy have a particularly deep bond, either. All the classes support each other in this way, and most players will choose, say, three.

The key to this is that the player has to build medium-duration constructs as part of their play. The player doesn't get a mortar and pestle and mix up whatever potion she needs today. Instead, if she wants to brew healing potions, she'll make that a dedicated part of her next setup. If she wants to grow pixieleaf, she'll have part of her next setup dedicated to that. And then, a month later, she'll get another chance to build something. And, during that month, who knows what resources she'll find on her adventures to help her build her next setup?

This seems quite complex, dumping all this interactive machinery on the players, but it is a gentle learning curve. When you start, it's all very basic space management - how much stuff can you fit on a tabletop, a windowsill?

Complications are gradually introduced in the same way as any RPG.

The whole thing needs to synergizes with the adventure phase. There needs to be a nice resonance. To that end, the adventures have to be carefully constructed to allow you to benefit from your setups, and also to gain new resources/information that will help you in your following setups.

We also have to allow players to collaborate with each other. That's pretty easy, it's just a matter of how far we want to take it. The more freely players can add to each other's setups, the more each class needs to diverge as you level up.

If only you can add alchemical stuff to your garden, then the alchemy class can be pretty linear. But if anyone with the alchemy class can add stuff to your garden, then each person needs their own, very different concept of how alchemy should work. Otherwise there's no advantage to having multiple alchemists.

Well, anyway, that's just a quick example, half of a Harry-Potterlike. You can do the same kind of thing with any setting. Just make sure that the classes build with each other on a shared framework, and resonate well with the more active play sections.

There are also other options, such as having these things be part of the active play session... I've barely scratched the surface of the possibilities here.

Cooperative vs Collaborative

Recently I've hit on some really neat little ideas. They came from one basic concept: there is a line between cooperative play and collaborative play. They are different.

Right now, collaborative play doesn't exist in computer games. There are collaborative games, but they don't involve collaborative play. For example, in Spore you collaborate with the player base to populate the universe with aliens - but there's no play involved. It just happens. Similarly, in Sim City you can collaborate by having neighboring cities, but the only "play" involved is trying to have the right kinds of inputs and outputs.

Mods are collaborative by nature, but although they create play, they don't use collaborative play. They are created by one person and used by another without any play between the two.

I think this is a big oversight. I think there is a lot of potential that we haven't really investigated.

There are things with collaborative play. Most tabletop RPGs are collaborative. The underlying structure of the game provides a framework of statistics and mechanics, and the players can build their own stories on top of that foundation. Putting aside the actions of the GM, the players collaborate with each other to distinguish their characters, move the experience in the way they prefer, and help augment another player's actions.

Jazz is collaborative in basically the same way. The foundation of jazz is a set of musical patterns that give everyone a similar foundation. They can collaborate with each other to distinguish themselves, move the experience in a way they like, and augment other players' music.

Most collaborative play today is face to face, and uses the incredibly fluid and nuanced signals inherent in human socialization. This allows collaborators to "stay on the same page", and collaborate tightly with each other.

However, that's not really possible in a video game. The most nuanced signals in a video game are less nuanced than a facial expression, and they flow less smoothly. Even incidental signals, like the timing of your turn, are more effort than a raised eyebrow.

We just have to live with that. We need to live with the fact that, aside from voice chat, we're going to rely on in-game signaling to synchronize our collaborators. That means slower, rougher, more awkward synchs.

The good news is that it also means we can save and play back signals.

The basic idea is that we can trickle in a bunch signals bit by bit, then let them flow over another user all at once. Asynchronous collaboration.

Minecraft multiplayer is probably the biggest current example of this. In shared universes, you can collaborate really entertainingly. This is often done asynchronously - the players aren't directly working on the same rooms at the same time. In fact, if playing is done synchronously, it's often cooperative play (exploring/mining ore) rather than collaborative play (building houses).

Asynchronous construction allows players to spend hours building their house on their own, without a whole lot of interference. Other players that visit the house are exposed to all those decisions in a quick and fluid experience as they wander around the house. It can even be done synchronously, with the host explaining the house as you walk. The host sets the stage ("this is the bedroom, and there's a secret passage behind the bookshelf...") and the nuance is provided by the level (exact placement of beds, nature of ceiling, choice of furniture, etc).

Minecraft doesn't really focus on that idea, so let's take this a few steps further.

The first step we want to take is to step on our own feet.

Because our game is the storehouse of signals, we can play back signals whenever we like. That includes allowing the player to collaborate with themself.

Let's draw the idea more clearly using The Sims.

In The Sims, you will typically play off of your own content. You have a house full of people, and you make decisions based on the nature of those people. However, even though each day builds off the last day, you are not "collaborating with yourself" in the way we're talking about, because the content is not represented as if it belonged to someone else. You always have full authority.

Now, on the other hand, if you build a second family in that neighborhood and invite the first family over - now you are collaborating with yourself. The original family is no longer "yours". They are presented as if they were created and controlled by someone else, and that someone else just happens to be "past you".

The Sims doesn't have a lot of persistent nuanced signals, so this collaboration isn't as rich as it might be. Mostly, The Sims relies on a player's internal fictions - if I download your family, I won't glimpse the rich lives you've built around them. The only signal from you that I can see is their appearance and maybe their basic personality.

Now, Kerbal has a LOT of persistent nuanced signals. Not just because the ships can be designed so diversely, no - that's only a small part of it. It's because modding plays a huge role in how Kerbal plays. You can tell which mods someone has installed by the parts on their ships, yeah. But you can also tell what role within the arc of that mod the ship plays, and how the player is interleaving their mods.

These gameplay-centric signals are a great idea, but it does require that the game vary massively from player to player, to the point where each player has an exceptionally wide number of in-game, mechanically-supported goals.

In Minecraft, that's not usually the case. No matter how awesome your house is, there's only a few mechanically-supported goals, and most of them aren't very nuanced. Instead, the value of a home in Minecraft lies in its sense of style.

This lets players put some of their personal style into the house, but I don't think that's anywhere near good enough. See, most people are not architects. We can build voxel homes, but we can't communicate very well with the nuances of these designs.

Most players are concerned with being people. So... perhaps the signals we should let them build should reflect the fictional people in the world?

A lot of Minecraft mansions try to do just that. The mansion is filled with decorations that suit the fictional lives of the player. Nonfunctional furniture, desks that will never get used, decorative racks of armor that will never be appreciated...

Some of the mansions contain multiple fictional people living fictional lives. "This ship I built has 12 sailors. This is where they sleep, this is where they eat..."

But that's just the surface of what's possible if we actually let the players create that content instead of just keeping it in their head where nobody else can see it.

There are a lot of possible ways to let players build their own people-living-lives content. One is to let them place NPCs. However, I think that's not very good, because NPC behavior will be very sterile, especially if modded furniture is introduced and they don't know what to make of it.

My recommendation instead is to build machinima systems. IE, you become a sailor. You "record" yourself sleeping in a bunk, eating at a table, scrubbing the floor. NPCs can play back those recorded bits, with the sterile pieces of their behavior being limited to pathfinding from bit to bit.

Allow bits to link up: I record myself as a pirate captain, I record myself responding to my pirate captain as a first mate, and now there are skits that can play. Collaborating with myself.

This is a very basic system that doesn't take into account how these NPCs should react to a new presence. But it's a damn sight more interesting than not having NPCs.

Players that are allowed to can further build out your scenario. Adding new places, new skits, new NPCs...

Sounds like a pretty great way to add nuanced content and collaborate with other players.

Sounds fun to me!

This is just one of the ideas that started to arise when I started to think about collaboration as a distinct kind of play. There's lots of space here!

Integrating Mods

I like mods. I'd like to talk about how to integrate mods into the core game. I'd like to talk about the future of mods. So let's start with the current generation of mods.

Right now, there are four reigning kings of mods. Kings and queens? Four reigning prime ministers of mods.

These four ministers of mods are Kerbal, Space Engineers, Skyrim, and Minecraft. I haven't done much Minecraft modding, so we'll put that aside and I'll explain my thoughts using the first three.

Kerbal and Space Engineers have similar fundamentals, so their mods often end up having a similar impact on the game. Both games feature picking parts out of a huge list and choosing where to put them. In short, they are construction games.

Most mods for these games add parts. However, this leads to swamping. No matter how many filters and categories you add, the player is tasked to consider all of these parts as potential components at all times. Kerbal has introduced a nice smooth slope via career mode, and Space Engineers is working towards a very diverse set of categories, but neither approach is perfect. In both cases the player will eventually have to be familiar with all parts all the time, and that means the guidance just delays the inevitable.

There are mods that are about things other than parts, but we'll talk about that later. Instead, let's talk about Skyrim.

Many of Skyrim's mods are also about adding stuff into the game - the Skyrim equivalent of "parts". Armor, weapons, spells, NPCs, foods, monsters, dungeons - add it all in and stir it up!

No matter how many Skyrim mods you add, you are unlikely to feel swamped. Even if you add 10,000 new swords, you're not likely to feel like you're drowning in swords. The reason is simple: you are never given a list of swords.

Skyrim is not a construction game, it's a scrounging game. Because of this, there is never a complete list of stuff. You stumble across it - a shop might have one or two, a bandit might equip one, one might pop up in a dungeon somewhere. You are never asked to pick a spear from the 10,000 possible spears. Instead, you're asked to pick between a Spear of Winter's Breath or a Kingfisher Spear.

In Skyrim, stuff is terrain. If you add more stuff, you widen the terrain. The player walks along and stumbles across the things you have added. They can choose whether to carry it with them as they go, or ignore it, or destroy it, or whatever.

The longer the player walks, the more times they stumble across mod content. And, of course, if the player knows what mods they want to focus on, they can seek out that place first and get that stuff first.

The equivalent would be if mods in Kerbal didn't add parts to your rocket construction facility, but instead scattered parts around the cosmos. If you went to the Mun, it wouldn't be to get science. It'd be to collect parts that are seeded there. There would have to be "core packs" too, of course, especially if we want to design decent-looking spaceplanes.

Anyway, these kinds of mods are "content packs".

There's also mods that change how the game works, and mods that do both at the same time. For example, Kerbal's "remote tech" mod, which radically changes how probes and communication work. Or any of Skyrim's "magic rebalancing" mods which change how magic works.

Functional packs that change how things work (while perhaps also introducing new content) are rarer than content packs for a few reasons. One is that it is way harder to program a new kind of activity than to just give new stats to a sword.

But even if they were the same difficulty, a player would still have more content packs installed than function packs. The reason is because of conflicts.

When designing for the future of mods, conflicts are at the heart of our considerations. The future of mods involves dozens, hundreds of mods installed at the same time. Conflicts will arise.

One kind of conflict is just in the player's head. For example, Kerbal has several life support mods. Aside from some minor resource overlapping due to shared resource names, none of them really conflict-conflict. It just doesn't make much sense to have them installed at the same time.

These are "categorical conflicts". Categorical conflicts are limits on the concept of your game. If all the players rush to create the same three mods over and over, it means that they all see your game as lacking in the same fundamental place. However, if the players create dozens of different mods and they rarely have any category conflicts, it means your game is a strong platform for them to explore their interests.

This doesn't necessarily apply to all categories. For example, Skyrim has hundreds of mods about sex and nudity: that's obviously a category the players really wanted to explore. But Skyrim also has dozens of mods about tweaking the rendering settings. That's not really a category in the game so much a thing the game does.

This is a "system conflict": the game has a system that works in a specific way, and two mods that both change that system are likely to conflict. Two mods that change how things render. Two mods that change how airplanes fly.

Kerbal life support mods are not a system conflict, because there was no system for life support in the game. But replacing the planet textures is a system conflict.

Sometimes it's hard to tell whether something is a category conflict or a system conflict. For example, the dozens of Skyrim mods that replace the base body and armor meshes/textures. These categories are not exclusive: many system conflicts are also category conflicts. One tells you what the players are interested in, the other tells you what the game is capable of.

"Resource conflicts" are the last type. This is when two mods conflict due to bad engineering. For example, one Skyrim mod which allows you to kill sleeping people, and another that allows you to drink their blood. When you hit the action button, which action happens?

That's a minor conflict, because most mods learned to add options to a context menu instead of overriding the basic operations. But there are similar conflicts that are more persistent: a mod that makes your NPCs loiter around towns realistically conflicts with a mod that makes them follow you in a more tactically-sound way. The conflict only exists because the NPCs don't understand that they should behave differently between a town and a dungeon.

When engineering a moddable game, it's probably worthwhile to consider these kinds of conflicts and understand how they will shape the modding community.

Categorical conflicts aren't necessarily bad - they let the player base cooperate in a specific way - but keep in mind that these will give rise to all-encompassing mods that dominate your modding community. These huge, complex mods will conflict with everything and everyone, so you need to give the modders the tools to subdivide their mods and/or create variations to get along with other mods.

Skyrim does this well - not through any effort of the Skyrim devs, but through efforts of the modding community. An in-game mod management console and an out-of-game mod install tool both offer players a bevy of options to specify not only what they want the mod to do, but also what mods they would like it to be compatible with.

Larger mods will have versioning, so the mod system should support versions right from the start, and allow for comparing the same mod to itself to see which one is more recent. Ideally, it should even support contacting a server to check whether the installed version is out of date. Super-ideally, a P2P system could be used to host mods to prevent centralization issues such as a primary distributor being bought out by Curse.

If you don't include these features, they'll probably arise on their own, but that usually means a pretty mangy, stumbling distribution system that will fall over dead randomly.

Moving down into the game itself, to prevent resource conflicts you should try to make flexible API integration for mods. Kerbal has a pretty good example of this in their resources system, where mods can specify the nature of resources such as oxygen, water, karbonite, etc. This doesn't require any C# code or libraries or anything, and every mod can access the resources.

A slightly better way to do it would be to allow mods to have part lists inside of resource/mod checks. IE, "if oxygen has been defined, add these three parts, otherwise don't bother" or "if Remote Tech is installed, use these parts instead of these". Allowing the mod to ask the player about configuration both up-front and in an in-game window should also be possible with a simple line of script. If conflicts arise, allow the player to choose which mod has supremacy, perhaps after checking with each mod for a fallback state.

Mods which are modular are probably going to slowly gain importance, so allowing modders to let players turn on and off bits of their mods will probably be more and more important.

However, all that stuff is the basic stuff. What we're really interested in is how mods are integrated into the game.

Those ideas are all about functional mods. But most mods are and will probably always be content packs. In fact, content packs are likely to become so prevalent that players will be creating and downloading them without even thinking of them as content packs, such as with Spore's creature sharing.

Content is going to explode. Space Engineers is touching on this - they let players create ships, and now their game infrastructure is buckling under the demand for better, faster, more interesting sharing options.

In addition to the skyrocketing amount of content and demands for ever-more-flexible content sharing capabilities, there's also the bugaboo that content packs often rely on other mods. If I have a mod which flies random player-created ships through my Space Engineers game, what happens when those ships have mods I do not have?

The Kerbal fail state is self-destruction: the ship flat-out can't be loaded. Space Engineers is slightly less bad, but you're still going to end up with busted ships.

Even if you autoshare mods, the mods will conflict!

The answer is wrappers.

Mod wrappers are in-game conceits that control which mods work, when. Rather than a mod flat-out overwriting the game's base code, the mod's code is only called when the game is "inside" the wrapper.

In Kerbal, that could be "space agency". So if Kerbal implemented a ship-sharing system with automatic mod-loading (impossible given their code base but let's pretend), the idea would be that your friend's ship would belong to their space agency. In turn, the mods their ship uses are considered separately from the mods you're using. Some might allow crosstalk - for example, if you both have a version of Remote Tech installed, the ships might be able to relay for each other. Others might be similar but incompatible, and not allow crosstalk - you have Remote Tech, she has Antenna Range.

The key to wrappers is figuring out the edges. What happens when one of your ships and one of her ships dock?

In Kerbal, the two ships are merged. So, what happens with the mods?

One option is to not allow ships from different agencies to dock. Another is to assign one player as leader and shut down all the mods from the other player - the parts that serve those mods are still loaded, but they are dormant. Another is to make the mods list actually per-part rather than per-agency - although the overhead might get absurd.

Imagine if in the next Elder Scrolls game, mods were by region. As you moved from land to land, things changed - the rendering changed, the rules of stealth changed, which swords were available changed. If you conquer a land, you can choose to change the mods. If you are playing multiplayer, you can shift between their world and yours, and the mods may change...

Anyway, the key to this concept is that the wrappers are clear in-game concepts that allow players to choose exactly what mods should be applied where. These aren't normally under the control of the modders.

To allow this, your code base will need to allow mods to register themselves rather than simply overwriting the game's base function. Your mod API needs to support not just the mod's capabilities within the game, but also the way the game knows the mod exists. It should allow mods to ask which mods are active in which wrappers, and it should ask mods whether they have anything to contribute.

For example, a sword content pack might have 10,000 different swords. Rather than making the mod responsible for littering the swords around the world, the mod would instead tell the game it has opinions about swords (or weapons). Whenever choosing weapons (for NPCs, for stores, as loot), the game would ask all interested mods whether they have any suggestions. Then the game creates a weighted stack and doles out the final result to the player. When you ask the mod for suggestions, you pass it an information pack it can ask questions from - what culture is it? How rich? What level?

If you want to be extra-safe, once you've collected a list, run the list back through the mods to see if they have any weighting adjustments they want to make. This would allow mods to synergize, or shut off the default content, or similar.

Even the information pack should be linked to this concept of suggestions from mods. The base content adds in level, wealth, culture, etc. But a mod might overlay a "biome" information bit, or a "minerals" bit, or any number of other things. This allows functional mods to behave in a way very similar to content mods with a minimum of hacking into the core game code.

Anyway, I'm looking forward to the mods of the future. I hope some of these ideas become common.

Generating Playable Star Trek Plots

I've talked about creating science fiction tabletop games, using the example of Star Trek. One of the things that comes up a lot whenever you do this is how you can create enough MEAT.

Fantasy games have grown a kind of plot progression out of long practice. Fantasy stories you read in books don't have the same pacing at all: a fantasy game features a huge amount of content that would give an editor fits. Dozens of pointless fights, considering which sword to buy, exploring each dungeon room one by one... this is the meat of a fantasy game.

If you've ever tried to run a science fiction game, you probably noticed that it was pretty hard to get enough meat. The plot either felt full of filler, or moved too fast. That's because you were probably using the same structure as a fantasy game. Science fiction plot lines can't really support that - there's no monsters to slay, no real advantage to exploring every room.

Science fiction plot arcs require a different approach. And we haven't really figured it out, because we haven't spent forty years perfecting our craft.

But I do have a guide that might help. Here is my guide for creating science fiction arcs that last 1-3 sessions - "Star Trek" plots that play nicely and have meat.

The Noose
The players always need to be under pressure in a science fiction plot. Players used to a fantasy plot know enough to move the plot forward even with relatively little pressure, but nobody is that used to science fiction plots yet. The noose is a crisp and looming deadline to force them forward.

Nooses should have a concrete time span and failing to deal with them is the lose state. Players might be able to push nooses back, but they can't ever reduce the noose's effect. The noose is all-or-nothing, high-stakes. The situation may also get worse as the noose approaches, but the noose is specifically the looming deadline.

Noose examples include: the disease will kill everyone on the planet in 2 days. The Klingons will declare war in a month if you don't find their lost ship. The vote happens tomorrow and the majority of the senators are planning to vote "no". The space wedgie will cause life support to fail in six hours.

Personal Mire
My planned gameplay revolves around people, and therefore the NPCs need to be the terrain of the game - half like a dungeon map, half like a monster fight. To make this easy for the GM to plan out without needing a ton of advance work, I recommend "constellations" of NPCs - groups of NPCs that are related to each other around a specific topic.

For example, the "impending new order" constellation would feature characters from the old guard and the new order and some conflicted bystanders, and their relationships would be clear. You could leave most of the characters in the wings until you need them, not bothering to create any details until you need them to play a role.

The idea is that any given NPC would belong to two or more of these constellations, and their motivations would intertwine. This adds some complexity to the things the players do, and create some nice terrain for them to be wary of. It also creates a lot of hooks that are easy to turn into complications, twists, and major NPCs.

Complications
Normally, solving the noose is pretty straightforward. If there's a disease, you need to research the cure. If there's a lost ship, you need to track the warp trail. If there's a vote, you need to convince people to vote your way.

Complications are what make the situation a lot more difficult - they are reason that the actions that should solve the situation either can't be performed or produce a bad result.

Complications usually give the noose emotional resonance, and should generally be themed to give a strong, unified feeling.

For example, the disease turns out to be a nasty engineered bioweapon, which makes curing it much more difficult. The next complication might be that the weapon was created by the locals, and they don't want that revealed and certainly don't want to help you fix it. The next complication might be that the creators died of the disease and can't help. These complications are loosely themed - they're about plans going awry, smaller evils blooming into larger ones.

Other Examples: The Klingon ship was kidnapped by a space godling. The senators you need to convince are stranded on an ice planet. The space wedgie is making time judder backwards and forwards randomly.

Twists
A twist simply changes the lose state. It either replaces the noose with a new noose, or it reverses the noose so that your efforts have been working against you, or it makes everything you've done feel very different now that it's over.

Examples: the vote needs to fail to keep their society stable. The "missing" Klingon ship is an ambush. The space wedgie was trying to protect you from a warp core breech.

Twists don't need to be clever. This is not about creating clever plot lines - it's about creating meaty plot lines. The twist either adds more meat, or makes the meat you already ate taste funny.

B-plots
The B-plot is actually an integral part of science fiction plots, although it may not be immediately obvious. See, the function of the B-plot is to create emotional resonance with the primary plot.

Most science fiction primary plots are about something big - a starship, a disease, a political movement. But in the end, the plots are an excuse to show how people live and act in those situations. The B-plot is the easiest way to lure the players into that kind of close emotional connection.

The B-plot is often "unrelated" to the main plot, at least in terms of causality. However, it reflects the human judgments and lives of the main plot. So, your B-plots should shadow your complications and twists. Since your complications and twists should be loosely themed, the B-plot will likely match many of them at the same time, and offer a human window into a world of big things going wrong.

Typically a B-plot is introduced before the first complication - often before the noose. It exists first even though it is an echo or window onto those larger events.

For example, if the vote is being screwed up because the senators are stranded on an ice planet, you'll start off with a B-plot that plays with that. Perhaps it's about planning a vacation, or the life support going on the fritz, or being unable to get off the ship, or having family visiting.

If the twist is that the lost Klingon warbird is actually waiting in ambush, the B-plot might be about your Klingon crewmember being proud of his culture's obsession with honorable combat, or it might be about an officer training test where everyone dies in an ambush: the Koboyashi Maru sequence. B-plots don't have to be clever or hard to connect.

However, B-plots do have to offer some meat. Think of them as a sequence that doesn't require the GM: when the GM is busy with a particular player, this is something the other players gnaw on.

Therefore, the B-plots should be things where the players can spend some time expressing themselves or their characters, and should involve some die rolling or content that A) doesn't require the GM and B) dictates how things go for them.

For example, the Koboyashi Maru B-plot. It isn't just a line you feed them. You say "this is an officer test." You walk them through it once or twice. But there's a table of results - if your leadership is this, this happens in the first segment. Roll weapons fire, check to see what happens in the second segment, and so on.

A concrete reference as to what can happen lets the players compare their performances to each other, and makes it easy for the GM to give various bonuses or penalties according to their efforts without having to spend a lot of time thinking up new things.

In another example, if the B-plot is that someone's family is visiting the ship and being annoying, assign a family member to every other player. Now whoever is free can be an annoying family member to anyone else who's free. Moreover, you can also get incidental synergy - if the same player is playing the goofy father and the lead starship engineer, then the goofy dad and the engineer get along oddly well. That's fine.

The whole point is to offload the content creation to the players. You need to seed it, of course - tables, NPC character sheets, whatever else is needed. But then the players run with it, try it in different permutations and different places. This lets them control the pace of the play rather than dumping it all on you, and is similar to how fantasy players might mull over what powers to buy on next level-up.

B-plot participation should be worth XP and/or in-game resources. The people who do best at Koboyashi Maru get a commendation point, for example.





Anyway, those are my thoughts.

Star Trek Tabletop Musings

I wrote a really long essay on mechanics inspired by my last essay, but it was too cumbersome to read. So let's talk about a Star Trek tabletop RPG, and I'll hit the same points with a clear example in mind.

Firstly, there's the concept of "class". Nearly every tabletop RPG has the concept of "class", because it's easy for the players to understand and the devs to balance. The issue is that some classes unlock new types of play: for example, only a magician can use spells, only a hacker can hack computers, etc.

Classes like "mage" and "cleric" are pretty seamlessly integrated into fantasy worlds because their abilities let them participate in the basic gameplay (fighting). A mage really sucks at fighting, but they are capable of throwing artillery fire into the mix.

On the other hand, classes like "hacker" are not integrated into Shadowrun very well at all, to the point of GMs just often just handwaving them as NPC-only classes. This is because the added gameplay - hacking, psychic stuff, and piloting - cannot easily integrate into the basic gameplay. A hacker sucks at fighting and has no easy way to contribute to a fight.

But hacker and pilot could actually be integrated into combat a lot more powerfully, and Shadowrun is slowly drifting that way. Use small combat drones, or perhaps live-tweak an allied cyborg to get every once of performance, or screw up enemy hardware, or create holographic illusions, or program heuristic nets in real time to predict and counter enemy actions.

Anyhow, our very first step is to make sure that all our "classes" can participate in our core gameplay.

...

... Our very zeroeth step is deciding what our core gameplay is.

Star Trek is not about combat. It's about seeing new things and meeting new people, and the conflicts that can arise. It's about finding common ground with aliens, no matter how odd: there is no "other" in Star Trek, no faceless masses to gun down. There are counterexamples, but those are usually from later on, after the series began to seriously decay. In the early days, even aggressive enemies like the Klingons were treated like people who didn't like you, rather than dangerous things you needed to kill.

As mentioned in the last essay, science fiction is about the life of people in the universe rather than about proving your own mettle. Therefore, rather than combat, we need the opposite: unification. Consensus. If D&D is like Pac Man, Star Trek is like Tetris. Rather than our basic action removing pieces from the board, our basic action needs to move pieces into alignment.

This also works well with the original combat of the series: it was u-boat combat. Submarines maneuvering, searching for each other in the dark. Pitched battles were rare and both sides usually came out pretty badly.

Unifying the pieces is a fun thing to consider, but we need to consider how that actually works. The advantage of a combat system as the core mechanic is that the GM can add and remove pieces pretty easily, without drowning in complexity. The plot of the D&D arc typically has very little to do with the combat, aside from maybe determining which pieces are involved.

But if we're unifying a large group of pieces, that means the GM is responsible for coming up with a lot of pieces, and setting them up strategically to offer a challenge.

We're not talking about a puzzle game with an optimal solution, but we're still talking about a game where pieces are related in a much wider variety of ways than "ally/enemy". The wider variety of options means that the GM needs to do a lot more planning.

Let's assist.

Instead of thinking of each individual person as the same thing as a monster in D&D, instead consider specific "constellations" of people.

Adding individually would require something like choosing to add "Renault, the old-guard dignitary", then deciding who he is related to in what ways. Instead, we would have a "government in transition" constellation which would have several people stock - the old-guard dignitary being among them.

There are two keys to this approach.

The first is that a person can be in multiple constellations. Renault might be the old-guard dignitary from the "government in transition" constellation, but he could also be part of the "corrupt medical industry vs the plague" constellation, or "industry vs preservation" constellation. Which roles he plays in those will inextricably link the old guard to those topics, and add a lot of complexity to the situation.

The second key to the approach is that the GM doesn't have to preplan everything. The players don't meet everyone at once, and there's no reason to add them all into the game at once. The GM can use our "constellation" system to roughly plan out a scenario, then introduce characters as they are needed. The GM will always know what characters remain "in the wings", and can pluck out various pieces as needed to make the adventure more interesting.

This sounds a bit dry, perhaps, but it's the same as talking about how GMs might populate a dungeon with monsters. There will also be various setpieces and named characters, but it's a different topic.

...

The stats and classes the player chooses are important. Let's start with stats.

We want to choose stats which create the Star Trek universe's unique flavor. Basically, if people can be good or bad at something (a stat), then that thing is going to be very important to our setting.

"Piloting" wouldn't be a stat, because only a few people pilot at all. Similarly, "strength" is a bad stat because it almost never matters.

"Combat" would be a good stat. Spock and Data have very high combat stats because of their species. Kirk has a high combat stat because of his training and build. Bones has a very low combat stat. This variation in skill creates variation in results - not just winning and losing in combat, but whether combat is a route that can be considered. Even if there is no combat, the act of avoiding combat is gameplay in itself.

"Intellect" is a bad stat, because it's too vague.

"Expertise" and "Theory" are good stats, instead. Expertise covers your ability to work with complex technical systems such as repairing starships. Theory would cover your ability to do things in your head, like math, history, or tactics. Theory would probably cover medical expertise as well: Star Trek considers it almost a humanities job rather than an engineering job. So Bones and Crusher would both have a high theory stat, but a mediocre (Crusher) or abysmal (Bones) expertise stat.

We would need a variety of social stats, because a lot of the challenges will be social.

"Leadership" wouldn't be as limited as in most games, because you have a lot more allies than in other games. The engineering staff follows you. The ally you made by rearranging pieces counts. So leadership could be used to move allied pieces faster, further.

On the other hand, "Negotiation" would be how well you could affect pieces that aren't your allies (or aren't operating in unity at the moment), and visa-versa. So Kirk would have a high leadership, while Picard would have a high negotiation.

Lastly, "privilege" is a good stat for us, reflecting a combination of rank, self-assurance, and backing. People with higher privilege can act much more outlandishly and be forgiven more easily - it's our version of charisma. Even when in trouble, Kirk's high privilege meant he could continue acting like an ass and eventually he'd be back on top. On the other hand, Worf has a very low privilege, and therefore he gets stomped every time he steps even slightly out of his comfort zone.

Privilege is an unusual stat, but it helps to define the universe of Star Trek. It's especially important in NPCs, as much of the behavior of guest stars is dictated by their privilege. It gives the universe that slight "dystopian bureaucracy" aftertaste that it often carries.

We could use these six stats: combat, expertise, theory, leadership, negotiation, and privilege.

With those in mind, we can discuss classes and species.

For example, Vulcans and androids have significant bonuses to combat, expertise, and theory... but they have significant penalties to leadership, negotiation, and privilege. (Vulcans like to negotiate, but they're really not very good at it.)

Betazoids have empathic powers which, among other things, radically increases their negotiation and privilege - perhaps balanced by a loss of theory or expertise.

Klingons have a bonus to combat and leadership, but a penalty to theory and privilege. Their low privilege is their adherence to their own aggressive, weird culture - it doesn't mean they blend in. Their aggressiveness is a fish-out-of-water issue, not a high privilege.

Classes could start simply as the branch you choose. Command-branch characters would obviously focus mostly on leadership and negotiation, while engineering-branch characters would be mostly expertise and theory. Security-branch would be combat, leadership, and expertise, etc. Rather than granting bonuses to these stats, they would instead require those stats for their class abilities, much as a a magician has a high intelligence but being a magician does not increase your intelligence.

But... what's the grist between the stats and the conflict?

...

Every decent RPG has "grist". This is the stuff that lies between the stats you chose at the beginning of the game and the actual die-rolling you do while playing. In D&D, the grist is mostly inventory selection - getting the gear you want, choosing the spells you want, and so on.

Those things are enabled by your stats, and then you use those things in combat. Your direct action is to swing a sword. You have a sword because your strength is high and warriors get weapon feats. But you don't "roll strength" against the enemy, nor do you simply rub the number of weapon feats you start with on them. You choose a specific weapon and a specific feat, and apply them at specific times.

In our Star Trek game, we're the same way. Except that we don't care about inventory at all. Captain Kirk does not have a different phaser than Scotty.

Our grist is made up of interpersonal stuff.

Rather than choosing a sword or an ax, Captain Kirk chooses a threatening or gentle approach. Like choosing a sword, Kirk cannot easily change tactics - it'll screw up his rhythm and make the target think he's unreliable and weird. "Why's he acting friendly/unfriendly all the sudden?"

Rather than choosing four spells from a spellbook, Kirk will choose four techniques he excels at. Some might be based on his authority as captain: the threateningly low orbit, the photon torpedo spread, the surprise teleport. These are things he can use without "owning" the abilities, but the abilities make them fast and effective.

Some of his abilities will be based on Star Fleet authority: offering technical assistance, threatening with regulations, setting up trade agreements, having crimes dismissed, etc.

Some of his abilities will be personal: the two-handed chop, dressing everyone up in local clothes to blend in, seducing the locals, monologuing.

Everyone gets abilities. Some are species-related, like the Betazoid empathic power, the Vulcan mind-meld, or the Klingon berserker pain resistance. Some are job-related, like the time-dilation powers Scotty has or Bones' tendency to put people on sick leave. Some are personal, like Riker's charisma or Geordi's visor. Some are based on cultural or social authority, such as Picard's reputation or Guinan's knowledge of everything everywhere.

And a vast number of them are just personality traits like arrogance, loyalty, racism, etc.

All of these "abilities" are a bit different from abilities in D&D. Rather than being permanent additions to your character, they are more like equipment. The player will switch them out whenever it seems like a good idea.

Similarly, traits like "arrogance" are not just a flat role play guide. There are hundreds of things that could be called "arrogance", just like there are hundreds of variants on "short sword". It's possible to refine your arrogance infinitely, and eventually end up with the Star Trek version of a short sword +3 flaming +5 vs ogres. Something like "arrogance about job (+2) and ship (+3)".

Sometimes your abilities will fail you or vanish - just like a sword can critically miss or you can be disarmed. Some are more permanent, like Geordi's visor. Some are quite malleable, like whether Bones feels argumentative this week.

And, yes, sometimes you'll gear up with specific abilities when going on a mission. Kirk can decide not to bring his arrogance along this time, because it'd make the situation worse. He's still Kirk, he's just trying to be less self-absorbed today. If that doesn't work, then he can spend the next time he's alone for a few hours to reconsider his approach.

That's the key to enjoying this game. Your characters' personalities are not some monolithic obelisk. This is about interacting with other people, understanding them, and working with them. Like in real life, your personality isn't always raging out of control.

...

Mechanically speaking, the game works something like this:

The GM comes up with a scenario intended to last 1-3 sessions. The players participating place their 'business cards' (note cards with their character names) into the center of the table.

The players explore the situation by free role playing, and while that unfolds the GM places business cards for each NPC and unfolding situation they encounter. For example, if you reach a high-tech but non-spacefaring planet where there is a disease raging out of control, the GM will place the disease as a card, as well as the various individuals the players meet, such as the planetary governor, the lead medical researcher, and the man dying of the disease. As time passes, the GM may add the military commander, robot police forces, and an oncoming hurricane.

Cards that are neighbors long-edge to long-edge are tightly allied (or being watched) and within shouting distance. Cards that are aligned on their short edge are more loosely allied. Note that tight allies chain - a giant stack of tight allies are all allies with each other. But loose allies do not: you can never be loosely allied with more than two people.

This is a player-focused arrangement, so if there is hidden information that only the GM knows, it doesn't have to be reflected in the cards until it is revealed. Of course, since it's player-focused, much of their efforts will be to align these cards to suit their needs.

Sometimes this is easy: if two players want to team up, they just agree to do so. Assuming no NPC or situation interferes, it's just a simple bit of free role play and the players' cards butt up.

Similarly, moving your card out of alignment is easy - going off on your own, breaking an alliance. It's just some free role play and you can move your card. But your erstwhile allies might not take it well, depending on the situation.

The real challenge is when you are trying to align yourself with non-player cards.

Bones wants to check out the disease, so he decides to move himself vertically with the disease. This doesn't mean he's allied with the disease, it just means that he's going to be in the midst of it. To do this, he'll need to explain how he's finding infected people.

One approach would be to talk to the lead medical researcher. Another would be to talk to the man dying of the disease. If they are okay with it in free role play, then Bones can be led to the disease and hook up with it without ever needing to leave free role play.

But there is plenty of strife. The dying man doesn't want to talk, and the researcher says it's too dangerous to expose him to. Now what?

One option is elbow grease. Bones can strike out into the city (perhaps with some friends) to search it manually. This is a shift action (~6 hours), so Bones expects it to take a while.

If Bones can use an ability to help out, this stands a pretty good chance of working. If he has a specific kind of medical scanner ability, that'd be fine. He could also use a less specific ability - such as medical intuition or intent to help everyone. The downside of the broader abilities is that he must have them equipped to use them, which means they can be used against him by the GM later on. It's much harder to use a medical scanner against you.

Bones has to roll against a particular target number on a D10. This number can be higher than 10 or lower than 1, but you may still want to roll, because the amount of failure or success matters.

Each point of success or failure can be spent to reduce the time spent or to increase the result's effect. If Bones succeeds by only a little, it could take him 6 hours! But if he succeeds by a lot, it might take him only a few minutes, or maybe he discovers a massive number of sick folk.

If Bones fails, he'll get in trouble. There's no such thing as "merely failing". If he fails by a small amount, he'll get arrested after 6 hours. But if he fails by a large amount, he might get shot after only a few minutes! Bones chooses how to spend his failure points, and he has to decide whether to fail fast and harmless, or slow and painful. Failing slow is really useful, because that means someone can interrupt his search before he actually gets caught, essentially negating the result at the last second. This requires that person spend "convenience points", but it's better than getting shot.

Anyway, that's if Bones has a suitable ability. If he doesn't have any suitable abilities, he can fall back on pure stats - probably privilege or negotiation. This may or may not succeed, but either way you ALSO fail by the exact same margin. If you roll a 3-margin success, you also have a 3-margin failure. If you roll a 3-margin failure, it's just a failure. This is the punishment for over-reaching.

Let's say Bones doesn't have any suitable abilities, but would prefer not to risk the automatic failure. So he instead chooses to win over one of the people who might be able to help him.

Let's say he chooses the lead researcher to buddy up with. He could also tail them, threaten them, etc, but let's say we're going the friendly route. The goal is to form a loose alliance (short edges of their cards butting up). The lead researcher is pretty antagonistic at the moment, so this might not be easy. How to accomplish it?

"Form a loose alliance" is a specific action, and there is a specific set of approaches to doing it. The negotiation stat is usually the backbone off this approach. Each time step dedicated to it reduces the difficulty - if Bones negotiates for a scene, he gets +0. An hour, +1. A shift, +2. A week, +3. In addition, he'll want to use an ability, or he'll run into the "autofail" problem again.

Well, Bones doesn't have any real negotiation abilities, and his negotiation stat is rock-bottom. So he has to fall back on privilege, which can always be substituted into these kinds of situations if you don't mind a small penalty. By ignoring cultural and situational barriers, Bones can just hang out with this researcher and try to make friends. Bones has a very high privilege - he's a grumpy old luddite weirdo that everyone loves.

Bones decides to hang out with the researcher for a phase to ally with him.

If this seems too hard, Bones can soften the researcher up by de-escalating. Escalating and de-escalating are important tactics to control the situation without directly moving cards. De-escalation is done by focusing on shared elements and ignoring potential thorns. Both Bones and the researcher are medical, and that means they share a job that relies on theory. Bones can use theory (and, hopefully, some ability) to de-escalate, then use privilege to form a loose alliance.

Even if Bones has no abilities to help with this, he can juggle timing to make it work out. He gets smacked with an autofail if he works without abilities, but that's okay. He'll spend all his success points on lowering the time to success, then spend all his fail points on increasing the penalty for failing. Now he has a few hours between his success happening and his failure happening, and in that space he can take advantage of the alliance.

Well, anyway, that's just a very basic set of ideas. I haven't polished it much.

Science Fiction Games are Different

When we look at tabletop RPGs, we see that fantasy is the most popular. Nearly everyone plays a fantasy RPG. Even famous science fiction games like Shadowrun aren't really that widespread. Plus, it's mostly a fantasy game anyway.

Why are science fiction RPGs less popular? It's not the genre itself - science fiction computer games, movies, and comics are at least as popular as fantasy.

I've thought about it, and I've come up with two big problems with science fiction tabletop games.

The first is that they aren't as easy to imagine. Science fiction games tend to have bigger, stranger things to think about. That means that the player has a harder time imagining them. It's easy to imagine a swordfight, trekking through a bog, sneaking through the dark, or looking out over a mountain range. At the very least, we've played at those things in real life. But it's much harder to imagine rescuing a stranded astronaut or saving the day with a piece of clever code.

These bigger, stranger images are the ones I prefer, and I think a lot of people feel the same way. Although most science fiction fare these days is basically action flick crap with a science fiction gloss, it still has big, powerful imagery. In computer games and movies, it's easy to show these images. An AI flickers into existence. A plague mutates the local wildlife. A gleeful coder hacks a mainframe while surrounded by massive screens. Biological cells bond to plastic, and your eyes reboot into Terminator-vision...

But when you look at a scrap of paper with words on it, those things are hard to portray. If I see a picture of a sword, I can immediately understand everything and imagine going to battle with or against the sword. If I see heavy armor has a speed penalty, I can immediately imagine a slow, armored knight against a fast, unarmored rogue. If I see a castle, I can imagine a siege. Etc.

If I see a robot... the images don't pop into my head nearly as fast. The robot looks cool, but there's no "AND THEN" going on. I don't automatically think about the scenarios the robot would be part of. Same with space ships, cybernetic enhancements, life support systems, computers...

Now, the first thought that popped into my head is that you simply need to be a lot more aggressive. When you describe a robot, lay out a fragment of a scene to give the player something to grip onto. When you describe cybernetics, have an NPC talk about something that happened to them because of the cyberware.

If it's hard to imagine, give the player a leg up. Easy enough!

But... this brings us to the second big problem with tabletop science fiction games.

...

Fantasy games can be thought of as running around in the back yard waving a stick around. Science fiction games can be thought of as running around the house with an armful of plastic toys making "whoosh" noises. As soon as you succeed in landing a plastic rocket on the couch and your action figure gets out to explore the surface of this alien world, you'll understand the appeal of science fiction.

That is, fantasy games are about your personal merits. Your strength. Your cunning. Your speed and willpower. You may use all sorts of equipment, but in the end it's about proving your mettle.

Science fiction games are mostly about STUFF.

Your space ship, your antigravity belt, your supercomputer, your robot arms. And of course, all the other stuff: that nebula, this space station, that mind-control laser, this ancient databank...

"Wait! Fantasy games have tons of STUFF in them!"

Definitely. But science fiction is fundamentally about how people behave when situations are different. The STUFF in these settings defines how people behave, what questions are being asked, and so on.

That said, it's definitely true that there is a vast amount of STUFF in a fantasy game. Massive amounts of stuff. In fact, most fantasy games have more stuff in them than most science fiction games!

Even the giant stack of guns in Shadowrun doesn't hold a candle to the array of weapons in D&D. And it's not just a matter of how old and widespread the systems are: D&D is fundamentally more stuff-heavy because it lets you arbitrarily augment or craft your own stuff. Enchanted swords, special potions, new spells, armors made of rare new materials. D&D has a literally infinite variety of swords. No matter how many different guns with different ammo types Shadowrun lists, they simply cannot keep up with that!

Hm. What the hell do I mean that science fiction is about "stuff", then?

Well, look, fantasy games are about personal merit. But there's not a lot of personal merits in them. There's a few stats, an alignment, maybe some personality traits, and a class. These things determine your personal merits. They determine who you are.

In turn, these merits serve as an anchor. The game has a vast statistical maelstrom of STUFF. This is the meat of the game, where all the players struggle and fight. The merits you have serve to anchor you within this maelstrom, so you can participate without getting swept away in confusion. You're a mage with a high speed? This is where you stand. A warrior with low charisma? This is where you stand. Your personal merits mean you'll approach the situation like such.

Most science fiction tabletops take this same approach. But that misunderstands a lot.

Because fantasy games are about your personal merits, they feature things which are easy to personally imagine. Even a dragon or a giant dwarven hold is something an individual can imagine pretty easily. They can hold their merits up against these challenges and see what kind of struggle would happen, what kind of standing they have. The vast array of statistical gear and spells and such allow them to grapple with these figments, pushing and pulling at the things they can do... but the things they can do are still rooted in their perception of who they are, their personal merits and traits.

Science fiction tabletops try to hold that same line, but the setting of a science fiction game is about STUFF. So you're a hacker, a smuggler, or a space princess - you have all these traits... but the setting is about a planet that's being colonized, or an ancient civilization, or a disease, or a robot rebellion. These are not things affected by your personal merits.

A smuggler or hacker can certainly get involved with all these scenarios, but the scenario is both larger and more lively than they are. A hero could imagine fighting a dragon... but a hero is of a lot less use when a radiation storm is inbound. A hero can imagine walking the ten thousand steps of fire... but those ten thousand steps are just a barrier to overcome, not a living thing like a space station full of refugees.

In the end, the setting sabotages the game. The game is built around individual merits, but the setting doesn't give a shit about your individual merits. The setting cares about STUFF.

Well, stuff isn't bad.

See, fantasy games can build this giant maelstrom of stuff on top of a setting that cares about personal merits. Science fiction cares about stuff, so it may be possible for us to build a giant maelstrom of personal merits.

This is really what science fiction is about. It's about a foundation of specific assumptions, and seeing how that affects the people. "What if space ships could travel faster than light?" "What if we were psychic?" "What would people do if aliens invaded?" "What happens when robots can do our jobs better than we can?" "What if our TVs were able to watch us?"

The STUFF here is very specific and limited. Robots that can do a specific kind of thing. A government that acts a particular way. A space ship that can move a specific way. There's not 10,000,000 different kinds of robots, each with their own stats - it's just a few kinds of robots to set the stage properly.

And from that foundation blooms an outpouring of human behavior. How do people behave? What do they do? How do they feel?

This is where the powerful imagery in science fiction tends to come from.

The images Roy Batty describes - "Attack ships on fire off the shoulder of Orion... c-beams glitter in the dark near the Tannhäuser Gate" - these are not things with any clear image, but they can still make you shiver. They are mysteries to us - but Roy has been there. He's been there, and he remembers, and he's fighting to live.

Roy's life is defined by the stuff he's seen. Roy's struggle is defined by the stuff he's seen. Roy is defined by the stuff he's seen.

By stamping down a foundation of stuff, we can allow people to shine, both as individuals and as groups.

So why don't any science fiction games work like that?

Well, because nobody's written one yet.

...

I can't pretend to have a good set of mechanics in mind. I'm still thinking this through. But logically, a few things seem clear.

First, the stuff is less complex and the personal merits/beliefs are a lot more complex.

Second is that you would choose your stuff more carefully than your personal characteristics. You don't need to know if you have a strength of 14. You need to know that you have an antigravity belt or Jedi powers. Those will provide a foundation for interacting with the challenges in the game. The personal merits like strength can vary over time or be completely unimportant.

Third is that your personal merits/beliefs would not be concrete. For example, in a fantasy game you'd choose "self-confident" as a trait and it'd stay forever. In this game, the self-confidence comes in many forms. There are times when you'll lose confidence, times when you'll only have confidence in certain ways, and times where your confidence doesn't matter at all. Just like wielding a sword in a fantasy game: you can drop it, replace it, and sometimes you'll leave it sheathed.

Fourth is that combat cannot be the focus. Combat is fundamentally about personal merits, so it can't be the foundation mechanic. The foundation mechanic needs to be about stuff. You won't struggle to kill goblins: you'll struggle to push through a mind-control laser beam. You'll struggle to get robots accepted as people. You'll struggle to keep death at bay.

...

I hope I've been clear. Let me know if you understood what I was trying to say.