Thread by @rdonoghue

This thread is *delightful* - (I'm with the rolemaster folks, who find all skill lists short), and it means that I should really reveal the secret sauce of these skills lists, at least in my experience.

https://twitter.com/jonrog1/status/1099544240869101568

Initially, when you set out to make a skill list, there is an instinct to cast as wide a net as possible. You want to make sure that you have covered every possible thing that might come up in play.

This is a fools errand, Whatever you come up with, it can always be longer.

After that you think "Ok, I will make a skill list that just emphasizes the things my game is *about* and sort of handwave other stuff." (or, "Just the AWESOME Skills")

This is better, but tends to fall apart at the edges, when you don't entirely understand your audience

But even if you get it right, you quickly run into the question of granularity, sometimes called the Musketeer paradox.

If you want to run a musketeer game, how do you handle the fencing skill? If everyone's going to have it, does it even matter at all?

There are many solutions to this. Some of them are terrible ("We have it so the ONE character - you know, the girl - can not have it!") but usually what ends up happening is some manner of slicing fencing up so your Fencing: 6 is different than my Fencing: 6

One solution to this is to go outside the skill system, and that is all well and good.

Another solution is to go outside the skill system but not ACTUALLY go outside of the skill system, and just have skills that are powers or exceptions and generally a total mess. (Palladium)

If you keep things within the skill system, you just make fencing into more skills : Parry! Lunge! Feint! Whatever. Now our musketeers have 6 different skills to reflect fencing, and they are now all very different. So yay!

Except...they kind fo suck now.

By introducing all these skills, you have mandated incompetence. The only way for them to be good enough is to buy all the skills, at which point you've just returned to the initial problem.

This is not a solvable problem. Not at the level of a published RPG at least.

You could solve this at the *table*, because you could build skill lists that align with the characters in a given game. Some games (Fudge, for example) strongly encourage this, but only a small subset of gamers actually like this.

A more practical solution is to say "Enh, close enough".

This is actually fine, especially if the game really has a lot of other moving parts. D&D may have skills, but playing D&D is not *about* skills. It's about combat and spells.

The D&D skill list is just someone's opinion of what might be interesting outside of a fight. Or rather, ti was that once, and now it is the fossilized remains of that idea.

Most games are pretty similar, if less fossilized, and with possibly different core activities. .

The point of all this comes back to the question of WHY THE SKILLS ARE EVEN THERE?

It's a good question. There's an OSR joke that no one fell off a horse until the riding skill was introduced, and it's kind of depressingly true.

So why have skills? Is it punitive?

So, here is what skills are actually good for in a game:

* Framing Challenges
* Gatekeeping
* Differentiating Characters
* Self-hacking

(I reserve the right to think of another as I talk, but these will do for now)

FRAMING CHALLENGES: Note, I don't say "resolving challenges". Skills are used for that, but they're not necessary. You could just flip a coin.

Rather, the skill list is a reflection of designers intent which explicitly says these are things which you might fail at.

Sounds punitive when framed that way, but put another way you could say that these are the pointers to the expected *challenges* in the game. If the designer has thought about this, awesome. If not, you get huge sheer.

See, it's not that "Pottery" is a boring skill. If the designer has a vision for how pottery is really interesting and challenging, then they can make it so in play.

But more often, the designer has no such idea, but instead has a sense of coimpletionism or bad simulation.

MInecraft has millions of dollars of evidence that making things can be fun play. If your game's crafting skills are dull, it's not the fault of those skills.

In short: The skills help tell what the game is *about*.

GATEKEEPING also sounds bad, but I don't mean in the "assholes telling people they're not real gamers" sense, but more in the "You must be at least this tall to ride the ride sense."

Implicit in the skill having a ranking is the idea that NOT EVERYONE CAN DO IT. Buying into a skill means buying into a different experience of the fiction than other characters, and that's actually *super fun*.

This is easiest to illustrate with things like language skills. If languages matter in your game, play can be radically different depending on the languages you know. Same is true of magic and many perception skills.

For other skills, it depends on how smart the game is about skill context, but if one uses Feng Shui or Four Corner Skills or the like (Where a skill also implies things like knowledge, connection or awareness) they you get similarly strong play drivers.

That is, playing an amazing blacksmith creates play opportunities as the fictional world *respects* that skill. Which leads us into the next point.

Skills offer an avenue for CHARACTER DIFFERENTIATION.

How important this is depends a lot on whether the rest of the game offers similar differentiation. In the Amber DRPG, for example there are no skills at all, but character differentiation is a huge part of the background.

In a skill heavy system, the skills carry a lot of weight on this. In games like D&D, it's not essential, but you get some interesting mojo out of merging these last two points, because sometimes it matters to HAVE the skill.

This is most classically illustrated in D&D by Rangers. See, it's not necessarily super interesting if I have one more point of tracking than you, but it *is* interesting when only one of us is a tracker. That's a gateway to action that gives a chance to be cool.

The last point, SELF HACKING, I include grudgingly. Sometimes you need you skill system to power some other subsystem, like how much mana a character has,

This is invariably kind of kludgy, and it's not a good look, but I get that sometimes it's necessary.

Ok, so what to do with this information?

Easy: MAKE YOUR SKILL LIST SHORTER.

(Getting rid of it entirely is also an option, but that would be a cheat of an answer. Topic for another day).

Look at each skill on the list and ask a few questions:
1. What happens if No One takes this skill?
(If the answer is "Not much" then look hard at why it's there at all. If the answer is "Disaster" then why is it a choice?")

2. Does the level of the skill make a real difference, or does it just matter if they have it or not?
(If not, consider moving this somewhere else. There are a ton of gateway skills which don't ever need to be rolled except as an exercise of habit. Can you swim or not?)

3. Will having more of this skill help the player feel more awesome?
4. Do you know how you're going to run this skill clearly enough that you can imagine running five different scenes using it that don't repeat?

If either of these is no, definitely reconsider.

"But Wait", you say, "I actually LIKE skill lists, and the story they tell, and this is going to cut things down so far that it becomes abstract. It is too much."

This is fair, and I sympathize. For you, I offer a different tip.

*Start* with a short skill list. One that is maybe a dozen activities that you consider important to your game, stated fairly abstractly, like "Fight, Pilot, Socialize" and so on. There are good models out there to steal.

Let your players buy skills in those things, however you do it. At this point, you now have an entirely functional, playable game, but you can take another step.

Take a look at whatever the max rank is in a skill and see if any characters overlap in that skill.

If not, no prob

But if they *do*? Then it's time to divvy it up.

Not, like, fully 50/50, but rather, talk to the players about their characters and figure out what the differences are, and change the skills to suit.

What mechanic you use here matters very little, but feel free to do the equivalent of giving them +1s in their "subskills" and -1s in the other players subskills (though even that might be more fiddly than necessary).

It's not the bonuses that create differentiation, it's gates

This inverts a design problem. Consider a game that has both alertness and search. That distinction is kind of useless *unless you have two very perceptive characters". Rather than create that split and not use it, you only create it when you need it.

There are a ton of other solutions too. If you have a game that has really felt like it's done skills right for you, then emulate it freely. Seriously. This is not a new problem, but it's still a fun one to solve.

PS - The burning wheel skill list is adorable. Put three or four of them together and it could make a decent RMCIII skill list.

Hat tip to @Nymdok who brought up one more INCREDIBLY IMPORTANT POINT.

There is one very specific and concrete virtue to very long skill lists:

They create an opportunity for *players* to communicate what they are interested in.

So I revise my advice with one more option: Turn it on its head.

Start with the biggest skill list you find interesting, and let your players pick from that.

Then collapse every skill they did not take.

You now have the game your table wants.

Gonna crash now, but I'll add a personal bit.

I will *never* write a skill list as good as the one in Spirit of the Century. Not just because I'm not sure I could, but because it's not something I would do again.

SOTCs skill list was my single boldest attempt to tackle this, and it resulted in the skill part of the book being 4 times longer than is traditional to cover:
1. Using the skill
2. How to be awesome with it (player)
3. How to make the skill exciting in play (GM)
4. Stunts

This is near and dear to my heart, but it is not what I would call a successful writing strategy. :)