A friendly correspondent (who, like me, is working on a home-brew game system but isn’t ready to release) asks me about ideal implementation of “log ST” in a system. Log ST is the name commonly given to a game feature that sets levels of character Strength to an exponential progression, so that every extra +1 Strength mutliplies the previous level of power by some amount.
Typically, that’ll be expressed as every additional X levels of Strength multiplying lifting power by some easy-to-grasp multiple Y. An example is in the HERO System, in which every +5 Strength multiplies lifting power by 2.
My reply to my correspondent largely mirrors this post, so there’s not a heck of a lot for me to add here. Still, it never hurts to recycle some new text into a recap. Here are notes on my ideal implementation of ST in a game.
But first: Why?
There are plenty of benefits to replacing most games’ implementation of ST with log ST.
One is that each level represents only the additional amount of power that you need care about. That is, you don’t end up with +1 ST (the smallest quanta) doubling the ST of a Pixie PC (with no in-between levels possible), while adding some piddling amount to a Giant’s ST. Rather, the same +1 represents the same multiplier to each character’s power, boosting each by the same meaningful relative amount. The result: All characters use the same mechanics for ST, yet that single ST stat finesses ounce-level differences in Pixies’ lifting abilities, while dealing in meaningful hundred-pound differences where Giants’ feats are concerned.
Another benefit: log Strength can be used directly as a modifier to rolls, anywhere. All Contests that compare log ST stats will work without special rules, as will adding Strength directly to skills, DX, etc., where appropriate – something decidedly untrue for implementations of Strength like GURPS‘.
Perhaps best of all, massive physical power for supers doesn’t require huge log ST scores or funny new rules. With power rising exponentially, even Hulk-like strength gets represented by a reasonably-modest, easy-to-handle log ST score. Likewise, even the tiniest physical power gets represented by a nice integer (though possibly a negative one); no fractions or other special “little people” rules are needed.
Setting it up
If you want to build log ST into a game system, here’s how.
Pick the “scaling factor”, i.e, the multiple of power that each additional +1 represents. It’s probably easier to think in terms of how many added levels of ST (call this X) multiply lifting power by what amount (call this Y). There’s no technical reason why Y needs to be a neat number like 2 or 10, but neat is what our meat brains like, so that’s what I recommend. (Read to the end for more on the math of things.)
I’m working with +6 ST = x2 lifting power in my home efforts. That may look inelegant, but has its advantages: in particular, +20 ST becomes a neat x10 power (after applying just the barest of rounding). If you use +3 ST = x2 progression instead, you get an even neater correspondence: +10 ST = x10 power! Under that progression, each +1 ST represents a bigger power jump than I prefer for my purposes, so I’m using what I’m using. But for, say, a superhero game where fine distinctions of power aren’t needed, +3 ST = x2 power might serve you very well.
Lifting power for any ST can be calculated on the fly via calculator, but of course you’ll want a single table for it all. The table doesn’t have to be too big if the numbers are easy to eyeball! In particular, if +X ST maps to a neat x10 power, then power for very high or low ST becomes a dead-simple matter of adding or subtracting X ST to add or subtract a decimal place of power. That’s a nice play aid that keeps tables short.
Here’s one big thing to note in a log ST implementation, though: You have to be able to let go of positive numbers. At a low enough level of strength, ST has to go below 0. If that sounds shocking, keep in mind that plenty of game systems offer stats that represent either positive or negative modifiers, like Reaction Mods and many other things in GURPS (including Will in 3e), even if core attributes normally don’t. You can still have ST in your game default to 10 or whatever’s normal for your system, heading down to 0 and then -1 and lower as strength gets smaller. (There’s really no reason for that, though. Since ST has to go negative anyway, I’m going to take the easy route of setting ST 0 as the human norm. Under this scheme, negative or positive levels of ST intuitively represent variation below or above the norm.)
A final note on the basics: there’s no theoretical upper limit to log ST, any more than there is for standard treatments of ST. I’ll just note again that no matter how bizarrely strong the planet-sized deity in question, its ST score will remain playably modest! But be aware that there’s no theoretical lower limit to log ST either; it too marches on to (negative) infinity, as the power level drops to the level of insects and then mites and then bacteria and onward down to some Planck ST, if you want to imagine such a thing.
Set whatever cost you like for log ST. Under plenty of systems, its cost might work fine as a flat N points per +/-1.
However, you may want to set a lower cost limit for weak ST. That is, decide that some point cost (-100 points or whatever works for your game) results in no ST (and makes the PC a ghost or floating brain or whatever has no strength). Low ST can’t net the PC more character points than that limit.
Using log ST in the game is dead simple. Use the ST score freely as a target number or dice modifier in rolls, use it in Contests, and so on.
But there’s also the question of handling ST-powered melee damage. HERO System connects the ST stat linearly to dice of damage (damage dice = ST/5), an approach that unfortunately doesn’t work too well (see this post again). I’d recommend something else.
Consider how you want ST-based damage to scale with the measurable aspect of strength (i.e., lifting power). When games bother to do this, they typically scale damage with some Z root of lifting power, which, using log ST, means you scale it with a neat ST/Z. The square root of lifting power (Z=2, meaning every four-fold difference in lifting power yields a two-fold difference in melee damage) works well in my opinion. Here are two ways to proceed, using that scheme:
1) Let damage scale directly with ST/2, and let damage itself be a log stat. That’s what I’m using for my home efforts – although details of “log damage” are a rich topic I won’t dive into here!
2) Let damage be a linear stat (so 2d damage is “twice” 1d damage, etc., as in most games), and use a table to pair ST scores with damage dice. So if (for example) +10 ST = x4 lift = x2 damage, then if ST 0 = 1d dam, then ST 10 = 2d dam, ST 20 = 4d dam, ST 30 = 8d dam, etc., while ST -10 = 1/2d dam, ST -20 = 1/4d dam, etc.
That scheme does require working out a table to pair ST scores with damage scores – but most RPGs use a ST damage table anyway, so there’s no extra work here as far as play is concerned.
Here’s what we’re dealing with:
- Multiplier = Scaling Factor ^ Score
That is, the multiplier of power (like x32) = your scaling factor (like 1.2 if each +1 ST adds 20% power, i.e., multiplies power by 1.2) ^ ST score (like 19).
Spinning that around:
- Score = log Scaling Factor (Multiplier)
If you want to derive Scaling Factor from a “+X ST = multiple Y” approach, then
- Scaling Factor = Y ^ (1/X)
Using my scheme in which +6 ST = x2 power:
- Scaling Factor = 2 ^ 1/6
- Multiplier = (2 ^ 1/6) ^ Score
So, where ST 0 is the human norm, ST -12 yields a power multiplier of (2 ^ 1/6) ^ -12 = 0.25, or one-fourth human norm.
Making a table
A spreadsheet is of course the sensible way to quickly generate a whole table pairing ST scores with power multiples. Don’t hesitate to round numbers. For example, under my scheme, ST 20 has a power multiple of about 10.079; I call that a clean 10. Meanwhile, ST 5 has a multiplier of about 1.78, and ST 25, a multiplier of about 17.9; I make those 1.8 and 18, respectively.
Remember, all the math above is “create the table” stuff that only the game designer has to deal, and then only once. it’s not the kind of thing that would ever come up in play! All you need to play is the completed table.
And with that, I close this foray into deepest nerddom. Any comments, problems, or suggestions?