Image by freeimages.com / Eva Serna

A collision of thoughts: the origins of this article

The other day, I was searching through past articles looking for a particular reference for a cross-link when I found myself re-reading my article contrasting literary processes and writing for games (The Challenge Of Writing Adventures for RPGs), and – as happens to me from time to time – I experienced a collision of unrelated thoughts, putting 2 and 2 together and getting 4.

I immediately paused what I was doing and began making notes for this article. The subject is character skills, and the assumptions that our social conditioning makes of the game systems that we play in respect of them.

Specifically, I started thinking about the concept of Transferable Skills, and whether or not that concept was, could, or should be reflected in the way we – and our game systems – interpret character skills in an RPG.

Transferable Skills

A “transferable skill” is a skill learned doing one profession that has elements of a broader ability and hence can be applied to tasks required of some other profession. They are often vaguely defined, general, and overarching – “Communications Skills”, “Customer Relations”, “Problem-Solving”, and so on. Employers like them because they demonstrate that a potential recruit is bringing abilities to the table that will value-add to the proposed position, should they be offered it. These days, positions and promotions are won and lost based on an individual’s transferable skills.

And yet, the concept is not really reflected in the skills systems of most RPGs, which make assumptions about the nature of the learned abilities of a character, and which are then often interpreted in a completely different fashion – one that does take the concept into account – by GMs in the field.

I have always maintained that understanding the nuts and bolts – the underlying concepts and mechanics – that are embedded in our rules systems makes a GM better able to interpret and utilize that game system, so when I spot one of these underlying concepts or mechanics, I like to share that insight with the readers here at Campaign Mastery.

There is no formal definition of the way most GMs and RPGs interpret skills; instead it’s something absorbed by osmosis at the game table, first as a player, and then as a GM. That won’t fly if we’re going to take a good hard look at the subject, so that’s the place to start.

Coining a concept: “Adaptable Skills”

The way most GMs (in my experience) interpret skills listed on the character sheet is as the focal representation of a more general capability. “Fishing” as a skill is assumed to imply skill at tying fishing lines, knowing the signs of a good place to fish, knowing how to clean a fish, and all sorts of other things. “Fishing” is simply the label assigned to a gestalt of actual skills.

Because this interpretation isn’t actually defined or written down anywhere in most cases, the point where such skill systems frequently run into trouble is when two or more skills overlap. One could argue, for example, that “Fishing” would include at least basic knowledge of how to cook fish, and possibly even how to prepare the most common accompaniments for fish – the basic, traditional recipes. Some GMs will accept this rationale, while others will rule that because there is usually a completely separate skill, “Cooking”, this element of “fishing” in the common-world sense of the term is specifically excluded.

If a character has both “Fishing” and “Cooking”, a new nuance is introduced – how does the GM interpret this? Do they compound? Does simply having one give a bonus to the other? Does one have to make a successful check of the less specific skill before this can occur? Is it always the higher one that the character gets to roll, or is it the one that the DM considers more directly applicable? Is consistency of interpretation uniform, or is there a general rule and some specific or ad-hoc variations?

The other aspect of the question is using a skill for some other task. “I’ve got ‘fishing’, so I know the basics of how to tie knots.” Let’s break this example line of argument down into its’ constituent elements:

• “Fishing” is made up of many separate minor sub-skills;
• One of those sub-skills involves the tying of knots in fishing lines to make nets and repair those fishing lines;
• The same knots can be made in a different material, e.g. rope;
• Therefore, a “fishing” check enables a character to tie someone up, the check determining how effective the result is at restraining the subject.

“Fishing” and all the other skills on the character sheet are not a transferable skill, but they are an abstracted representation of a whole string of skills that are considered to be transferable, under this interpretation. A skill on the character sheet, in other words, is not transferable, but it is “adaptable” to a different purpose.

The GM who interprets skills in this way is perfectly entitled to increase DCs, or their equivalent in other game systems (skill modifiers or whatever) to reflect the degree of difficulty in adapting one skill to another. Balanced against this is the capacity of a player to argue that they have several “adaptable skills” with the same core ability in common – continuing with the knot-typing example, “profession: porter”, “animal handling”, and “riding” could all be assumed to involve knot-tying in the same way that Fishing does. If each such skill adds +1 to the effective skill of the character at “adapting” the skill they will actually check against, you have the basics of a sophisticated skill handling system, one that balances ubiquity and universality of some transferable skills against the need to actually use a skill in a way the character not covered by the character’s specific vocational training.

Skill Systems from a rules perspective

There are two essential approaches to skills as used by rules systems. These are described in many different ways all ultimately meaning the same thing: you have “narrow”, also described as “focused”, “strict”, and which define skills from a “bottom up” perspective; and “broad”, which may use terms like “generalized”, “relaxed”, “adaptive”, or “interpretation”, and which define skills from a “top-down” perspective.

Quite often, rules systems won’t be explicit about these underlying assumptions, leaving GMs to get themselves into a tangled mess – especially if the GM assumes one interpretation and players another. Things can get even trickier when you adopt a “Say ‘yes’ quickly” approach to skill interpretation, something that Campaign Mastery (and a great many of the GMs who contributed to our recent 750th post) have advocated for quite some time, because that implicitly assumes a “top down” perspective, such as the one described using the “fishing” example – and that doesn’t work properly if the game system isn’t engineered to match.

Skill systems from the bottom up

“Bottom up” skill systems assume that there is a specific skill for every task, and that each skill explicitly defines what it can be used to do, and nothing more.

More sophisticated versions of “Bottom Up” skill systems involve “prerequisites” and may also invoke “tiers” of ability – for example, you may require “mathematics” at a certain level before you can buy “physics” beyond a certain level, and your skill in physics may be capped or restricted to some number relative to your mathematical skill.

Further variants are a little looser, employing pricing levels to achieve similar ends – “+1 physics knowledge” may cost 2 “skill points” or equivalent if you have “mathematics” below a certain standard.

And there are many hybrids. “Specializations” may offer greater specificity in advanced topics, for example.

Such systems generally are characterized by having a great many skills on offer, and are more commonly encountered when looking at Sci-Fi and modern-day genres, where the breadth of knowledge is greater and the existence of specialized expertise is more justifiable. Levels in a given skill are relatively accessible, but diversity of available skills diffuses advancement to reasonable levels; characters may be “experts” in one or two fields, but will have relatively low skill levels outside of those fields. The concept of a “jack of all trades” also has considerably greater currency in such systems, which convey that a character has a moderate level of expertise in all skills but more restricted specialist expertise.

Skills applied in other ways

Skill systems, like all RPG rules, are slightly-vague abstract simulations of a more complex “reality”. They are inherently imperfect, because perfection requires such levels of detail as to be impractical at a gameplay level. Because of these imperfections, Bottom-Up skill systems may break down when characters attempt to do something that isn’t covered by the specific applications provided by the system mechanics.

GMs ultimately have two options: to extend the existing definition of a skill to incorporate the proposed new application, or – if it sufficiently broad that it should have been a skill in the first place, to add a new skill to the system. The best yardstick for determining the optimum answer is the scope of the proposed new application; if it is of a scale commensurate with the other specific skills supplied by the game system, then it should be a new skill; if not, it should be a new approved application of an existing skill. The use of this yardstick maintains the system’s integrity in terms of inflation of available skills, and the overall degree of abstraction within the system remains relatively consistent.

The GM’s problems don’t end there, however; introducing a new skill as part of the existing body of rules is inherently retroactive; it has to be assumed that the skill has always been available for players and NPCs alike to take, but that (for some reason) none of them have ever done so. This can shatter credibility like so much spun glass. Most of the time, this disaster can be avoided by permitting retroactive adjustments to character skills, creating a minor break in continuity of development that can be glossed over. Ideally, characters should not be permitted to completely “unlearn” a skill, but can reduce levels of expertise in another skill in order to develop the “new” skill in their stead.

This leaves the verisimilitude of the past intact except under one specific circumstance: where the existence of the new skill would have materially changed the outcome of a key plot event, saving the villains for example. Completing the remediation process requires the retroactive insertion into campaign history of some reason why this would not have worked, or (alternately) assuming that the event did in fact produce a different outcome that was concealed from the PCs at the time by trickery or deception. Their enemy really did escape, but he tricked them into not realizing it – until now!

Because this will obviously have an impact on the current and future campaign, recasting or even invalidating parts of it, the GM has to decide which choice is the least harmful to the campaign – editing either the past or the future (actually, there’s a third choice, but that’s a subject for an entirely different article).

Skills applied to related tasks and sub-tasks

Rules debates about skills in a bottom-up system tend to be about whether or not a given task is inherently a part of the abstraction described by the skill. Does a skill in “History Of England” include a detailed knowledge of the history of Wales? Or just the history of interaction between the two? (Okay, that’s a fairly simple example; the answer is “no”.)

So let’s ask a curlier one: to what degree does ability to drive a horse-drawn wagon confer the ability to drive a reindeer-drawn sled? The two are more-or-less equal in scope, so arguably “Sled driving” should be a completely separate skill – but the two are similar enough that you could argue that they are both specific applications of the one skill, “driver of animal-powered vehicles” – and the rest is simply a question of making suitable allowances for environmental conditions. So this is right on the cusp of falling either`way.

Because skills are interpreted so precisely and narrowly in the “bottom-up” model, such debates are always about trivial minutia that has suddenly assumed disproportionate importance, and hence always infuriating and annoying to all concerned; and because there are more skills in such systems, this sort of debate occurs more regularly. As a result, there is a constant temptation to impose some inflexible ruling or overarching guideline, or to settle such questions quickly without giving them the thought they deserve.

It was thinking about such broad generalities that led me to come up with Look beyond the box: a looser concept for NPCs.

Skills applied to complex tasks

To some extent, it’s when a character attempts a complex task that this sort of system comes into its own, because the complex task can be broken down into smaller subtask, defined as requiring a separate skill roll (often against a completely different skill). This means that any failure in the complex task can be precisely pinpointed, as can the consequences and the timing of the discovery of the error, which in turn defines what remedial action (if any) is possible – turning the complex task into something that can be roleplayed, and giving the player something to do while their character is tied up performing this task.

TORG took this one step further, building time variability into each part of the complex task – these were broken down (by default) into four stages (A, B, C, and D) and permitting the character to roll for each only when a card was played/turned over with the appropriate letter. If, as your turn, you completed A successfully, for each subsequent round (while others were doing whatever they were doing) you were assumed to be doing B until a card came along with a “B” code to signify potential completion of the “B” step – you then rolled for success or failure.

Transferable Skills in RPGs

Another way of looking at bottom-up systems is as explicitly defining every occupation and task in terms of the explicit transferable skills. Every skill is either one of these “universal building blocks” or represents those elements of the vocation that are not transferable, By defining vocations in this way, a more comprehensive and complete analysis of both tasks to be performed in-game and character abilities to perform specific tasks is assembled.

Summary Pt 1: Transferable Skill Systems

Bottom-up skill systems are those in in which the purposes/actions to which a skill can be applied are defined and restricted, and in which no skill can be assumed in a task that is not explicitly specified, can require the addition of new skills whenever actions are defined that do not already exist within the skills system. Skills function as defined and discrete applications of the skill-system class of capability. Your skill in any given complex activity is the combination of your skills in all the lesser tasks defined by an individual skill.

Skill systems from the top down

These are fundamentally different in concept to the bottom-up approach. A skill implies the ability to perform all the subtasks, and is an abstracted entity that comprises all the subtasks. The more skills the set of available skills is broken into, the greater the granularity of the system, ie the level of precision possible. However, that level of precision is defined by the game maker and rarely actually discussed within the game rules.

Transferable skills are considered to be implied and embedded within the system rather than explicitly defined. The “Skill” that is listed is a synthesis, an abstract representation of the capability of completing every task that is explicitly listed and any task that the GM rules is also part of the field regardless of its not being explicitly stated.

This enables the player to argue that their skill in Animal Riding includes the basics of how to care for the animal, and therefore gives them a chance to use that Animal Riding skill to diagnose the problem and find a solution when a mount falls ill.

Right away, we’re in deep water with that example, because there is obvious potential for overlap in transferable skills – let’s make it obvious by talking about “Profession: Animal Veterinarian” – but there are often no guidelines for how to deal with such overlaps, or such guidelines have a sense of being ‘tacked on afterthoughts’.

Skills applied in other ways

A skill can be applied to any task the GM decides that it is relevant to, beyond a small range of specific and mandated examples incorporated into the skill description. This immediately raises the specter of GM inconsistency as a problem that can occur. On top of that, everyone will have a slightly different knowledge and understanding of what is or is not covered by a particular skill, so confusion can result when jumping from one game table to another.

Players will have different levels of expertise in any given field to their characters, and because so much is not explicitly stated, this can impact on what they think their character can do with the skills that they have.

Furthermore, it is reasonable to expect that most players will have at least one sphere of knowledge in which they are more expert than the GM is, and may disagree (with good cause) with the GM’s calls on the scope of a skill.

As often as not, attempting to apply a skill in any non-specified way will trigger a discussion of the scope of the skill – which is deathly dull to everyone else at the game table – at least until everyone comes to terms with the unwritten “rules” in the GM’s head.

Skills applied to related tasks and sub-tasks

This is where the greatest scope for disagreement potentially lies. I know one GM who advocated the line that since skills were not listed amongst the exceptions, stacking limits applied when multiple skills potentially applied to a given task. If he had chosen to permit players to use their highest relevant skill to roll against, he might have gotten away with it; he did not, instead defining a principle he called “allied skills” in which the skill that he nominated was the primary skill against which checks had to be made, and any relevant related skill was worth +1 to the die roll if, and only if, it was at a higher skill than the primary skill to be checked. Even that might not have been too bad – it certainly sounds reasonable on the page and in context – but he then further ruled that every subtype of a skill was an explicitly different skill and that a character’s racial profile automatically appended the skills with an invisible “subtype”; in other words, an Elf who put points into the “architecture” skill was explicitly taking levels in “Elvish Architecture”, which was a different skill to “Human Architecture” and so on. “You have no skill in [X]” became a repeated refrain at his game table – for about three weeks before his players deserted in droves.

Where this GM really went wrong was treating a top-down system as though it were a bottom-up system. He wanted everything to be explicit and racially-profiled – something that is not unreasonable, but that can be managed in a number of ways – when the system is designed to be more abstract and umbrella-like in its definitions.

Skills applied to complex tasks

This tendency to gather things under a single abstract umbrella often also manifests in how the GM chooses to handle complex tasks. Quite often these will also be abstracted and generalized into a single die roll for success or failure, with the GM and players improvising a narrative that describes how that die roll will be interpreted – a success may be achieved after setback after setback is overcome, for example.

There’s nothing wrong with that, but many GMs also use the degree of success or failure as a measurement of other narrative criteria, such as the character’s satisfaction with the result. Others “band” degrees of success – barely succeed and your end result looks like you did the work while wrestling alligators, barefoot; succeed by 5 or more to get a “good quality” result; succeed by 10 or more to get an “excellent quality” result; and so on. Still others use degree of success or failure to measure how long completion of a task to a minimum acceptable standard takes, with that minimum acceptable standard being defined by the skill level of the character at the time – so a “marginal success” by a character with a skill of 10 means something completely different to a “marginal success” by a character with a skill of 2; the character with the skill of 10 sets himself a higher acceptable standard, and is entirely likely to reject as “junk” something that the character of skill 2 would be quite chuffed at accomplishing

Too many interpretations for one die roll! Some GMs see such proposals written up online, or in gaming magazines, and try to implement them all at the same time because they sound cool. The result: it never rains but it pours; the only question is whether it’s milk and honey or acid rain.

Some GMs, realizing the problems that this can cause, chooses from die-roll to die-roll which interpretation is most useful for the current game circumstances. In fact, I sometimes do so, myself – though these tend to be exceptional circumstances. This can be a problem because the players never know what a die roll will actually achieve, beyond the mere fact of success or failure; there is a strong temptation to cheat as a result, or at least, to “massage” the circumstances to be in their favor.

By-and-large, a GM is best served by deliberately choosing one meaning as their normal default for a given campaign and using the alternatives to make each campaign a little more distinguishable from the last. They can then integrate that choice into their rules and rulings, treating the other variables as independent of the die roll, therefore giving them greater narrative control at the game table, which they will exploit for dramatic purposes. So long as this is made clear to the players going in, there should be no problems.

Transferable Skills in RPGs

Transferable skills in a top-down system are the “glue” that connects one skill to another, the overlap in each skill’s scope, never explicitly defined. This actually provides an excellent characterization tool that can be exploited by canny GMs and players if both agree: a player can give his character a matches advantage-disadvantage pair in which they get a -1 or -2 in one transferable skill and a matching increase in another. It is therefore assumed that, since the character’s overall ability in any given skill does not change as a result, the other aspects of an affected skill are benefited or harmed to like extent. This natural “knack” or lack of it thus becomes a defining filter, coloring the skill system for that particular individual in a specifically-defined way.

However, there is a caveat to this approach; the GM must be sure that each element of the pair really does balance the other. Taking a penalty in anything related to Goblins may sound well-and-good, but it’s no real penalty if goblins are rarely-if-ever going to feature in the campaign. Both advantage and disadvantage have to be approximately equal in applicability for this to work, and there also needs to be a hard limit on the number of such pairs that can be accepted. Experience has shown that 1 is too simplistic, 2 is manageable, 3 is about the limit – but this function is also dependent on the number of players; this was in a player-light campaign. If there are more than 3 players at the table, I would set the limit to two.

The great power of this concept this the flexibility that it brings, You could have a character who is hopeless at anything to do with maps – but excellent at dealing with animals, whether that be tracking them, riding them, hunting them, cooking them, or whatever.

This example also brings up the second great pillar of equality of which the GM should be mindful: significance. At first glance, you might feel that these are inadequately balanced, because the advantage will apply far more frequently than the disadvantage; but that’s not necessarily the case, because on a lot of the occasions when it is relevant, the advantage won’t achieve anything particularly significant beyond the characterization, but while the disadvantage won’t apply very often, almost every time that it does will be important.

The last time I used this was to create a shy, introverted, withdrawn character with extremely poor people skills – who became a silver-tongued devil when bargaining, bartering, or trading. “Please, just a little more, guvner. I’m juft a poor widdle orphan boy stwuggling to earn a little money to buy food for my poor sick muvver. Have a heart.” I doubt the player would even remember the encounter now, even if he had not passed away a few years back – but the ‘street urchin’ went home with about twenty times what he should have, given the true quality of what he was peddling. Changing his appearance and patter, he proceeded to tap the same target another four times without being recognized, earning about 4,250 gold for products that (if as advertised) should have been worth about 500 gold – and which were actually worth between 5 and 10 gp!

Game system design implications

Many systems designers don’t think about these two very different approaches, employing both in equal – and confused – measure. Sometimes, it’s the case that one half of a development team has one perspective while other has the opposite – and unless the line editor figures out the point of disagreement in philosophy, half the skills system ends up being incompatible with the other half.

Points-buy systems – small purchases vs expensive ones

One way of figuring out what was going on in the game designer’s head is to look at the number of skill points that it costs to improve a skill, and hence what likely skill progression is likely to be. If skills are expensive, the likelihood is that the intent was a top-down system, while if they are cheap, the likelihood is that the intent was a bottom-up system. Of course, “cheap” and “expensive” are relative values; they need to be placed in context by looking at the rate of progression of penalties or increases in difficulty.

For example, in the Hero System, skills are relatively cheap, and there are a lot of them. The implication is that these should be interpreted as a bottom-up system. Skills in 7th Sea, in comparison, are quite hard to put up, and the implication is that these should be given a top-down interpretation. The same can be said of Star Wars: The Edge Of Empire, to use a more recent example.

D&D, 3.x, and Pathfinder

And what of D&D/Pathfinder? Ah, therein lies the rub. There are enough skills in these games to suggest a bottom-up approach, and they tend to be relatively easy to put up – but so are the difficulty targets, at least at lower levels. The examples of play offered for both hint at a top-down approach. But the DCs that should be applied to tasks are a muddle – rising more quickly with increased difficulty than skill levels at lower character levels but rising more slowly with increased difficulty than skill levels at higher character levels. It thus becomes ridiculously easy to achieve DC25 as a target at even moderate levels. What we have here, then, appears to be [is] a conceptual problem in the design of the game mechanics for 3.x that Pathfinder then inherited. This problem largely went away with D&D 4th edition from what I can tell, and was definitely less of a factor when I playtested 5th ed.

A solution of sorts is possible: most of my campaigns use ([DC-5]x2)+5 to set the DCs for any given task, where the “DC” in square brackets is what the book says it should be. So DC5 remains DC5, DC8 becomes DC14, DC12 becomes DC19, DC18 becomes DC31, and DC25 becomes DC45. The theory is that characters won’t attempt High-DC tasks until they have a reasonable chance of success, and this keeps those high-DC tasks at arms length until the characters are quite high level. Other solutions are possible, though possibly less convenient: “([DC-10]x3)+10, no effect on DCs under 10”, for example: DC5 stays DC5, DC8 stays DC8, DC12 becomes DC16, DC18 becomes DC34, and DC25 becomes DC55. This decreases the effect at mid-ranges (DC 10-20) while increasing it for higher DCs.

Both these are shortcuts for simulating a more precise solution in which DCs are increased at a rate more commensurate with skill level progressions, or a revision of the stacking limits rules to cull some of the ways of evading these that have built up over the years. Be that as it may, what we have in 3.x/Pathfinder is a system designed at least in part as a bottom-up system and used almost-universally as a top-down system. But for all that, it’s a better solution than the total absence of one in 2nd Ed, or AD&D.

It’s sometimes said (inaccurately) that the Chinese ideogram for “trouble” represents ‘two women under the same roof’. Certainly, an accurate alternative would be ‘two game systems at the same game-table.’

Is such a butcher’s hack truly the only solution? After all, the same problems occur with other game systems, too; can we not find a more interpretational solution rather than fiddling too much with game mechanics? Changing the way we translate in-game attempted actions into game mechanics, in other words?

The Bottom-up approach

There’s a simple three-step process that turns D&D/Pathfinder into a true bottom-up system (provided the GM is also willing to add additional skills as necessary, and as described earlier):

• Define the tasks that in aggregate comprise the overall action being undertaken.
• Player rolls against each task at the same basic DC. If he succeeds in all tasks, then he has succeeded in the overall action. If he fails in one or more then the overall result is at best a marginal success and at worst a complete failure, trending toward the worst-case result with each additional failure of a subtask. The GM interprets the results accordingly.

What this systemic interpretation achieves is a number of useful things. First, it redefines every attempted action into the application of transferable skills. Second, it checks those individually. Third, it represents overall competence as more valuable than being good in one specialist subject when it comes to real-world applications. Fourth, by increasing the number of times a high-DC must be achieved, it at least partially alleviates the mismatch. The rest can be handled by the GM being more generous in his interpretations at low levels, and much more strict at higher character levels. But, to avoid any suggestion of bias against high-level characters, base that differential tolerance on the DC required – so rolls at DC 5 tasks are treated generously, while rolls at DC 16+ or 20+ or whatever are treated very strictly.

It can even be argued that this is a more realistic interpretation, insofar as complex and detailed tasks are more prone to total failure if each element is not completed successfully, while simpler tasks have more leeway for error. Get the design of a chair a little bit wrong, and you may have to cut off part of one leg of the chair to balance it; get the design for a castle’s supports wrong even a little bit and the whole structure will come down.

One roll to rule them all

It is also possible to Conflate the relevant skills into one roll, if desired. All it takes is a calculator: Multiply the die rolls needed by each other and divide by 20^(n-1) to get the chance of total failure; multiply 20 minus those die rolls by each other and divide by 20^(n-1) to get the chance of complete success; everything else is a smooth continuity in between. For two rolls, 20^(n-1) is 20; for three, it’s 400; for four, it’s 8000; for five, it’s 160,000.

For example, lets say that for a task, the character has 3 rolls to make, requiring 4+, 8+, and 6+, on d20. 4x8x6=192, so the chance of total failure is 192/400 on d20, or 0.48. Effectively, no chance. (If the last roll required had been 16+, we would have gotten 1.28 on d20, i.e. a 1 in 20 chance). The chance of total success is (20-4)x(20-8)x(20-6)/400 =16x12x14/400 =2688/400 =6.72 on d20. So 13 or better to succeed completely, 0 in 20 chance of complete failure, and an overall likelihood of success after overcoming some difficulty or success taking a little longer than desirable, or a partial success.

You could even use the principle that a natural 1 is always a failure and a 20 always a success. In this case, that would make no difference to the chance of success, but would ensure the risk of total failure remains.

A top-down alternative

It’s also possible to adjust our thinking to make D&D/Pathfinder a more truly top-down system. I’ve already telegraphed the way to do so, in fact.

• The GM selects the one most applicable skill to the task at hand. This is the primary check that they have to make.
• All DCs over 10 are increased by 5.
• If the character does not have the required skill at a level greater than or equal to half the DC, the DC is increased by (an additional) 10.
• For every relevant skill that the character has that is both greater than the DC required AND the primary skill, the character gets +2 to his die roll.
• For every relevant skill that the character has that is greater than either the DC required OR the primary skill, but not both, the character gets +1 to his die roll.
• The player makes his primary skill check as indicated. Success indicates total success, a 1 indicates total failure, anything in-between is subject to GM interpretation.

Once again, this achieves a lot of different things. It acknowledges that high skills in a related discipline bring proficiency at a transferable skill to the problem, without bothering to get into the nuts and bolts of what that skill is. The player simply has to recite a list of the skills they think might be relevant while the GM counts (either to himself, aloud, or on his fingers) a “yes”, “no” or “partial” modifier. It’s fast, only taking a few seconds. Only one die roll is involved, but the results solve the problem of high DCs at high levels by imposing the additional requirement of a skill level equal to or greater than half the DC, then increasing that DC if the result isn’t achieved. The principle is one of making the DC higher, then allocating conditional modifiers to erode that penalty if the character meets the requirements; it means that a character should easily succeed at tasks that are within the scope of his character level’s expertise, but will have to have things go their way to have a reasonable chance at succeeding at anything too far beyond reasonable.

An abstracted half-way house

In theory, it’s possible to design a game system that abstracts all tasks into a group of “specific” skills which are then used as building blocks for any particular skill check. Roll under target, Stat +1 for each building block, -2 for each building block missing, one roll. I have never seen such an approach actually used, but it’s possible.

The Zenith-3 rules approach

The Zenith-3 game system offers a very different alternative that’s worth a brief description.

• Stats give ability checks.
• Specific ability checks are then combined to give aptitudes, i.e. how good people naturally are and how good they can get.
• Aptitudes are used to calculate specific base skill scores in Fundamental Skills when those skills are purchased.
• The price of a skill, and the cost of improving it, depends on the difficulty of the skill and this “natural talent”.
• Some skills are defined as “Expert” skills, and are based on, and require, specific Fundamental Skills.
• Skill levels in those Fundamental Skills are used to derive base levels in Expert Skills.
• If the character doesn’t have the required skill, the aptitudes are used instead.
• The System biases against unskilled use by imposing penalties for not having the required skill.
• The System insulates skill levels against changes in stats by simply altering the improvement cost thereafter, not retroactively.
• Characters can purchase specialized areas of expertise within a given skill.

There’s a lot more; it’s a complex system that specifies well over 100 specific skills and details exactly what they can be used for. It is a deliberately bottom-up system that is equally deliberately designed to have top-down application in-play. But, at more than 20 pages of tiny, tiny, type plus the skill descriptions themselves (which have not been completely finished at this point but still add another 48 pages of type), it’s far too extensive to be published here (or anywhere, under the terms of the license for the Hero System, on which it is based).

Game-play implications of top-down and bottom-up

If the system is clear about its approach, interpret it accordingly, knowing what the system expects. Evaluate the tasks proposed either in terms of the relevant skills or in terms of the subtasks involved, and determine a result accordingly.

When the design is confused – which is more common than my focus on 3.x/Pathfinder may make it seem – make an interpretation and stick with it.

A flexible compromise

There is one final compromise on offer for dealing with confused mechanics, and it may be the best answer of them all. That’s why I’ve saved it for the next-to-last word.

• If the skill description explicitly defines a function, it is directly applicable and must be tested whenever that function arises as part of a complex task. This defines some activities as requiring multiple skill rolls and having multiple vectors for failure, though they can still be conflated through basic probability math. All you need be able to do is multiply and divide, as described earlier.
• If no skill explicitly defines a function, use a top-down approach, looking not for transferable skills but for Adaptable skills.

Conclusion

A lot of the trouble that arises from skill systems is unnecessary, caused by GMs not understanding the intent of game designers, or game designers not understanding the implications of what other game designers have put in place. There are solutions to all these problems, of varying complexity and impact on a game. Understanding what the underpinning philosophy of the game system is enables you to make the correct choice of solutions when presented with problems, and avoids many of the problems by framing the interpretation of attempted actions into game mechanics in the correct way.

Where there are so many solutions, there are bound to be more. Sometimes groups will stumble onto something that seems to work without ever understanding why it works. If whatever you are currently doing is working, don’t change it – but use the discussions in this article as a tool to understand it and why it works, enabling you to enhance it further – or simply avoid harming it. If, however, any of the problems described struck home for you, this article should tell you why they are happening – and at least some things you can try in an effort to do something about them.