Skill systems in tabletop RPGs are a response to two design questions : “can the character do [thing]?” and “how well can the character do [thing]?” A primary force drawing serious players to these games is their interest in reasoning about outcomes, and these questions directly address this concern.
However, even though skill systems often do answer both of these questions, conventional implementations bring along serious design downsides.
An Example
Consider a tabletop RPG with a military setting. The designer shows us three types of characters—Soldier, Medic, and Scout—which are the intended player classes. During the course of play, a party of three Soldier characters sees one of their number downed by a shot from a sniper. They drag the downed Soldier to cover, and the question arises: “can I do something to heal or revive him?” The answer has far-reaching consequences.
High-Contrast Design
The cleanest answer to this question is, “no, you'll need to find a Medic.” If the Soldier, Medic, and Scout classes are all given exclusive domain over particular game mechanics, it underscores their role in the game and simplifies questions like this.
A Thief in AD&D would never even reach the point of asking, “can I Lay On Hands to heal my wounded ally?” just as the Paladin would never attempt to Hide in Shadows. These concepts are placed by the designer strictly within the boundaries of the relevant classes.
Serious players function in tabletop gaming by interpolating between well-established anchor points. Player objections to strict boundaries will highlight the conflict between this interpolation and the designer’s vision of a clean split of functionality. “Healing/medicine exists in the game, and my character is a perfectly capable functioning adult. Isn't there something I can do?”
Some interpret this as an appeal to realism/verisimilitude, but I think most remarks like this use realism as a justification for the remark rather than it being the cause. Players who are paying attention are always interpolating in this way, and that isn’t necessarily negative—interpolation is a weapon that can be put in service of good or evil.
Universalist Design
An entirely different answer to this question would be, “roll a Healing skill check to see if you heal him.” Anyone familiar with later iterations of D&D will recognize this design.
Universalist designs take elements which would otherwise be locked behind class membership and make them available to anyone. Part of the appeal is the simulation aspect it provides—we can compare two characters in the game by looking at the scores of their skills. This character has Breadmaking 4, and that one has Piloting(Astromech) 2. Skills and scores give us an idea what the character can do and how well—answering those two essential design questions.
This approach has serious issues. Although these problems are not a necessary consequence of a universalist design, we see in practice that these patterns lend themselves heavily towards loss of distinguishability between system actors, awkward interpretations of states and outcomes, and a lack of supporting systems.
1. Distinguishability Loss
Imagine the text under the Medic class was "You gain +5 to your Healing skill" and nothing else. This extreme example illustrates the first problem—the more universalist our design, the more difficult it becomes to identify meaningful distinctions between characters. As a system approaches complete universalism, each character moves closer to being an indistinct blob of degrees of mastery.
This might be a desired, or at least partially desired, outcome for the designer. There is a vague attraction to the idea of any actor in a tabletop RPG following the same rules, being subject to the same considerations, and being set apart only by their particular distribution of scores.
But something isn’t right. Primeval whispers tell us that powerful stories, important events, and legendary figures have staying power because of their archetypal nature. Designing a system where everything is of, by, and for the same brown mud as everything else is designing a failure—even if we succeed.
On a more pragmatic note, this indistinguishability isn’t impermeable. After all, an expert in the system can carefully analyze a character and form a precise idea of their capabilities. But there is a communicability problem. A comparison between a sword and axe is a lot more intuitive, accessible, and immediate than a comparison between two surface-to-air missile designs. For the latter, we must resort to lists of specifications to build a mental model of which is better.
Serious players are fully capable of creating memorable characters (and campaigns!) in such systems, but that is despite this design choice.
2. Interpretation Problems
If Jebbro has +13 to [idea] and Brojeb has +14 to [idea], then we can say that Brojeb is undeniably better at [idea] than Jebbro. If these bonuses are on a D20 scale, Brojeb has a 5% edge over Jebbro.
Some of you are nodding your heads like this makes perfect sense, but people do not evaluate anything except deterministic machines and tools in this way. Intelligent evaluators instinctively organize the skill of others by simple classifications like Novice, Intermediate, Expert.
Even in situations where candidates are highly filtered, we still do exactly the same thing on a different scaling. If everyone in the room is an Expert-level hacker, we start to break them down further (only if necessary!) into Expert, Master, Wizard—but these are all just expressions of Expert. In a context where we have to consider a legal team and an IT squad together, we revert immediately back to Novice, Intermediate, Expert in both cases without missing a beat.
Having our list of ideas with numbers next to them subtly changes our interpretation of dice rolls for the worse. If someone starts rolling very well, we are unconsciously placed in a mindset to sardonically comment, “wow, very skillful today.” Or worse—we interpret bad dice rolls as dunce-level failure.
This is even more emphatic when we must compare rolled results. If a Medic has +5 to Healing and rolls a 4, he has the same result as a Soldier with +0 rolling a 9. Did the Soldier really just achieve Medic-level Healing ability in that one moment? It’s a difficult situation that many experienced players have trained themselves to overlook or laugh off, but there is not a brief and coherent answer to this question.
In an ideal system, dice rolls represent the whims of Fate—we are discovering what happened or what the circumstances were. Picking an easy-looking lock and failed? It was much more difficult than it appeared. Opening a sophisticated vault as a novice? It malfunctioned or someone forgot to engage the locking mechanism fully!
When we start interpreting dice rolls as a measure of effort or skillful application, even unconsciously, we lose alignment with this most perfect interpretation.
3. Lack of Support Systems
Anyone that has played D&D 3.5 knows its skill system to be a prime example of the flaws of a universalist design. However, the Jump skill really stands out from the rest in a positive way.
More than just an idea with a number next to it, the Jump skill is integrated with the movement system. Usage results in movement and is something that can be done only when a character is moving. It has an attached set of tables conveying precisely how to interpret the outcome of a roll.
The Jump skill has an attached score, its bonus, that directly ties into a set of quantifiable outcomes. This input-output matching is a well-aligned design, and it results in the Jump skill being an intuitive and fitting addition to a skirmish-scale game that D&D 3.5 is clearly set up to be.
Unfortunately, the Jump skill is the exception that proves the rule here. Most of these systems were probably not originally envisioned this way, but we have example after example of skill lists churned out with barely a paragraph attached to their meaning or interpretation.
The lack of supporting systems causes a general ambiguity in reasoning about the outcomes of actions. A particularly egregious example is the Knowledge skills which are subdivided into their own sub-list of types—and none of them with more than a sentence devoted to conveying their purpose or intent.
An example which stands out to me as entirely opaque design is the Traveller skill Science, which is described in this comically bleak way in the second edition:
The Science skill covers not just knowledge but also practical application of that knowledge where such practical application is possible. There are a large range
of specialities.
Aside from the sub-list, this is all that’s ever said about a skill which conceptually covers all of known material reality. Creative and intelligent players can utilize this skill to good effect, but it’s because of their own blessed talent and devotion rather than anything the designer gave them to chew on or work with.
As a referee running into these systems, you really have to earn your keep to make room for skills like this without them being gatekeeping devices, I-Win buttons, or useless point fodder.
One last problem with this ambiguity is that players gradually adopt an inverse decision-making process. Rather than reasoning about outcomes through a concrete understanding of connected systems, they come to see skills as the endpoint of a black box process. If every problem we encounter ends up in a read-through of the skill list, we start to see the skill list as the solution to every problem and can only conceptualize problems in terms of their relation to skills. Hammer; nail.
The difference between “how am I going to solve this problem?” and “which skills are the most applicable to this problem?” is subtle but of extreme importance.
Something In Between
Between a high-contrast design and a universalist design, there is a lot of space. We can begin with a universalist design and corral parts of it into well-defined boxes. Or we can take a high-contrast design and release some of the pressure. Methods like these are how tabletop RPGs commonly get assembled.
But there is an asymmetry in traveling one way vs. the other.
If we go too far in the direction of a high-contrast design, we create (unwanted) tension between the players’ desire to interpolate and the restrictive access to functionality. But successful board games do this all the time, and players learn to recalibrate their interpolations to fit the strictures.
If we go too far in the direction of a universalist design, we open ourselves to the problems above. They can be addressed in a more detailed way in whatever system we’re developing, but the weight of these problems and the anti-patterns of play that have culturally developed around them strongly imply that we should begin with a high-contrast design skeleton instead.
The Way Forward
As far as practical implementations go, membership-based “skills” are a compromise for when we want to keep clear divisions but allow for shared participation. Two good examples of this are D&D 3.5’s feat system and ACKS's proficiency system. Even though 3.5 is infamous for its design decisions, the feat system works cleanly. Special mechanics and alternate systems are available to anyone willing to pay the entry price.
A binary membership system answers the “can I do it?” question but not “how well can I do it?” If this is truly necessary to address (it often isn’t), then it is much better to make a system for the functionality rather than a skill in the conventional sense.
For a game in a futuristic ground combat setting, it is probably sufficient to know whether someone can pilot a spacecraft. On the other hand, if the game has dueling spacecraft as a key feature, then knowing that my pilot has a +4 bonus to a roll that decides the outcome of a battle is less than satisfying. More design elements are needed to ensure that spacecraft duels are rich experiences (in inputs and outcomes) instead of mere die rolls.
There is so much more that we could mention here, but the important takeaway is this: we need to be implementing more systems and removing more ambiguity. Conventional skill systems work against both goals. And after years of people wrongly “evolving” D&D into its current state, we can clearly see the drawbacks of these skill systems in contrast to the old ways.
An interesting note is that Classic Traveller's skill system is closer to D&D 3E Feats or ACKS Proficiencies than to later Traveller Skills of D&D 3E Skills. In many cases, outside weapon specializations ("weapon skills"), the skill level matters less than whether or not you have the skill.
I look at it another way. I call it the "inclusive" vs "exclusive" skill approach - if it's not listed on my character sheet, can I do it anyway, even if not well? Yes (inclusive) or no (exclusive)?
Advanced Dungeons & Dragons 1st ed, as a class-based system, did not cover many more mundane things like "can you tie a knot?" or "can you trap a rabbit?" This is for cultural reasons: as the saying goes, the past is a different country, they do things differently there. When Gygax wrote AD&D in the late 1970s, and certainly when he had his childhood years before, essentially everyone could ride a horse, pitch a tent, cook dinner and so on. No roll was needed because, "yeah, of course you can do that."
There was a level of assumed competency. This was inclusive.
As time went on more and more people lived in urban settings with airconditioning and TV dinners and so on, and this competency could not be assumed. The default went from "yes you can do that (because after all, everyone can)" to "no, you can't do that (because after all, most people can't)". Thus the skill system in AD&D 2nd edition and of course later editions. The game designers couldn't start a fire or ride a horse, so they assumed that characters in a medieval fantasy setting couldn't, either - unless it was written on their character sheet. This was exclusive.
This was compounded by computer games, where character development was commonly in terms of skills. The computer game designer had two options, either to make the skill development closed ("100% now, maxed out") or open ("sure, you can have 150% lockpicking... and do "impossible (-100% to roll" locks!". Now, that's all well and good, but of course since you need only yourself to play computer games, you can play them for many more hours than you can tabletop RPGs. This led to the "drop-down menu effect" at game tables, where the DM would say, "Now what do you do?" and the players looked down at their character sheets, mentally dropping down the menu of applying Skill X to Problem Y - where in previous years, players would look around the table at other players for suggestions.
Let us not give into silly communist ideas that "there's no wrong way to play." Tabletop roleplaying games are a social creative hobby, and therefore we must take approaches which encourage both sociability and creativity.
A game system where, "if it's not listed, you can still do it, even if not well, if it's listed then you can do it well," encourages sociability, since it avoids the "drop-down menu effect". A system which errs on the side of the simple takes the creativity which the rules-lawyer/power-gamer dual-classed player would have applied to minimaxing, and has them apply that creativity to play.
Obviously there are other things to consider, too. There's a difference between, "Even if not listed, you can do it" with a roll of 20 on d20 vs 10. Likewise with +0 as the default and +1 as the first skill level, vs +0 and +5. And of course there may be other considerations like taking extra time, using equipment and so on. And perhaps having the skill is a prerequisite for using the assisting equipment at all. And some kills like horse riding might be available to everyone, and others like flying a jet fighter only to those with training.
But when in doubt, before considering realism or being true to the genre or what-have-you, I would choose whichever approach encourages creativity and sociability at the game table. Because that's where the fun is.
Of course, you may choose a different approach. But you're wrong.