Design notes: Implementing “log ST” in a game

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.  

The math

Here’s what we’re dealing with:

Basic formulae

  • 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)

Scaling Factor

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?


  • bwoods

    “I’m using +6 ST = x2 lifting power, which initially looks a little 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 +10 ST = x10 power.”

    Why not just use x10 per +20 (or x10 per +10) directly? It’s the same barest of rounding and it prevents extrapolations above or below the table from drifting away from their actual values.

    Also, if damage is a log stat in Project T, what about falling/collision damage? Gulliver collisions—as you know—are proportional to the square root of kinetic energy. How do yo plan on keeping the simplicity of d6/10mph?

    • tbone

      bwoods wrote:
      Why not just use x10 per +20 (or x10 per +10) directly? It’s the same barest of rounding and it prevents extrapolations above or below the table from drifting away from their actual values.

      Well, that is what I’m doing – I suppose I should say that I’m using x2 per +6 and x10 per +20, as they’re almost the same thing. You could specify either as the exact scale used, and the other as the one rounded a tad. Either way, it’s a rounding of less than 1%; the two are indeed pretty darn close. (And either way, there’s no problem of drifting away from actual values; no matter what the extremes of the table, the pairing that’s being rounded will always be less than 1% off from its “correct” valuation.)

      As for collision damage: The log-equivalent rule for “1d per 10mph” would simply be “Damage = Speed + X”, where Damage and Speed are log stats, and X is a normalizer. That does point out the obvious requirement that things like object speed be expressed as a log stat, which might sound scary – but it’s something games typically already do, for purposes of (for example) turning speed into a TH mod. So all we’re establishing here is that a car whose speed creates a -7 TH mod also gets a +7 Damage mod in collisions.

      • tbone

        A correction to my comment:

        bwoods noted that rounding weight multipliers in a “log ST” scheme (or more broadly, rounding value multipliers in a “log anything” scheme) will result in extreme values slowly drifting away from actual values.

        I had a clever reply to that: “Nuh-uh! No it won’t!”

        I was of course wrong (having that day failed a roll against Wake Up And Comprehend Math). Values will indeed drift off, just as popular rounded values for “number of bytes” increasingly drift away from actual numbers as we progress from kilobytes to megabytes to gigabytes and onward.

        Yes, rounding leads to drift. For example, in the “+6 = x2” scheme I reference, a +20 to stats isn’t quite the rounded x10 value that I use; it’s actually x10.07937 or so, a difference of about 0.8%. That much is easily ignored, but it does build up: at +100, say, my rounded value of 100,000 should in reality be just under 104,032. Now we’re up to a 4% difference between rounded value and reality!

        At what point does it matter, though? Using my progression, each +1 means an increase in value of about 12.2%, so a mere 4% discrepancy is literally what’s known as a rounding error. When does my rounding actually result in value that’s off by about 12%, or a solid ±1 stat? If I’m working the numbers correclly, it doesn’t happen until a stat of about +300! At that point, we’re talking about values in the quadrillion range. So that’s the level of inaccuracy I’ve created: when a PC tries to lift a quadrillion-kg weight, I’ll coddle him with a -300 penalty instead of the correct -301. : )

        In short: If the rounding is slight, rounding off multipliers in a log system need not be a practical concern – but the designer should check the actual degree of discrepancy to make sure it’s acceptable. Thanks, bwoods, for correctly pointing that out!

  • uE5Xg9p2

    Just to bring this up to date with current trends: The article “Knowing Your Own Strength” from Pyramid #3/83 — Alternate GURPS Ⅳ proposes that +10 ST provide ×10 BL. I find it particularly convenient, as the attribute numbers mesh well with the Basic Set sidebar “How to Select Basic Attributes”, plus it contains a quick-reference list of descriptions like “Half again as strong”.

    • tbone

      That progression does have a lot to recommend it. In my case, I suppose I used GURPS as an unconscious guideline, with the idea that the jump in lifting power for +1 ST should be similar to whatever GURPS was doing. Of course, +1 ST doesn’t boost lifting power by a set percentage in GURPS, but one could take the jump from ST 10 to ST 11 as the guideline to use.

      In 3e, that was of course a 10% jump in lifting power, which has a reasonable “feel” as not too big, not too small. My chosen progression of +20 ST = x10 lifting power, meanwhile, has lifting power jump about 12% for every +1 ST – pretty darn close to that 10%. So I liked it.

      But GURPS 4e is grainier with the jumps in lifting power: now, the jump in BL from ST 10 to ST 11 is 20% (21% if you don’t round). So if I still want to use GURPS as my guideline, perhaps I should go grainier as well. With a progression of +10 ST = x10 power . . . well, I don’t have the Pyramid article in front of me, but +1 ST should be about a 25% increase in lift.

      That’s grainier than I’ve had in mind all along. And I’m using my progression for everything, not just ST and lifting. So I don’t want to make a switch without a lot of thought, but I will give “+10 stat = x10 value” another look.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.