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

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.

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.

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.

Experience and Character Improvement

I totally shot myself in the foot last week, because I knew that I would need an "E" themed entry for the A-to-Z Blogging Challenge, and I put up Elfquest as my Flashback Friday entry anyway. So instead I'm going to continue my series on the types of things I prefer or like to see in roleplaying games.

Character advancement is an odd beast. Most games include some sort of mechanism for making characters better, and most gamers like being able to add new skills, abilities, powers, etc. Very, very few of them simulate how human beings learn and grow. The ones that claim to be realistic about skill development through training or education are often the least (which is typically true of any roleplaying game claiming to be the most realistic, ever). In the end, a lot of experience systems fall under the variety of "do some stuff, get some arbitrary points to spend on things". Unfortunately, it can often feel contrary and bolted on to the rest of the system because, after all, "We have to have an experience system."

That's one of the reasons why I love how Fate Core handles improvement, through major and minor milestones. It captures the spirit of the way characters in books, film and television tend to change over time. It gives the player more flexibility in deciding how they want their character to change, by taking the character's events and experiences into consideration. It probably doesn't work for gamers who prefer to have some sort of objective system in place.

+1 to Hatchet and Youtube was his Milestone

If there's going to be an experience point system that isn't something like Fate Core's Milestones or some other hippy communal lovefest (which I say with much affection for cooperative play), the question becomes how to make improvement not as arbitrary or with teeth gnashing over where to spend points.

I do have a method I drop into most skill-based RPGs (provided they don't have something like it already). It's kind of inspired by vague memories of playing Call of Cthulhu, and it's pretty straightforward. The first time a player makes a skill roll during the session, whether the roll succeeds or fails, they place a tick mark next to it. If the system has critical successes or failures and that is the result of the roll, the player places two ticks. If they roll a critical success or failure later on in the game, they place one more tick each time (but not every time they roll the skill). At the end of the session, the player rolls whatever passes for a standard (unmodified, unskilled, whatever) roll against their current skill level. If the roll succeeds, the character gets an experience point toward that skill. If the roll is a critical success or equivalent, the character gets 2. The player doesn't need to roll at the end of the session either - I usually allow enough tick marks to accrue until the skill might potentially be improved (but not more - in most games I don't allow skill level "jumping").

This method does require a little more bookkeeping, but I've played with different slight variations and it works pretty well. I usually mix it with some more arbitrary improvements such as a skill increase here (typically skills the character doesn't have), skill swaps, added advantages or disadvantages, a spell or ability, etc. In point-based systems, where the group is trying to hew to the point-buy philosophy, this doesn't work so well, but in many games it does.

How character improvement should be handled is something the table should decide on, regardless of what's in the rules. Players want their characters to be able to grow and change, whether it's actually in terms of "character" or just to pick up the next stunt, feat, power, whatever. It's just a matter of doing it in a way that feels natural to the game that everyone agrees on.

Combat Basics

I figure for at least the next few posts it might be a good idea to establish my stance on various elements in roleplaying game design and play. It will help anybody reading this blog know where I'm coming from and where I'm likely to be going to.

Combat is featured in a good number of roleplaying games. The basics of the majority of combat systems trace themselves back to Dungeons and Dragons and its war gaming roots. You have a hit roll, which may or may not be opposed. There's some kind of assessment of damage. A number of different actions are usually available to choose from, that have different benefits and costs associated with them.

Over the years, I've become extremely impatient with overly detailed, move by move combat systems. Part of this is due to changes in how I think about games, and another part of it is probably just getting old. I don't like hit locations or detailed wound systems, which is actually going to be the subject of tomorrow's post. I think tracking exact combatant location, having a pick list of  lots of maneuvers, detailed weapon statistics that include much more than damage and accuracy, or any number of minutiae add little to my play experience and more often subtract from it. I'm impatient and just want to know who did what, the results, and resolve it all in a dramatic way that doesn't take too long. Physical combat is supposed to be fast paced and confusing, not the result of precisely figuring attack arcs and how many "Step" maneuvers can fit into a round.

That means I gravitate toward simpler combat systems, such as Silhouette, Interlock and the Synergy system. There is only one die type, with a unified mechanic. You make opposed rolls, figure out the damage (if any) and then move on. There aren't complex tick systems, or step-by-step rounds, or action points. Everything after the rolls is colored by narrative and what makes the most sense.

Silhouette in particular has a fundamental mechanic that appeals to me. The die mechanic is to roll xd6, where x is the character's skill level, and then take the highest. Multiple sixes add +1 to the result (so a roll of 6,6,6 is totalled to 8). This means that skilled characters reliably roll slightly higher than average. They are just as unlikely to roll a spectacular result as they are a poor result (granted, a skill 4 character is going to be rolling fives and sixes, which is remarkably good). Unskilled characters can roll high too, but they're just as likely to roll poorly. They're inexperienced and thus unpredictable. Even a seasoned veteran can be seriously injured by an unskilled, but lucky, attack.

Overall it's the dynamic, chaotic nature of fighting that I think overly detailed systems detract from. There's just too much going on. You might have gotten hit by the orc because another orc missed - maybe you misstepped trying to avoid the first one, or were put off balance. The guy who was seriously injured by a punch might have sustained the injury because he fell and hit his head on a sharp corner.

Because of this, I see initiative systems as less of a play-by-play breakdown of time and more of a pacing mechanic. In the shared imaginary space, everything is happening at the same time. The ones who roll higher on initiative or whatever are simply those that set the pacing of the round. Functionally it doesn't make much of a difference, but it drives my preference for summarizing the exact order of events at the end of the round or exchange. In essence, my combats look like this:

1. Make necessary rolls with only minimal details.
2. Apply damage or other effects.
3. Tie everything together into one cohesive narrative.

Even systems that lean a little heavy on mechanical detail work pretty well with those general guidelines. There was one exception - Exalted. Both first and second editions were just too mechanics heavy for me to be able to handle it. Sure, there are any number of various counters and sheets and battle wheels and other methods of keeping track of things, but there's no room in my head for both keeping track of the mechanical bits and trying to piece it all together at the end (especially if the sequence of events goes on for 15 minutes or more). I wanted something quick and vivid, and instead got bogged down in DVs and soak.

Hopefully this gives a little more insight into where I lean when it comes to physical conflict in rpgs. Tomorrow I'll talk about my views on injuries, hit locations and other after effects of combat (hint: it doesn't involve d1000 hit location tables).