Love em or hate em, you cannot escape charts in Rolemaster. This feature, more than any other, distinguishes it from other surviving game systems. I cannot have a conversation about modifying or even understanding the game system without talking about charts and their impact.
Specifically, I am going to talk about complexity and efficiency, the cost of algorithms. Nothing about this conversation is about the goodness or badness of Rolemaster, only about its expense. Charts are the elephant in the hallowed halls of Rolemaster. This post is all about weighing the elephant.
If you are familiar with algorithms, you probably already know how this post will develop and I hope you do not mind my attempts to simplify a subject that can get, um, rather complex. Much of what follows might be obvious to you even if you are not, especially if you have been living with the complexity of RM for decades, but perhaps because I am about to explain this too awesomely. Perhaps. Or, you can just wiki computational complexity and algorithmic efficiency, and know everything! More likely, I will not have explained things well enough. Otherwise…
Complexity is basically how much stuff it takes to support an operation. The usual ‘stuff’ considered is time: If I run an algorithm on an input of size N, how long will it run? But we can also consider operations: How many operations does it take? This is pretty useful to measure the agility of a game system during play: How many things do I have to do to reach a conclusion? Finally, we can consider space: How many physical resources does it consume? We will be talking a lot about this last.
Suppose I have N talents that cost the same and work the same for everyone: No special cases. How much space do I need to represent them? Well, it’s the average length of a talent write-up, which we can consider reasonably constant, multiplied by N, or k*N. We ignore the constant and call this O(N), because as N gets really huge the constant doesn’t matter very much. If I have 1000 talents in RM, the space I need is 1000 entries. If I have 4 talents, I need 4 entries. If I add a brand new talent, whether I have 1000 talents or 4, I do not have to modify any other talent and I need exactly one more entry. We call this linear.
So far so good? Well ok: The same thing happens if I decide to add a new skill to RM, right? Nope. Let’s walk through this. First, I have a chapter all about skills. I add another skill, and that’s just another entry, as for talents. But I also have different skill costs for every class. So if I have S skills and C classes, I need S*C entries, or O(S*C). Hey, that starts to look like a table, or a chart: It’s no longer linear, but quadratic. It’s representation no longer looks like a list of stuff, but a quadrangle. If I have 300 skills and 50 classes, I have 15000 entries. To add a new skill requires C=50 new entries; a new class requires S=300 new entries. Ouch.
Of course, if I add a new class, I also have to calculate and then create entries for the cost of every Lifestyle and Vocational Package too. If I have P packages, that’s O(P*C), which is also quadratic. Having to do two (or any constant number of) quadratic things is still quadratic.
If you’re wondering why so many rules tinkerers go with a single Non-Profession class, or if you are one of these tinkerers and think you are doing it for some other reason, you are really doing it to reap the benefits of greater algothmic efficiency. These quadratic algorithms become linear because you have set C=1. When balancing skill costs, you have S costs to think about rather than S*C, so you are more likely to get the balance right. When representing skills, you have S entries. That’s linear. The same reasoning holds for packages, and maybe some other charts I don’t want to think about now.
Of course, we can use skill categories to tame this problem, which has already happened :). This reduces the size of S, which is nice. Instead of S=300 we have, say, S=20. But the algorithm still consumes quadratic space, because it hasn’t changed: 20*50=1000 entries. That’s better than 15000! And if we limit ourselves to only 20 classes, we have even fewer entries: 20*20=400. But if we had a linear algorithm, O(S), we’d have 20 entries, or we could ignore skill categories and have 300 entries.
This is what a game designer I know calls “the n squared problem.” When designing a game, he never wants rules that require him to make a big table (he simplified the rectangle to a square, which is reasonable) because he then has to fill in every entry and be sure they are all correct before going to print, and then players who want to really understand what is happening have to look at N*N cases rather than N.
So, RM has “the n squared problem,” right? Nope. We should be so lucky. RM has Armor Type rather than mere Armor Class. Where lesser games are content to represent each weapon as some die roll for damage with maybe a damage type and maybe a special rule, every RM attack is unique. And where other games settle for a mathematical formula for deciding what a die roll means, RM has something like 50 entries for the range of 0 to 150+.
That’s A (number of ATs) * W (number of weapons or attacks) * D (dice roll bands on table). That’s O(A*W*D). My game designer guy would call this “the n cubed problem.” We in the biz call it cubic. It’s like a stack of tables. Let’s weigh the elephant:
If I have 20 ATs, because that sounds like a good number :), 40 different weapons and attacks and 50 dice bands, thats 20*40*50=40000 entries. (I won’t even bother with the crit charts here, but that’s also cubic.)
Add another weapon or attack type? That’s A*D new entries, or a page. Want to add a new AT, say, to support the plant people and plant armors I really want to add to my game? That’s W*D new entries, and I have to edit all the pages. You get the idea. (Here is where a purist might point out that I should represent D as a really big constant. But I’m simplifying, and I think you know why I’m not.)
I hope we are getting something for all this algorithmic inefficiency: Other rpgs usually represent weapons and armors in linear space. Remember: If I have one list of armor that doesn’t depend on weapons, and another list of weapons that don’t depend on armor, that’s two lists, both of which are linear. That’s O(N), and I have a number of entries precisely equal to A+W.
We can reduce entries too: RMU cuts the number of ATs in half, for a substantial savings. But I still cannot easily add new armors, as I can in other systems. The relative algorithmic inefficiency is forcing some hard choices! We’ll be talking about choice in another post. But could we instead change how things are done? Change the algorithm? Should we?
Maybe you don’t care about space complexity, but only about time complexity. After all, once you have a character, you can copy the few charts that character needs, and it doesn’t matter because everything is so easy for a guy who can GM this game in his sleep. We’ll talk about time complexity in a moment.
But first… it does matter. You pay for the space complexity when you buy a book and much of it is table entries like 22AK, 24AK… when it could have other kinds of content. You pay again when it takes forever to get a new book out because all of the entries have to be correct. You pay again when you find that things aren’t balanced right even after that forever: Human beings really don’t do a good job balancing 10000 table entries, and trying to reduce the problem with categories creates other problems, which have been discussed in other RM fora, though not from this perspective. You pay again when a new something or other is added, and all the charts have to be updated. You pay again when you are the one who wants to add or change something, because that’s expensive in RM. There are some other subtle prices to be paid, and RM veterans who start to look at the game through this kind of lens are more likely to find the most insidious these than I.
There’s a time penalty too, because looking things up on a matrix is often more difficult than rolling some dice and comparing to something simple. But this is not so terrible.
All rpgs have to deal with time complexity, and few do a great job of it. Time complexity here is all about the cost of each operation. Do I have to figure out how many dice to roll? If so, given the capabilities of human brainpower, what is that cost, compared to a mechanic that always has me roll the same dice? That’s the best, by the way: constant complexity, or O(1). RM can brag here. But calculating all the modifiers is a different kind of expense, and RM has that in abundance. Then there’s tracking actions, percent action, initiative… What are the real costs? Each kind of operation is just plain different. Having to open a book and reference a table has a different cost compared with finding the right dice to roll, especially if some other player borrowed one, compared to calculating a formula, even a simple addition or subtraction. And then there’s the cost of human error.
So, in the simplest sense, most rpgs seem to have linear time complexity: Add up each relevant modifier, find the necessary dice, roll them, figure out what it means. But if any of these operations requires greater than constant time, the overall time is worse than linear. I am very confident that looking anything up on a table is worse than constant for a human being. I suspect it is worse than O(logN) and would be shocked if it were better. Alas, that awaits a real study or a good Google search.
As an aside, the advantage/disadvantage mechanic of D&D5 oversimplifies, perhaps, but it has powerful, um, advantages: Although running through the possible sources of advantage and disadvantage is linear, you get to stop much earlier, because only one of each matters. Also, the math is dead simple, since there is no math, so we can be sure the operation really is constant. (I’m not sure that adding modifiers is really constant.) It is also far more reliable: If you accidentally use the same modifier twice, you still get the same result. Combined with no table lookup, this really is a safe O(N).
So, here we are. I haven’t gone through everything, some of which will come up later, like spell lists, but RM has some rather inefficient features.
I do not mean to say they are the wrong features! If the features provide you with something you don’t otherwise get and still really want, well, you paid the price for what you want. That’s the big question, isn’t it: If you’re willing to collapse classes to reap the rewards of efficiency at no loss of playability and perhaps even a gain, what else might you do?
This week’s offering is Call That A Knife.