I was chatting with Spawn of Endra the other day about Bards and multi-classed characters in old-school Labyrinth Lord-type games. As regular readers know, our own gaming group has struggled mightily over the issue of how to integrate a Bard class into our present campaign, and to be blunt, I am STILL not 100% satisfied with what we've come up with, as I recently confessed.
The problem stems from the "skill system" conundrum observed by so many other grognards. And that conundrum originates with the Thief (not the Bard) class, though the problem carries forward into all other "special" classes outside the "core" classes, which I define (at least provisionally) as Fighter, Cleric, and Magic-User, plus the race-as-classes such as Dwarf, Elf, Halfling and (in Ara) Rodian.
That's right, I am officially going on record now as excluding Thieves from the core D&D classes, even though they appear as a "core" class in Labyrinth Lord. To be clear, I do not mind the concept of a thief, i.e., a specialist who develops expertise in certain areas like finding traps and picking pockets. Nor do I mind the general concept of Bards, i.e., experts in folklore and public performance and storytelling and the like. No, I actually really like these "specialist" classes for their core concepts, I just despise what the grafting on of skill systems does to the game, specifically the way in which it can interfere with player ingenuity and role-playing.
Let me give a few examples. The first couple will relate to my experiences DM'ing Uncle Junkal, our party's Rodian Bard, and just let me make clear right out of the gate that I do NOT blame Uncle Junkal or his player for these disappointments of mine. They are ultimately my responsibility for not seeing how the Delving Deeper Bard, as good as it is, participates in the form of "skill resolution" that started with the introduction of the traditional Thief class and ultimately kind of dampens things for me. So this is My fault, which is why I am discussing it now, in an attempt to fix it while still being as fair as possible to my current PCs.
Example #1: Uncle Junkal Charms Grand Vizier Krock. Back in Session 35, our beloved rodian bard used his charm person ability to place himself in the good graces of Prince Arkus' right-hand man. This whole episode was brilliantly role-played by Uncle Junkal's player: he used his juggling and entertaining skills to get near the Vizier, then, after amusing him with some tricks, started asking him innocuous questions about the Prince's visit and the like. He built trust with the charmed Krock, so by the time he started planting ideas about the the local dwarves, it made sense that the Vizier would listen to him. It was a delight to see this unfold even though it did involve an initial successful 2d6 Charm Person skill check, as we developed for our Arandish Bard Class.
A Solution: No skill roll needed? Maybe just role-play it out as we did anyway? What did the skill roll really lose us or gain us? Is it necessary?
Example #2: Uncle Junkal deciphers the significance of Ponaturi Runes. Just this last session or two, the Bard has been using his Legend Lore ability to decipher the meanings of runes inscribed on the pillars and doors around the Temple of Thoopshib. This has been going okay all in all, but I have found the skill roll itself to be intrusive. Being the great player he is, Uncle Junkal's player always explains and justifies how he would know certain things in-character; in this case, he would know seagoing legends about Thoopshib due to his background as a rodian, which is a seafaring culture.
A Solution: The player and I related Uncle Junkal's bardic knowledge to the rodian's background and back story anyway, so again, what function did the roll serve? Did we need it? Or am I just nitpicking?
UPDATE! Since writing the introductory remarks and examples above, I have played one more session with the group and actually have found Uncle Junkal's skill rolling far less obtrusive this time. I did not mind the Legend Lore rolls he made; I just, if you'll pardon the pun, "rolled with it." And it worked out fine. I guess it IS kind of old-school to trust the roll of the dice, and perhaps I should appreciate the random element (and hence excitement) skill rolls introduce into the game. With the roll of the dice, it cuts both ways: I think the Bard actually failed more Legend Lore rolls than he made last session. There were surely a couple times when he failed to recognize some potentially important rune. So maybe I am making a bigger deal of this skill system thing than it needs to be. Yet. . .
Example #3: Vivuli "Assassinates" Thoopshib. In Session 44, Vivuli snuck up on the physical manifestation of the demigod Thoopshib and, upon successfully sneak-attacking it, made a roll to assassinate it. Now this makes about as much sense to me in retrospect as Uncle Junkal charming an extremely hostile, human and demi-human-hating rock troll does, but I tend to be indulgent of my players' whims in the heat of the moment, and given that we were in the climactic seconds of a pitched melee battle, I allowed Viv's assassination attempt to occur. Note also that for that attempt Vivuli's player rolled "00" on his d%, which would technically be a critical failure, NOT a critical success! So it was fucked in every possible way. But what I SHOULD have done was to grant Viv his sneak attack bonuses and let him attack the thing normally -- it really WASN'T a proper assassination attempt, which should be pre-planned and done for political reasons or for hire. In other words, in this case I FAILED to push Viv's player to role-play it out or justify it. Perhaps understandable under the circumstances -- I did not see it coming -- but nevertheless a misapplication of the rules (or at least the spirit of the rules) as far as I am concerned. My bad for not catching it sooner.
A Solution: Enforce tighter restrictions on what counts as an "assassination" [any suggestions about this from the blogosphere?] and remember that a sneak attack and an assassination are two different things, even though they may often (in practical play situations) coincide.
Some tentative conclusions (?): In some ways the bane of my existence as a Labyrinth Lord has been my open-door policy toward the content of the Advanced Edition Companion. The spells and monsters therein are easily added to basic Labyrinth Lord without disrupting things at all, but the new "advanced" classes can be troublesome, and the rules for "Multiclassing" open up dangerous doors as well, as Telecanter has discussed here and here. Nothing against Vivuli, who I love, but I see now that I should not have let Assassins (as writ in the AEC) into the game. Hell, I don't even want standard Labyrinth Lord Thieves in my game! If anything, I should treat Assassins and Thieves exactly as I would prefer to treat Bards -- as Specialists, using a "x in 6" skill system, as in LotFP Grindhouse.
Why? Because James Raggi's system accounts for specialized skill use while retaining compatibility with certain "basic skills" that ALL PCs (regardless of class) can perform, like searching for secret doors and hearing noises. Since everybody has a base 1 in 6 chance to do stuff like that anyway, Raggi's Grindhouse Rules maintain, why not simply have "thieves" be people with a slightly increased chance to do the same stuff? As James Maliszewski has written, ALL older edition D&D dungeoneers are assumed to be de facto thieves:
"the Thief is a self-justifying class. Prior to its introduction in Greyhawk, pretty much every "thief ability" was something a character of any class might attempt. Listening at doors? Check. Moving silently? Check. Locating and disarming traps? Check. The list goes on. I've noted before that 'thief' is an occupation that could describe characters of any class."*
According to this line of thinking, it really doesn't make sense to have separate "thieves' skills" in the game at all. No, "thieves" would more properly be adventurers who happen to specialize in those kinds of dungeoneering skills instead of focusing more effort on, say, martial prowess or the arcane arts. So it's better to call them Specialists if you need to differentiate them from the other PC classes, since ALL PC classes are thieves!
--
* Interestingly, in this same post, Maliszewski goes on to defend the existence of the Assassin class. It also worth noting that over time, Mr. M. made peace with the thief class -- see his discussion here and here, and his final result here.
2024 in Review
4 hours ago
I love the idea of the Assassin, just not the AD&D or AEC implementation of the idea.
ReplyDeleteThe way I work Thief Skills now, is to treat them kinda like a Saving Throw.
We do it with Role-Playing and Negotiation (and any class can attempt this,) but the Thief's special abilities mean that if he royally screws up, he gets to fall back on his Thief Skill percentile rolls and gets a second chance. Also, if something's so devilishly complicated that RP/Negotiating just isn't feasible, I'd go straight to the Skill roll, though that hasn't come up, yet.
The more I read Raggi's system the more I like it. If I were to start another campaign I would probably use it as the base.
ReplyDeleteIs there some potential in mapping thieves' skills onto the Cleric Turning Undead paradigm?
ReplyDeleteAlthough I like the idea of "x in 6" which sounds simpler anyway.
I have always likes x in 6 mechanics, though I suppose that the Thieves Skills and Cleric TU skill could be "unified" via Dyson Logos' "2d6 Thiefin'":
ReplyDeletehttp://rpgcharacters.wordpress.com/2009/08/01/d6-and-2d6-thiefin-for-basic-dungeons-dragons/
I actually use that very chart in my campaign; my thief players found they preferred it. I guess I've already got my answer!
ReplyDeleteAlso, Rients' suggesting extrapolating the Reaction Roll chart into a skill resolution system, which I have also attempted to adopt. I want to rationalize it all for the next campaign somehow...
Yes, I like the Reaction Roll mechanic quite a bit myself. Also, another post on this subject:
ReplyDeletehttp://hackslashmaster.blogspot.com/2011/11/on-skills-in-games-surprising-insight.html