Our characters could run up stairs. They couldn't walk up them.

Lab Log #001 from BeeMaster Engine: a stairs test that passed at 4 m/s, a walking character that never got past the first step, the geometry behind it, and what we measured after the fix.

Tionscadal: BeeMaster Engine

▶ Watch the episode: Lab Log #001 on YouTube

Stairs are never really the point. In a game world, a character should simply deal with the things around it: a step, a ledge, a door, a box to carry, a chair to sit in. In many projects each of those becomes a little project of its own, with an animation, a trigger, a script and numbers tuned by hand. We’re building an engine that tries to understand what things are and how a body meets them, so the natural thing happens by default and you go deeper only when you want to. Stairs are the first, simplest test of that idea.

The stairs fixture in the engine’s grey-box test scene, with the capsule that stands in for a walking character — The stairs fixture in our grey-box test scene. Test geometry, not finished art.

The test that passed

For collision, most engines treat a walking character as a capsule: a cylinder with two half-spheres. To climb a step it does three things every frame: rise by the maximum step height, move forward, come back down onto whatever is there. In BeeMaster a step can be up to 0.30 m; anything taller is a wall.

A chalk drawing of the three moves at a step: rise, move forward, come back down — Rise, move forward, come back down: every frame.

Our first stairs scenario (a player and one NPC walking up, walking back down, and stopping at a ledge that is too tall) passed. It passed at 4 m/s. That’s a run.

The bug that only existed at walking speed

A day later, six characters walked around a small test level. Two of them, at 1.4 and 1.15 m/s, had to walk up the stairs. Both stopped at the first step’s edge, for good.

Box-shaped test characters at the stairs in the engine — The six-character test level in the engine.

The engine steps 60 times a second, so a character moves Δx = v / 60 per frame: about 2.3 cm at a walk, 6.7 cm at a run. After such a small move, the capsule’s rounded bottom came down on the edge of the step instead of its top. A sphere touching a corner is pushed along the line from the corner to its centre, n = (−d, √(r² − d²)) / r, where d is how far the centre is behind the edge. While the centre is still behind the edge, that push has a backward component. The capsule slid back off, the step was refused, and the same thing happened on the next frame. And the next.

A chalk drawing of the capsule on the step corner, with the contact normal and its backward component — While the centre is behind the edge, the contact normal points partly backwards.

At 4 m/s each move was about three times bigger, and in our scenario that was enough for the step to be accepted. A box-shaped character, with its flat bottom, never had the problem at all: a flat bottom on a square corner is pushed straight up. Our test passed because it walked at a speed nobody actually walks at.

The fix, and then the feet

The fix was small: when the top of the step is already under the character’s footprint, within one step’s height, set the character down there, the way a box would stand. The Climber and the Courier walked up.

Then we looked at their feet, frame by frame. On the stairs, a foot that was supposed to stay planted jumped 12.5 cm in a single frame, and its leg turned 31°. You’d never see that in a screenshot; in motion, it’s the moment a character stops feeling like it has weight. We had been asking the animation where the foot should be planted instead of looking at where the foot was, and whether the leg could still reach it. Now a foot plants where it really is, and only within its leg’s reach; out of reach, it lifts, steps and lands again. And because the collider’s flat footprint could already stand on the next stair while the hips were still over the last one, body corrections are measured from the ground under the body.

A chalk drawing comparing where the animation says the foot is with where the foot really is — Where the animation says the foot is, and where it really is.

What we measured

Recorded straight from the engine at 60 samples a second (hips, knees, ankles), six characters, 600 steps each, debug build:

3,880 planted foot-steps; a planted foot moved 0 m.
No foot went into the ground.
On the stairs, the lower foot was on its own step about three times in four before (61 of 82, 83 of 100), and on every step after (184 of 184, 220 of 220).
About 50 µs per character per frame.

The Climber walking up the stairs, drawn from recorded engine data — The Climber today, drawn from recorded engine data. Each mark on a step is a moment a foot planted.

The lesson

A test that passes at one convenient speed tells you nothing about the others. Everything that moves in BeeMaster is now tested at the speeds a game actually uses, the slow end included, with the real shape of the character, and with an eye on the feet, not just on whether the body arrived.

The full write-up, with the geometry, the measurement method and its limits, is below as a PDF.

BeeMaster Engine is being built by OpenLabWork. A new Lab Log every Thursday.

Go deeper

The full write-up behind this note, to read offline or share.

Walking Speed and the Step-Up Problem · Technical Note LL-001PDF · 7 pages · 1.8 MB · in EnglishDownload