With this article, I’m starting an entirely new series on tacking problems in RPGs that aims to explore the ways we can speed up play and make it a smoother user experience by reducing the lag that happens when interpreting roleplay through mechanics. This streamlining process can be applied to everything, both during the session and out of it, and each article will focus on a different section – what I consider the current “problems” to be, what solutions I think are possible, and what I consider (and have done in my games) could be a “solution”, mostly focusing on Chimborazo RPG for examples.

Introduction

In this instalment I want to tackle skill usage and how we can reduce the amount of time it takes to check whether or not a skill succeeds/fails, to what degree, etc., as resolution and the often involved rolling of dice are one of the major sources of downtime, when roleplay is interrupted by the necessity of going through the motions as dictated by the mechanics.

Disclaimer: While mostly universal, this is by no means exhaustive or applicable to all RPGs. Even though the rolling of dice is mentioned as an example, the methods outlined in this article apply to various resolution mechanics. Still, they won’t cover extreme edge cases in many systems, and I expect this to hold true for most articles in the series.

To begin this piece, I want to take a moment to clarify some nomenclature. When I say “skill”, I don’t mean the type of skill you see on your D&D character sheet. Think of it as an… action, of any kind. Something you do, something you use. The way I use the term “skill” in my games, is anything a character can do – discrete actions they have available (such as attacks, spells, negotiation techniques), passives that augment them in any way, etc. Basically things they can do. To think of it easily, skills are what can be found on a skill tree (though that’s not necessarily a requirement) and can be as varied as the things skill trees can be used for. But since I’m going to give examples from my own implementation, it will be easier to proceed with the term I’ve chosen to use.

Thesis

The issue with skill usage is that most systems, especially those that stick more closely to the traditional formula of RPGs (and don’t pretend you don’t know exactly what that is), involve resolution. Not only limited to rolling dice as modifiers to figure out the exact effect the skill will have at any given point in time, this can also take the form of looking at tables, consulting lists, etc. There are exceptions, of course, but traditionally within the RPG structure, some form of determining the exact outcome of a skill is present and must be checked every time that skill is used – the inherent variance of skills is used for different purposes, from determining success to determining the specific type of effect the skill will have, sometimes both at once. Because of this, I propose that the following is the core issue that needs to be addressed:

The process of resolution is the major factor that slows down gameplay, since it involves the usage of tools extraneous to the skill itself.

Going further, I postulate that the case-specific method of resolution is irrelevant and I am hoping to propose universal solutions that address the issue at the root of the problem.

Since the goal is to speed up the time it takes for any kind of resolution to take place, it stands to reason that any method aiming to do that would revolve around skipping the checking process (consultation with external factors), either entirely or at least partially. This means that success/failure has to be linked to the skills themselves without going through additional hoops. Normally, action resolution is an entire subsystem in most RPGs, and a core one at that. Bypassing it is not intended and must be handled carefully. It is axiomatic that automating the process of resolution will break the game if it was built with the usage of a non-autonomous resolution mechanic in mind, so we need a way to prevent that. If making all skills resolve automatically is out of the question, then the need arises for a way to determine which skills should do so.

This will inevitably re-introduce some of the delay we wanted to remove by automating resolution, however this time it will be less, and we can choose where to inject it back into the system so it doesn’t result in a big block of time spent not playing the game. In implementing this selection process correctly, we can ensure the balance of the system is preserved (deviation is likely to occur, the degree of which will depend on the particular system, but steps can be taken to mitigate it). Lastly, I suggest that any modification that targets only certain skills needs be tied to the user interface (be that character sheet, skill cards, cheat sheets, or anything else with a similar function), since it is only a secondary feature that is bypassing the game’s primary mode of operation.

Until we learn to better integrate automatic resolution in our games from the very start of the design process, that is.

Solutions

For my own project, I have focused my attention on the selection process by which I determine what skills ought to be subjected to automated resolution. It seems to me that this is the key to the entire thing, and I have used every bit of good game design practices I know to ensure that it follows with the rest of the game. Realising that the balance of the system would inevitably shift, instead of working to patch it back to the previous state I let it change – quantitatively it remained the same, but qualitatively it was now different, and more importantly, better. In the process of cutting down on time, I also realised that this method can be used for other types of actions as well. Simple and mundane actions, such that weren’t made into skills lest the game had a thousand skill trees, lend themselves very handily to this type of behaviour and binary success/failure modes in general. Due to my implementation I call them “stat checks” and I’ll take a moment to talk about them first, then move to the sped up skill system:

Stats

Since “stats” (or “attributes”, as they are often called) are what define a character in the mechanics, I took the opportunity for stats to dictate how good a character is at things that are only affected by their stats. If an action requires only strength, such as moving a boulder to block a passageway, in my attempts to speed up resolution I quickly found that there’s no need for dice rolls or Convoluted ways to determine if they can. As long as the boulder has some strength of its own to compare the character’s strength to (you can call it a TN, short for target number, but I find my phrasing easier for players to wrap their heads around in the long run), this is already a built-in way to measure whether or not they can interact with it and requires no further handling by the system. It’s a binary state, yes, but a very useful one, and it allows for roleplay to flow without interruptions, as basic actions can be resolved automatically based on a predetermined value. The best part is that this preserves important aspects such as player agency – they got to choose how to distribute stats and what their character is good at. It is also using a selection process that already existed in the game and simply re-purposing it to do more work.

To make this feature work better, a game can provide useful descriptors and examples for its stats (such as what difference in capabilities there is between a character with 4 strength and one with 5 strength), gauging difficulty and making managing expectations even easier, allowing for smoother gameplay still. On top of that, this aid helps the GM (if there is one) judge what stats to assign to objects and actions (as a TN or its equivalent) when they are not already provided, significantly cutting on the downtime.

Skills

A game’s skill system needs an equally robust way of selecting which skills can be subjected to automatic resolution. The crucial factor here is to make sure that while introducing this selection process we don’t add back all the time we take away from resolving each skill, otherwise this will have all been an exercise in futility. The subsystem that caught my attention was skill progression. It’s already quite involved, however most of that happens in the natural downtime outside of actual roleplaying (or often, straight up outside the game itself, between sessions). Building off of this, I decided it’s a perfect fit, tying the selection process to progression takes care of things in a similar fashion as does tying simple task resolution to stats. Since we can’t have all skills resolve automatically for balance reasons, picking the right ones is key, and the best way to make sure that they are “the right ones” is to pick the ones that really matter – skills that come up often enough that speeding their resolution impacts the amount of mechanical downtime during play, skills that the characters and players care about.

To that end, I ended up introducing established actions” into the game. This plays off from the already existing progression system, except it replaces upgrading the skill (which I scrapped entirely, in favour of this) with simply giving it the “established action” status forever. To spare unnecessary details in this already long piece – the more you do something, the better you get at it, and eventually it will become well established that your character won’t fail at it if there are no external factors influencing their actions. This makes all of your established actions automatically succeed and speeds things up significantly, however for balance reasons the normal resolution mechanic still takes place if something would influence the character while performing that action (though there still exists a lot of design space where I can manipulate how much established actions are influenced, if at all). With this method I take the things the character already cares about doing and speed those up, while not subjecting unnecessary skills to this process (as I already proposed, the more a system bypasses the resolution method it was built in mind with, the more it grows in danger of breaking its intended balance).

Since this still leaves even established skills subject to the normal resolution process under certain conditions, I put an extra layer on top of that called signature skills”. These are the character’s favourite skills, the actions they have practised the most, and have no chance of failing at no matter what (barring being directly stopped, of course, but that is an entirely different conversation). Signature skills are very few and far between, in fact in Chimborazo they are true to their name and a character only has one (or two at most), though theoretically I can see this going further in longer and/or higher power level campaigns. Once again, this speeds up the game a lot – not only is this method taking the character’s most practised (aka most used) skills, but it now creates even further incentives for their use. The self-balancing nature of skills in my game takes care of abuse cases – the more powerful a skill is, the more constraints it has, higher costs, etc. This is something each game does differently and should take care of on its own.

To show how rare they are in my current implementation – in order to be able to nominate something as a signature skill for your character, it has to be an established actions and your character needs to have fully unlocked that skill tree (something to do with “true mastery” in a particular field). For something to become an established actions, you must have used it successfully three times in a row with the odds stacked against you (e.g.: with Disadvantage or under other negative conditions) in a single gaming session.

The one kink that I have yet to work out is a universal solution to what would happen when two signature skills have to resolve against each other, akin to an opposed roll. I think this is only really an issue when one skill would be a direct counter to another, at the solution can be as simple as erring on the side of the counter. (There is an excellent Drive to Work episode on why you might want to go that way, in relation to MTG Rule 101.2. Click here if you want to hear Maro talk about it, this section starts around the 7th minute if I recall.)

User interface

I mentioned that it seems to me like such a method would demand integration with the UI (user interface), and here’s why. Operating under the premise that a game has a consistent style and all skills are presented in roughly the same way, dynamically applying the selection process of determining which skills can and should be subjected to automated resolution is bound to leave out most skills. A method for tracking which ones are selected each time (each campaign, or for each character, or each adventure, or however your progression resets) is necessary, and unless the game completely lacks a UI for skills, it needs to provide some easy way for tracking such status.

In conclusion

It’s my argument that within traditional resolution mechanics design, too much time is wasted by players purely going through the motions. If we can cut back on this time and make the transition between the roleplay part and the game part more seamless, everybody stands to gain from the process. I am proposing a universal method that should be applicable to most games, which involves automating the process of skill resolution through conversion to a binary success/fail system, then applying a good selection process to filter which skills can be subjected to that conversion without resulting in overall game imbalance.

In this article I’ve explored my solutions, and they are mostly geared toward the success side of this binary state, but the opposite can be done just as easily. It’s quite likely that I explore that side further in an addendum to this piece. On a related subject, there will be a “Part 2” in the not too distant future, expanding on indirect ways to bridge that gap.


This article, the theories and methods within, are part of the field of Applied Game Dynamics (AGD), a collection of works that attempt to organise and advance game design. Focused on (but not strictly exclusive to) tabletop games, AGD is an effort to systematise game design and bring it into an era where it can be taught and studied from a consistent base.

One Response

Leave a Reply

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