Why I Hate Skills

[Fenris-77]

I'm your opposite number: I LOVE skills and skill systems in RPGs.

I do look askance at the skill-improvement mechanic you describe for Dragonbane. RuneQuest 2e had something similar, with similar problems.

I see the "me too-ism" as a feature, rather than a bug; it's a bug when it's usually one character only who gets to take an active part with all the other PCs sitting on their hands.

I see the character doing things, with skills and abilities different from the player, as a feature, rather than a bug. There is a balance-point problem in getting the player to experience that he-as-his-character is doing a thing, rather than the PC being either the player's waldo or a separate entity doing things while the player watches, but having the player do things, without the character having separate skills, is just kicking that problem to one far side away from that balance point.

I find it incredibly satisfying to play a PC who does things that I cannot, ought not, or dare not do in the Real World. It's perhaps the most important reason why I play, and what I seek to provide my players with when I GM. And I find good skill systems to be a wonderful tool toward providing this experience.

This is all true and I really like the passion in how you describe it. That said, you can get the exact same thing, more or less, without discrete skills. That's one part of what the thread is about.

 

[Bill Zebub]

Knowledge checks:

1. should be defenses; they're ultimately the same thing as perception, and allow players to shift resources from action effectiveness to action planning during character creation. Making them proactive action rolls complicates them, mostly unnecessarily. Sometimes a time cost can be appropriate to try and get more information, but that really doesn't need even need to be the and skill or love of action at all.
2. exist as a somewhat mitigatable randomizing element on top of scenario design. Generally, they either reveal new action options or clarify the tactical/strategic implications of the existing set of actions players might take.

The gameplay implication of knowledge is way too frequently muddled by tying the checks in to exposition or characterization. They can be an effective design tool, if you go in with a clear goal.

Totally agree that what you are describing is how many/most people use them.

The bolded bits are the elements of game design that I'm questioning/doubting/not enjoying.

 

[Edgar Ironpelt]

This is all true and I really like the passion in how you describe it. That said, you can get the exact same thing, more or less, without discrete skills. That's one part of what the thread is about.

No, you can get something you find to be just as good, if not better, without discrete skills. I cannot.

 

[Bill Zebub]

No, you can get something you find to be just as good, if not better, without discrete skills. I cannot.

I think he meant the same gameplay/mechanics. But maybe missing some of the enjoyment you find in discrete skills.

 

[Fenris-77]

No, you can get something you find to be just as good, if not better, without discrete skills. I cannot.

Yeah, I wasn't telling you how to play.

 

[Fenris-77]

That said, a lot of people have never tried playing with, for example, a background instead of a skill list. They really do the same job, but the former means you have to interrogate your character regularly and decide things about their background. Personally, I think that's far more useful at the table than a skill list, but it's just personal preference on my part.

 

[Pedantic]

Totally agree that what you are describing is how many/most people use them.

The bolded bits are the elements of game design that I'm questioning/doubting/not enjoying.

I'm going after calls for Perception checks/"roll History to understand this mural" but it's certainly defensible to completely remove that element of gameplay.

 

[Bill Zebub]

There is a balance-point problem in getting the player to experience that he-as-his-character is doing a thing, rather than the PC being either the player's waldo or a separate entity doing things while the player watches, but having the player do things, without the character having separate skills, is just kicking that problem to one far side away from that balance point.

I find it incredibly satisfying to play a PC who does things that I cannot, ought not, or dare not do in the Real World. It's perhaps the most important reason why I play, and what I seek to provide my players with when I GM. And I find good skill systems to be a wonderful tool toward providing this experience.

None of that conflicts with the approach to skills that I have been advocating, although neither are they necessarily identical.

I will summarize my approach as:

1. The player comes up with a way to overcome a challenge, hopefully a cool/creative way.
2. The character will be required to execute it, possibly using a "skill" possessed by that character
3. The GM explains the dice result required, as well as the consequence if the attempt fails (or the cost of trying, such as "you won't also get to attack")
4. The player then decides whether to go through with it by weighing the odds of success versus failure, and the reward/cost of each. Ideally that is a non-obvious choice and the player has a tough decision to make, but that won't always be the case.
5. If they proceed, dice are rolled

My beefs with skill systems come down to two things:

1. Discrete skills (like 'stealth', 'lockpicking') versus general skills (like 'thievery') tend to...in my experience...encourage people to skip that whole process and just "use a skill" without the player having to think up plans. E.g., "I'll search for traps."
2. Skills like Perception and knowledge skills don't require any player problem solving, or hard trade-offs, at all. They are just randomizers. I have nothing against randomizers in a game, but combining randomizers with something described as "skill use" encourages...again in my experience...to dissociate players from problem solving, and authors from creating interesting problems to be solved.

 

[Pedantic]

None of that conflicts with the approach to skills that I have been advocating, although neither are they necessarily identical.

I will summarize my approach as:

1. The player comes up with a way to overcome a challenge, hopefully a cool/creative way.
2. The character will be required to execute it, possibly using a "skill" possessed by that character
3. The GM explains the dice result required, as well as the consequence if the attempt fails (or the cost of trying, such as "you won't also get to attack")
4. The player then decides whether to go through with it by weighing the odds of success versus failure, and the reward/cost of each. Ideally that is a non-obvious choice and the player has a tough decision to make, but that won't always be the case.
5. If they proceed, dice are rolled

I think the bolded steps are the place where a well designed skill system can come in and meaningfully change gameplay.

The downsides to setting the GM as a designer action to action are generally understood and doing a good job is most of what gets called "DMing technique". Basically, it's possible to do poorly by setting the odds badly, setting the consequences too punitively, not providing an effective decision point, or by simply failing to provide all the information to the characters. You call all those risks out nicely here, and I think it's generally agreed to be a matter of GM skill to thread neatly between them.

A less obvious impact is that it largely narrows the scope for a player to do problem solving and make meaningful plans down to a singular action (or maybe a short set of actions with the additional risk of iterated probability). Even if, as you indicate above, you let players propose several actions and work through the risk/reward of all of them, there's no way for a player to have enough information to propose several actions in a row to build out a strategy. Players can't actually know what their full capabilities really are until they're actually in a specific situation and do the discussion of what actions they might take. The closest I think you can get is playing with a given GM a lot, learning how they tend to do their design, and then trying to push toward a state they think is predictable.

All of which is to say, what a skill system can do is specify those interactions beforehand, so players can know them without asking the GM moment to moment, and that can create a larger space of gameable decisions. Done poorly or without enough detail though, you end up pushing the GM back to design and/or restricting the player's options, or creating the negative state you describe below.

My beefs with skill systems come down to two things:

1. Discrete skills (like 'stealth', 'lockpicking') versus general skills (like 'thievery') tend to...in my experience...encourage people to skip that whole process and just "use a skill" without the player having to think up plans. E.g., "I'll search for traps."
2. Skills like Perception and knowledge skills don't require any player problem solving, or hard trade-offs, at all. They are just randomizers. I have nothing against randomizers in a game, but combining randomizers with something described as "skill use" encourages...again in my experience...to dissociate players from problem solving, and authors from creating interesting problems to be solved.

I totally agree with what you're identifying here as the negative results of skill systems not designed with an eye toward the resulting gameplay. Not writing fully explicated skill rules seems to largely result in the skills just becoming big, vague actions. You don't try to pick a lock and reference the rules to see how that works; you do the action "make a Lockpicking check." Worse, that generic action usually ends up defaulting to having rules that boil down to "roll 15+ to conquer any obstacle, roll 10+ to conquer an easy obstacle." There's basically no real space for player decision making to matter at that level of resolution, it's just iterated gambling with the level of stakes set by GM/system taste.

 

[Micah Sweet]

That said, a lot of people have never tried playing with, for example, a background instead of a skill list. They really do the same job, but the former means you have to interrogate your character regularly and decide things about their background. Personally, I think that's far more useful at the table than a skill list, but it's just personal preference on my part.

I prefer the more granular nature of the skill list, so you can model specifically what the character knows and is good at, since not everyone with the same background should have identical skills.