Thread by @rdonoghue

Ok, a little bit of morning follow up on skills. A few different folks brought up the idea of player-defined skills as an alternative, and that’s a really important but very different topic.

Having players come up with heir own skills (or inferring skills from other things players come up with) is an incredibly powerful technique. It’s flexible as heck, and it guarantees that the skills in play are the ones that matter to the game. When it works, it’s my favorite.

However, a lot of exposure has revealed to me that it doesn’t always work, and that fact itself is hard to get past.

If you are the kind of player who finds it easy to self-define your skill lists, it can be *really hard* to imagine that it might be hard for someone else.

This is not a technical challenge, but an empathy one, and it’s critical foe a designer. if you do not understand why something is hard in your design, you are telling people who find it hard that the problem is *them*.

That is a jerk move.

So, with that warning out of the way, what are the downside of freeform skills? There are 3 main risks:
1. Paralysis
2. Breadth
3. Integration

PARALYSIS is a big deal, because you are presenting players with a blank page problem, and some players will jam up.

There is an instinct to think that is a creativity problem, but IT IS NOT.

If doing this is easy for you, it is easy to frame it as creative vs. not, but that is self serving. The reasons that a blank page can cause paralysis are many and varied, and a lot of them are rooted in an *excess* of creativity.

The paralyzing thing may be too many ideas. It may be a social fear of doing it ‘right’ (and if other people at the table are going to judge, that social fear may be well placed)

There are ways to help this - examples and suggestions, for example - and they’re good to include. Anything is better than hand waving it away with a snobby declaration of “People are creative.”

(I may have seen a lot of this antipattern over the years)

Ok, BREADTH - this is more of a technical challenge related to how useful the skills are. The easiest way to illustrate this is with granularity: If you take the “soldier” skill and I take the “sword” skill, we have invited a problem.

Because your soldier skill will probably allow you to do anything that my sword skill can do, plus a LOT of other things. You are going to be able to do more stuff and engage the game more fully because you picked a better word.

Again, this can be addressed. Clear guidelines on scope or guidance for balancing depth vs breadth can both solve this problem, but they require time and design.

It is very easy to allow free form skills as a cop out. As a designer, it reduces the word count of your skill chapter by about 10x, and that’s appealing. Unfortunately, it’s not that much of a get out of jail free card.

INTEGRATION is more about the rest of your system. In a lot of games, the skill system provides connective tissue between other mechanical elements, and may do things like determine how much mana wizards have, or what powers can be bought.

Integrating that with a freeform skill system can result in weird Frankenstein results as players discover that what they *thought* was freeform is actually freeform-with-obligations if they want to engage the rest of the game.

Again, not an insurmountable challenge, but something that needs to be designed for.

All of which comes to the main point: Freeform skill lists are *great*, unless the designer thinks they require less thought and attention than a defined skill list.

They are easy to implement, but as hard or harder to implement *well*.