Performance is a Designer Trap

[Blue]

This is a post from my blog, you can read it here, or there. It does not matter to me. Performance is a Designer Trap — C22

Before I start explaining why Performance is a designer trap, I should explain what a designer trap is. To understand that, we need to understand what a design trap is. A design trap is a player choice that looks beneficial but does not provide appropriate benefit. Now for some examples.

In original wow, now known as WoW Classic, when you leveled up, you learned new ranks of spells that were stronger more powerful versions of those spells. Naturally, you would just assume to start using the stronger version of the spell, rank 2 fireball does 45 damage up from rank 1 fireball that does 30 damage. This natural thought process was wrong for casters and especially healers. Because the lower ranks cost less mana, those versions of the spell were used when mana needed to be conserved and you still wanted chances to proc passives or talents. This is a design trap because the natural thought process of a player is to just use the newer bigger spell always, when in actuality maintaining access to some lower rank spells was crucial to maintaining your mana. This design trap was fixed in the first expansion, Burning Crusade.

Another example, In modern Call of Duty, players are taught to use C4 one way. press the use C4 button to throw then, when all of your C4 is thrown and attached to a location, press the button again to detonate that C4. But another use of C4 exists that is better in almost every way. The C4 can be tossed and detonated, 1 at a time, in the air by pressing the general “use” button twice. This is another example of a design trap as one option is better, but the existence of both leads player to believe that both options have their uses. That in itself is the design trap.

So now that I have explained design traps, I can move on to a designer trap. A designer trap is a mechanic that game designers adopt or add that creates a design trap within their game. I will admit, I fell into this trap. When analyzing other systems for the skills they included in their system, I considered each skill as a method to solve a problem and checked whether I needed to be able to solve those problems. Thus, skills like Performance were added. As I refined my list, some skills were removed, and other added, but I never found something to answer the “What if a player wants to be good a playing an instrument, singing, etc”, as a result, Performance stayed.

That was the mistake. I was looking at the Performance skill through a different lens than all of my other skills. All current skills are methods to solve a problem, you want to look for more information? Awareness; you want to fiddle with something mechanical? Tinker. If a player wanted to put on a performance, what would they be trying to do? Draw attention or distract in some way, right? But I already have a skill that does exactly that, its called Misdirection. So why did Performance last so long? Its because I was looking at it like a background of a character, to accommodate Bard like characters, while all other skills were being looked at through the lens of how would a player use this to solve a problem. This was a designer trap because Performance as a skill was a design trap in my game. It was a niche skill, that would rarely get used, and every case that it could be used would almost always be covered by the Misdirection skill, so any player that took points in it would be wasting skill points, to create their own background.

Performance as a skill or ability may not be wrong for your game, but it is important to consider that just because it is contained within popular RPGs does not mean it is necessary in yours. Remember to consider what the players will be doing regularly in your game, because all skills should emphasize those actions. If Performance is only there because you want to give music playing characters a way to mechanize their backgrounds, you are creating a design trap for them to waste their advancement resources.

Final Notes: The removal of Performance did lead to a lower number of skills than I targeted, but this allowed be to fix the issue that has been nagging me for months, Intellect Potential does not have an appropriate representation of skills within my system, but I’ll talk about that solution next time with the addition of Navigation.

A different take on the design trap for performance is assuming that just because it fits the English definition of a skill that is should be bought with the same currency.

Having perform, crafting, professional, and other "non-adventurer" skills that would not be used on a regular basis to "solve" but still help (a) enrich and define the character, and (b) can come up occasionally or in a complementary/synergistic manner can be the right design choice if it isn't using up the same character creation/advancement currency as the "solve" skills.

This could potentially be expanded to other pillars of play. To use D&D 5e as an example, all characters are expected to be able to contribute during combat, but it is acceptable that during other scenes that some challenges are met by a subset of the party or even just one expert (perhaps with a helper), such as tracking. If a system requires spending the same currency for those different aspects of play, you can end up with characters who can over-focus on combat (which is the densest mechanical type of scene) and be unable to assist (and therefore possibly bored) during other types of scenes, or the opposite where becoming good at types of scenes that require several skills may make them less able to carry their expected weight during whole-party scens like combat. 5e solves this by making Skills of less import during combat, but we still see a higher preponderance of characters taking skills like Perception that help avoid some nasty combat situations.

 

[payn]

I do see two types of traps here as well. One is in the application, the other is in the category.

For example, players not knowing they can explode C4 in the air is an application trap. That type of trap lies in the rules descriptions and the expected use of concept. I mean, how often do you see in the movies or actual instruction of C4 use that its tossed in the air and detonated? Most folks imagine it is carefully placed and detonated from a safe distance. This is one of those things that is either not explained by the rules, or is an exploitive use outside the intended purpose. In a CRPG these become optimal exploits, in TTRPGs the GM can step in a make a ruling on RAI.

Category is the trap that is designed in a series like performance as a skill. A player has to weigh taking performance over things like investigate, thievery, sense motive, etc.. Performance in this case is suboptimal in its usefulness as a problem solving skill. In PF1, performance allowed the Bard to merge several skills into one category. Which begs the question, should performance be a skill or just a bard class feature to interact with the skill system? Speaking of feats, the category trap is most obvious in the 3E/PF1 era of D&D (PF2 kept this legacy item unfortunately).

Application is actually pretty easy to resolve in two ways. The first is with a rulings over rules take. In this design, the designer encourages the players to use their imagination to find interesting ways to interact with the systems and mechanics. The GM is encouraged to ensure a fair application remains consistent at the table. The other is obvious rules over rulings. In this design space, the designer needs to come up with compressive rules regarding the mechanics that inform the users what is and isn't acceptable.

In the category section a designer needs to be mindful of what mechanics they are comparing. Using the newly popular three pillars dynamic as an example, you want to design chargen parts in an even distribution. Putting all or most options in one bucket, like feats, can be tricky. In this design you are forcing a player to decide between being better at combat, exploration, or social aspects of the game. Some folks expect to be able to play in all pillars, in this case, the design is best to be spread out between items. For example, ancestry contains social mechanics, background contains exploration aspects, and class combat aspects. If your design intention is that one player is the combatant, another the explorer, and a third the social character, then you really want to spell that out in your rulebook descriptions.

Thats the mindset I'm in from the OP.

 

[TBeholder]

In original wow, now known as WoW Classic, when you leveled up, you learned new ranks of spells that were stronger more powerful versions of those spells. Naturally, you would just assume to start using the stronger version of the spell, rank 2 fireball does 45 damage up from rank 1 fireball that does 30 damage. This natural thought process was wrong for casters and especially healers. Because the lower ranks cost less mana, those versions of the spell were used when mana needed to be conserved

Decrease in efficiency with raw strength is a pretty sensible feature in itself, if only because the other variable here is time, so it’s actually a trade-off.
It's not a “design trap”. It’s either bad UI (if it doesn't show both cost and effect nor at least notes in TFM “there be diminishing returns”) or the problem is on the player side. Unless WoW somehow induces inability to handle vulgar fractions and understand the concept of diminishing returns.

 

[dragoner]

I look at skills as either hard or soft, Why Hard Skills Matter
and are usually task oriented, performance seems more of a soft skill as described in the op Soft Skills
Though it definitely can be taught, which makes me think of it being a hard skill. The law of unintended consequences can make anything a trap, though some designers might mean it that way, to have diminishing returns so to drive the game in another direction or so.

 

[Yora]

Performance and Gambling are special skills in that their biggest use is not in what they seem to do on the surface. In many games with skills like these, I've seen them described and explained as mechanics that let you make a bit of money on the side. Which is often rather useless, and even when it works it's very uninteresting.
What they are actually useful for is to get social leverage on NPCs. With performance, you can get popular with a crowd, with gambling you can force people into debts. This limits what NPCs can do to you and might open doors to favors. And the key here is that you can do it in public with lots of witnesses while making it look completely innocent.
Pretty much every gambling scene in James Bond movies is not about winning money, but Bond taunting and embarrassing the villain to get a first foothold. Performance should be approached in the same way.
Characters who are great at performing or gambling can use that skill to gain access to social circles normally beyond their status. It can be used to open doors to NPCs, if the GM runs with it.

 

[c22system]

Performance was a designer trap in your instance. Title makes it seem like performance is a design trap itself.

True, but this is a blog where I talk about the game's development. I do know the title is a bit clickbaity

 

[c22system]

Here you're creating a different trap. As a GM I have some control over the kinds of things the PCs will be doing in my game, but taking control over how they overcome obstacles means the players aren't co-creators of the story, but just an audience that get to roll some dice for fights.

Could you elaborate on what type of trap is being created?
The post is more about making sure your skills are consistent with the overall narrative and experience the rpg is creating, because no RPG creates every experience, not even GURPS. It would make very little sense for a game about dungeon delving to have both of the skills Piloting and Drive airship. In this case, Piloting can do everything that Drive airship can do, and more, all within the concept of diving deep underground, airship would rarely be used one would expect. Sure you might be expressing the world above with more detail because there are airships to travel between the different dungeons, but it is being used to describe a character's background while the other skills are describing what the character is good at doing.

To reverse it. If you have a game about backgrounds and all of the options are Soldier, Woodsman, Sailor, Scout, Builder, and Battle. Battle is using a completely different framework as a background than the rest of the backgrounds. Soldier, Woodsman, Scout could all have experience in battles so could cover that as well if they were used for checks. Designer just need to consider that their options are consistent with both the style of their other options, and to not necessarily include skills in their games, just because big names have them in their games.

 

[pemerton]

@c22system

It seems to me that skills are a form of player-side resource, typically used to buff the chance of success at a certain category of actions. In a tabletop RPG the relationship between a particular skill and the category of actions that it buffs is established by real people engaged in conversation with one another using natural language descriptors and applying them informally or (perhaps) semi-formally (eg by using lists of examples, canonical definitions, etc).

In your example, the relevant categories of actions are described by results - like distract someone or make someone well-disposed towards you - and hence if you already have skills like Bluff or Manipulate or Persuade or Impress that link to those categories, Performance seems redundant. And hence a trap for players.

There are other approaches to describing the relevant categories, which might produce a different conclusion. I'm thinking here of Classic Traveller, which describes actions related to technology not in terms of results (like get quickly from A to B) but in terms of the equipment used - and so Electronics is a different skill from Mechanical is a different skill from Computing (which deals with software, not hardware) is a different skill from Engineering (which deals with nuclear-based power systems).

If we used the Traveller approach to social skills then we might have a Performance skill - you do your social stuff using performing arts - and Words skill - you do your social stuff by talking. Performance has the downside you need your instrument, or everyone has to be quiet as you recite your verse, etc. Words has the downside that the audience really needs to be able to follow what you're saying (so languages and dialects matter), probably make eye contact, etc.

I don't think there's any unique or "magic" solution to how to carve up the descriptor-space so as to achieve a rough parity and lack of redundancy among the options. Some of it is about what we want a particular game to do and how we want it to feel; and some of it is a little bit arbitrary and will actually contribute to the distinctive feel and play of the game.

I've recently been reading and playing a bit of Torchbearer, and thinking about its skill system. It doesn't follow any particular hard logic in its descriptors and categories - eg one skill is Armourer (everything to do with making and repairing armour and weapons - ie the relevant category is defined by material outputs) and another is Fighter (trying to kill beings or drive them off in one-on-one or small group combat - ie the relevant category is defined by a goal which is rather gerrymandered by reference to standard FRPG conventions) and another is Hunter (which includes identifying creatures by trails and spoor and also bringing down creatures from ambush or with traps and snares) and another is Dungeoneer (which includes stuff that in D&D would be climbing, swimming, squeezing through gaps, and Dwarf-type detection of sloping passages etc). To use the skill system, you need the canonical lists of what each skill lets you do. The system doesn't have a Performance skill - it treats musical instruments as tools that can be used to buff some social skills - but there's no reason in principle why it couldn't - eg Performance can substitute for Manipulator or Persuader but only when you are able to use your instrument. (Whether that would be balanced or not would be a further inquiry.)

 

[c22system]

It seems to me that skills are a form of player-side resource, typically used to buff the chance of success at a certain category of actions. In a tabletop RPG the relationship between a particular skill and the category of actions that it buffs is established by real people engaged in conversation with one another using natural language descriptors and applying them informally or (perhaps) semi-formally (eg by using lists of examples, canonical definitions, etc).

I completely agree, skills, combined with action economy are a resource. I think you are right in your analysis of the post. The point is more about how you should look at the skills/feats/abilities/whatever you are adding to your games to make sure they are all following the same framework. For me, it was solving a problem, for Traveler as you pointed out, it was about equipment used.

 

[GMMichael]

I was looking at the Performance skill through a different lens than all of my other skills.

Indeed, a mistake.

All current skills are methods to solve a problem, you want to look for more information? Awareness; you want to fiddle with something mechanical? Tinker. If a player wanted to put on a performance, what would they be trying to do?

But what is a problem, at least in TRPG context? Does that depend on a player's definition, or is it something more objective?

Draw attention or distract in some way, right? But I already have a skill that does exactly that, its called Misdirection.

Design trap: overlapping skills. But I think Performance can solve other problems.... e.g. I'm broke and I'm not getting a room at the inn for free tonight. E.g. the troops' morale is low and tomorrow's battle will suffer unless I can pick them up.

So why did Performance last so long? Its because I was looking at it like a background of a character, to accommodate Bard like characters,

and so the true designer trap rears its ugly head: bards. Stop trying to write bards into games, and game design becomes a much more rewarding endeavor