Entry tags:
Toggle Skills
I played a fair amount of 2nd Edition AD&D when I was in high school. AD&D is a bit of an odd creature; while it retained many of the "core" features that made (and still make) D&D fairly unique compared to many other RPGs, it was also also bowing to the pressure exerted on it by the inexorable forward march of "trad". In particular it ended up implementing this half-formed skill system in the form of Non-Weapon Proficiencies (NWPs), but it was one that was rarely (if ever) fundamental to the procedural functioning of the game in the way that trad skill systems are (arguably by definition, but I don't really want to litigate "trad" here).
We played 2E with NWPs, but we rarely actually rolled dice to use them. D&D texts at the time mostly avoided structuring play around resolving a "skill-use procedure" to accomplish tasks, in part because the NWP rules were always relegated to an "optional" rule. But what we would often do is modify the fiction based around whether a character possessed a given NWP; to avoid a penalty, as an opportunity to present a "clue" to the players, to allow a specific kind of movement, or whatever. Yes, the delineated procedures for using NWPs included an explanation of how to determine target numbers and told you to roll (as a modifier to D&D's basic, generic roll-under ability check), but it was not something we used much in play.
Toggle Skills: A Vague History
I've been playing the Shadowrun reboot video games (Returns/Dragonfall/Hong Kong), retro isometric 2D point-and-click turned-based RPGs, and they tend to use characters' skills/attributes in the same way: the games have hard-coded checks that show up as dialogue options that are only available if you have the skill/attribute at a certain level. No randomisation involved: you either got it or your don't. This is fairly common to this genre of game, for what it's worth, I'm just bringing up Shadowrun in particular because it jogged my memory.
Usually when the topic of implementing video game mechanics in RPGs comes up, people will argue that video game mechanics don't work at the table because they're designed specifically for video games: either they require too much processing power to be feasible for a human to employ, or they're an unfortunate restriction borne from the fact that video games can only follow their rigid programmed story, or whatever. Nowadays we tend to see these "toggle skills" as a video game mechanic, but given my experiences using them in tabletop play first, I'm inclined to see them as one of those tabletop mechanics that video games inherited (and still often use in a form that's not all that different even after decades of iteration and innovation in video game design).
On the other hand, I feel like the "toggle skill" in RPGs has somewhat died off over time. 3rd Edition D&D fully yielded the fight against "trad" in this realm, adopting a kind of play that was far more structured around skill-based task resolution and characters who were much more defined by their skill lists. Many post-Forge proge designs did away with skill lists completely. Trad kept on tradding. I've seen a lot of the less-mainstream indie space adopt much more concise skill lists that could be amenable to toggle skills, but I also think many of them undercut the potential by taking a limp-wristed approach to forcing procedure on play.
The most obvious example (read: the most popular one I can think of right now) of a game that does design in this direction is Gumshoe, and maybe also some of its inheritor games although I know less about them. Gumshoe aims to solve the "brickwall-problem" of mystery-solving games by using a constrained skill list (in my opinion it's still larger than is ideal), encouraging characters to have a decent spread of skills, and encouraging the construction of scenarios in a way where these factors align to make them solvable within the procedural framework of the game. Cool stuff. I also recently saw someone describe Shadowrun Sixth World Edition as doing something similar with its decision to prune its skill list, although mechanically it is still more "trad" than not (which is good, Shadowrun should always be about that dice pool, baby).
Exception-based Design
Probably the reason that I like the "toggle skill" design space so much is that it overlaps/synergises with another of my favorite game design spaces: exception-based design. And specifically I enjoy the way that it encourages bringing exception-based design into scenario design, and the potential that has for baking theme directly into the game. "Negotiating with the anarchist-controlled TAZ is difficult, unless you're familiar with anarchists (have an [Anarchist] contact or [Knowledge: Anarchism]), in which case they're more amenable to you." This kind of thing was bread-and-butter for some AD&D module design, it showed up in a lot of trad stuff (sometimes to the explicit disfavour of those games' rules texts' explanations on how they were meant to be used), and it's been a common part of open-ended player fiction-querying in all manner of RPG play for a long time.
The king of exception-based game design is almost inarguably Magic: the Gathering. In the RPG world, my forever and eternal baby Meikyuu Kingdom also does it exquisitely, with almost every ability, item, monster, and facility (the things you build in your eponymous kingdom) having a unique function; very few things are keyworded, and most of these effects are significantly more complex than "add +X to Y". As a close relation to Satasupe, I'm thinking that I want Saturday Night Shadows to use toggles of some kind. Probably not skills (Satasupe doesn't even have a skill system at all, really: neither does Meikyuu Kingdom, if you care), but the challenge of building Shadowrun's various character options into a heavy exception-based design is one I'm looking forward to tackling. Notably the aforementioned video games already do this to some degree, so I'm in this weird limbo where I want to take inspiration from the games, but also avoid just making "Shadowrun Returns: The Very Boardgamey-feeling RPG". We'll see how it goes.
We played 2E with NWPs, but we rarely actually rolled dice to use them. D&D texts at the time mostly avoided structuring play around resolving a "skill-use procedure" to accomplish tasks, in part because the NWP rules were always relegated to an "optional" rule. But what we would often do is modify the fiction based around whether a character possessed a given NWP; to avoid a penalty, as an opportunity to present a "clue" to the players, to allow a specific kind of movement, or whatever. Yes, the delineated procedures for using NWPs included an explanation of how to determine target numbers and told you to roll (as a modifier to D&D's basic, generic roll-under ability check), but it was not something we used much in play.
Toggle Skills: A Vague History
I've been playing the Shadowrun reboot video games (Returns/Dragonfall/Hong Kong), retro isometric 2D point-and-click turned-based RPGs, and they tend to use characters' skills/attributes in the same way: the games have hard-coded checks that show up as dialogue options that are only available if you have the skill/attribute at a certain level. No randomisation involved: you either got it or your don't. This is fairly common to this genre of game, for what it's worth, I'm just bringing up Shadowrun in particular because it jogged my memory.
Usually when the topic of implementing video game mechanics in RPGs comes up, people will argue that video game mechanics don't work at the table because they're designed specifically for video games: either they require too much processing power to be feasible for a human to employ, or they're an unfortunate restriction borne from the fact that video games can only follow their rigid programmed story, or whatever. Nowadays we tend to see these "toggle skills" as a video game mechanic, but given my experiences using them in tabletop play first, I'm inclined to see them as one of those tabletop mechanics that video games inherited (and still often use in a form that's not all that different even after decades of iteration and innovation in video game design).
On the other hand, I feel like the "toggle skill" in RPGs has somewhat died off over time. 3rd Edition D&D fully yielded the fight against "trad" in this realm, adopting a kind of play that was far more structured around skill-based task resolution and characters who were much more defined by their skill lists. Many post-Forge proge designs did away with skill lists completely. Trad kept on tradding. I've seen a lot of the less-mainstream indie space adopt much more concise skill lists that could be amenable to toggle skills, but I also think many of them undercut the potential by taking a limp-wristed approach to forcing procedure on play.
The most obvious example (read: the most popular one I can think of right now) of a game that does design in this direction is Gumshoe, and maybe also some of its inheritor games although I know less about them. Gumshoe aims to solve the "brickwall-problem" of mystery-solving games by using a constrained skill list (in my opinion it's still larger than is ideal), encouraging characters to have a decent spread of skills, and encouraging the construction of scenarios in a way where these factors align to make them solvable within the procedural framework of the game. Cool stuff. I also recently saw someone describe Shadowrun Sixth World Edition as doing something similar with its decision to prune its skill list, although mechanically it is still more "trad" than not (which is good, Shadowrun should always be about that dice pool, baby).
Exception-based Design
Probably the reason that I like the "toggle skill" design space so much is that it overlaps/synergises with another of my favorite game design spaces: exception-based design. And specifically I enjoy the way that it encourages bringing exception-based design into scenario design, and the potential that has for baking theme directly into the game. "Negotiating with the anarchist-controlled TAZ is difficult, unless you're familiar with anarchists (have an [Anarchist] contact or [Knowledge: Anarchism]), in which case they're more amenable to you." This kind of thing was bread-and-butter for some AD&D module design, it showed up in a lot of trad stuff (sometimes to the explicit disfavour of those games' rules texts' explanations on how they were meant to be used), and it's been a common part of open-ended player fiction-querying in all manner of RPG play for a long time.
The king of exception-based game design is almost inarguably Magic: the Gathering. In the RPG world, my forever and eternal baby Meikyuu Kingdom also does it exquisitely, with almost every ability, item, monster, and facility (the things you build in your eponymous kingdom) having a unique function; very few things are keyworded, and most of these effects are significantly more complex than "add +X to Y". As a close relation to Satasupe, I'm thinking that I want Saturday Night Shadows to use toggles of some kind. Probably not skills (Satasupe doesn't even have a skill system at all, really: neither does Meikyuu Kingdom, if you care), but the challenge of building Shadowrun's various character options into a heavy exception-based design is one I'm looking forward to tackling. Notably the aforementioned video games already do this to some degree, so I'm in this weird limbo where I want to take inspiration from the games, but also avoid just making "Shadowrun Returns: The Very Boardgamey-feeling RPG". We'll see how it goes.