Forums

A Case for Traits
 
Notifications
Clear all

A Case for Traits

1 Posts
1 Users
0 Reactions
543 Views
(@erin-smale)
Member Admin
Joined: 15 years ago
Posts: 84
Topic starter  

Chimera traits and what they're good for

Once, in a fantasy campaign I used to run, I needed an NPC that, for various plot and setting-related reasons, was a lowly commoner but a crack shot with the bow. Nothing remarkable—just a simple farm boy who could shoot an arrow better than anyone.

Unfortunately, this simple creation wasn’t really possible in the RPG system I played. The game was level-based, so being a crack shot with the bow was reserved for characters who (1) were classed, (2) had earned a high experience level within that class, and (3) were completely defined by that class. My farm boy archer was none of these.

My (inelegant) solution was to fashion the NPC outside the rules. In doing so, I knowingly courted imbalance to the campaign—exactly what following the rules is supposed to prevent. And while I had enough experience to prevent game problems, I wondered about neophyte players: How would they have created the same NPC, and what would have been the game-wide result? More importantly, would they have been able to accomplish their in-game goal?

Such questions have everything to do with traits in The Chimera RPG.

As noted in the Core Rules (CR), traits are abilities, skills, and qualities that describe what a character is or can do. Because traits are granular in scope and modular in nature, a given character possesses one of literally millions of possible trait combinations. But despite their open-ended potential, traits function within Chimera's closed-state rules. Object Oriented Programmers will correctly reference this mechanism as not unlike class inheritance, where a new class (i.e., a trait) may over-ride methods of an inherited class (i.e., the Chimera rules) to instantiate a unique object (i.e., a character).

Traits could have customised my peasant archer quite adroitly—perhaps with Missile Weapons +1 and Marksman +2—without any concern for game balance or rule adjustments. If I may extend the programming analogy, under the old RPG system, I had to "rewrite" a section of code (i.e., the rules) and risk introducing a few bugs in the process; under Chimera, I wrote a simple class (i.e., a trait) that "piggy-backed" on the existing code, which I didn't have to touch at all.

The implications for game customisation are quite broad. Consider an idea inspired by the 1938 film, The Adventures of Robin Hood, with Errol Flynn: what if, during mêlée combat, a fighter could push toward his foe, causing his opponent to lose ground. You've probably seen this in a dozen action films, where the fury of an attacker drives the defender backward (especially when there's something bad—like a pit or a lurking monster--behind him).

Again, in most RPG systems, incorporating this manoeuvre would require an addendum to the combat rules, which introduces the expected risks to game balance. But is also raises two, rather subtle issues as well: First, the move is likely to be over-used since, again as part of the RPG's canon, it's open to virtually anyone. Second, performing the move is likely to become static; that is, because it's part of the *system's* combat rules, it's not necessarily an ability one can improve over time.

Crafting the "Push" ability as a trait, however, negates these issues. The problem of rule tinkering never surfaces, since Chimera's core mechanics are never touched. The possibility of over-use is unlikely, since the manoeuvre is available only those characters who purchase the trait. Finally, characters can improve their Push ability by spending pool points to increase their trait rank.

The last point brings up another subtle dynamic of traits: because traits cost points, it's easier to justify any amazing abilities you want to include in the campaign setting, but exclude from the game rules. It's generally acceptable for a character to possess some major advantage, so long as he pays something for it, and pool points are good currency. It might be clever to say that when it comes to rule tweaks via traits, characters don't do any bending until they first do some spending.

We've defined Push as a mêlée combat manoeuvre that drives opponents backward, but doesn't do any damage. Parsing these qualities into individual components lets us easily set up some parameters:

  • Combat move - Push belongs in the Combat trait family; note also that it is effective only during mêlée
  • Non-damaging - Push cannot be used in conjunction with an attack; the easiest way to ensure this is to stipulate that Push requires trait roll, which necessitates a full action
  • Drives opponents backwards - A successful Push roll pushes a foe back, and it makes sense that the attacker's Size relative to his opponent is a factor in success

We now have the bulk of what the trait can do, but there are a few other items to consider: ability score, cost, and "faking it."

Most traits map to one of the four ability scores. That is, traits dealing with physical power correspond to Strength, traits of physical agility correspond to Dexterity; traits of mental accumen map to Intelligence, and traits dealing with mental presence correspond to Willpower. These are good rules of thumb, though there are two situations where a trait does not have a corresponding ability score, despite how well-suited to one it might seem:

  1. Whan a trait stacks - A trait designed to stack onto another (e.g., Backstab, Mounted Assault, Giant Killer, et al.) has no ability score. This is because the trait enhances another trait; mapping to an ability score would be "double dipping." If you think about it, it makes sense to avoid: you wouldn't want to apply the ability score more than once to a single roll.
  2. When a trait modifies - A trait that modifies another roll (e.g., Dead Eye, Reflexes, Hit Points, et al.) has no ability score. Such traits represent either an adjustment to a mechanic that has nothing to do with an ability score (e.g., Dead Eye's effect on damage dice is unrelated to ability scores; likewise Hit Points' effect on hit dice) or a specialised enhancement to one of the ability scores (e.g., Reflexes is essentially a situational DEX bonus).

If you wanted to summarise these provisos, use this rule: Only traits used with a trait roll get an ability score.

A trait's point cost is somewhat subjective, but we've attempted to approach values logically, using a consistent range of 1–3 points. As a general rule, the more powerful or broadly relevant the trait, the higher the point cost:

  • One-point traits are relatively common abilities, or are of low complexity so as to be easily learned and mastered; for example, Craft, which is common, open-ended, and not often applicable to most adventures, costs 1 point.
  • Two-point traits are harder to master, representing relatively uncommon disciplines and abilities, or skills that enhance and build upon other traits; for example, Heal, a highly specialised skill of significant value during play, costs 2 points
  • Three-point traits are truly difficult and represent highly esoteric or rare skills and talents; for example, Wield, which gives broad access to all sorts of supernatural powers, costs 3 points

Finally, you must evaluate the possibility of faking the trait. Faking it (CR/22) is the means by which a character lacking ranks could reasonably pull off a given trait, either by luck or through the raw potential of a corresponding ability score. In game terms, faking it gives a character a chance—however slim—of doing something in which he has neither experience nor formal training.

The litmus test of whether a trait may be faked is based on its corresponding ability score: if there is no score, it cannot be faked. Otherwise, it probably can. Thus stacking traits or traits that do not require a trait roll to use are impossible to fake—there is no reasonable way a character without training could hope to replicate what the trait does. Conversely, any trait that requires a trait roll to use might just work.

Given the above, and based on the qualities we've assigned to Push, we might come up with the following (in fact, we did; CR/28):

Push (1/STR/f): The ferocity of your mêlée attacks forces an opponent to lose ground in a fight. Push requires a full action during combat, but a successful roll causes your opponent to retreat 1". For every Size category larger than your opponent, you gain a bonus of +1.

The key to creating and including new traits is to look at game situations from a character's point of view. In fact, most traits start out as statements about what characters can (or should be able to) do in the game, and these statements typically begin with, "It would be cool if...", "It would make sense if characters could...", or "I need a rule to handle..." In many RPG systems, these statements end with a tweak or two of the core mechanics. While there's nothing necessarily wrong with changing the rules—for, as most RPGs (Chimera included) are quick point out, they are merely guidelines—doing so can introduce risks that threaten to undermine the purpose and usefulness of the new rule, create significant game imbalance, or both.

The great benefit is that traits keep such modifications balanced, specific, and completely within the scope of Chimera's flexible model. In other words, traits let you use the rules to change the rules. For the more handy among you, consider that traits are to Chimera as attachments are to a Dremel power tool: If you need the tool to do a certain job, you add an attachment, you don't recreate your tool. By simply changing its capabilities—instead of its foundation—you can go a long way in customising your Chimera game easily and with excellent results.


   
Quote
Share: