Skill Organizations

The “skill levels” approach is an example of a linear skill progression. To acquire a specialized skill, you have to learn its parent (or prerequisite) skill first. Thus, you can’t learn, say, “diving,” unless you already know “swimming.”

A skill hierarchy takes this idea one step further and allows several specialized skills to be learned following the acquisition of a general skill. For example, having learned a “single-handed weapon” skill, a character may then learn “sword,” “axe,” or “club,” and from there further specialize into particular weapons (longsword, shortsword, rapier, cutlass, and so on).

A skill network is like a skill hierarchy except that it allows for skills to have two or more other skills as preconditions. You can’t learn the skill of “horse archery” unless you already have “horse riding” and “archery” skills; you can’t learn “espionage” unless you have at least three from “stealth,” “disguise,” “bluff,” and “hand-to-hand combat.”

Looking at skills this way, it’s easy to see how attributes came to be regarded as the same thing. “You can’t be a blacksmith unless you’re strong” is just like “You can’t be a pearl diver unless you can swim.” A concept such as “strength” becomes the concept of “being able to use strength;” although this is ultimately dependent on a character’s physical prowess, it nevertheless offers enough leeway to allow for increasing the “attribute” as a device for character improvement.

Doing this has certain implications for skill systems, though. Ideally, all skills should be implemented using the same basic mechanism, so as not to distract the players. If two or more skill systems run in parallel, they must be disambiguated somehow (this is why feats get a separate name). When attributes are handled just like skills, this means that skills and attributes should “look” the same. In other words, if attributes are on an integer scale then they should all be on the same scale and it should be shared by skills.

In practice, this actually works quite well. There are some awkward intrinsic properties of characters that don’t fit naturally into the scheme (the number of genders is fixed, for example) but they can usually be shoehorned in without too much bother. This isn’t to say that there aren’t better ways to do it, of course; however, it does mean there isn’t too much incentive at the moment to do it some other way. As usual, as long as designers understand why things are the way they are, they can make informed judgments as to whether to keep them that way.

It’s worth considering whether skills should be applicable to objects other than player characters. They can quite obviously be extended to NPCs and even some monsters, but what about objects in general? Could not a shield’s ability to deflect arrows be implemented using the same skill that a character might use to deflect them? Or more frequently, shouldn’t a fireball wand simply cast the spell? Skill transference like this is particularly useful for virtual worlds that use magic, where a wand could be given the same spell-casting skill as a player or a player given the same petrifying gaze skills as a basilisk. Could a sword improve, through use, to become better? Could it be trained (that is, enchanted) to learn new skills? If object qualities are implemented using the same system as player character qualities, at least these are options (albeit not necessarily ones every designer will want to pursue!).