07Quarterly
Weight And Momentum
How movement feels, measured
Weight And Momentum
How movement feels, measured
Everything in a jump that matters can be read from one recording, provided you have decided in advance what counts as the first frame. Here is the procedure we use, and the two errors that produce wrong coyote windows.
Applies to platformers and any game with a discrete jump · Requires capture at 240fps or higher
A jump looks like a single event and is at least five measurable ones: the input, the rise, the apex, the fall, and the landing. Each has a boundary, each boundary is a judgement, and if the judgements are not fixed in advance the same jump will yield different numbers on successive attempts. That is not a measurement problem, it is a definitions problem, and it accounts for most of the disagreement between people who count frames.
Capture at four times the game's frame rate. At 240fps against a 60fps game, each game frame occupies four captured frames, which removes all ambiguity about whether an event happened on frame twelve or thirteen. Capturing at 60 to measure 60 does not work: a single-frame event either coincides with a captured frame or does not, and you cannot tell which case you are in.
Put the input in shot. This is the part most people skip and it is the whole basis of the measurement. We clamp the controller in a jig with the face buttons visible to the camera, so the recording contains both the physical press and the on-screen result, and the interval between them is directly readable. Without the input in frame you are measuring the animation, not the response.
A human press is not instantaneous: the button travels, and the travel time varies between presses by two to five milliseconds. Over a hundred jumps that variance is larger than the figures being measured.
The jig does not press the button — a finger still does — but it fixes the geometry so that the travel is consistent and the camera sees the same movement each time.
| Event | First frame is | Common alternative |
|---|---|---|
| Input | Button contact closes | Finger begins moving |
| Rise | First frame with vertical displacement | First frame of jump animation |
| Apex | First frame with zero vertical change | Highest visible point |
| Fall | First frame of downward displacement | End of apex animation |
| Landing | First frame of ground contact | First frame input is accepted |
The rise definition is where most disagreements start. Many games play two or three frames of anticipation animation — a crouch — before the character actually leaves the ground, and whether those frames belong to the jump is a real question. We exclude them from rise and record them separately, because a player experiences anticipation as part of the input cost rather than part of the arc.
Apex is defined as the first frame of zero vertical change rather than the highest visible point, because those are often different. In the platformer in this issue the character holds altitude for two frames at the top; the highest visible point is the second of them, the apex by our definition is the first, and the two-frame hold is the interesting figure.
The coyote window — the interval after leaving a ledge during which a jump input is still accepted — is the figure most often misreported, and both of the errors are easy to make.
The first error is measuring from the visual edge of the platform rather than from the collision boundary. Those differ in most games, usually by a few pixels of art overhang, and at speed the difference is one or two frames. The fix is to establish the collision boundary first, by walking the character off the ledge slowly and marking the frame at which the fall begins.
The second error is measuring a single instance. Coyote windows are usually implemented as a frame count and are therefore exact, but a game that ties the window to velocity — and several do — will produce a different figure at walking pace than at a run. We measure at three speeds and report the range if they differ. In review five they did.
A coyote window measured once, at one speed, from the visual edge, will be wrong in at least one of three ways.
The mirror figure: how many frames before landing a jump input is accepted and queued. Procedure is the same in reverse — press early, count back from ground contact — and the trap is different. Some games buffer the input and execute on landing; others buffer and execute a frame or two later; a few discard the buffer if the player also holds a direction. Test each combination, because a buffer that silently fails under a directional hold is a bug worth reporting.
We test four cases: press early with no direction, with a direction into the wall, with a direction away, and with a direction changing mid-buffer. In eighteen games measured across seven issues, three behaved differently in the fourth case.
Ten jumps per configuration. If all ten agree exactly, the value is exact and the figure is published without qualification, which is the usual outcome because these systems are implemented as integer frame counts. If they do not agree, something in the setup is varying and the correct response is to find it rather than to average.
We have published an average exactly once, in issue five, and it was a mistake — the variance turned out to be a physics timestep interacting with frame rate, which is a finding rather than noise, and averaging it concealed the most interesting thing about that game.