How I Adapted Tribe 8 to Fate Core

I was reading an RPG.Net thread and thought it might be helpful if I outlined the method that I used to adapt Tribe 8 to Fate Core.

Of course a lot of this is in hindsight, because the adaptation was an iterative process starting several years ago with Spirit of the Century, moving to Strands of Fate, and finally settling on Fate Core where it's going to sit for a while. It's taught me a number of valuable lessons, most prominently one that you hear a lot:

Adapt the setting, not the mechanics

It's a concise little saying, but not without landlines. For me, when coming into it from a highly detailed setting with tightly integrated mechanical bits that work just so, it's hard to divorce preconceived notions of how things should work from how they already work in the parent system. So something I prepare myself for now is tearing everything apart and putting it back together - I make no plans or have no expectations that anything mechanical will be ported to the new system. Concepts, yes. How those concepts work, no.

Getting Organized
One thing that helped tremendously when adapting Tribe 8 was sitting down and figuring out exactly where I needed to put my effort. There's no need to re-examine and tweak the entire system to fit the setting. At a high level, I'd say that there are four areas that need to be considered:

1. Skills (or Approaches for FAE)
2. Extras
3. Mechanical tweaks (including stunts)
4. Setting-specific considerations, such as setting aspects, genre-enforcement, etc.

The reason why I put setting-related things last is because they can often derail an adaptation. Depending on the game, there are things that can be hard to quantify. Plus, it might be beneficial to save them for when the players actually get involved - in essence, saving a bit of the collaborative world building for them.

What Do You Want To Do Today?
The reason why I choose skills first is because exactly what you want characters to do in the setting is pretty important. Tweaking the skill list and making any additions, merges, or removing skills does a lot to reinforce the feel of the game and make it "feel" like the setting.

For Tribe 8, I left the base skill list alone for the most part. I tweaked Contacts, Crafts, Investigate and Resources to better match the setting. I knew that I was going to be further tweaking Resources with an Extra and tying it to a new skill, Survival, so I simply created a placeholder for the Barter mechanics. I removed Drive and added a Ride skill, and added Survival. Finally, I knew that I would need placeholders for Dreaming, Sundering, Synthesis and Technosmithing - basically, the magic of the Tribe 8 world.

Extra or Extraneous?
Once the skill list was fleshed out, I set out about defining various Extras. The key was to not pump too much into it for the sake of novelty. For example, in an early draft I created a new method for defining Contacts that I ultimately decided was too much and removed.

For Tribe 8, I knew I had four major areas I needed to create Extras for:

• Social groups
• Bartering
• Equipment
• Magical abilities

The first three were purely emulation of elements I wanted to either bring forward from the Tribe 8 setting or things that I wanted to bring out. Social groups are pretty important in Tribe 8, as is bartering, and both had a lot of implied support without anything really to hang them off of. Equipment was something that I knew I wanted to be a little more defined (particularly weapons and armor), without being too detailed and fiddly. I saved the magical abilities for last because they were the most complex and there were a lot of factors to consider.

Dealing with porting over things like magic or other special abilities benefited the most from completely ignoring everything but the fiction regarding the powers. I've talked about ludonarrative dissonance a bit, and this is typically where it worms its way in to tabletop rpgs - the description of how something works doesn't line up with the mechanical implementation. I didn't necessarily want to balance the abilities against one another (balance, to me, is a knob on my stereo) but I did want the various abilities to snap together properly. I went through multiple iterations, each stripping away some assumption I had that I thought was based in the setting - but only turned out to be limitations of the Silhouette system.

For a different setting, winnowing through the extras might mean divorcing a mechanical assumption completely. Essence in Exalted comes to mind - there's a strong urge to retain it because of how embedded it is in the setting. Thinking outside of the box may not actually lead to not having Essence at all, but the process of trying to do it without mirroring the original mechanics can lead to a better implementation.

Just Hit It Till It Works
The next to last thing I tackled was specific mechanical tweaks that I wanted. In general, I'd say that unless there are overwhelming reasons to change the basics, leave well enough alone. That includes aspects and their use, stress, consequences, etc.

However, when the Fate System Toolkit draft was released and I got around to looking at it, I did find some changes that I wanted: namely scaled invocations for use with Synthesis and conditions instead of Consequences. These changes weren't made lightly, but fortunately I had just come back to the document because of another thing I've found helpful...

Shelve It For A While
After working on in-depth writing, such as a new adaptation, I find it's useful to set it aside for at least a few weeks and come back to it with a fresher set of eyes. It helps snap things into perspective and identify rough spots. Typically this is the time that I start to remove extraneous elements and generally tighten things up. Depending on the size and complexity of the project, it might get shelved more than once. Even though I consider Fate of Vimary to be "done", I'm planning on looking it back over in the near future as I get closer to starting to play.

Play It, Revise It, Retcon It (If Need Be)
Speaking of which, actually playtesting the hack in some fashion works wonders. I have to admit I haven't had the chance to do it with Fate of Vimary, but some of the decisions I made were based on prior playtests of similar components. In the past I've learned a lot more from letting my hacks into the wild by playing them. Even if it's just one component in isolation, with only one other person, it's well worth doing. A lot of harder to quantify elements like setting aspects or other larger scale bits can be hashed out either just prior to or during play.

Even after (or in lieu of) playtesting expect revisions. Some concepts that look good on paper don't work quite as well in actual play. I usually find that I already knew which ones were going to need to be tweaked or dropped. They'll typically be the parts that I fiddled with a lot or couldn't quite wrap my head around the implementation. How I've implemented conditions in Fate of Vimary is a good example. There are a couple spots that I don't feel are ironed out yet, so I'm letting those concerns rest until we actually play it out. It might also mean outright retconning an implementation if it proves to not work correctly. The important takeaway is that it's really difficult, especially for an involved adaptation, to get everything nailed down ahead of time.

Your Character Knows More Than You Do

Hiyo, I'm Bryce. I'm one of Wil's very old Palladium characters. He hasn't really done a lot with Palladium in a very long time, and with me in even longer. But just because he's not really played any Palladium doesn't mean I'm not in here. There's a couple others in here too. On my way up, I saw some crazy woman with  metal in her face and tattoos babbling about rivers and dreams. Creeped me out, so I just kept walking.

What I do know is that I've forgotten more about my world than Wil knows. See, I actually live here. I'm a mage, and for sure Wil doesn't know horsecrap about magic. The willpower required, the studying, the years of apprenticeship. So when I know that there's an herbalist on Market Street because I had to slog my way over there every morning to pick up laxatives for my master (don't ask), Wil doesn't know it until it becomes important to me. Like when I need a particular herb for an antidote. So I'll tell him, and then maybe he can mention that "Bryce thinks there's an herbalist over on Market Street that might have the antidote" so we can get on with things.

Now, that might not necessarily be true any more. Maybe the place burned down, or the herbalist moved away for some reason. I wouldn't know that either if I hadn't been there in a while. If that was before Wil started playing the game, I don't think anybody would know that. It still doesn't mean the herbalist wasn't there though. I would know. Because I live here.

You often hear about how to handle the player knowing more than their character does, but seldom does anyone talk about the character knowing more than the player does. I can guarantee that the latter is more extensive than the former - at least when it comes to the character actually functioning and living within the world. This process I'm going to call "reverse immersion", because it's letting the character run the show when appropriate. It's a conceptual-type-thing I've had knocking around in my head for many years, and is actually very close to the way I "immerse" in my characters. I let them act through me, and not the other way around.

Of course, since the character is just a construct of the player this puts us in an awkward position. When the player says the character sits down at a table in the tavern and picks up a knife and fork to start eating and the GM says, "They don't use forks here" - the character would have already known that, even if the player didn't. That one's easy though...the player is merely channeling their own experience, so of course the character never picked up the fork. The character chides the player for cultural insensitivity (forks were banned after that incident some time ago), there's a tiny retcon, and we can continue with the game.

But it seems like details that have a bigger scope are a sticky wicket for some people. Like Bryce's herbalist shop. Some GMs would positively bristle at the idea of a lowly player adding something like that to their game world. Some players would complain that making such a statement without the GM handing them that information breaks their immersion because it pulls them out or makes them think or something. What I'm here to tell you is that in both cases, they're not listening to the character - and the character is the one who knows. Because let's think about this for a minute: we've already established that Bryce is a mage, and he had his apprenticeship in that city. It's perfectly reasonable that he would know where there's some herbalists nearby. Now whether Bryce, through the player, says he knew of one on Market Street or the GM tells the player Bryce knew of one is immaterial. It makes no difference at all, other than scuffing some imaginary and arbitrary line that some people think needs to be drawn between the GM and the players. Either way, if Bryce needs an herbalist shop we already know there's going to be an herbalist shop, so we might as well let him lead the way.

In the end, these types of situations help keep the players engaged and does more to give voice to the character the player has in their head. Shutting it down when it happens just because of some notion of the players being allowed to interact with, but not contribute to, the world only serves to hurt characterization in the name of...nothing. Absolutely nothing. It serves no purpose whatsoever to set those arbitrary limits, except maybe feeding some ego trip.

So, to GMs and players alike, it's not completely all about you. Sometimes your characters have things to say, too. You just have to listen.

Zero-Sum Games And When To Avoid Them

In game theory, zero sum games are when in order for one player to win, another player has to lose the same amount. Poker and many board games are an example of this, and it works well for them. Roleplaying games, by their nature, are not zero-sum games - but they can contain zero-sum conditions. Whether they are good or not depends. Zero-sum conditions can be intentional or unintentional, and either way can have a negative impact on the game.

When zero-sum conditions appear in combat systems, it's usually due to a choice nullifying another choice - which means there honestly wasn't a choice. For example, if in a game system the only effective defense is to parry, but you have to sacrifice your next action to do it, that's a zero-sum result. It happens with weapons and armor too, where armor and weapons consistently null out one another's offensive or defensive capability. It isn't bad - there's strong real life precedent for it - unless there's nothing else in the rules to help break the cycle. This may also happen in games that force accuracy to be sacrificed in the name of damage. More accurate weapons don't do enough to get through armor while heavier weapons aren't accurate enough to hit anything.

Sometimes the mechanics tip things in one character's favor too much, and if they don't provide a way to recover it becomes zero-sum. Death spirals (as much as I like Silhouette's damage rules) are an example of this. Once a character has taken damage they are more likely to take more damage, and it just continues to get worse. This means, in most cases, the character with the first significant success will win. It also doesn't help that characters in Silhouette with identical offensive and defensive skill levels have a high probability of not being able to hurt one another - making it two zero-sum games for the price of one (you can't hit the other guy most of the time, but if you actually do hurt him now you're more likely to keep doing it).

Any point buy-type system where the net result is no change are zero-sum. This is typically intentional - for example, there's no way to be ambidextrous without either spending points or taking a disadvantage. I don't find point buys like that to be a helpful way of maintaining character balance (a concept I'm dubious of as it is). I understand the reasoning, and that some people prefer it). I'd rather have distinct spheres of character ability (such as traditional attribute/skill splits, or skill/stunt/aspect in Fate) where points can't be traded between them. Balancing that out is a lot easier than trying to figure out if +1 DEX should be worth the same number of points as being agoraphobic.

That never gets old

Finally, we get to my last example of a zero-sum condition in an rpg: the players versus the GM. In games where the GM takes on an adversarial relationship with the players - especially more traditional games where there's nothing the players can do about it within the system - there's typically only one true outcome. The players "lose" (their characters are killed) and the GM "wins". This is nicely summed up on the TV Tropes entry for Killer Game Master. But it doesn't have to be the over-cliched extreme of the Killer GM. For some GMs,  it's "common sense" to do things like increase the difficulty of every encounter, skill check, die roll, etc. as the characters advance, in order to give players a "challenge". While it's great to tailor something to the power level of a group, doing so by rote can result in a zero-sum if everything included in the encounter completely nullifies every advantage the PCs have, then there's no real reason for the "challenge."

After all of this, it might seem logical to ask, "So what do I do about zero-sum games I don't want?" The answer isn't clear cut because it depends on the situation. Games like Fate Core address this by allowing invokes after the dice are rolled (meaning the use of the Fate points aren't a complete gamble), as well as in the concept of "failure as success at a cost". Other solutions might mean tweaking portions of the system to allow a loss for one player that doesn't automatically translate into an equivalent gain for another.

In the end, not all zero-sums are bad. Examining them is probably a good idea, though  - if only to make sure that the zero-sum condition is something that was intended (or even fun).

Recursion in RPGs

Before you read any further, I need you to go to Google right now and search for "recursion" and take note of what Google suggests under "Did you mean". Being a database guy, recursion is a very good friend of mine. But what does it have to do with rpgs? There are two ways I can think of. Any time the characters are playing  another character within the game, or the game acknowledges that the characters are doing so, the game is recursing. Obviously this doesn't happen very often.

Pretty much exactly like that

The Dream Park rpg was one of them. You played a character who had a character in what amounted to a high-tech LARP. We actually never played the game like that (I used Dream Park for a short lived fantasy game). By the way, I loved Dream Park's Beat Charts and still use them for helping pace games. Immortal: the Invisible War started its recursion one level higher...by default you played yourself, in the game. It could also be said a game that admits it's a game is recursive. HoL is an example of this, as are a couple of RPG.Net joke games like D02 and Man What. A second example is actual recursion in RPG mechanics. This is both harder to find and not nearly as useful a concept. The closest I can see would be games where you keep rerolling if you get a certain result. We used to do this in Interlock - when you rolled a 10, you kept rerolling and adding until you stopped rolling 10s. Another example would be those tables where if you roll a certain result you roll again. Theoretically you could keep rolling that "roll again" result (even though that would be highly unlikely). Honestly except for the rerolling concept I can't think of any time that recursion like this would be desirable. It is something to keep in mind when designing mechanics or tables so it doesn't become part of the game accidentally.

Quantum Libet

Quantum libet is Latin for "as much as you please" and is used in medical shorthand on prescriptions. Seeing this (and struggling to come up with a post topic that starts with "Q") made me think about a number of related concepts that I've been flitting around for the past month or so. Namely, the ideas of "Yes, but...", failure as a costly success, and die rolls setting the threshold for how much success will cost instead of being binary success/fail.

When I think of "as much as you please", it brings to mind the "Too Much Is Too Much" rule in Teenagers From Outer Space. Effectively, when a roll was too good it meant there unintended side effects. The classic example is the character that tries to develop a pheromone spray to attract a girl he's interested in. The player rolls so well that it not only attracts her, but every female in the entire school. Other examples are the hacker who's so good at covering his tracks that he fixes something else that was wrong on his way out, or the accountant that cooks the books so well that he is never audited and gets a massive influx of unwanted attention or clients. It's the opposite of failure being "success at a cost" - it's "success with strings attached."

From a Fate Core perspective, the half-assed idea I have is when the roll is substantially high enough over the difficulty then the GM can bring quantum libet into play. I think 6 or 8 over might be about right - either way the idea is to make it very difficult for this to happen unless the character is 1) highly skilled, 2) rolling for low difficulty tasks or 3) invoking lots of aspects. In this manner, the player is almost asking for "too much is too much" by either rolling for a low difficulty task they are sure to beat by a huge margin or are stacking lots of aspects. I'm thinking the GM would place an aspect on the character (possibly called Quantum Libet) or just reserve the right to have the success come back around at a later time. It isn't something that can directly harm the character and needs to be a logical extension of what the original roll was for. It's not intended to be an actual "punishment" for rolling too well. I can see this method used to discourage players from dumping all of their invokes into rolls ("blowing their wad", as it were) when they don't need to.

Obviously this would be something totally genre (and table) dependent. I think it would work for light-hearted or generally less serious games better than gritty ones, and wouldn't be something that was a hard and fast rule for every die roll...only when it can liven things up a little bit.

Object Oriented Principles in RPGs

Being a programmer, I like to think programming concepts with regard to games and rules systems. Sometimes I go a bit further, like the time I built a .NET Silhouette vehicle design program or built a SQL database out of the Mekton Zeta Plus construction rules. Today's topic is object oriented principles in roleplaying games. Before we get into that, a couple caveats:

First, I wouldn't be surprised if this post has one of the lowest view counts of any post on this blog. I'm fine with that - it's more of a philosophical pondering than anything else.

Second, for anyone who's not familiar with object oriented programming languages this is a really good article (it is long, I'll wait while you read it): What Is OOP. If you don't want to read it (or just want to hit the salient parts) I will only be discussing these three things:

• Abstraction: Stripping something down to its basic elements or characteristics.
• Inheritance: The reuse of abstractions to build new ones.
• Polymorphism: The ability to use the same interface but with a different implementation.

Now almost all game systems do these to some degree (as well as many of the things the article's author says "isn't OOP").  A good example of abstraction is a weapon. In the real world,  the subtle differences between weapons probably have an impact, but it's too hard to keep track of that stuff in an RPG. Instead, the system abstracts out the basic elements: damage, range, accuracy or balance, etc. Some of them go into more detail than others - such as durability or quality - but all weapons have the same basic characteristics. They use inheritance to create, say, a magic weapon. It uses the base weapon class but then adds a attribute such as "+1" to it.

Polymorphism can typically be seen in mechanics. Fate Core is a perfect example of this. Each of the four basic actions you can perform with a skill (overcome, create advantage, attack or defend) has the same interface (the die roll), but the implementation within each of them is different (the rules inside them are different). The output - failure, tie, success or success with style - is also the same. As an aside this is also an example of encapsulation - the inputs and outputs are the same, but the interior "code" of the action is a "black box" (at least in terms of the output not caring what happened inside the action).

Fate does an excellent job of embodying these concepts. Take the "Fate Fractal" for example. Anything can have an aspect, or a skill, or a stress track - up to and including the setting itself. I recently implemented survival rules where as the players run out of Resources, the setting gains an aspect representing their Struggle For Survival. As their Resources go into the negative, the setting picks up three skills: Hunger, Thirst and Exposure. These skills can be used to "attack" the characters. This implementation is fundamentally object oriented in nature.

Most systems can accommodate something like this, but Fate Core (and other Fate games) facilitate it through design, and are especially good at it. This isn't to say that an rpg based on  OOP principles is "good" and one that doesn't is "bad". Game systems aren't code or operating systems in the most technical terms. But I think some games, like Fate Core, definitely do it better than others. There is at least one game, Alternate Realities, that claims to "object oriented". I've taken a look at it and think it's much more complicated than it needs to be.

Also, on a related topic to object oriented principles is a rather lengthy PDF called Design Patterns of Successful Roleplaying Games by John Kirk. Kirk identifies various design elements and then uses those to try to determine the design patterns in various rpgs, through a lens similar to software design patterns. It is highly detailed and I think it's successful in a lot of ways. Obviously, because of the sheer variety of rpgs there are likely to be some that slip through the cracks (and I predict at least one comment saying how such-and-such rpg doesn't fit any of those patterns). I wouldn't say it's required reading for all game designers, but just as it can be helpful to have an eye toward high level object oriented principles when designing an rpg, being aware of the possible design patterns can't hurt either.

Non-Protagonist Characters

First off, I'm not trying to redefine the "non-player character" Cougartown-style. I've seen the term "Non-Protagonist Character" in several games, and it fits how I consider NPCs better than "non-player character" does. If you don't like it, there are extensions for Chrome such as Word Filter and similar ones for Firefox (and I'm sure others) that can replace words in a live webpage. Have a field day.

NPCs have always been somewhat hit or miss for me. They're arguably the most valuable means for the players to interact with the game world (aside from the PCs themselves). When NPCs are done well, they can bring the game to life. When they're not, they can turn the whole thing into a parody of itself. The unfortunate thing is that, as a GM or player, I'm a poor actor. I suck at voices and I suck at portraying mannerisms. I can do expressions okay because I do have a face. Overall I'm in this gig for storytelling, not drama club.

This means I fall back on something that I am (or think I am) much better at - writing. I tend to describe things in narrative terms and seldom take on the direct role of the NPC. Instead of sternly saying, "Not in my courtroom!" I'll say, "The judge sternly says, 'Not in my courtroom!'". I'm not quite sure it makes my games better or worse, but I've gotten few complaints. It goes along with the very astute advice, "No silly voices." To me playing the NPC is not much different than describing the scene, or narrating the action.

Describing the NPCs in this manner, rather than "playing" them, means a constant tightrope act between making the NPCs "pop out" from the background and having them just be part of the scenery, forgotten as soon as I stop talking about them. By the way, I suffer from this as the GM, and I'm sure if I was trying to "be the NPC" it might not happen so much. Because of this, I'm always on the lookout for ways to improve my NPCS. Having key mannerisms or phrases are pretty much part of GMing 101. Just as I do when writing fiction, I usually draw inspiration from real people that I know. I can loosely mimic their behavior, speech patterns, etc. and hope that the character comes across as more than a cardboard cutout. Sometimes just Googling for a general image gives me an idea for how to portray the NPC off of.

But I think have a new technique, or at least a way of looking at NPCs, that I'm itching to start using. It may have originally showed up in the Dresden Files rpg, and is also a part of the Spark rpg. They are called Faces. Essentially, a Face is an NPC that is the essence of a particular location or faction. I'd actually extend that out to include scenes, concepts, themes or moods. For example, a tavern where the PCs frequent might be populated with dozens of NPCs - only one of them is the Face of the tavern. It doesn't even have to be the barkeep, either. It could be that old man who's always sitting by himself, mumbling to himself with odd random outbursts. Or the hulking Northerner who is always challenging people to arm wrestling matches. The Face might change with the night of the week, or the season. By making the NPC tied to something else,    I think it would help cement the NPC in my head and improve the portrayal.

You know, that guy

Luckily for some games, like Tribe 8, this is an extremely easy thing to do. Various characters have already been created that are the Faces of their outlook, tribe, faction, sect, etc. That doesn't mean they're the only NPCs for each of those, but it helps anchor them a bit and increases the chances that I'd use them in the game (especially, as I pointed out in yesterday's post on Metaplot, I now know which characters are important and which aren't). One way to look at it is a form of "What's my motivation?" (although that is a remarkably good method too). Instead, it's "What am I giving a face to?". Once I get this game up and running, I'm certainly going to give it a try.

Metaplot

As I start to wind down writing the rules for Fate of Vimary and begin to turn my eye toward actually playing, I'm going to have to confront the elephant in the room for any Tribe 8 game: the metaplot.

Now to make sure this discussion gets off on the proper foot: I'm for metaplot. Not all metaplots everywhere - while I've not played through, for example, the metaplots in the Old World of Darkness, or Torg, or 7th Sea, I understand they had quite a few problems. Heavy Gear's metaplot I am familiar with and I thought it was remarkably well done. Tribe 8's metaplot I have always liked in principle and in the direction the story took, but not always in execution. Children of Lilith is one of the best of the Tribe 8 metaplot books - it starts it off with a bang and overall has some great sections - but it still had some warts (particularly in the railroady category).

Of course, there's no need for a Tribe 8 game to follow the metaplot. The setting is rich enough in story opportunities to touch nary a portion of the metaplot if the group so desires. Aside from any number of ideas I have for non-metaplot campaigns (one of them can be seen in Saturday's blog post, Fate of L'san), it's always been my desire to see the entire thing through.

Luckily the metaplot itself isn't as large of a problem as it might seem. Fate Core has the perfect advice for how to handle it:

You don’t need to have everything planned out (in fact,  you probably shouldn’t  given that no meticulously planned story ever survives contact with the players), but you need to have an idea of where things begin and end, and what might happen in the middle.

Without giving away too many spoilers (at least I would hope, it's the name of the book) the first chapter in Children of Lilith involves the player characters finding Lilith. There are some bits in the middle that could happen, but they're not as important. The beginning...I see as one way that the metaplot could begin, but honestly this needs to be the most flexible part, dependant on the PC's motivations and goals. That much should be child's play for virtually any GM.

The bigger thing to deal with, especially in a game like Fate Core where the players have much more authorial power than other games, is NPCs and what can be done to them without totally hosing everything. Most metaplots have NPCs that are intended to be important to the story as a whole. It shouldn't be  in terms of how important the PCs are (although poor metaplots sometimes fall into this trap), but because they've been worked into various levels of the plot. Some of the best I've seen weave these NPCs in early on, often with little or no indication of their ultimate importance. If the players establish the wrong detail about one of these characters (including their death) can cause the GM to scramble more than the players generally frakking around with the plot. "You decided you didn't want to do anything that I had set up...fine, I can handle that. But then you killed Marisol McSue! What the hell am I supposed to do now?"

Or just get fed up and end the whole thing.

There are a number of ways to mitigate the impact of player action when it comes to NPCs. First the NPC roles in the metaplot need to be as vaguely defined as possible. If an NPC's role is too specific, something is guaranteed not to go as planned. Second, there should be at least one or other NPC that takes a similar enough position to be able to step in. Now this can become complicated if one of the main drivers of the metaplot is like the King of Gondor or something, but that's why you have a Steward to back him up (and perhaps a way to shift gears in how things develop from point A to point C). These are things that a GM can do in any game, pretty much regardless of whether or not the players have the ability to modify parts of the setting or change the course of the plot.

Heavy Gear had a "chess piece" system that designated how significant the NPC was to the metaplot. Tribe 8 never had it, but it's not hard (now) to figure out which NPCs are important or not. Aligning these characters to the classifications of NPCs in Fate Core is the first step in figuring out whether the players should be able to muddle around with an NPC. If the NPC is important, the GM can simply veto anything the players try to establish that doesn't fit. This is something that GMs do anyway, so it's not a huge stretch. It will be a dead giveaway that the NPC is essential to the plot as a whole, but I see this a feature and not a bug. An NPC's importance shouldn't be a mystery to the players anyway - it's what that NPC is going to do that should be the surprise.

Of course, NPCs can easily be the subject of an entire post on their own - which is exactly what I have planned for tomorrow.

No Wandering Murderhobos Allowed

Before going any further, I'd like to submit a disclaimer. In no way am I suggesting that the "typical RPG adventuring party" of what amounts to a bunch of strangers with no common bonds is 1) BadWrong play or 2) something that happens in every single roleplaying group. But  from anecdotal and personal experience it happens often enough and can present certain types of challenges. Hopefully if this has ever been an issue for you, there will be something here you may not have considered before.

A discussion about the community rules in the Burn Shift setting for Fate Core got me thinking about generalizations of player character groups over the years. In particular, the concept of the "murderhobo" - a player character with no ties to anything, who simply moves through the game world wantonly killing and doing whatever they want. Obviously this trope is a gross exaggeration, despite how much the word amuses me. But the reason this stereotype exists is because it does happen to one degree or another, and I would think most gamers have experienced it in one form or the other. It might be the single player who wants to play Stabby Loner McDude who won't cooperate with anyone and wants to bring his swords everywhere; the guy who robs and tortures random NPCs because "it's in character"; or just the entire party having no permanent residence or significant social ties. There are usually other things going on in the group dynamics or with individual players that cause problems, but sometimes it can be chalked up to the characters simply not having a common center.

This setup, especially in it's most chronic form, can lead to a lot of headaches - for the GM and the players. Because having a diverse group of PCs with wildly different backgrounds and motivations, not to mention from far-flung regions in the campaign, can make it difficult create a cohesive group. It can lead to disconnects in expectations and frustrations because the characters only have shallow common goals. There are a number of techniques GMs use to try to get around this, usually by forcing the characters together in some manner (even if it's by saying, "You guys have to be together or this game won't work"). Obviously, many groups work around this in any number of ways. This can result in some very contrived situations as the reclusive netrunner and the socialite fixer have to come up with a reason to work with another, or the paladin and the thief have to constantly dance around the fact the paladin shouldn't tolerate the thief's existence. While either one of those are totally full of role-playing opportunities, the situation should exist with a goal in mind other than, "This is the only way these characters will work together".

Having the players all create characters at the same time, and ensure there's at least some group cohesion is one way around this. The group can also go one step further: have the characters all be a part of a community. This community can be a tribe, family, clan, military unit, criminal cartel, village, town, neighborhood, guild, or whatever works within the setting and the campaign. A social group that the characters care about its success or safety. The idea is that the players all collaborate to build this community and give it characteristics they'd like to see in the game. Once they have a fundamental social hub not only does it help the players feel engaged, but it opens up more opportunities for adventure. It creates situations where the characters have a reason to take action for their community's benefit over their own. Games like Fate Core actually have mechanics for creating the community through the "Fate fractal", either through the use of aspects all the way up to creating the community as a full-fledged character. In other games, it is probably sufficient to record a few things about the community that define it, especially those things that can move the characters to act for the community over their own interests.

There might be unease among some groups about allowing player collaboration to establish setting details, especially something like a faction or social group within the setting. Many settings have groups within their canon material, or it is just tradition to let the GM to decide these things. In those cases, I suggest just keep doing it that way if it works. But at the very least, the GM can try to take the suggestions above into consideration. I'm serious when I say it truly can't hurt.

Fate Core, Some More Thoughts

Fate Core, even as a draft, contains some of the best GMing advice I've ever read. It's a fundamental revelation, like the first time reading a system that didn't use levels, or classes, or random die rolls for attributes, or random damage from weapons. Even someone who runs a non-Fate game can benefit from this stuff.

The recurring theme throughout is something I've subconsciously understood when running games, but never gave a lot of thought about: how does this add to the game? We are told in various ways, in various sections, to make things matter. If you can't come up with a compelling reason for a die roll, or a ruling, or a story element, then you need to rethink it a little bit. If it doesn't do something to move the story forward or challenge the PCs, maybe it doesn't need to be there. Chapter 9 - "Scenes, Sessions and Scenarios" - is a particular goldmine of wisdom on examining various elements ranging from the relationships between the PCs, other characters, the world, and various other connections for getting a scenario going. A GM doesn't need to have Aspects in their game to take advantage of the methods Fate Core suggests.

In "What Makes a Good Fate Game?", three basics are laid out: competence, proactivity and drama. The characters are competent at what they do. Situations shouldn't exist unless they let the PCs show off their competence. When things go pear shaped, it's not because they didn't know what they were doing, it's in spite of their competence. Maybe the plan doesn't go right, or there's something beyond their control. The PCs are also proactive. They get involved, they do stuff, and don't just sit around waiting for the adventure to come to them. Finally, there need to be complications and difficult choices that the PCs have to make. Nothing should be single-faceted, unless that in itself is interesting and moves the story forward.

I've played in games where the GM seemed to only focus on setting our characters up for failure. They weren't fun games. Nobody wants to be forced to make a Dexterity roll for no reason other than to open a door - not an important door, not because the character is being chased by a demon, but just because the GM randomly decides it's a thing to do. Similarly, I've played in games where none of the players actually had their characters do anything. The PCs sat around like lumps, waiting for the next plot point to find them. The only way to get them engaged was to set up a fight, and even those turned out mechanical and boring because the players weren't engaged. They didn't have any skin in the game besides the scribbles on their character sheets. Fate Core's advice does a lot to counter these types of things and I can see how employing some of the techniques could help pretty much any game.

Obviously, some GMing styles might not mesh well with this. If you're someone who doesn't really like metagaming - or are a "let the dice fall where they may" type person where chance encounters are expected to be deadly - competence, proactivity and drama may not be the best fit. Even so, the higher level idea of make it matter should still  be a takeaway. If a character is going to get an infection from a random injury they sustained, it should matter somehow. If you're going to call for a die roll, at least think about how that die roll might turn out. What happens if the character fails? How can it lead to additional complications? What are the stakes? Those are questions I'm going to be asking from now on, regardless of what game I'm playing.