Speed and Movement Distance in DS

From w.mfi
Jump to navigation Jump to search

I tested on PC (without using a controller). The PC only has a few set speeds, whereas the PS4 and PS5 have a variable-speed analog thumbstick. Still, the Sony probably uses the exact same mechanics and speed ranges (max speed, default speed, etc.). Why would they completely redesign something that works fine, eh?

I and other readers would be very interested to hear if the PS4&5 use the same default speeds as PC, if someone is willing to test it.

Overview of Speeds in Death Stranding

Speeds for Vehicles and Sam in kph

Usain Bolt's speed is from a 100m event on this Olympics page. It's not sustainable, but still, there it is.

Sam's speed:

  • Depends on load. The values shown above are for near-zero load. Near-max loads reduce speeds by about a third.
  • Roads slightly increase standard (Jog) speed (in any skel or none), and substantially increase Sprint speeds for all but the Speed Skeleton. (Apparently it's maxxed out.)
  • In Snow (not counting paths), the All-Terrain Skeleton is king. It goes the same 14.1 kph whether Sprinting or not (so Jog and save your battery – unless going uphill; use it to save your Stamina). The SS3 only Sprints at 12.5 and the PS3 or no skel Sprint at 8.3 kph. And everything besides ATS3 Jogs at 6.0 kph. Paths in the snow are more complex; see Snow.
  • These speeds are the same for a young Sam, and an old one (Chapter 15 after-game with all Bridges Star points 60+).
  • Having absolutely no Stamina left and even high Fatigue does not slow you down, but the game says it makes you to lose balance more. (I didn't test this; it would've been hard to do.)

Vehicles are pretty straight-forward, as shown. When their load increases:

  • Trucks maintain the speeds shown, but can't go as far. A fully-packed Bridges Truck can only go ~40% as far as one that's (near) empty.
    • This only depends on the truck's load; Sam weight doesn't matter. He's found a loophole!
  • When heavily loaded, bikes don't slow much if Boosted (60 kph only decreases to ~55 kph). But they slow tremendously if going Standard speed (40 decreases to 20 or less), especially if they hit any sort of hill. (But they do speed up going downhill.)
    • On a full battery, bikes only go about 63% as far if Boosted with a heavy load (530 kg) versus almost no load, and only 28% as far at Standard speed.
    • Whether empty or loaded, they still go farther at Standard speed. ~2.5 times as far with little or no load, but only ~10% farther with 530 kg. This big difference between Standard and Boost speed is because a heavy load really impacts Standard speed, but ultimately Standard speed still gets you the farthest because the battery lasts so much longer.
    • Unlike with trucks, Sam's load matters for bikes. He and the bike's loads are added together.
  • Being on road or off-road doesn't seem to affect vehicle speed or distance under ideal conditions (long level stretches with little or no terrain impediments). But in actual play, complex off-road navigation and terrain will in fact slow you down.

All vehicles and even Sam effectively have a "grace load" whose weight is ignored for speed calculations.

  • Sam can carry quite a bit before it affects his speed. Each skeleton type (or none) has its own distinct curve for this.
  • Both types of vehicles allow a relatively minor grace load (~100 kg for bikes, ~336 kg for trucks). It helps with bikes and Mule Trucks, but is a trifling amount for Bridges Trucks.

Sam's Speeds

Unlike vehicles on the PC, Sam has many options. The following values are while On Roads:

  • Sprint (with the Boost key, Shift): 32.3 kph with SS3, 27.0 kph otherwise (other skels or no skel).
  • Standard speed (moving without any modifying key): 15.5 kph. I call this Jog speed for lack of a better term. Type of skel doesn't matter.
  • Walk speed (Control key), which has an adjustable slider on PC (PS4 users just tilt their thumbstick). 6.9 to 15.5 kph; 9.0 at default setting of 30.
  • Crouch speed (C key), 12.1 kph. You read that right! When Crouching, he moves faster than Walking (at default Walk slider setting of 30).

Walk and Crouch are toggles that can be on at the same time. Crouch essentially reduces your speed by ~23%, whether also Walking or not.

Speed Skeleton

Only the Speed Skeleton affects Sam's speed, and only when he is Sprinting. In any other situation, skeletons (or lack thereof) have NO effect on Sam's speed. For example, he Sprints at 27.0 kph with an All-Terrain or Power skel, or no skel at all. At standard (Jog) speed, he goes 15.5 kph, regardless of skeleton (even Speed skel). Skeletons also don't affect Walk or Crouch speeds.

I have only tested the level 3 Speed Skeleton, not levels 1 or 2.

PC Walking Speed slider at System / Options / Controls (Keyboard & Mouse) / Walking Speed. Default is 30.

Walk and Crouch speeds

For Sam, Sprinting and Jogging are pretty straightforward. But Walk speed depends on a slider on the PC. It's also a toggle (Control key) that can be on while Crouching (C key). So of course your intrepid explorer tested it for you.

On the PC, the Walking Speed slider is at:

System / Options / Controls (Keyboard & Mouse) / Walking Speed

It can be set from 1 to 100, with a default of 30 (see inset).

Walking Speed slider versus Sam's Walk and Crouch Speeds

On Roads Off Road
+ 6.3
W+C as %
of W kph
W+C as %
of W kph
1 6.86 6.4 5.31 77.4% 6.78 5.28 77.7%
15 7.80 7.8
30 9.04 9.3 6.78 75.0% 8.68 6.57 75.8%
60 12.30 12.3 11.41 8.33 73.0%
90 15.45 15.3 13.76*
100 15.49 16.3 12.10 78.2% 14.54 12.12 83.3%
* The 13.76 kph value for Off Road Walk 90 is actually at Walk 88.

More details on Walk and Crouch speeds

Walk and Crouch while On Roads

This simple equation gives a good approximation of Walk speed (the dashed green line on the graph):

  Walk kph = 0.1 x Walk_slider  + 6.3

Here's a much more accurate equation using a third-order polynomial (the dotted blue "Poly. (Walk)" on the graph):

  Walk kph = -6.331x10-6x3 + 0.001109x2 + 0.04729x + 6.823

For what it's worth, the order number suggests the number of factors affecting the equation. Here, there could be three things affecting Walk speed. In the best of worlds they could be pulled out as separate factors. But since we have no idea what the other factors are (or what they're doing), we can't.

There's a cut-off at ~91 on the slider where Walk speed can't go above 15.5 kph, which is Sam's default speed without using any modifiers (walk, crouch, or sprint). Stated another way: You can't exploit a high Walk slider value to go faster than Sam's default.

In any event, who would set Walk so high that it equals standard speed? It effectively makes Walk cease to exist as a speed option. May as well set it to something slow so you can go slower when needed. On reddit, somebody even said they set it to 12 so they could enjoy the view sometimes.

That said, don't forget that Walking with the slider at 88 or lower means your boots last twice as long.

As shown by the C+W as % of Walk kph column, Crouch has an average value of 76.9% of Walk kph. (This is almost exactly 10/13, 76.92%.) Stated another way, Crouch always reduces your speed by ~23% (3/13), no matter what your Walk slider is set to, and even when you're not Walking. In other words, Crouch also reduces Sam's standard Jog speed by 23%, too.

Walk and Crouch while Off Road

Speeds are slightly lower than when On Roads, as expected given how Roads affect Sprint and Jog.

The average speed if Crouching while also Walking is 77.5%, very close to the 23% reduction seen when On Roads.

Furthermore, since you're going slower, you don't hit the cut-off at ~91% on the Walk slider (where it becomes equal to Jog speed when on roads); going over 90% still increases your Walk speed, when off road.

Some observations about working with Sam's different speeds

  • Sprint can't be combined with any of the other three (standard jog, walk, or crouch).
  • Crouch and Walk are both toggles and can both be on at once.
  • Sprint and Walk both give you the option to Toggle or Hold Down to use them, in the PC "Controls (Keyboard & Mouse)" options. Crouch doesn't; it's always a toggle.
  • Crouch gives clear feedback (you see Sam crouch). But you can easily tell if you're Walking by watching your speed while toggling it (Control key). This is true whether you're crouching or not.
    • Unless your Walk slider is set high, and causes little or no slowing.
  • Players instantly drop out of Sprint by doing any number of actions (stopping, Map, etc.). But Crouch and Walk persist if you stop.
    Of these two, Walk is more "sensitive"; the following lose Walk but not Crouch:
    • If you go into Inventory, whether by hitting "I" or Map / Cargo. (Other menu options under Map don't kill it, though.)
    • If you get on and off a vehicle.
  • All three states are dropped if you access a knot terminal or re-load a savegame that had them on.

If your Walk speed is near standard Jog speed, it's hard to tell if it's on. If you're uncertain, the simplest way to be sure is to just re-engage it: Pop into any menu for an instant. This is guaranteed to turn off Walk. Then turn it back on.


Things are really switched up in Snow. It's not just a simple modifier to Sam's speeds in other terrains. The skels themselves perform quite differently. That's why I didn't try to shoehorn all this into the Speed chart at the top of this page.

Look at these numbers:

Skel Snow (no path) Path in Snow
Sprint Jog Walk 88 Sprint Jog
ATS3 14.1 14.1 13.7 21.1 14.1
SS3 12.5 6.0 6.0 32.2 8.7
PS3 8.3 6.1 6.0 21.1 8.7
none 8.3 6.0 6.1 21.1 8.7
  • All values are kilometers per hour (kph). Bold is the fastest for that column.
  • Numbers in italics were not tested but are presumed to be this, consistent with how skels work everywhere else.
  • The values around 6 kph were only tested once; that's what I actually saw. I could've done more testing and/or artificially smoothed the values, but why bother. The Jog values are probably all the same; I'm calling it 6.0 kph. And Walk 88 is probably slightly lower than that.

I tested a snow path in the BT alley NW of Geologist (when BTs weren't there, and it had zero snowfall). This corridor has gusty winds over a third of its length. Wind resistance may have slowed me slightly, so the path speeds above may be slightly low. This path may not exist for you until you go this way a time or three.

The All-Terrain Skeleton is king in snow. It goes 14.0 kph in snow, whether Sprinting or Jogging. So save your batteries and stamina, and just Jog in an ATS.

  • Except when going up hill; /u/MisterCrowbar reports that it can really save your stamina when going uphill in virgin snow.

In other types of terrain except Snow, paths have the same speed as Off Road... they don't matter much except to show you the way. But in snow, paths make a real difference in travel speed versus untrammeled snow. You can tell you're in virgin snow because Sam walks very awkwardly there.

  • As you can see, the ATS is fastest in snow for every possibility except Sprinting on a path through snow, where the SS3 is fastest.
  • But most paths in the snow are pretty short.
  • So it's arguably easier to just switch from Jogging in normal snow to Sprinting on short snow paths in your ATS, instead of hassling with switching to a Speed Skel. Some paths will be downhill, where the SS is overkill anyway. Plus SS3s use 2.4 times as much energy, as well.

With Floating Carrier(s)

Floating Carriers (FCs) reduce your speed by one sixth (16.7%), pretty much regardless of other factors.

The following do NOT matter:

  • One or two FCs tethered together
  • Sam's speed (tested: Jogging, Sprinting with no skel, Sprinting with SS3)
  • Whether the FCs are empty or full only affects the "one sixth" very slightly (~1.3% slower when full versus empty).

Details on Floating Carriers and Sam's speed

Examples, all On Road (running circles around the DC N MKC; Sam himself only had 4.4 kg):

  • With two near-full FC1s (561.0 kg), SS3 Sprint speed is 26.9 kph. That's 17.0% less than Sam's no-load SS3 Sprint of 32.5 kph.
    • Same exact speed (26.9 kph) under same conditions with two almost-full FC2s (1,196.0 kg)
  • With empty FC1s or FC2s (0.0 kg), SS3 Sprint speed is 27.3 kph. That's 15.7% less than 32.5 kph.
  • With two two near-full FC1s, No-skel Sprint speed is 22.2 kph versus the usual 27.0 (18.0% less). (Not tested, but should be the same, for ATS3 and PS3, since they have the same 27.0 kph.)
  • With two near-full FC1s, Jog speed is 13.1 kph versus the usual 15.5 (15.7% less).

So they're not exactly 1/6th, but they're all real close.

Full FCs only reduce speed by 1.3% compared to empty (1 - 26.9/27.3), and it doesn't matter if it's 1 or 2 FCs.

You might've thought the inertial mass of two FCs would slow you down more than one, but I never found any difference. If there is one, it's super small... my FC speed tests were for 5 minutes a.k.a. 300 seconds, so it'd have to be less than a 1 in 300 difference.

I only tested on level ground, but on slopes, it's probably the same 1/6th of whatever your speed there is, too (given that no-load versus full-load speed is practically the same).

So Floating Carriers' effect on speed is simple: They slow you down by one sixth.

Compare the rate of Chiral Crystal use by FCs, which is also pretty simple.

Trudge Speed

When you are overloaded and can barely move, you've been Trudged.

The Max Stated Capacity at the bottom of your Inventory screen turns red when you're carrying more than you're rated for. This value reflects:

What it does not reflect is Bonus Chiral Capacity (BCC), equal to 1 kg for every 1k CXls, with a max of 50 kg for 50k CXls. However, you can see its effect reflected in the color of the centroid at Sam's feet.

Once you exceed your max capacity, you are Trudged. More details here.

When you are Trudged, you go 2.25 kph. It doesn't matter how much more weight you have (I tested up to 865 kg)... you move at the slow 2.25 Trudge speed, regardless. That's the max I could get on Sam without resorting to a lot of HD Special Alloys.

So as far as I can tell, Sam is never immobilized. He just gets trudged at 2.25 kph, and that's that.

You won't stumble or fall from turning; turn all you want. (But it's a wide turn; use the Compass to re-orient faster.)

Still, it's hard to imagine any situation where you'd rather trudge instead of just doing two or three trips without trudging. About the only time I ever trudge is when I impatiently exit a knot's interface with a huge load and trudge the tiny distance to my vehicle there, instead of re-juggling all my junk in inventory just to walk those few meters, shrug. Either way costs a handful of seconds.

The Power Skeleton

A special shout-out for this guy. The Power Skel:

This means it is uber stable if carrying heavy loads, even using Bonus Chiral Capacity to get right up under your Trudge Point. See my graph for Reduced Speed with Heavy Loads. You have to drop about halfway down the transition speed to start becoming unstable, but the Power Skel doesn't even reach halfway before you hit the Trudge point with it... it's real stable up to its (really big!) max capacity.

It's a beast for stability.

Zipline Speed

Not a whole lot to say here. But I'll still write tons, laugh.

Speed Measured

I did 28 tests with a stopwatch and got:

  54.88 ± 0.90 kph (standard deviation of the sample)

This included tests when:

  • Carrying almost nothing, or being way over trudged (537.5 kg)
  • Going on level lines, going up steep inclines, coming back down them
  • The acid test of going up versus coming down steep inclines, completely trudged. Only differed by ±0.6%, well within measurement error.

Always the same, within margin of error.

I'm making an executive decision and calling zipline speed 55.0 kph. It's well within one Z score of 54.88 ± 0.90. Most everything else in the game uses nice simple numbers under the hood, so why not this, too.

Handling the elevation discrepancy of zipline traverse graphs

The "steep incline" mentioned above was down the spine of the cliff face between Spiritualist and Craftsman. Coords while hanging on it were: top zipline +167.71 +1114.51, bottom zipline +322.30, +1151.37.

To get the slope using the traverse graph:

From the top zipline I measured looking downward and the traverse graph showed elevations of: high point 591, low point 418, delta 173m. Then I double-checked from the bottom one looking upward and got: high 591, low 408, delta 183m. That's a 10m difference (183-173) when looking down versus up, hmm.

A week later (real time) I checked it again and got: From top looking down: high 595, low 418, delta 177m. And from bottom looking up: high 592, low 406, delta 186m. Almost 10m (186-177), again.

A level zipline along the west side of Central's Incinerator

So I studied it at a very level place - with ziplines near the NW and SW corners of the Central Incinerator.

The ground was quite level here and showed elevation of 216 (occasionally 217) with markers placed on the sidewalk at these corners. If I got on either zipline and viewed the traverse graph to the other, they both showed the same thing: distance 208m, elevation high 221, low 216 (Δ 5), up 1, down 5. The dot chart traverse looked completely level.

By looking closer (you can use Zoom (T) on the zipline) and playing with Compass markers I put down, I figured out what's happening.

The game considers you to be ~5m up on your zipline, and it measures the other one at its base (where the zipline structure meets the ground). Let's do a little thought experiment:

  • Say you have two ziplines, with one exactly 100m higher than the other (measuring them both where they meet the ground).
  • When you are on the higher zipline, it's all downhill. You are 5m up on the line, plus there's 100m more descent which stops at the base of the lower zipline. The total elevation delta is 105m (100+5).
  • But on the lower zipline looking up, it works the other way. Yes, the zipline you're on is 5m off the ground. But that's 5m down, then 100m up is added to that. 100 - 5 = 95m.
  • The apparent difference between the two readings (105 versus 95) is ~10m. Just like I got.

So the net result is:

  • If you are on the lower zipline, add 5 to the elevation difference.
  • If you're on the higher one, subtract 5 from the elevation difference.
  • Or if you want, get the difference from both ends (high and low) and average them, like I could have done above. Should be about 10, but I've seen 9 before. Apparently there's a little variation, and maybe it's not exactly 5 anyway (but the game doesn't show decimals). There are definitely rounding discrepancies possible with containers that are not full (see Inventory choices for pinpointing fine weight differences). So who knows where else they happen.
  • But be careful if they're pretty much level, lol (like in my Incinerator example). I guess the other zipline has to be at least 5m higher than the base of your current one.

Anyway, you get the gist.

Of course, any time you use the traverse graph to get a slope angle, make sure there isn't anything lower than the low-end zipline's base. (We already know there won't be anything higher than the high-end zipline's base, or it'd block the zipline.)

For more, see Measuring Slopes Angles with the Traverse Graph.

How I Measured

For most other testing, I sing the praises of using Order Time and Order Distance.

But you can't do that with ziplines, because you can't bring up Map Info (to look at Orders) when hanging off of a line.

The good news is that the game shows you the distance to your target zipline structure. That's half of what you need right there. (I love how this game bursts with details.)

But they're all very short trips; even the longest (350m) is only ~23 seconds max. (350m would be 22.91 s at exactly 55 kph, a.k.a. 15.28 m/s.)

If you tried using order time and distance, you'd have to account for the time to mount and dismount the line. Not only would this add lots of seconds, but oddly, it adds a non-trivial amount of distance (see next section).

So this is one of the few places I think stopwatches (alone) are justified.

That said, stopwatches inevitably introduce some error. Not only is there a slight fraction of a second at both start and stop when you have to coordinate the stopwatch. But also, you can clearly see a moment (a pause?) when Sam first starts to move on a zipline, after you tell him to.

I don't know for sure if this tiny little pause takes a little time away (a.k.a. momentarily reduced speed), but it's certainly possible. It simply depends on exactly how they did it.

Maybe it would help to video capture it, but I don't want to go to all that trouble. Video capture did not help with generator charge times.

Weird Thing about Ziplines

If you've tried doing precise measures on ziplines with Order Time and Order Distance (which I don't recommend, for once), you notice a few oddities.

One is that they add a non-trivial amount of time due to mounting and dismounting. (Because you can't read Order info when hanging off of a line, you have to get an Order reading on the ground before getting on it. Then mount it, zip along it, then dismount, and finally take another reading.)

A single standalone mount/dismount cycle adds 5 or 6 seconds of Order Time (average 5.33, N=6). This is without zipping anywhere; just mount and dismount a particular one as quick as you can.

Another oddity is that if you try multiple mount/dismount cycles in a row to get a total delta time and distance over, say, 10 cycles, you find another problem: After a zipline lowers you down, it takes a couple of seconds to raise back up to its ready position. During this time, you can't get on it again. Ten cycles took me ~67 seconds in total (using Order Time), or 6.7 s per cycle. The extra (vs. 5.33 seconds when doing one cycle at a time) is due to waiting for the structure to right itself so you can get on again. (You also have to turn around, but can usually do that within the second or two it's righting itself.)

But the oddest thing by far is that one up/down cycle increases Order Distance by at least 18 meters (59 feet). That's just for one cycle. Think about it; that's a pretty big number just for getting on and off a zipline.

Given how the zipline works, it looks like you're swinging along an arc. Like a quarter of a circle, if the zipline goes from straight up horizontal, to straight over horizontal (90° out from the bottom of the zipline's U-shaped holder).

If a full cycle is at least 9 meters, and that's a quarter of a circle, then the full circle is 36 m. If 2πr = 36, then r = 5.73 m (18.9 feet). So presumably ziplines raise you 5 or 6 m above ground level, if you get on when it's at a right-angle to its base. (It's entirely possible to get on at higher or lower angles, depending on nearby terrain. In fact, it's probably usually not at 90°.)

That's kind of high! If Sam is ~1.8m, the thing looks much more than three times his height. (Not counting his arm when he's hanging off of the zipline.)

Anyway, there it is. I'm not sure what to make of Order Distance when you use a zipline. So I guess I don't trust it for measuring that. And I'll stick to the stopwatch and the distance to your target zipline, when testing zipline speed.

Speed, Batteries, and Distance for Vehicles

This is pretty complex info since it depends on type of vehicle, battery size, and load. Let's break it down.

I'll be talking about run time a.k.a. battery run-out times; the time to use up a battery's charge.

Sam Run Times and Distances

Max Speeds versus Loads Table

Let's flesh out a little table from my Batteries page. An SBU is a Sam Battery Unit. You get 2,400 SBUs by adding two level 3 batteries; this is just a nice round number for illustration purposes.

This table is for Sam off road:

Skeleton SBUs/
Light Load Heavy Load Heavy
/ Light
1,000 SBUs (Sam's standard battery)
ATS3 or PS3 2.50 6:40 400 5.92 21.3 2,367 4.14 14.9 1,656 70%
SS3 6.00 2:47 167 9.00 32.4 1,500 5.75 20.7 958 64%
2,400 SBUs (2.4 times the rows above)
ATS3 or PS3 2.50 16:00 960 5.92 21.3 5,680 4.14 14.9 3,973 70%
SS3 6.00 6:40 400 9.00 32.4 3,600 5.75 20.7 2,300 64%
Light Load is below and Heavy Load is above the transition shown in the next section.

I'm not showing data when on roads because you can run forever with roads' energy grid. You'll go a little faster (as shown in the speed graph at the top of this page), but there's nothing else to show.

Also, Sam can run off-road forever at 21.3 kph without a skeleton. This is true for a newbie Sam fresh out of Cap KC, or a grizzled vet in the Chapter-15 aftergame. However, the load you can bear, and how well you can handle it, increases as Sam levels (see next section).

Although the Speed Skel uses energy 2.4 times as fast (6/2.5), Sam can go over half as far in it versus the other skels (63% as far; 1500/2367). Its greatly increased speed (32.4/21.3 = +52%) somewhat compensates for its high energy consumption.

After you're weighed down past your configuration's speed-transition (see next section), you'll go 70% slower and 70% as far in an ATS3 or PS3, and 64% as much in an SS3. It applies to both speed and distance equally because the amount of time it takes the battery to run out is fixed, whether with a light load at high speed or heavy load at lower speed.

Reduced Speed with Heavy Loads

Death Stranding - Sam Skel and Load vs Speed when Sprinting Off-Road v1.png

Most of these data points are one instance of Sprinting 5 or more minutes, using Order time and distance. The slight bits of bouncing around are from the actual data. It would've taken multiple trials at each point to pin them all down better, but you don't need it to get the main gist.

As you can see, each skeleton is unique in its profile. All are for a maximized Sam (in Chapter 15 aftergame, baseline 130) except for Young Sam with Delivery Volume 10 (baseline 80.4).

  • Stability doesn't become an issue until you get to the lower half of the descender in each curve.
    • For example, an SS3 won't give you balance problems at all up to ~190 kg. They start kicking in at ~205 kg, and are severe by 220 kg.
  • Up to a certain point, your speed is maximal and there are zero stability problems.
  • Then there is a linear decrease in speed and stability...
  • ... Until you reach a level of minimal speed and maximal instability. You won't go any slower and will be very unstable at this point.

The slope of the transition "descender" varies a lot, with the Speed Skeleton the most peculiar one. You can Sprint just fine until 40 kg below the stated max capacity of 230 kg, then you quickly lose speed and balance going from 190 to 220 kg. From 220 to 280 kg (this is the 230 stated max plus the additional 50 kg Bonus Chiral Capacity), you're hindered like this.

Value Young
No Skel
No Skel
Baseline (kg) 80.4 130.0 130.0 130.0 210.0
Max Stated Cap (MSC) 125.0 150.0 230.0 270.0 330.0
MSC + Bonus Chiral Capacity 125.4 200.0 280.0 320.0 380.0
Speed before Transition (kph) 21.3 21.3 32.4 21.3 21.3
Transition Start (kg) 20 80 190 130 210
Transition Middle (kg) 42.5 110 205 195 295
Transition End (kg) 65 140 220 260 380
Speed after Transition (kph) 14.9 14.9 20.7 14.9 18.6
Transition End - Start (kg) 45 60 30 130 170
Speed End - Start (kph) 6.4 6.4 11.7 6.4 2.7
End - Start (kg/kph) (slope) 7.03 9.38 2.56 20.3 63.0
  • The Power Skeleton hits its Trudge Point at 380 kg, and thus can't be measured any farther. I underlined values affected by this cut-off. A rough projection shows it ending around 600 kg if we presume the final speed is 14.9 kph, as for the other non-SS3 configurations. The slope is probably fine because we have some slope to work with there.

The last slope row shows how quickly the transition occurs. It's the number of kgs of load that reduce you by 1 kph. Higher is better; if it takes more kgs to reduce your speed, you'll be faster (and more stable) over a wider range.

For example, Young Sam's transition takes 45 kg (20 to 65 kg of load), and his speed goes down by 6.4 kph (21.3 - 14.9). In this interval, his speed reduces by 1 kph for every 7 kg (45 kg / 6.4 kph = 7.03 kg/kph).

Conversely, a high-level Sam's transition is 60 kg wide (80 to 140), and reduces by 1 kph for every 9.4 kg (60 / 6.4). He can carry much more before being affected, and his speed declines less rapidly once it is affected.

As Sam levels, the start of the transition rises from 20 kg to 80 kg. It's 60 kg higher in the end game than in the beginning. Anything easily divisible by 6 should ring a bell for DS vets: You get increases to skills for every 10 Bridges Star (Porter Grade) points, up until they reach 60. I wouldn't be surprised if one of them affects this, but I haven't tested it. Probably Cargo Capacity, which is said to increase balance.

Sam's run-time for a battery is always what's shown in Max Speeds versus Loads Table. So if you want to see how far you can get with a heavy load, use the speed from the Heavy Loads info, and combine it with the run-time for your battery. Example:

  • Sam Sprinting Off Road in a Speed Skel 3, 225 kg load, and 2,000 SBUs.
  • This load is above the end of the SS3's transition (220 kg), so you'll be going 20.7 kph. That's 5.75 m/s. (Divide kph by 3.6 for m/s.)
  • With 2,000 SBUs, he can Sprint for twice as long as shown above. 166.67 s x 2 = 333.33 s or 5:33.
  • In 333⅓ s at 5.75 m/s, he can go 1,917 meters.

The battery run-out times are so reliable that I could use them as double-checks that I got my data right. It would always result in 2:47 with SS3 or 6:40 with ATS3 or PS3, if I converted the SBUs used over the trial to 1,000 SBUs.

In fact, I could even tell how much I stumbled, based on it... if I was heavily overloaded and stumbled a bunch of times, each act of stumbling would increase my run-out time by about half a second. Apparently, the game momentarily doesn't consider you to be Sprinting, so you momentarily don't use the battery each time you stumble... so you gain a tiny amount of Sprint time for every stumble. (This is stumbling without actually falling; it's when you go from teeter-tottering to running forward a little out of control.)

Vehicle Run Times Under Load

Speeds in DS with little or no load

With little or no load, vehicles do not have any slowdown (see graph at top of this page, also in inset to right). A few notes on this:

  • Vehicles have an initial small "grace load" that doesn't affect their speed. It's ~100 kg for bikes, and ~336 kg for trucks.
    • This doesn't really help Bridges Trucks, which can carry 3,360 kg (stuffed with 28 XL4 Special Alloys) and undoubtedly much more.
    • But it helps a little with Mule Trucks, and helps a lot with Trikes.
    • I found at least one small variant to the grace load in what I tested (namely, for the BT3 at Boost, it's ~420 kg).
  • Remember that trucks don't reduce speed when weighed down, it just makes their battery run out faster. Only bikes and Sam go slower with heavier loads.
    • This is a real plus for trucks when you use roads' energy grid. They won't lose energy or slow down.
    • A heavily-loaded bike won't lose power on a road, but it will still go slower. ESPECIALLY if it's not at Boost speed.

Okay, let's get to the meat.

Run Time under Increasing Load

Vehicle Loads vs Battery Run Times, unadjusted

To the right is a graph of how long vehicle batteries last at standard or boost speed, under load:

  • They all have a very similar curve shaped like a spoon or dipper.
  • The "handle" of the spoon (with very low kilograms) is the grace load. Vehicle speed does not decrease from 0 kg up to ~100 for bikes and ~336 for trucks (420 for BT3 when Boosted).
  • Boosting uses batteries four times as fast, as discussed in Batteries. So, e.g., the BT3's battery at Standard speed lasts 15:00, but with Boost, just 3:45.

Normalizing all the curves together – For the curious

I put this in a collapsible because it's only supporting info for those of curious mind: You can normalize all the load and speed curves together with about four adjustments.

Vehicle Loads vs Battery Run Times, normalized to Bridges Truck Lv.3 (BT3) at Standard Speed

The second inset of Battery Run Times vs Load normalized all the data together:

  • All vehicles had their curves normalized to be the same as the BT3 at standard speed. It's an arbitrary but good choice because it has the largest battery, which gives it the widest breadth (and thus shows the curve the clearest). Also, I had a lot of data for it (which is also why I chose it for modelling).
    • It's the most sensitive because it had the longest trial times (good!) but of course that means it took a ton of time to test (bad!).
  • All vehicles at Boost speed had their run-times multiplied by four, because Boost uses batteries four times as fast. It normalizes them to the time they run out at Standard speed.

Here's how it's done:

Normalizing Boost

Pretty simple. If a vehicle is at Boost speed, its battery runs out four times as fast. So multiply the battery run-out time at Boost by 4 to align it with Standard speed.

Except that bikes need 3.8, not 4.0.

Normalizing vehicles within type (truck and bike)

This part takes info right from the Battery Results table to normalize each vehicle's battery size to the target one we're normalizing everything to.

For trucks, we're normalizing to Bridges Truck Long-range Lv. 3 (BT3). So:

  • The first Bridges Truck (BT0) is multiplied by 2 because its battery is half as big as the BT3's.
  • The Mule Truck was multiplied by 4. It's battery is half as big as BT0's.

For bikes, I only got data on the first Reverse Trike (RT0) and the RT Ride. The Ride's battery is 50% bigger than RT0's, so it has to be divided by 1.5 to normalize it to RT0.

Normalizing bike times to trucks

Trucks don't need this because the target (BT3) already is a truck. But all bikes need it.

Once a given bike's data is converted to RT0 (in preceding section), now multiply values by 1.875. This is from:

  • Times 0.9 to account for how bikes are lighter than trucks. To make them equal (normalize them to trucks), you have to scale bikes down a little.
  • Times 2 to go from BT0 to BT3. (The 0.9 converts the basic RT0 bike to the basic BT0 truck, then you need 2 more to go from BT0 to BT3.)
  • Times 1.0465. This is a fudge factor that simply seems necessary based on the fact that when you normalize Boost (if needed) and you use the 1.8 above (2/0.9), the no-load bike times actually get to 14:20 (860 seconds), not 15:00 (900s) as expected for trucks.
    • 1.0465 = 900/860 = 45/43. If I don't use this, all the bike curves are a little lower than all the truck curves.
    • I can't explain it... I guess it's just an internal factor accounting for some difference between the two types of vehicles. But whatever it is, it's real, and this is its value.
  • Okay I lied a little. 0.9 × 2 × 45/43 actually equals ~1.884, not 1.875. But 1.875 simply makes the bike curves overlay the truck curves more snugly.
    • In case it's not obvious, I have no damned idea what's actually going on under the hood. I haven't dissected the code nor has anybody told me secrets (not counting posts in the DS /sr, where helpful players sometimes point out things I missed). All I can do is my trials. Apart from a few real obvious things like the Trudge point signs and the super-tight boot-wear stairsteps, all I can do is write down the data I collect, warts and all, and try to make sense of it.
Normalizing bike loads to trucks

When you transform the data with the steps above, all the bike data is properly aligned along the time axis – they're all pegged at ~15 minutes with no load – but as loads increase, the curve for bikes is lower than the one for trucks. It descends at 100 kg (which is not the truck grace point of 336, of course) and even if you simply add 236 to all bike loads, it's still not right... although all the bike curves then start dropping at 336, they still hang below trucks' curves like a stubby little branch. (It's shorter because bikes can't carry nearly as much as trucks.)

Upon examination, it only makes sense that there has to be an adjustment to normalize bike loads to truck loads. If bikes' grace load is ~100 kg and trucks' is ~336, of course it has to be propped up somehow.

By playing with the data, I found this transform for bike loads:

  ( Bike_Load + 125 ) × 1.5  =  Truck_load_equivalent

Two things:

  • Bikes' grace load is ~100 while trucks' is ~336. By adding 125 to the bike load and multiplying by 1.5, you transform a bike load of 100 to 337.5. (The measured 100 plus the added 125 equals 225, which then equals 337.5 when multiplied by 1.5. It's a little over trucks' 336, but 125 is a simpler value and actually looks a little better when graphed.)
Okay, simple enough. Now bikes' grace load is normalized to trucks', a.k.a. the handle of the spoon.
  • Very interestingly, there's direct and arguably independent support for multiplying by 1.5. Over where I compare batteries between bikes and trucks, I already found that truck batteries are 50% larger. In fact, I wrote that up weeks before this section and wasn't even thinking of it as I tinkered with the spoon curves and tried to get them to mesh. But it makes perfect sense when I remembered it: If we're going to lay bike curves right over truck curves, we need to normalize to trucks' bigger batteries.

Another way to state the reason bike loads need a +50% normalization is that trucks (with a 50% larger battery) can carry that much more of a load in a given amount of time. A.k.a. the absolute amount of battery charge used over time.

In summary: Bike data has to be normalized for both time and load.


Mule Truck at Standard Speed:

  • Super simple. Just multiply run-out time by 4.
    • Equals 2 to go from Mule to BT0, and 2 to go from BT0 to BT3.
  • No adjustment to the load is needed because it's a truck already.
  • I didn't get Boost data for the truck because the times are so short that they'd amplify tiny fluctuations in data if multiplied by yet another 4 for Boost. The Mule is just 59 seconds with no load, and 47 seconds with 720 kg!

Notice how the curve for the Mule Truck at Standard speed is right on top of the BT3 at Boost, without normalization. This is exactly what we expect:

  • Mule at Boost is 4 times less than BT3 at Standard, as explained above and by its relative battery size.
  • BT3 at Boost is 4 times less than BT3 at Standard, as has also been explained.
  • So if you have a Mule at Standard (3:45 of run-time) and a BT3 at Boost (also 3:45), the 4x multipliers cancel out and they lay right on top of each other.
    • Of course, the practical difference is that, in 3:45, the BT can carry far more and go 43% farther (50 kph for BT at Boost vs. 35 kph for Mule at Standard).

RT Ride while Boosted:

For the RT Ride carrying 126.0 kgs while Boosted, trial run-out time 3:05 (185s):

  • Times 3.8 to go from Boost to Standard Speed, for bikes
  • Divide by 1.5 to go from the RT Ride to RT0 battery size
  • Multiply by 1.875 to go from RT0 to BT3 equivalent
   185 seconds × 3.8 / 1.5 × 1.875  =  185 × 4.750  =  879 seconds (14:39)
  • The bike grace load is ~100 kg, and 126 kg is just above this. Compare how an empty Ride bike (up to 100 kgs) runs out of juice in 3:08 when Boosted. At 126 kg, it ran out slightly sooner (3:05).
  • Normalize the load with:
   Normed_Load  =  1.5 × (Original_Load + 125)  =  1.5 × (126 + 125)  =  1.5 × 251  =  376.5 kg
This is slightly over the BT3 grace point of 336 kg – just like 126 kg is slightly over bikes' grace point of ~100 kg.
  • For comparison, an empty BT3 at standard speed (up to 336 kg) runs out in 15:00.
  • By normalizing the Ride result to a BT3, we wound up with about the same number (14:39) as we would've gotten with a BT3 at standard speed with slightly more than the grace load (something a little less than 15:00).

FWIW, sure I could've made a conversion table for you. (Actually a matrix, I guess.) But why bother. I showed you how to do it. Meanwhile, 1) I don't know what vehicle you'd want to convert everything else to, and 2) I'll be surprised if almost anyone gets this deep into caring or testing, laugh.

Both of the people that do can make their own look-up table, smile.

Exceptions in the Data

All the normalizations we have done so far have caused there to be relatively pretty overlays of different vehicles' data. However, at least some, and maybe many, vehicles have specific idiosyncrasies that would require you to perform lots of trials on each vehicle to pin down.

Cases in point:

  • I tested the BT3 extensively at Standard and Boost speed. It has the largest battery of all vehicles, longest run times, and thus the most precise trial data. I found that its grace load is ~336 kg at Standard speed, but 420 kg at Boost. It seems real and reproducible – the grace load really is slightly different for the exact same truck, at the two different speeds.
  • The basic Bridges Truck (BT0) seems to have a grace load of 360 kg for both Standard and Boost speed speed. Something like that.
  • Conversely, both RT0 and RT Ride seem to have a grace load right around 100 kg. Maybe slightly higher for RT0 at Boost (120?).

I wouldn't be surprised if other vehicles had their own wrinkles – but I also wouldn't be surprised if they didn't.

Getting all the data that I already have took tons of time. As of this writing (10/26/21), I have a summary table of 114 datapoints totaling 732 minutes, and I did many more trials past that. (It's a summary table because I did many duplicates to pin down important results and/or ensure results were replicable, plus I tested some other variables only to find they didn't affect results.)

Even past all the duplicated trials, I didn't put all of my unique trials in the graph because I only got a handful of data points on some vehicles like RT and BT Defensive, just to confirm that they didn't have some crazy, completely unexpected values. (If you never test even one place on their curve, you'd never know if they were surprisingly different from other vehicles.) But these other vehicles were fine, with the same low-load run time and therefore probably same characteristics as more-representative and/or more-precise (larger battery) models, etc. (I did at least one and usually several trials on every single unique vehicle.)

If you wanted to make complete load curves for every vehicle at both speeds with, say, ten datapoints each, you would have to do so much more work than I've done already. There are 11 unique vehicles (6 trucks, 5 bikes) times two speeds is 22 curves. I've done seven of them (BT0, BT3, and RT Ride at Standard and Boost, and RT0 at Standard), leaving 15. Times 10 data points for different loads is 150, plus some more for goofed/interrupted/failed tests, plus a bit of duplication for unexpected/suspect/confirmation retesting is ~200 more trials.

And you'd have done all this just to detect any idiosyncrasies between them.

Meanwhile, I'm sure the basic graph (and ideas) I've illustrated would still be almost exactly the same. You will mostly only have added to the wrinkles (slight differences for particular vehicles).

So... hey. You're welcome to do more testing if you want. I've shown you the way. 😃 😨 😖

Modelling the Load versus Time Curve
Modeled BT3 Standard-speed Load vs Time curve
Using only the BT3 at Standard Speed, and excluding the grace-load values (so they don't mess with curve fitting), I can get a logarithmic fit with a correlation coefficient of 0.99910, which is pretty damn good.
Time (in decimal minutes)  =  -4.404 × ln(Load) + 40.75

Example: Time for a load of 3,360 kg (the max with 28 Special Alloy XL4s):

Time  =  -4.404 × ln(3360) + 40.75  =  4.995 (4:59.70 or ~5:00)

Versus an actual trial value of 5:02, which probably includes 2 seconds of interface lag.

It will give values above 15 minutes for loads less than 336 (actually, the equation returns 346.46 for 15:00); just remember that in reality (in the game), results are pegged at 15:00. The BT3 can't run for longer than that.

Here's the reverse, converting Run Time to Load:

Load (kg)  =  e^( (Time - 40.75 ) / -4.404 )   Time in decimal minutes

Example: Load for a Run Time of 7:30 (half the max of 15:00); note the decimal for time:

Load  =  e^( (7.5 - 40.75) / -4.404 )  =  e^( -33.25 / -4.404 )  =  e^( +7.551)  =  1,920.4 kg

This is 56.6% of a max load of 3,360 kg (28 S.A. XL4s).

Okay, let's go nuts with the equation. The following results can't be expected to be right since they're off the edge of the modeled data; reality is sure to be a little higher or lower. Still, we can see what it says.

If you could go below the grace point:

Load (kg)  Time (m:s)
  200.0     17:25
  100.0     20:28
   50.0     23:31
   10.0     30:37
    5.0     33:40
    1.0     40:45

As it approaches zero, it approximates that constant of 40.75 (40:45) in the first equation. What a difference the last 50 kgs make! In fact, 102.2 kg is the "half-way" point of 20:22 (the max time divided by two).

If you had much heavier loads than the 3,360 kg I've tested, which ran out in 5:02:

 Load (kg)  Time (m:s)
  4,000.0      4:13
  5,000.0      3:14
  7,000.0      1:45
  8,000.0      1:10
  9,000.0      0:39.4
 10,000.0      0:11.5

If you could fill a BT3 with 84 HD Special Alloys, it'd weigh 4,032 kg (20% more than 3,360) and the model says it would take 4:12 to run out.

At the high end, the equation hits a wall just above 10k kg. The battery would run out in exactly 1 second at 10,406 kg, and in a tenth of a second at 10,441 kg. The Load equation is approaching the point where Time is zero and it becomes e raised to -40.75/-4.404 = +9.254. At this point, e9.254 = 10,445.6 kg.

Vehicle Run Times and Distance Under Load

For Trucks

Pretty straightforward because, for trucks, having a heavier load doesn't slow you down. It only reduces your run time (battery run-out time) which directly equates to distance, because the speed of trucks doesn't change based on load.

Times shown below are for a Bridges Truck Long-Range Lv. 3 (BT3). All Bridges Truck have:

Standard speed: 40.0 kph (11.11 m/s)       Boost speed: 50.0 kph (13.89 m/s)
Mule Trucks go 35.0 kph at Standard speed and 45.0 kph at Boost.

% of
kg load
% of
Standard speed Boost speed Notes
0 0.0% 100.0% 15:00 10,000 03:45 3,125
336 10.0% 100.0% 15:00 10,000 03:45 3,125 Grace point (same as no load)
672 20.0% 80.6% 12:05 8,055 03:01 2,517
1,008 30.0% 68.6% 10:18 6,865 02:34 2,145
1,344 40.0% 60.2% 09:02 6,020 02:15 1,881
1,680 50.0% 53.6% 08:03 5,365 02:01 1,677 Half max load (14 S.A. XL4s)
2,016 60.0% 48.3% 07:15 4,830 01:49 1,509
2,352 70.0% 43.8% 06:34 4,377 01:38 1,368
2,688 80.0% 39.9% 05:59 3,985 01:30 1,245
3,024 90.0% 36.4% 05:28 3,639 01:22 1,137
3,360 100.0% 33.3% 05:00 3,330 01:15 1,041 Max load (28 S.A. XL4s)
3,696 110.0% 30.5% 04:35 3,050 01:09 953
4,032 120.0% 27.9% 04:12 2,795 01:03 873 Max load (84 HD S.A.)
An "S.A. XL4" is the 120-kg Special Alloy XL4 and the HD S.A. is the 48.0-kg Medium-size High-density Special Alloy, which is 20% more dense than the S.A. XL4.
This table uses the equation from Modelling the Load versus Time Curve. The equation is not 100% perfect, of course, but it's pretty damn close (correlation coefficient 0.99910).

Boost speed is 25% faster (50/40 kph) but uses batteries four times as fast. As a result, trucks go 3.2 (4/1.25) times farther at Standard speed than at Boost speed.

You can easily relate this to other trucks using the Compare column of the Battery Run Time Table. Divide the other truck's Compare value by 2 (for the BT3). For example, the BT0 lasts half as long (1/2). Or just use the Standard and Boost time columns in that table.

The same applies to distance. For example, the BT0 can go half as far as the BT3 for a given number of kgs load.

For Bikes

Trike Loads vs Time, Speed, and Distance

Bikes' performance curves are much messier. Their battery run times can be normalized to trucks' (good), but their speed (and distance travelled) falls off as their load increases, unlike for trucks (messy). IOW their run-times look like trucks' under load, but not their speed or distance graphs. This is why I've kept things simple up to this point and only talked about bikes' run times – until now.

When they're at Boost speed, bikes' speed, run-time, and distance only gently decreases as the load increases. Ultimately they go from 60 kph with little load to only 50 kph at ridiculously overloaded amounts for a bike (~800 kg). In the inset, see the dashed lines at the top of the second panel (speed) and bottom of third panel (distance). When Boosted, the RT0 can go ~2 km with little weight, and ~1 km when heavily loaded, on a full battery. (Both the speed and the battery time are a little less; together, it amounts to half as far.)

But we see a very different behavior at Standard speed:

  • Speed and distance stay maximal up to the grace point, 100 kg (Step 0).
  • From Step 0 to Step 1 is a smooth linear decline in speed and distance.
  • At Step 1 (200 kg), there is a dis-continuous, drastic drop-off in speed and distance:
    • Just above Step 1 (200.0 kg), the RT0 runs for 7:16 at speed 38.4 kph, going 4,729 m.
    • Right after it (200.2 kg), it actually runs a little longer at 7:32 (see Note 1), but speed has dropped to 23.7 kph, and the distance is only 2,917 m.
    • Suddenly it only goes 62% as far (2917/4729) when the load only changed by 0.2 kg! (Just 0.1% of 200.)
  • From Step 1 to 2, speed and distance declines smoothly again.
  • At Step 2, there's another drop, but not as severe as with Step 1:
    • Before the drop (450.0 kg), the RT0 takes 6:01 moseying along at 22.1 kph, going 2,213 meters.
    • After the step (450.2 kg), it still runs for 6:01, but at 16.9 kph, going 1,693 m.
    • That's only 77% as far (1693/2213) with just 0.2 kg more.
  • Above Step 2, I didn't test a lot of points higher than 450 kg. If there are more steps, they're pretty small. Maybe there's another little drop around 600 kg? (look at the middle graph)
  • At the highest load possible without HD Special Alloys – 865.5 kg – the RT0 at Standard speed lasts for 4:42 and crawls at 11.4 kph, only going 891 m. Somewhere around 12 kph it becomes obstinate and even the slightest attempt to turn causes it to practically stop for an instant (at least with the PC's stiff steering).

By the way, in case it's not clear: The middle panel shows two pairs of curves practically super-imposed: The two Standard speed and the two Boost speed curves. That's no mistake. What's happening here is that the speeds are the same for the two different types of bike (the RT0 and RT Ride). All bikes go the same speed, eh? But the RT Ride has a 50% larger battery so it lasts 50% longer (top graph) and goes 50% farther (bottom graph).

Note 1: If you look closely at the top graph, there's a little kink upward in the Load vs Time graphs at Step 1. (It's hard to see for the RT Ride, because I got a lot of points just below Step 1 as I tried to figure out where the drop happened.) There's an increase in battery run-time that happens here:

  • The RT0 goes from 7:16 just before Step 1 to 7:23. (These are actual values; I haven't tried to pretty them up or smooth them over. They probably have a couple of seconds of interface lag.)
  • The RT Ride, with its larger battery, goes from 10:53 to 11:04.
  • They're both increases of ~1.65% or 1/60.
I can't explain it, but it's real. I figure that they're using two different algorithms under the hood (above versus below the step) and they didn't quite integrate them well. After all, values from 100 kg (Step 0) to 200 kg (Step 1) are a very simple linear decline. Past that is probably a different equation.
Yeah, okay. So anyway, there it is.

So I guess I'm not going to make a table of distance and speed for bikes. It'd be pretty messy. You can look at the graphs and try to estimate based on your load and bike type. If you're got a Long Range bike, multiply the RT0 values by 2. Relative battery sizes are in the Battery table.

Don't forget: For bikes, Sam's load is added to the load of the bike. In any discussion of bike loads, that's what you must use: Sam's weight and the weight of anything in the bike racks.

Trucks are very different. Nothing on Sam counts toward a truck's load.