RPG Realism And Why It's Crap

The past week or so has been quite busy so I had to take a little break from blogging. I'm back with some thoughts that have been brewing about realism in tabletop rpgs. This post is an expansion of a point I brought up in a previous post.

I don't think any tabletop roleplaying system mechanics can be "realistic". Skill levels, attack and defense rolls, damage, experience, modifiers - none of them have a damn thing to do with realism. Mechanics are abstractions - even the ones that most people consider complicated - and in no way approach realistically simulating anything. As such realism is a complete waste of time as a design goal. If you're trying to create a ranged combat system to realistically simulate firearms, just fucking stop now. The same goes for sword fighting, or vehicle combat, or anything else. You're just going to wind up plastering "Most realistic rpg ever" on the cover and get mocked. Maybe go play a video game instead if you want that kind of realism.

But are video games really more realistic just because they're driven by HD-quality graphics and physics engines? Given the uncanny valley, flip-floppy rag doll physics and a host of common glitches that are fodder for nightmares or Tool videos I say, "No". That's because while photorealistic graphics and attention to detail is a goal for most video games, actual realism typically takes a back seat. Most video games strive to have consistency, believability, and suspension of disbelief. Everything else is gameplay and looking pretty, and those are the two things that tend to attract me to videogames (although looking pretty and glitchy as hell isn't).

Others just go for silly

Tabletop rpgs are a universe of magnitude simpler than a video game and "just realistic enough" is a lot more granular. Someone can go and run all of the physics calculations and figure out what kind of a damage bonus each point of strength should get, or how much energy a projectile loses per meter, but in the end all of those calculations will boil down to a singular abstraction of the reality the game takes place in. Realism flows naturally out of how those rules are interpreted and implemented in play. When realism is the design goal, in my experience complexity goes up and the chances of losing consistency or breaking down completely are much higher.

One of the defenses of realistic rules is that the GM often doesn't have experience with a particular circumstance - whether it be rock climbing, or driving a tank, or firing a gun, or hacking a computer. Therefore, the realistic detailed rules provide the framework for the GM to be able to adjudicate those situations. The problem with this approach is the designers often don't really know either (cf Vampire Undeath's being advertised as realistic and thoroughly researched, with a rule that a jammed assault rifle needs five minutes and an armorer to clear). This extends to many things like how difficult tasks should be (how many times have you seen a system with task thresholds that just seem out of whack), how often people succeed at tasks (ditto for people failing at tasks, but this is usually a dice issue), the number and scope of various modifiers, and how people learn. The designer might have pages of equations backing up why a particular modifier works the way it does and even that will be a white room affair that doesn't take into account countless variables.

That isn't to say it's not a good exercise to incorporate whatever level of realism into actually designing the mechanics. It might even help balance out some rules and figure out where the boundaries of believability are. But once that tweaking and honing is done, the consistency and playability need to be the ultimate goal -  not whether or not the game accurately represents the unladen weight of a swallow.

Corollary to Things I Hate In RPGs

I realized there is a corollary (or set of them) to the things I hate in RPGs. This is mostly aimed toward game designers and publishers

1. Don't claim that your RPG is realistic, historically accurate or well-researched and then make stupid mistakes that prove it isn't. Especially don't make that claim and then write it takes five minutes and an armorer to clear a jammed assault rifle (Vampire: Undeath, I'm looking at you).

Also, deadEarth

2. Don't tell me how your game is only limited by my imagination. It's a role playing game. That's kind of what it already does.

3. Don't claim your game has a super innovative mechanic, only to have it turn out it's the same thing used in a dozen other roleplaying games. Especially if you're going to claim it's something like being able to choose to dodge, attack or parry. It just reminds me of this:

4. Don't tell me that your game is dark, or horrific, or gritty, or anything else without having something other than "Because I said so, look at the fonts!" to back it up.

"Do you have anything blacker?"

5. For the love of God don't tell me how your game "encourages roleplaying." See #2. It's already a fucking roleplaying game.

6. DO tell me if your game has limited options. Like if it's a science fiction game but missing the starship combat rules, or it's a game about playing three mice stuck in a mouse trap pondering the futility of their existence. I like to know these things up front.

Especially if one of those options is this

Things I Hate In RPGs (And Sometimes Gamers)

Here goes my break from blogging, because I found something I have to write about.

I've had a couple conversations recently that have been a bit frustrating in the relative pig-headedness of the other person. One of those was a bizarre PM conversation with someone on RPG.Net. It went kind of like this:

Them: "Fate can't do Blue Planet well. Fate is genre emulation and Blue Planet has no genre."
Me: "You can do it by doing this and this."
Them: "But that's cheating because you'd have to put a subsystem in place that wasn't there before."
Me: "..."

As a result, I'm putting this up as my (likely incomplete) list of Things I Hate in RPGs.

Nothing else needs to be said

Genre Emulation As A Goal: Genre emulation is a crock of shit. That might be a strong term - at the very least its use in the conversation above is. People use "genre emulation" to justify why their favorite game is better, or another game sucks. It falls under the same asshattery that demands paladins do certain things because they're Lawful Good or accuses games that dare to have meta game mechanics of  "not being roleplaying games".

Good games don't enforce genre. They enable it. Typically this is by including elements that help the feel of the game - it could be the writing, or the artwork, or the way that a particular rule or rules work. But they don't force the game to be played a certain way. Mekton Zeta - considered an "anime" genre game - has nothing in it that forces things to be "anime-like". Once you get rid of the hair color chart, and artwork, and strip down the construction system and remove any giveaway terms like "Beam Saber" or Transformation, it's just a good, fun game. That's because Mike Pondsmith is a good game designer and knows games aren't a straitjacket.

To address the paraphrased conversation above, by definition Fate Core has no genre. It has a built-in set of assumptions about game play - notably that the player characters are competent, or that fiction takes precedence over physics - but otherwise it provides a set of tools to help the table mold the rules to the game they want to play, and for everyone to provide narrative input. Does that mean Fate Core is a good fit for any kind of game? Of course not, but that's a taste and style preference more than anything. Just setting boundaries and defining aspects in a certain direction is going to help enable particular genre tropes. The game itself doesn't have super-specific genre rules. Spirit of the Century may have, but Fate Core is not Spirit of the Century.

Realism  As A Goal: This one is going to be a landmine topic. I don't give a damn if a game's rules are "realistic". Just like I don't want to play a genre simulator, I don't want to play a physics simulator either. For one, "realism" is another one of those things that gets trotted out as the reason why "Game X sucks", when truly what the critic means is "Game X isn't to my taste." But even when I'm playing a game that is supposed to be gritty, or low powered, or whatever term you want to use, there are a whole lot of things I don't care about. I don't care about the rules encapsulating things like, "An unladen European can jump exactly 1.875 meters." I do care about whether the results of applying the rules meet my expectations - how they get there is unimportant, at least in terms of the rule itself operating in a particular way. I'd use verisimilitude to describe what I look for in games, but that's kind of crap too. A few years ago I was using the term like it was going out of style. Now I realize it's a farce. If the rule or the results are reasonable, not boring, and I can reasonably say, "that could happen", then I'm good. It doesn't need to go any further than that.

Please, let's not go there

Immersion As A Goal: Wait, this one might be the one that blows up in my face. "Hate" might - again - be a strong word. Immersion should never be the goal of a roleplaying game any more than genre or reality emulation. That doesn't mean it's not important or doesn't exist. It's just that the game should enable immersion and not enforce it - provided it's even possible for a game to do either one in the first place. You can create a game whose goal is to enforce genre (which I think would kind of suck), you can create a game whose goal is to be "realistic" (which I know for me would suck). But you can't in reality create a game with the goal of enforcing or preventing immersion because immersion just happens. If there's a magic combination for making it work with genre or realism, there isn't one for immersion because it's entirely too personal.

Mostly I see people touting immersion over games. They say they things of the, "Game X sucks/isn't a roleplaying game because it yanks me out of immersion" sort. Personally, I think finding games that enable immersion is a snipe hunt that people get sent on to earn their "ROLE playing not ROLL playing" merit badge. Now I know someone is going to say, "Well Game X makes immersion impossible because of the meta game rules, but Game Y doesn't because the rules get out of the way." Do they actually? For that person I can buy it, but not the whole game for everybody..

Unfortunately, my experience with people complaining about immersion has been colored by a few bad eggs. They were the most likely to complain that their character would never do something, justify some fucktard thing their character did, or generally be inflexible and unwilling to cooperate with anything. The excuse was always something "breaks their immersion" or "I can't help it, that's the way my character is." The last person in one of my games that tried to murder the entire party because he was "in character" got bounced following that session (it wasn't the first offense).

Now if I don't like those things in my games or gamers, than what do I like? The first thing is balance - and not in terms of character balance. I'll play a game that is "realistic" as long as it is enjoyable. That doesn't mean, "I always get my way" or "I have to have a special snowflake character." I have plenty of love for realistic systems - but they have to written to be playable and allow for meaningful choices. While I place genre embellishments (and narrative control) higher on my list of likes than realism, again there needs to be a balance. My favorite genre games are the ones that have nods toward their chosen genre. They don't grab you by the throat and say, "There is only one way to play this game!" (and, as an aside, I avoid any game that says that regardless). Immersion is completely off the table when I decide if I like a game system, because I find immersion when and where I will. Most immersive roleplayers would disagree with me over what I find to be immersive anyway.

Going to take a break for a couple days

The A to Z April Blogging Challenge is over, and I need to take a break (I'm not getting paid for this, you know). So I'm going to restart next week on a regular schedule of Monday, Wednesday and Friday.

The challenge taught me a lot, mostly that it helps to have a focused theme when doing it. It helped that one of my personal truisms is that it doesn't matter what I write about as long as I write (and the corollary that it doesn't have to be good writing either)...so while I might have changed some of the things I wrote about it, I likely wouldn't have written them any better. If I do it next year, I'm going to plan a bit more (which sounds a lot like my take away from my first NaNoWriMo attempt was).

So, I'll see everybody next week!

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).

Your Game Has The Fate Fractal Too

Did you know your game already has the Fate fractal? Even if you don't know what the Fate fractal is? Well, it's true to one degree or another. Do you remember that time you wrote up a trap that attacks as a 10th level fighter? Or you assigned a hit point value of a door that had to be broken down? Or gave a penalty to driving rolls because of the car having a bad suspension? Or had the PCs roll saving throws versus cold in the middle of a storm? When you did those things, you were roughly operating within the Fate fractal.

For people who haven't heard of it before (or have and just aren't sure what it is), the Fate fractal is not so much a rule or a standardized process as it is a design pattern. The core parts that make up characters in Fate - Aspects, skills, stunts, stress tracks - aren't limited to just characters. Anything can have them if needed to show importance or enhance the narrative. The trap gets ranks in Shoot. The door gets a stress track. The car gets the aspect Bad Suspension. The storm gets the aspect Blizzard of the Century and a Frostbite skill to attack the characters.

So, if nearly every other game already has the equivalent of the Fate fractal, what makes the Fate fractal so different in Fate? The key word is equivalent. The Fate fractal isn't a hack or a stopgap measure. While most modern rpgs have unified resolution mechanics, most still have different systems for dealing with characters, inanimate objects, the environment, etc.. In Fate it's implicit in the system. It's possible for an aspect to have a stress track. Or an aspect to have an aspect. Or a stress track to have a skill. It abstracts out to a level that is not only still useful in game terms, but infinitely useful in making the game and the narrative work together.

The Fate fractal doesn't need to be used all the time - it usually suffices to name an Aspect and keep right on trucking. But when something is really  important, you can go further down the rabbit hole and do it without a whole lot of trying to fit round pegs in square holes. This is why I think, for the Fate fractal alone, every game master should at least look at Fate Core once it's released. The concept applies to nearly every game, and even if it's not used in the same way being cognizant of its existence is just another tool in the GM's toolbox.

Xeno: A Fate Accelerated Edition One-Shot

After nearly a month of posting six-days a week it's not surprising that I'd miss a day. But real life does take precedence, and it's better late than never. I also think that this was well worth it, because I'm presenting a highly focused FAE hack: Xeno.

This is intended not only to show off various things that can be done with Fate Core. It's intended to happen with a specific structure - that typically found in the source material it emulates. It also may not be perfect, because I kind of rattled it off the top of my head in the space of a day or so. Either way, it should serve as a great starting point for anyone wanting to run a convention game, demo or other.

You can grab Xeno from this link:

Xeno: An FAE One-Shot

Why Fate Core Is Awesome

+David Larkins  on the Fate Core G+ Community said he'd like to see a post on why Fate Core is awesome so here we are.

Why is any game awesome? Typically because it's fun to play, it has the options to support one or more styles of play, or it's rules are particularly well written, elegant, or hits the right spot in terms of what it covers. To me, Fate has all of those things. I haven't played Fate Core yet (working on that), but I have played Fate-based game and they were great.

It's fun to play because what the people around the table want out of the game inform the rules, and not the other way around. Aspects aren't just indicators of what the players want in the game - they're instructions for how to do it. When a character has the aspect My Favorite Dish Is Revenge, it's saying the player wants to have a game with betrayals and revenge and also communicates the theme and tone for that happens. It's a little capsule of how and why.

From a system perspective, for me it feels wide open. Rather than having to think outside the box to recreate some element in the game, Fate Core encourages redefining the box. It's not so much that Fate Core is the first to introduce concepts such as the treating anything like a character - in  other games a car, for example, might have hit points or stats like how fast or maneuverable it is. The difference is that in Fate Core if I want a haunted house, I just say it's a Creepy Old House. I don't have to figure out what kind modifier or rule covers "old" or "creepy".

But more than all that, Fate Core has a number of "Oh shit, I never looked at it that way before!" moments. I've always used some measure of "fiction over physics" in games I've run. I've also used some variation of "Yes and/but..." for years without realizing what I was doing.  But die rolls measuring the distance from success, and failure possibly being a success at a cost? That's huge. Conceding versus being taken out, and giving the player a choice in how badly they want to push in a conflict instead of just wearing down hit points until they're dead? That's exactly how I want characters being removed from play to work. The entire Fate fractal? Brilliant in its simplicity. It's like the first time that Basic D&D really clicked, after multiple times of reading it. Or the first time I heard Skinny Puppy and realized how much music there was in non-music. Or when I read Neuromancer for the first time. Or first picked up Tribe 8. Fate Core for me is a perspective-changing experience.

The feeling isn't just novelty either - it changes the way I look at every game. Even when I'm not running Fate Core, there's no putting the genie back in the bottle. Fate Core is part of my gaming consciousness now.

Vimary Redux

When Tribe 8 first came out, it wasn't a huge secret that the setting, Vimary, was the remains of Montreal, Canada (Vimary is a play on Ville Marie). But there wasn't a whole lot to go on, aside from looking up other maps and information on the area on the Internet. We didn't have Google Maps or Google Earth to get a bird's eye view of the locations in the game. Looking over street view and photos of different locations in Google Maps, I think there are some tweaks that can be made to Vimary as a whole.

First is the proximity of the Z'bri to Tribal lands. They're just too close for me to find it believable that half of the Tribes don't see them as a large threat, at least in the default starting point of the game. My solution, at least in my game, is to move the Z'bri lands on Vimary proper back across the river. The areas where they were become a no man's land, an extension of the Discarded Lands that acts as a buffer between the Z'bri and the Tribes. This can be seen as a mutually agreed upon DMZ. It facilitates all kinds of story opportunities for the Z'bri to harry the Tribes by releasing monstrosities into the no man's land and fostering Serfs, forcing the Joanites from the Seven Fingers to have to deal with them.

A corollary to this is the Seven Fingers gets an upgrade. In the canon setting, the wall is a very porous border. In my game, it gets beefed up into a formidable fortification. There aren't any holes to exploit (except going underground), and the Joanite population is increased. The line of the fortification actually crosses over and continues toward Duskfall, although the actual Seven Fingers are still located where they are now. In addition to the increased fortification, the Seven Fingers are also imbued with Synthesis to repel Z'bri (similar to how The Wall in A Song of Ice and Fire is warded against the White Walkers). In fact, I see the Seven Fingers as being a spiritual counterpart to The Wall.

Similarly, I think the Jo'han Skyrealms are too close for comfort. I can see a handful at most taking residence  high up in the remains of skyscrapers on the outskirts of Tribal land where they can't be reached from the ground. I think parts of the underground would be better suited for the Jo'han than living atop a skyscraper.

Speaking of the skyscrapers, these are structures I think the Tribals would generally avoid being near period so the Skyrealms might work out. Anyone who's seen Life After People knows that the elements, lack of maintenance and time conspire to bring these buildings down. They're just not that safe to be around. I do think the Tribals would make extensive use of the Emporiums year-round as opposed to in the winter season. The majority of the population in and around Bazaar probably live down there. It also gives them refuge in the event of some kind of attack.

There's a fort on the island. Why was that never mentioned?

As far as Hom, I've always envisioned that the amusement park that makes up the center of the settlement is in relatively decent shape. Part of this is due to once the Fall began, it just wasn't a place where people went to and suffered relatively little damage. The other part is due to the spiritual nature of the setting. Sure the place is still a shambles, but there are some structures that are not doing too bad. These are the structures like the ferris wheel, carousel, funhouse, etc. Maybe whimsical things like statues or whatnot are still mostly intact. Also, a lot of buildings on the island look really cool. I mean, there's a freaking fort there. As the Fallen come into their own, the place starts to look better and better. It gains less of a depressed, tent city atmosphere and more of a vibrant one. Part of this is going to be tied to the spiritual nature of the setting and things happening like when Lilith [REDACTED].

Access to Hom over the Fallen Bridge (the Pont de la Concorde) to me is not realistic. I think that the bridge would have near completely collapsed and would not be an easy access point onto the island. This is noted in Tribe 8 1e, but I think even "makeshift" efforts aren't enough to allow access. The South Tier (Jacques Cartier) bridge, on the other hand, would still be mostly intact. For some reason,  the rulebook doesn't make mention of the off ramps leading from the bridge to the island. While they might have partially collapsed, I can see access to the bridge being easier the other bridge. It would be the primary means for Fallen to get on and off the island (besides boats). Thematically it works well too - Tribals are perpetually looking down on the Fallen from the bridge, and Fallen going to the island have to descend to get there.

I've always assumed it's not important to get things 100% right - it is a fantasy game. The landscape will have changed through altered river courses, erosion, natural disasters, etc. Supernatural influences can shift things around and cause conditions that can't exist in the real world. But going back and looking over Google Maps and Google Earth...there's a lot of awesome stuff in Montreal and little tweaks that can make Vimary come alive.

UML for Gaming?

Falling back on another programming-related post, because I didn't have anything else planned for today.

UML stands for Unified Modeling Language. It's a standardized set of notation and symbols for modeling workflows, data diagrams, etc. It's different than flowcharting because it covers details - though still high level - of how a process is supposed to work; the inputs, outputs and other interfaces; messages that are sent from one process to another.

Being a programmer, a geek in general, and a visual person means I really like diagrams and charts. I'm having a great time right now creating a chart showing the relationships between Spark rpg setting creation elements. A version of UML for gaming is really intriguing idea, but I'm not sure how practical it would be. From a system design perspective, it might be useful just to get the feel for how the system flows and identify any potential issues. There are a number of things in the UML standard that could be taken as is, but some of the notations and symbols would need to be changed I think, particularly several of the structural things and notations. Maybe someday I'll tinker around with doing a straight UML diagram of Fate Core combat or something just to see how it all fits together.

Tribe 8

I'm going to get lazy and make a Tribe 8 post for today's A-to-Z Blogging Challenge post, but it is actually rather timely so it's not that bad.

For those who don't know what I'm talking about when I mention Tribe 8, it is a roleplaying game published by Dream Pod 9 in the late 1990s. It is best described as a "spiritual post-apocalyptic dark fantasy" setting, with elements of body horror (the Z'bri), social upheaval (the Fallen), clockwork goddesses (the Fatimas) and a healthy dose of a New Agey vibe.  It is my favorite roleplaying game ever as it has a perfect mixture of horror, dark fantasy and post apocalyptic elements

Which one is the clockwork demi-diety?It isn't the bear

The line had about 25 books or so and a second edition, which isn't a sorry run by any measure. The second edition signaled the end of the line, although it had the grace to outline the remainder of the metaplot in very broad brushstrokes and detail a number of big reveals regarding the bigger picture.

That's right, I said metaplot. Coming on the coattails of the White Wolf pioneered splat book and metaplot business model, Tribe 8 had it in spades. The implementation was great in many respects and abysmal in others. A number of the metaplot books were well-written and were good at handling some of the sticky points with regard to players coming into contact with the plot. Others, not so much. In addition, many important pieces of information were dribbled out here and there, sometimes buried in in-character narrative (which, for better or worse, was a defining feature of the line). I've already opined about the lack of a Keepers sourcebook, which was the last thing the line needed to be complete. I've also posted about the metaplot in more detail.

So, the point of this post is to highlight some of the fan works I've created for Tribe 8.

• The newest is my completion of my Fate of Vimary draft, which consolidates the various rules modifications I've made to support Tribe 8 in Fate Core.
• Next, I'm going to be doing a quick Spark setting write-up. This is actually for the eventuality that I run a dual Fate Core/Spark Tribe 8 game. I'm thinking two parallel games, but I'm not sure yet.
• Previously, I had worked on an adaptation of Tribe 8 to Strands of Fate called Strands of Flesh and Spirit. Since reading Fate Core, I've stopped developing that branch but it's reasonably complete.
• I have a blog dedicated solely to Tribe 8 called Dreams of Flesh and Spirit. It is the spiritual descendant (no pun intended) of my long-gone Tribe 8 website of the same name.
• I also have a pretty much empty Wikia wiki called The Hundred Books. This will be an eventual rebuild of the wiki I once hosted on my website (which was sadly lost).

If you think Tribe 8 sounds the least bit interesting, I highly suggest picking up the first edition core book and the Vimary sourcebook. They're really the only things you need to run a good Tribe 8 game. Get the core book in hardback, if you can find one. If you want even more, the Tribe 8 Companion (which can be hard to find), Horrors of the Z'bri, Into the Outlands, and Adrift on the River of Dream round out the additional "must haves". After that, if you want additional detail on the Tribes you can pick up the "Word" books - Word of the Dancers, Word of the Fates, Word of the Pillars. Finally, there are the Cycle books themselves if you want to run the metaplot. The set is rounded out by the non-metaplot books - Book of Legends, Harvest of Thorns, Word of the North and the Capal Book of Days.

Finally, Blood and Sacrifice is one of the best Tribe 8 fan sites out there, hosting material by some of the people who worked on latter Tribe 8 books. It includes the write-ups of the Destiny Deck cards, which are kind of like the Tribe 8 tarot (and, if it were up to me, an automatic stretch goal if a Tribe 8 Kickstarter ever happened).

When Do You Succeed?

Fate Core has a concept of "success with a cost". It's a rather difficult subject for people coming from other systems to wrap their head around. Basically, even if a player fails to meet the difficulty, they can still succeed - provided they are willing to accept the cost of that success.

Here's my slightly expanded take on what it means to succeed or fail. Success means that the player gets what they want on their terms. Anything else is a failure, even if what they were attempting actually gets done. Success at a serious cost and completely failing to accomplish the task are both the same thing if it's the overall goal that is failed as a result.

Getting into this mode of thinking can take some doing. The first thing that has to happen is the players and GM need to be completely upfront about what their goals are, and what is at stake. While the GM should have say over what success at a cost actually means, in order to make an informed decision on whether to accept it the player should know what success, a tie, outright failure, or success with a major cost will result in beforehand. Also, the goals should be set appropriately.

An example would be a character who is being forced to hack into a system in under 60 seconds or the Big Bad Guy will blow his boyfriend's brains out. The main question should be: is hacking the system the goal, or keeping the boyfriend alive? If it's the former, than failure or success at a cost on the roll would be logically related to the hacking itself (I'm not saying it has to be, just that it follows). If the goal is to keep the boyfriend alive - which is what I think it is - then this drives the narrative of exactly what happens on a failure. Either the boyfriend is getting killed, or there is going to be some other cost. For success at a cost, maybe right at the 60 second mark, the character yells out, "I found a back door! Give me a few seconds!" and the Big Bad Guy shoots the hacker instead, giving him a minor consequence, to show that he "meant business."

There are a lot of ways to go about this, and most are going to be completely dependent on the context. But keeping an eye on the appropriate goal can help make the distinction between a success and a failure, even in cases where the player chooses success at a cost.

Successful Kickstarters!

In the past few days, a couple of very cool Kickstarters have wrapped up. Last week was Jason Pitre's Spark rpg. Today was Godmachine Production's Apotheosis Drive X. They were very successful, not only in terms of blowing away their funding goals but in the buzz that they generated. Both products showed an enormous amount of potential during their Kickstarters and I'm sure they will live up to it when they are released. Spark has even picked up an Apotheosis Drive X setting write-up for cross-promotion goodness. With ADX's setting anthology, there will be more Fate Core-based mecha goodness than I'll know what to do with. Spark does what Aria: Canticle of the Monomyth tried to do, but without all the terminology and obtuseness and hundreds of pages. For my part, I have a setting I pitched for ADX as well as a Tribe 8 write-up for Spark in the pipeline.

There are other really good Kickstarters going on if you're feeling like you missed out on Spark or ADX, or just need to spend more money. Trigger Happy, Invulnerable and Short Order Heroes are well worth checking out.

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.

Ghosts of Homebrews Past

I started tinkering with games very, very early on. One of the most ambitious homebrews that I ever did was basically making Battlesuit, the man-to-man tactical game set in the OGRE universe into an rpg.

I no longer have the notes for that game as the binder was in a trunk that my dad gave away after I turned 18 (it was a misunderstanding on his part). I remember meticulously handwriting out pages and pages of notes on skills, classes, attributes, battlesuit options, combat, you name it. I kept the original "dot map" (Battlesuit's map used dots instead of hexes or a grid) for movement. I also kept the combat results chart and 2d6 rolls, and had attributes as modifiers to the results. I remember MERP and possibly Palladium as being inspirations for the system that I finally came up with, but a lot of it was pulled from an old Atari game that had battlesuits in it as well.   We actually played several sessions of the Battlesuit rpg rules, but it became evident pretty quick that it might be easier to just use another game system (like Heroes Unlimited or later on Mekton). I'd give anything to be able to see those old hand written notes though. What truly horrible ideas did it have in it? What strokes of game-design genius? I just don't remember any more.

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.

More Programming in RPGs

In response to yesterday's post, +Robert Hanz brought up that a discussion of messaging and the actor model in RPGs might be a good thought exercise, so I figured I'd take a shot at it. This is high level and steamrolls over a lot of nuances and details within the actor model. I'm not going to tackle things like message queues or service layers or anything else.

What's interesting about this in relation to yesterday's post is that Alan Kay, who developed the Small Talk programming language and is considered one of the founding fathers of object-oriented programming, lamented that he should have called it "message oriented programming" because it is the message and not the objects that are relevant. He felt everybody was concentrating too much on the objects, class libraries, etc.

So for this post, I'm going to look at only the messages that are sent between the actors, and who those actors are.

No, NOT him

So what is this "actor model" anyway? In simplest terms instead of everything being an object, everything is an actor. That is, it is able to act upon or in response to other actors (that's my wording and may not jive 100% with the actual model). Actors send messages to one another, and in response they can do one or all of the following at the same time:

• Send messages to other actors
• Create new actors
• Decide the behavior when the next message is received.

A classic example would be driving a car. The driver and the car are both actors. When the driver presses the gas pedal they send the message Go faster. The car responds to that message and through the speedometer sends the message I am now going 65 mph. The driver receives the message and decides they're not going fast enough, and sends the Go faster message again. If the car has a governor, or is now out of gas, it may respond by not going any faster and may begin to slow down (deciding the behavior when the next message is received).

These messages can be synchronous or asynchronous. The gas pedal transmits a synchronous message as the gas pedal is depressed. The driver doesn't need to press the pedal, wait for the car's speed to respond, then press the pedal again. The pedal provides a steady flow of information to the engine. Asynchronous is when you start your car. You have to turn the key and wait for the engine to start before you can start driving. The messages can also be concurrent or non-concurrent. If the car runs out of gas just as you are pressing on the pedal, both messages are sent at the same time and are concurrent.

So in the context of typical rpg combat between two characters, the messages may look like this:

Actor 1 sends a message to Actor 2: I'm a wreck your face!
Actor 2 receives the message and responds with a message of their own: Oh no you didn't!

Depending on the game the messages can be parallel (attack and defense roll at the same time) or non-concurrent (or asynchronous), such as rolling an attack versus a static value like an armor class.

Now let's say Actor 1 succeeds. He now creates a new actor - damage - which transmits a message to Actor 2: Subtract x hit points. Actor 2 receives that message and decrements his hit points by that amount.

Modifiers to actions are the actor changing behavior when the next message is received. If Actor 1 did an All Out Attack, the actor's behavior in response to the next attack may be "Lose a turn.". If the game has a wound system with penalties, his response to the next message coming from Actor 1 might be Subtract x from defense roll because of wounds.

Another example of actors (or characters) creating new actors would be casting a spell that has an effect independent of the caster. Summoning a monster is the most obvious, but pretty much any spell is a new actor. It will be able to send and receive messages and respond to them in predetermined ways (such as reacting to a counterspell or a dispel).

So far the ability to create new actors has been inferred. In other words, a particular character is only able to create a limited number of specific actors (which fits perfectly into the actor model). In games like Fate the actor can decide what new actors to create, plus when and how, through the use of Fate Points and declaring aspects.

But the biggest takeaway in how the actor model applies to Fate is the fact that in Fate everything is an actor. Things like a security bot are obvious. But what about the tree with the aspect Just High Enough To Get Over The Wall? Or a trap with the aspect Spring-Loaded Trap and the skill Spiky-Hurty Bits +2? Those are actors too. When you use Security Systems to create the advantage Targets My Enemies on a turret control panel, you're sending and receiving messages with the panel as an actor and changing its behavior for when it receives the message "Detects presence of an enemy".

Even the setting is an actor. In yesterday's post, I talked about dwindling Resources creating skills the setting can use against the players. Resources send a message to the setting I am now at 0 which responds by creating the aspect Struggle For Survival. In addition, the setting sets its behavior so if it receives the message from Resources I am now at -1, it will create three actors in the form of skills (Hunger, Thirst, and Exposure). These actors can now start sending messages to the characters (i.e., starvation, dehydration or sunburn) until Resources is above 0 again.

Much like object-oriented programming, I don't think that the actor model is something that would be a singular design goal for an rpg. But the parallels are strong enough that just a slight change in viewing what is an actor and what isn't can have profound effects on how pretty much any game is designed or played.

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.