A visitor writes by email:

T.Bone:

Cool new site! Now on to the irritating part… 🙂 Once again, I’ve forgotten (or maybe never even learned) part of the power-to-mass argument. Please tell me which of the following is right:

( { power – weight } / mass ) ^ 0.5

( { power – weight } / mass ) ^ 0.5 * stride_length

( { power – weight } / mass ) ^ 0.5 * stride_length ^ 0.5

Everything here but stride length is based on E=mv^2, so at least that should be correct. I can see how stride length might play a role, but I can’t quite picture the geometry of it.

— MJ

Referring to how all these things come together into Move, correct?

Well, let me look review the way it works now in GULLIVER, followed by caveats. Not even sure that this will address the question fully, but it will let me wax faux-pedantic:

First, check this link for an overview:
http://www.gamesdiner.com/gurps/GULLIVER/B2mobility.htm#RulesBackgrnd

GULLIVER doesn’t work weight into any neat formula. I’ve tried, others have tried, and I haven’t seen a solution that works well.

Weight is handled as in GURPS: a mystery X factor that applies completely arbitrary Move Mods. In fact, for the range of encumbrance from None to collapse, GULLIVER incorporates the GURPS encumbrance rules as is.

Let’s toss aside tricky weight (but not non-tricky mass), to see how things work without it.

Stride length multiplies Move directly. The reasoning: All else being equal – i.e., the same stride geometry and frequency – a stride twice as long will carry you twice as far. That means you go twice as fast.

Move is also multiplied by Move Mod. Move Mod is based on the square root of Mass to ST Ratio (MSR) — specifically, sqrt (30/MSR). The effect can be read as a change in stride frequency and/or geometry caused by the power/mass factor.

(Why the square root? Because I say so, and because there’s a little scientific evidence to support it, and because so far no one’s shot it down. It looks nice, and I got nothing better.)

Boiling that down, using neatly-scaling critters:

Move scales with (power/mass)^0.5 x linear dimension.

and as power/mass is expected to scale with linear dimension^-1:

Move scales with (linear dimension^-1)^0.5 x linear dimension = linear dimension^0.5.

So, bigger size makes you faster, though the boost scales with only the square root of linear dimension.

Caveat 1: As discussed in GULLIVER, the “all else being equal” simplifying assumptions are a problem in all the above. The big creature should also be burdened by weight, which adds some arbitrary, weight-based, game encumbrance factor. (No telling what that factor is in real life.) Further, the large creature is likely to have some design tweaks that differentiate it from simply a scaled-up small creature. So it’s hard to predict what’s up with the big critters. But the above works fine as a general rule, up until big sizes where the design changes a lot.

Caveat 2: Here’s something not discussed in GULLIVER. The above probably contains a good-sized flaw, at least if you’re looking at a single stride from a stop.

Say a Giant uses the same stride geometry you do – that is, similarly proportioned legs, striding at the same angle as yours, achieving the same length relative to height.

Fine. But it doesn’t make sense to assume, as the above does, that stride frequency remains unchanged until power/mass factors come into play.

Given stride length X, and a set power/mass ratio, time to accelerate a leg to move distance X should scale with sqrt (X). That suggests:

Move (at the end of that stride) scales with (power/mass)^0.5 x linear dimension^0.5, which works out in the end to 1. Thus, Move at the end of the first stride is unaffected by size.

BUT, that’s the first stride. Once you’re up to speed… things work differently, and I can’t say how exactly. Running’s complex. In the end, both evidence and intuition suggest that the GULLIVER result of Move scaling with linear dimension^0.5 (before weight and design factors) makes sense – or at least, it’s good enough for game use!