You can use your Bluesky account to reply to this post.
(Learn how this is implemented here.)
So one thing where I feel like I don’t have like…authority in but at the very least have thought about is the concept of performance loss (and specifically avoiding it through process optimization) in TTRPGs: the kinds of things that bog down a situation in a process.
WARNING: This post started as me making a little comment on a great, concise post on Fool’s Pyrite. Then I decided to make it a fun little post on its own. Then I thought about it some more. Then I drilled down and kept drilling. This starts simple enough but quickly becomes a True Sicko Post. You have been warned.
So anyone who plays AAA-ish video games regularly probably understands the concept of framerates.1 In case that’s not you, this is how frequently the graphical state refreshes. Typically a game aims for a particular target, like 30fps (refreshing 30 times a second) and 60fps (refreshing 60 times a second). Faster is obviously going to feel more responsive but that means the code needs to be able to refresh everything that quickly, meaning it needs to be much more performant: when the computer is expecting to spend 33ms vs 17ms, it can fit a lot more calculations in there. So the tradeoff for a developer is understanding what the hardware can do as far as visual fidelity, physics work, and so on.
Now, what happens if you try to cram too much in there, or the processor isn’t good enough? Well, it starts dropping frames - it skips around a bit or slows down, and both of them make the game not feel good or work half as well.
TTRPGs work the same way. There’s a million posts about optimizing video game processes; this is a post about optimizing your TTRPG process. I don’t have any profiler stats or anything half as objective as that, I just have my own observations and hot takes.
So I reckon the big first step to thinking about this is: what are you willing to put up with? Continuing that analogy, this is the answer to things like: Does this game only run on a proper, current desktop computer or can it run on some shitty chromebook from 5 years ago? Are we making a 30fps, 60fps, or 120fps kind of game?
Obviously we’re not talking about computing in the technical-specs sense here. But we can be talking about very similar things, such as:
Instead of CPU cycles and RAM and GPU output, people have cognitive load, which is similar conceptually but not as good at the same things: for instance, computers are really good at math and drawing triangles and holding things in memory. Nobody is that quick at that kind of stuff. But they’re quite bad at synchronous, “close enough” style approximated communication, which people are VERY good at. Part of any design discipline is understanding the strengths of the field in which you are working: art and design are flexible enough that certainly can jam a square peg into a round hole if you’re trying hard enough, but there are best practices to keep in mind that can make things go better in the design process. So overhead is the bucket you can reasonably fill with process: how much performance loss from any given mechanic are we willing to tolerate? It might be ok if a game is just intended for Hardcore Gamers only and/or you basically intend to ship it with a VTT module as the primary way in which you play it - in that case, your overhead is very high because either the intended audience is expecting that so it’s not a problem or you have a mitigating factor. But if you want something to be more accessible and flexible with regards to platform, etc. then your overhead is going to need to go down.
Generally speaking, I will assume that if you’re reading this, you want to aim at least more towards the “runs on a potato” end of things, if not fully there. If you just want to make something fully indulgent that only caters to the most hardcore of hardcore people who already know what they’re all about, godspeed, go in peace. (If you just wanna do what you wanna do in general, then yeah I’m not gonna stop you.) I’m not going to get into how the sausage is made because frankly, how it’s made isn’t remotely rigorous enough to examine and a lot of folks just kinda wing it. I’m going to get into what the sausage IS. I’m going to attempt to break that sausage down at the molecular level.
So let’s talk about operations.
I’m going to outline a traditional extremely basic D&D “damage on hit, nothing on miss” attack roll:
Simple, right? Well. Let’s get more granular and break it down into several operations.
(Everyone will probably have a different taxonomy for these, this is all just from my observation. We’ll get into them in more detail later but there’s a lot of overlap.)
Using this taxonomy, let’s break that D&D2 attack roll down in the most excruciating way possible:
This is for a basic attack. It doesn’t account for:
Now. This may seem incredibly pedantic, and you’re right! These operations are not all created equal and depend a lot on varying factors. Again, we don’t have a profiler, so we have to play this a little by ear: but the more you engage with these kinds of ideas, the more you get a feel for it. Let’s go into each.
You have dice, cards, whatever. Roll ’em or draw ’em, get the value. Easy, right?
Well, not all rolls are created equal. Rolling can easily get into calculate territory once you start adding operations to do TO the rolls to get out secondary results: adding rolled dice together for a total, picking out a number of successes for a dicepool, picking out doubles or triples or combinations, the wild poker dice thing that Cthulhutech was doing, and so on. So be wary. Some tips I can give:
So you can probably guess what “look up” generally means: I believe in you. But if you’re reading that example above, you’ll understand that I mean it in a very broad sense. From low-impact to high-impact:
Things that help mitigate lookup slowdown: aids like good character sheets, good cheatsheets, and good tools go a long way. But just putting down what a thing does instead of relying on tags, keywords, conditions, etc is even better than that: if you can keep the number of concepts referenced to a minimum, so much the better.
I want you to think about a few things for me.
The more things throw numbers and values around to achieve sub-totals, the more time you’re going to spend figuring out where it all ends up. If there’s some kind of lookup table or complex result involved, well, no prizes for guessing what operation this intersects with.
Keep numbers lower (or remove them entirely) and things will move faster. Let those numbers balloon out and things will slow down. As far as actual calculation-operations, if at all possible, stick to addition. It’s going to be way faster and there’s fewer edge cases of negatives/zero/rounding. Multiplication is ok too sometimes if values are low - it gets sticky when they’re higher, like everything else.
Ideally when thinking about those kinds of floating modifiers that get calculated, it helps to limit where bonuses and penalties go: in the sample attack roll, for example you can have attack bonuses/penalties and AC bonuses/penalties, which are redundant but are calculated separately. Whenever you throw a modifier around, try to make it affect the direct roll rather than a value from which others are derived because on the fly you’re not likely to remember what derives from it, or if you do you’re not likely to remember to switch it back after.
This is the kind of thing where computers, VTTs, etc help a lot. Anyone can add in every bonus into roll20 or whatver and it’ll just add it all up while rolling, which is great, and if you have a particular module for a VTT it’ll do all that kind of busywork for you - even better! But if you lean on the fact of those kinds of tools existing too much in your designs, you’re going to have a hell of a time running the game WITHOUT one of them. Try out anything as analog as possible and see where it lands - if it can reasonably be run that way, that just means it’ll be even faster automated.
Obviously this overlaps with calculate and determine and roll because you need to have things to compare them. But it’s an intersection-subset that comes up often enough to call it out specifically. Is this ability higher than this one? How about if they’re equal, what does that mean? How much of a disparity is there and does it matter?
A binary threshold - standard pass/fail, for example, despite all valid critiques about how pass/fail sucks - is fairly quick as these things go. Ternary thresholds - fail/partial success/full success or fail/success/crit are the most common ones - are slower because inherently you’re going to be comparing one value against multiple others, but it doesn’t mean they’re necessarily WAY slower or anything. For common rolls, the more unmoving the comparison target is, the better. If I always know a sure success is when the highest die is a 6 and a partial success is when it’s 4-5, it makes for a quick comparison. If double digits is always a success, that makes it scan pretty easily.
For less common situations where one roll has a lot of weight, you can be looser with this: I’m quite taken by Inevitable’s showdown roll and Troubleshoot’s recovery/advancement roll, for example, because they both happen fairly infrequently so the drama and tension of setting up those thresholds can feel good.
This one’s a little fuzzier than the rest, which are often more quantitative: this is my catch-all for “figure out if something qualitatively changed in the fiction”. As mentioned above, this is where you decide if states change: bloodied/staggered, knocked out, dead, etc. This is where “success/fail and there’s a consequence/complication” live too though.
On the first point because it’s quicker: A big thing you’re going to run into when you hit those kinds of states as a result of effects is, well, a double check after every action. Half health isn’t usually too hard to remember, and it’s not too hard to write. When there are rules like “X% damage in one sitting does something extra” or death spiral effects, that then gets into various other things like record or look up or calculate. Be judicious about these kinds of things being ambiently attached to anything because that’s an extra background process you’re going to have to mentally go through every time. It also helps if certain factors are personalized over generic: Pathfinder 2E making Attacks of Opportunity a class feature instead of something everyone has to think about, for example.
In general, the more nebulous the results of an action or outcome are, the more time this can take. The generalized “there’s a complication” is by a long shot the worst offender of this: if your GM is great at improvization or a situation has a very obvious outcome, fantastic, but if they’re not then, y’know, good luck. It’s also really hard to determine just how nasty a complication should be on the fly and it’s extremely easy to overshoot or undershoot, which can then have knock-on effects on whether a partial success feels more like a failure or a success: position/effect or similar concepts help with this but it’s all pretty subjective. Sometimes this kind of thing can be mitigated by knowing exactly what a partial success or a failure looks like: PbtA moves are half and half on this, for example, as a lot of them are great at defining partial success but leave failure as a more nebulous “something bad happens as a result”. LUMEN v1.0 combat complications do the thing of being like “usually this means an enemy can act” so you have a good baseline for what this looks like. A lot of games nowadays that use a generic-complication have big “here’s some ideas for what that means” charts. ( FIST is a great example of this.) You can also nip that in the bud a little via “determine what the potential risk is before rolling”-style things but this is definitely a “you should just play the game differently to make my design make more sense” style of fix, so you’re going to have to decide if that’s enough.
A transmission is whenever you pass information between players. In our attack roll example, we have three transmissions:
So we’re going back and forth between two people three times for one action. Every one of those transmissions can come with pitfalls like:
As anyone who’s had to deal with any of that knows, these can just suck up time like a sponge. So this one’s easy: When at all possible, reduce transmissions during a process. Ideally this goes as low as one transmission: the actor does their thing entirely on their end and informs other players what happened all in one go. When you do have a transmission, encourage it to be as clear an concise as possible.
So we’ve done something: now, we have to track it turn-to-turn. The part where this came up in our example was HP, but that’s just because this was one basic attack. Once you start getting into any kind of resource expenditure, this gets pretty sticky. Spells, powers, MP bars, ammo, different kinds of ammo, and so on and so forth. This also comes into play with state tracking: this is where systems that do everything by conditions or tags or descriptors or etc. can bog down hard, especially when you’re duration-tracking.
Whenever you can make something a yes/no state or something tracked with small numbers (i.e. small enough that you can put them on a clock or a series of checkboxes) instead of something tracked by larger numbers, that’s for the best. This is one of the better outcomes of Vancian-style one-and-done casting: you either have the spell or you don’t, so there’s not much in the way of paperwork, you just cross it out when you’ve used it and that’s that. Simplifying durations of effects goes a long way too.
When you do have a situation that involves a lot of changing states that need recording, understand that some things will slip. When you have to deal 1 damage to 5 targets as a result of an action, not only is this annoying and slow sometimes, it’s prone to rushing through and missing something big. When someone is getting 4 effects put on them at once, one of them might just get left out by accident. When you have to write something qualitative down, today’s shorthand will often not make any sense next week. So put a little thought into how flexible your design is to missing a beat: if something will really harm the experience by someone not changing a value or writing something down, try to make it as uncluttered as possible to avoid this.
Ok, so we’ve gone wildly in depth into these kinds of component operations of a process. You have one, it’s slimmed down to your overhead, you’re feeling good. But something’s still up. Let’s try to put two kinds of problematic processes in context.
In all of these cases, the prescription is similar:
So naturally as soon as I came up with those component features I plugged my own processes into them. Some of them came out pretty well! But I do have a few habits in there that bog things down.
First, thinking about operations:
And thinking about those process types:
I’m sure you can do the same to your games. If you find that something’s pretty high up there, it’s ok! Despite the title, there’s nothing to worry about. The truth of the matter is that this is a hobby made up of a lot of people who have simply not put that much thought into this, and that could be you - and that’s fine. If you want to improve it, though, the thing about games in the internet age especially is that you can always make another version and put it out, even if it’s already out. I’m going to try to keep improving my craft, making things tighter, making them better, optimizing processes as much as possible, and in general iterating to make my existing games continually better and improve future ones. I recommend you do the same.
This is a gross simplification to make a point. Don’t worry about the details. ↩︎
I’m thinking 3E/5E but it applies to most of them. ↩︎
I’m an insufferable asshole about this tidbit so this is as good a place as any to put it: Most PbtA rolls at bonus +X have a fairly similar distribution to 1+X die FitD rolls as far as distribution of failure/partial success/full success. For example, 1 FitD die is about the same as PbtA +0. Hit “At least” and compare the FitD 4+ result to PbtA 7+. and the FitD 6 result to PbtA 10+. Do whatever you like with this information. ↩︎
I frequently have to give credit to this article for making me think about the “collapse gracefully inward” aspect, because that’s a whip-smart way to design things. Ideally I want to design games such that they don’t HAVE to collapse gracefully, though, even if the potential is there. It’s not that it’s a failure state or anything if they do as long as everyone’s having fun and knows WHEN to collapse, of course, but well…that’s the rub, isn’t it? If you don’t know when to move things along and when to dig in, you can either end up ignoring half the game OR slowing everything down to dig in, and any game with a GM already puts a lot of pressure on them to pace things right. Write your game for people who will not be planning to ignore most of it. ↩︎
I’m required to mention it at least once per post, no exceptions. ↩︎
You can use your Bluesky account to reply to this post.
(Learn how this is implemented here.)