Monday, November 11, 2013

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.