On weights
(and other measurements)
The next time I see another unamaginative D&D clone slap lb values on items because it mistakenly believes you need to have encumbrance rules in your ttrpg, I’m immediately closing that book. Pounds are by far one of the absolute worst ways a designer could possibly do this niche aspect of weight, even if they needed it in the first place, and that’s already a very dubious proposition.
(There’s a huge caveat to the above statement, but the caveat is the entire rest of this article so I can’t sum it up here.)
Story time: I generally don’t bother giving objects stats ahead of time, not least because I generally don’t do prep work for sessions. In my own game there’s a succinct guide on what each point in a stat roughly equates to anyway, (keep this in mind for later) and as somebody who’s GMed it quite a fair bit at this point, I know it by heart. So, last night when a player asked me how heavy something was, I just said “5 STR” on the spot and moved on with other narration. Then he asked me again, so I said the same thing, assuming they just forgot or didn’t hear me well originally. By the third time, it was painfully clear that there was a disconnect which needed to be resolved. As a new player to the game (three sessions in), this is something he hadn’t run into yet. He was expecting to get a weight value in a measurement he’s familiar with outside the fiction (kg), meanwhile I was giving him the game’s requirements for the amount of muscle you need in order to produce the force necessary to lift that weight.
And so… here’s the thing. I’m convinced that weight doesn’t actually matter. Not when measured in conventional, “irl” units anyway. To understand why, let’s be a little more precise:
Definitions
Mass is the amount of matter an object is composed of*. Weight is the force exerted upon an object’s matter by gravity. At the Earth’s surface, an object whose mass is exactly one kilogram weighs approximately 9.81 newtons. Mass stays constant, while weight changes based on different (gravitational) conditions.
*Technically, mass is a measure of inertia, but this level of precision goes beyond our purposes here.
Granted, in a game with a consistent setting those conditions probably wouldn’t change much, but the fact remains that weight is a force that’s being exerted. So I put forth the argument that strength, albeit technically an expression of “muscle mass”, is actually the amount of force that a character can produce. More specifically, force in the exact same context as weight. This… shouldn’t be a controversial statement by any means, I just wanted to be super clear about the core of the argument here. After all, that’s what muscles are for in the first place, to exert force on things.
The only purpose for weight for is to determine how hard something is to lift (or push, pull, pick up, etc. etc.) And when I say “only”, I concede there may be some other purpose for it out there, but for 99.9% of use cases, that’s precisely what we do with it. So I see absolutely no reason not to measure weight in the force required to act on it. Whether that’s a Strength stat (or its equivalent/alternative) or a skill, an ability, a trait, a something that serves the same purpose (I will refer to all these things simply as “strength”). And while that may not be an accurate expression of (fictional) reality, let’s not forget that the point of (most) games is not to be scientifically accurate. For one, that would be incredibly tedious. More importantly, it’s also just… not useful. We want an abstraction, something that gets us “close enough”, so that we can accomplish one (or both, ideally) of two things:
- Interact with the concept while playing a game.
- Get a good intuition what it’s representing in the fiction.
Let’s unpack these a little bit more, just so that everyone writing and reading this article is on the same page. The simpler something is, the more people will be able to interact with it (as in, use and make use of that thing). It doesn’t just come down to the possible lack of understanding on part of one or more players, complex things are hard to work with by their very nature, even when they are well and fully comprehended. Science is amazing, but it needs to be accurate, and with that need come a lot of rigour and procedure that simply get in the way any time we don’t need a high level of precision. Such as, for instance, when playing (most) games. That’s why designers make use of abstractions, and strive to use the simplest possible form and method (that still achieves their goals), allowing the most people to understand their games and perform gameplay actions for the least amount of time.
In much the same way, the easier it is to imagine what something is (and it gets easier by being more intuitive), how it looks and works within the fiction, the more consistent that imagination will be between multiple people. Ttrpgs are very much the type of game in which any misalignment between one player’s interpretation of the shared fiction and another’s can be an extremely detrimental, in so far as that it means the fiction isn’t actually being shared.
Hopefully now we agree that things need to be as simple (as a synonym for “easy to use) and as intuitive as possible. I argue that the fewer steps needed to accomplish something there are, the simpler that thing is. Likewise, the closer something works to how a player assumes it would by their previous experiences (most commonly “life” in general), the more intuitive that thing is.
For a concrete example: Obviously, if the game says things weigh a certain amount, it understands what “weight” means, but if that amount is in a different unit than one that’s on a character’s sheet, then that character can’t really interact with said weight. You end up needing a conversion mechanic* to bridge that gap and make the game understand what to do with weight, which is an extra step. The more steps removed a property is than the way we interact with it, the worse it’s doing its job by being less intuitive and more complex.
*Remember how I asked you to keep something in mind? Well, this guide that I have for translating the numerical value of a stat into its fictional representation is technically a conversion mechanic of this sort. It’s not the most elegant solution, but it gets the job done while I’m actively looking into better ways of handling the problem. At the same time, I sidestepped the “issue” entirely because it serves as an optional layer that’s not actually required by the game engine.
Making it work
Naturally, this entire point begs the question how to bridge any and all possible gaps so that no conversion and/or extra steps and/or extra mechancis are needed in the first place. And before going further, I’ll just point out that this won’t be feasible for every game, whether due to too narrow or too broad a scope, complexity budgeting, or a million different possible reasons. But if and when it is possible (and despite the previously mentioned millions of potential reasons I maintain the vast majority of games don’t fall in that space), I argue that it should be done. Not with “relatively high” priority, too, but with the highest priority. It’s hard to overstate how much these kinds of optimisations improve games.
Now, as how to actually accomplish this, there are many ways. I have a few ideas myself (which I’ll list here), but I’m sure there are plenty of things I’m not thinking of. This is a prime area for blue sky design, and my current point of view on ttrpgs hasn’t explored this space too deeply. At the moment, the best I can offer on thet subject of bridging gaps is to align the fictional component with the mechanical, regardless of which way you do it. A very simple example, rather than using numbers to represent the scale for a given stat, you can use degree adverbs (though, note, this particular strategy will work only as long as your stats don’t go too high). So instead of a character having “3 strength”, they’d be “fairly strong”. This natural language integration into the mechanics allows for absolutely seamless transition, especially if the narrator makes a habbit (and especially if the game rules require them to make a habit) of using those exact keywords when describing things. For instance, when they say something is “fairly heavy”, you will instantly know what somebody at least “fairly strong” could lift it. For some added fluidity at the cost of a little immersion, you could even go so far as to describe the weight of something as “fairly strong”.
And while aligning mechanics with fiction is my personal preference, the other way around works just as well. You can forsake natural language and describe something as being “3 heavy”. It doesn’t sound great, but if you get into the habbit of thinking more in terms of gameplay and less in terms of the unfolding fiction, it will come to you rather easily with some practice, while at the same time providing the benefit of seamless transition. You should still have it mechanically written down as a rule, but it’s extremely intuitive to figure out that something 3 heavy would be interactable with by a character with 3 strength (or more). Design is very much (if not all) about leveraging pre-existing and in-built human habits, knowledge, behaviour, and everything of the sort. We can always overengineer to account for a lack of any of those things if we felt compelled to, but it’s important to recognise when we don’t have to.
Besides aligning mechanics and fiction into either a qualitative or a quantitative state, the next best thing that we can do is reduce the disconnect down to a single step, one which hopefully vanishes from time to time under the right conditions. I’ll explore this in the following example of what I’ve personally done, because even though I’m looking into making the above work with all the peculiarities of my system, I’ve already makde a simple reference guide work quite well in the mean time.
But that’s not all. At the very start, I mentioned the misguided belief of many a “designer” that encumbrance rules are something a game needs and that wasn’t a random example. For one, it’s the worst offender because encumbrance specifically is, indeed, unnecessary more often than not. But more importantly, it’s an excuse to delve into the rabbit hole that is subcategories of weight. Because, technically, that’s what something like encumbrance really is, a very specific application of the concept of how heavy things are. Obviously, the small indie game Diablo did it best, but in the ttrpg space that’s not really feasible a lot of the time (though I’ve seen it done and if I remember the name of the game I’ll edit this to mention it). Or you could all but ignore it, like I have. Regardless, enough on encumbrance, the main point here are really the subdivisions of measurements (the next article on movement will delve even deeper into this aspect).
I’m not a huge fan of them myself and avoid unnecessary mechanics where possible, but every designer should judge on a per-case basis if they are needed and what the best version would look like. Whenever you include one subcategory but exclude another (consciously or unconsciously alike), you are making a statement that you care about this particular thing and also that you don’t care about the other(s). Which, despite its many other faults, is certainly something that reinforces theme and makes a statement on what the game is about. Therefore divisions like these clearly have their place in design, if nothing else than at the very least as a tool for emphasis.
Lastly on edge cases, I’d like to raise something for designers to keep in mind. You need familiarity with the subject you’re dealing with in order to purposefully stress or unstress certain aspects of it. The less knowledge you have, the more often you will be inadvertently including only a certain aspect of it and unconsciously omitting another. Which is no big deal, just be aware that for somebody with more knowledge on the matter, you are for all intents and purposes actually reinforcing a particular theme, even if you didn’t know you were.
My implementation
Like I alluded to earlier, I do use a conversion mechanic, which I admit doesn’t align with my ideal vision for a game. I have (currently) kept stats quantitative and provide a guide on how to interpret these quantities as qualitative representations. However, to alleviate this issue, I took this additional step and made it entirely optional. At the start I described the confusing experience that a new player had with the game. The disconnect came from the fact that they were expecting some form of conversion, something they’d need to account for. And it’s there, and I did use it for myself (in this instance, there are many in which I wouldn’t even need to), but because the game measures weight in terms of strength, that step was entirely nonexistent as far as the player was concerned. See, it helps for the sharing of fiction to have these guidelines, but the game engine doesn’t actually care about them. They are for you, the players, if and when you need them, but for purely mechanical purposes there’s no added complexity any time you end up not using it. And when would that be? When it becomes intuitive.
So if there was an actual extra step in play here at the end of the day, how is this useful? Well, two very important things to consider. One, this only comes in when you need to do some on-the-fly stat adjustments. For anything with mechanics that tell you how to create it (chargen, itemgen, etc.) you have the system itself guiding and dictating how to set those stats, so you don’t need to engage with this step. Not only that, but any time you provide a pre-generated version of something that uses stats, even if you used this conversion mechanic to make it, in-game that’s entirely ommitted, saving time and processing power. Second, equally or perhaps even more important, the guide is extremely intuitive by virtue of leveraging concepts every player is already very familiar with, which means that over time it becomes so natural you stop thinking about it, which in turn means this “extra step” gets instantly and unnoticeably performed by our amazing human brains.
But why stop there? I took one extra precaution to bridge this gap even further. The more you engage with the fiction, the easier this will become to use… because weight in the fictional world is also measured in terms of strength. In the worldbuilding, I made sure to have people measure the things you use stats on with the same unit as the stat itself, in order to reinforce the concept from the other way as well. Since strength has been our example throughout this article, yes, in-universe people use the “standard muscle” as a unit of weight.
Now that I was comfortably representing weight via the strength stat, there’s one last thing I had to resolve. Those pesky subcategories, the dreaded edge cases that plague designers and fuel their nightmares. Here’s an example of something I considered:
All’s well and good doing this for inanimate objects, but what about things with strength of their own? An example would be lightweight devices that can exert a great amount of force when provided with a power source (though that’s easily solvable via a force multiplier provided by the source of power), but the common case is just… people. Characters in general. What if you want to have a character that’s very strong but not very bulky? Or a more massive but not particularly strong character? If weight = strength, they have to weigh more the stronger you want them to be, and vice versa.
Well, first of all, that’s how this sort of thing works already. Yes, there can be outliers, but for the most part the corelation exists naturally. You need muscles for strength, and those muscles make you heavier. Conversely, the heavier you are, the more muscle you will develop in order for your body to support your weight. Second, and more important, we have to remember that this is an abstraction. Your weight is how difficult you are to be lifted/pushed/etc and being stronger definitely helps with that (yes, you can be unconscious or unable to use your strength to resist). And finally, it’s just very easy to model extreme outliers via a status effect that spells out the required interaction. This brings us back to having a hoop to jump, except now we’re only using it for edge cases, which will either happen rarely enough so that we’re not dealing with the extra step all the time, or be at the forefront so much that the operation becomes intuitive by virtue of repetition.
More generally, when it comes to edge cases like these, I prefer to tackle them if and when I need to, rather than dedicate niche mechanics to them, handling the bulk of the use case with one generalist system. As I become aware of more things, I can deal with them if I feel like I need to, and that’s what research and playtesting are for.
In conclusion
The same principles apply to any and all measurements in a game, whether they be distance, speed, accuracy, density, brightness, etc. These things are only as useful as the ease of interacting with them, which in turn means that the closer the fictional element is to the game component, the better.
A great benefit from measurements done well is that they reinforce a game’s theme. The more the fictional and game elements align, the clearer the message based on which ones the designer has chosen to include in the first place. Glaring omissions also add to this, though I’d argue they do so to a lesser degree since they can sometimes go unnoticed by people (in the same way that “common sense” is not at all as common as one may assume, so too “glaring” things can be rather dim for others).
In the next article, I’ll look at distance and spatial mechanics through a very similar lens, since they are an interesting case of where I think the added extra step of a conversion mechanic can actually be extremely beneficial. But for now, those are my thoughts on weight.
Cover image artist credit:
