A Defense of Knowledge Skills

Statue of Episteme, Greecian personification of Knowledge
Statue of Episteme

While my recent posts on skills have focused on crafting skills, I haven’t forgotten that my stated intent was not just to rebuild Pathfinder’s crafting from the ground up, but also to rebuild Pathfinder’s knowledge skill. Knowledge, however, is a much more controversial type of skill than crafting is. And even crafting had to be defended against the argument that it should not be included in the game!

In this post I will make the argument that knowledge skills have their place. I don’t think they belong in a retroclone, or in a rules light game, but that doesn’t mean they are completely without value. Their presence in the Pathfinder ruleset is justified, even if I think it ought to be implemented better. I also hope that through this attempt to articulate a logical support of knowledge skills, I can gain a clearer picture of what is important and what is not for when I move on to designing my own version of this mechanic.

I’m familiar with two important arguments against the existence of Knowledge Skills:

  1. By forcing players to make a successful knowledge check before receiving information, knowledge skills create an environment where the GM often fails to communicate information which the players should be given freely. Players may not be given knowledge that their character should have.
  2. A game where knowledge is a mechanical ability of the character, rather than something possessed by the player, creates a gaming environment where the importance of the player’s skill is reduced. The player is not allowed to use knowledge which their character “wouldn’t have.”

Taken together, these arguments might seem like a case of wanting to have your cake, and eat it to. If the players don’t know something and the GM is supposed to tell them what their character would know; why then also should the player be able to turn around and use information their character wouldn’t know? The answer is quite simple, if somewhat flippant: because we’re playing a game. Our primary goal is not to embark upon a profound exploration of the characters we’re playing. D&D and Pathfinder are not, as -C has put it, an activity for those with thespian aspirations.  Perhaps that’s what you’re doing, and if so I truly hope you enjoy it. But that’s not something I’m interested in writing about.

In a game, the player is expected to play to the best of their ability. They bring their experience and their knowledge to the table, and they’re also provided with information about the games rules, and how it functions.

But I’ve diverged from the point of this post. The fact is, depending on how Pathfinder’s knowledge rules are interpreted, both of the potential problems mentioned above can appear. But they do not have to.

In his analysis of the knowledge skill, Courtney listed three possible types of information, and posits that none of these should ever be hidden behind a successful roll of the dice.

  1. Trivial and of no importance.
  2. Non-vital, but interesting and providing some depth and background to the game.
  3. Crucial.

In reviewing Courtney’s analysis in preparation for writing this post, it occurred to me that there is a fourth type of information. Imagine, for example, that my players have entered a room. It would be trivial of me to mention that the cobblestone floors have cracks in a few of the stones. I could mention to the players that the room smells so bad they can taste the pungent air on their tongues. It’s not vital for me to do so, since the smell does not affect the game, but it does help the players to imagine their environment, which is fun, so why not. It is crucial that I tell the players there are two exits on the north wall, and that there’s a large pile of stones in the corner.

4.  Hidden information.

I should probably not tell the players that there’s a pile of gold under the stones. If they want to learn about that, then they’re going to need to do some work. Like maybe digging through the pile of stones.

 There are two types of hidden information. The kind which can be modeled at the table, and the kind which cannot. The example above of the gold hidden under the pile of stones can easily be modeled at the table. If the players say “I knock over the pile of stones,” then voila, they’ve revealed the hidden information about the gold. However, this room also contains a hidden door on the south wall. The players haven’t seen it, but they’re pretty sure it’s there, because they saw a monster run into this room. There’s no sign of the monster now, and the only other exit from the room is barred from the other side. So they players would like to start searching the walls for hidden doors. At this point, we bring out the dice, because there’s no way for the players to describe how they look at a blank wall for a secret switch.

Based on this, I would say that there are three types of information which might be included in a game.

Player Knowledge is what the player themselves knows. When a black dragon appears, the player knows to ask the wizard if he can borrow that potion of acid resistance, because the player knows that black dragons have acid breath.

Character Knowledge is information the GM freely gives to the player, because the PC would obviously know it. If the player is in their home town and says they want to go to the local pub, the GM can simply tell them that it’s called the Pig and Whistle. When the player decides he wants to become more religious, the GM can identify a few religions the character would be familiar with. There’s no reason to hide that kind of information.

For Skill Check Knowledge, three things should be true. First, it should not be trivial. Second, the game should be equally interesting whether the players know it or not. Third, there should be more than one route to obtaining it. When a fighter encounters magic runes on the door of a crypt, it would not be trivial for that fighter to know whether the runes were arcane or divine. Even if they can’t read it, the type of writing on the outside of the door could provide valuable clues to what’s inside. If they fail to determine the type of writing it is, or even get it wrong, the game will be interesting because they’ll be less prepared for what they encounter within. Whereas if they succeed in determining the rune’s type,  the game will be interesting because the player will have an opportunity to prepare for what they think is within. And, of course, if all else fails they could just go find a wizard or priest and ask them.

Related Posts Plugin for WordPress, Blogger...

11 thoughts on “A Defense of Knowledge Skills”

    1. >Hidden Knowledge Exists
      >Sometimes discovery of hidden knowledge can’t be modeled at the table
      >When hidden information can’t be modeled at the table, a skill roll is called for

      1. Every example you’ve used is already modeled in B/X.

        Magical runes on a door? Read magic.
        Secret door? Secret door discovery chance.
        See a monster before it sees you? Surprise roll.

        There are surprisingly few of these and each is made substantially worse by allowing the player to acquire ‘skill’ in it. (Due to the importance of these types of information, making the skill acquisition a tax)

        1. First, read magic requires that the player be a magic user.

          Second, correct me if I’m wrong, but read magic would not be needed to determine the difference between arcane and divine runes, correct? It would be needed to *read* them, certainly, but not to determine which magical ‘language’ they were written in.

          Third, as noted, there should be alternate means of acquiring knowledge-check information. If the players don’t know it themselves, they can ask someone who does know. In doing so, they take the risk of letting that person know they’re interested in certain knowledge. Ergo, not a tax.

          1. Courtney, what about your appraisal subsystem? That seems like a decent candidate for a knowledge skill. How does that work again?

            I feel like these sorts of things are specific enough though that considering them “adventuring skills” might be better than knowledge skills.

            Even in the arcane/divine runes example, don’t you think that might better be handled by intelligence and wisdom checks to represent the class specialties? A knowledge skill system seems like a big overhead for little payoff.

            1. Well, I would reiterate that I’m not arguing that you *should* put a knowledge skill into your game. I’m arguing that knowledge skills can be not bad.

              Consider other example uses for a knowledge skill:

              -Identifying historical context
              -Information about a piece of art or what it depicts
              -Contextually relevant information about nobility or royalty.
              -Information on laws and how a legal system works
              -Detailed information on factions which exist in the world; nations, religions, knightly orders

              There’s a lot here which could be useful in play. Hell, take identifying art objects alone. How many art objects show up in a dungeon? Personally, I put a lot into mine. When I do, I almost always have some idea of what the piece depicts. The players will never know, but why shouldn’t they have the chance to learn? It may help them uncover the dungeon’s other secrets more easily.

              1. It seems like those examples mean that 1) you need to know those things as a referee beforehand (I usually don’t) or be prepared to improv them effectively and 2) for real payoff they should be game-useful in addition to being interesting.

                If, for example, 2) is not satisfied, but you know an interesting piece of invented historical info that you think would enrich the setting, why not just tell the players? Presumably characters of any class would have some sense of setting history.

                I’m not inherently opposed, but I’m not convinced yet.

                Possible principle: unless the knowledge skill has a homology to a hacking skill in a cyberpunk game (that is, plugs directly into success/failure in some way), it is probably better to assume that at least one PC would have the knowledge and just tell the players.

                1. Right. Appraisal is a specific sub-skill, devoted to making the “What should we carry out of the dungeon?” game more efficient. Among skilled players, it certainly straddles the line of a skill tax.

                  Yes. You have to be a wizard or a cleric or a thief with a read magic scroll. Fighters are screwed. Which is why they shouldn’t be dicking around with magical runes.

                  As far as every example on the ‘other example’ list, well, I would, without a check give out all the information freely.

                  Think about it. You did work for the campaign. For whatever reason, the player is actually interested in your data dump about campaign lore. there should be no chance that you would prevent yourself from engaging them in your history when they want to be engaged.

  1. Since the days of 2nd Edition, my group always played Knowledge skills along these lines: success = ask the DM one question regarding your area of expertise and it worked fine. This way the skill worked as a bonus rather than something required.

    Example: “We want to convince King So-and-so to fund our mission. I rolled under my Intelligence with my Knowledge: Nobility. What are his interests and goals?”

    Example: “I rolled under my Intelligence with my Knowledge: Arcane; have I ever seen a circle like this before? Do I have any idea as to its purpose?”

  2. I personally run knowledge at my Pathfinder table like this: make the DC you’ll remember something correctly, roll badly and you’ll remember nothing or even worse: remember incorrectly. It has turned up some interesting results.
    Also, I have no problem with meta knowledge. Part of the game is learning to be better and playing more intelligently as you the player gain experience.

Leave a Reply

Your email address will not be published. Required fields are marked *