Chimera is like school on Saturday—no class.

Chimera characters are based on kits—little, bite-sized stereotypes that define a particular set of skills and abilities. The idea is that you start with a vision of your character—what he can do, what he’s good at, and what abilities he uses to survive adventures. Then you combine individual kits to match that vision. For example, a ranger can fight, shoot, track foes, do wilderness things, and maybe cast a spell or two—each of these things is represented by a kit.

The kit concept supports Chimera’s multi-genre framework. While we’re all familiar with so-called fantasy classes (fighter, priest, rogue, magic-user, ranger, assassin, barbarian, et al.), they don’t translate well outside the fantasy genre. Sci-fi campaigns, for instance, might have space marines, colonists, empaths, pilots, scouts, and spies in addition to a priest here or there, or a barbarian race of low-tech folks living on the Outer Rim. There’s a parallel between Fighter and Space Marine, but only inasmuch as they have common preference to fight their way out of trouble. Outside of that, they’re quite different.

Character kits are meant to address this, because each kit is generic by design—assembled in any combination, they describe ability, not genre. But the concept seems to be a hard sell, at least for Chimera initiates. Feedback I’ve received from you (or, at least, others like you) suggest that classes are the way to go. Classes would make character generation faster and more convenient. But, besides being genre-specific, classes lean toward rigidity—who says your fighter can’t try to move silently, or that your magic-user can’t use a sword?

Not me. But then we’re getting into the realm of skill-based characters, which poses a different set of problems.

So let’s try to sort things out a bit.

Class-based

Class-based characters have one thing going for them that others do not: they’re easy to roll up and unleash on the campaign setting. Classes are also convenient for game masters who need to quickly describe what a particular character can do. Assuming familiarity with the rules, labels like “thief,” or “cleric” convey a lot about the character’s role and capabilities.

But classes pose a danger of over-generalisation. If you’re going by the rules, a class can do only what’s specified, meaning not only a limited skill set, but also that every 4th-level thief, for example, has the same abilities. If you want a fighter who can also pick pockets or maybe cast a spell, you’re out of luck. You could create a new class to satisfy your vision, but that’s a pain to do every time you want to customise a character.

Yet there is one thing we can take away from classes: they clearly define a character’s survival tools. Fighters rely on their strength to beat things down, thieves rely on stealth and trickery, magic-users put stock in their ability to hurl spells, etc. In a class-based system, these conclusions are obvious, though they’re unnecessary with skill-based. But hold onto the concept—we’ll come back round to it later.

Skill-based

The opposite end of the spectrum—specifically designed, perhaps, to address the limitations of class—is the skill-based character. Instead of describing a character by his profession, skill-based defines a character by what he can actually do. On the surface, it’s a natural solution to customising characters. Now you can have the sneaky fighter or the mage who’s a crack shot, or even the space marine with a hint of empathic power.

But just as skill-based addresses class limitations, it nullifies class benefits. A GM cannot easily encapsulate a character by his array of potentially disparate skills. Nor can a player create a new character without deliberating over assigning competence to each. While you gain the benefit of customising a character, you now have spend the time to actually do the customising.

The lesson I take from skill-based is that its chief benefit is flexibility. I’m just not always satisfied with the concept’s execution.

Attributes?

All this time we’re assuming that characters, whether class- or skill-based, are also partially defined by a set of common attributes: Strength, Dexterity, Intellect, Charisma, etc. But are they really necessary?

I’d say the answer depends on how they’re used in the system. In most cases, though, they’re not. Typically, an attribute serves one of two purposes: (1) to modify one’s effectiveness or chance of success with a given ability, or (2) to act as a default mechanism for arbitrating actions that have no corresponding skill or game mechanic.

But you could take care of these requirements by focusing on the actual abilities instead of their underlying attributes. Attributes are useful for describing, in loose terms, a character as an individual—he’s smart, or he’s strong and dexterous, or he’s sickly and butt-ugly to boot. But if your system concentrates more on what a character can do, as either a matter of profession or skill, then attributes take a back seat. Your character is more likely to be typified (and remembered) as a fighter who dealt crushing blows in melee than as a “strong” guy. If so, we’re really talking about his ability to fight—either as a class or as a skill—than his STR score.

So, in an effort to streamline character generation and actual play, let’s think about nixing attributes for a bit.

Ability-based Characters

Let’s assume that characters are best defined by what they can do. This is generally true of both class- and skill-based systems, though each has a different mechanism for doing so. Let’s also assume that what a character can do—that is, his survival skills—are more significant in practice than the attributes upon which he bases those abilities. Finally, let’s assume that, as a player or GM, you want to generate and describe characters quickly, but customise them as needed without a lot of effort.

What if you combined the two models? What if you defined a character by his class, indicating a default set of abilities, but you allowed customisation via skills? Not a new concept, but it’s really about the execution. Dungeons & Dragons, well before 3E, included the concept of general skills. I welcomed them as a vehicle for customisation, but I’ll concede that didn’t really integrate well with the game’s class model or existing mechanics.

How about we approach from the opposite direction: first, let’s define what characters can do, absent attribute scores or class or skills. What are the abilities a character—any character—would use to survive an adventure? So you come up with a list of these things.

Next, you think about some character archetypes—call them classes if you want. You have guys who fight, guys who cast spells, guys who rely on stealth. Make another list of these archetypes, but not too granular (i.e., stick with classes, not sub-classes).

Now you start deciding how good each archetype on your second list is at each ability on your first list. The guys who fight are good at fighting and shooting, but not so good at casting spells. The guys who cast spells are good at magic, research, and lore, but they suck at fighting. Importantly, however, the fighter could learn magic, just as the wizard could learn to fight.

Represent each class’ aptitude for each ability as a cost for improvement. For example, come advancement time, the fighter has to spend 1 XP (or whatever) to improve his fighting ability by +1. A +1 improvement to spells, though, costs 4 XP. The opposite is true for the spell-casting guy.

Over time, as the character advances and earns points to spend on his level or ranks, or whatever, he’ll naturally get better at core, class abilities. As a player or a GM, you can easily create and reference the character by his class. But customisation is possible by having that character acquire and improve non-class abilities, and as descriptors, these extra talents become minor exceptions to the class-based generalisation.

Final Words

Ability-based characters aren’t new. ICE’s Character Law is the first reference to the concept I’ve seen, though the execution is far more number-crunchy than I think is necessary.

Still, an adaptation of this model would solve the sometime-issues of Chimera character kits. Newcomers could dive right in by selecting a class, which is ready to play out of the box. As one gains familiarity with Chimera, one could start customising that class through the acquisition and improvement of both class- and non-class abilities. Assuming an appropriate level of abstraction, there’s no reason a single list of abilities couldn’t cover every conceivable character action, which would obviate the need for attributes—certainly that would shave off some complexity, both during character generation and during play.

I’m still formulating the best way to execute this, assuming the idea is still attractive to me after playtesting. But I’m curious to hear what you have to say—any experience (good or bad) with this model?