There is a particular wrongness to a badly animated walk that everybody notices and almost nobody can name. The feet slide slightly. The legs race during acceleration and stutter at the top. The stride changes tempo halfway across a room for no visible reason.
All three of those are usually one mistake, and it is arithmetic rather than art.
The mistake
The obvious way to animate a walk is to pick a frame from the clock. Take the character's running time, multiply by a frame rate, take the remainder over the number of frames. To make faster movement look faster, recompute that frame rate from the current speed each frame.
It seems reasonable. It is badly broken, and the reason is worth understanding because it shows up in more places than animation.
The character's clock never resets. After thirty seconds it is a large number. Multiply a large number by a frame rate and nudge that rate slightly, say from 9.00 to 9.06, and the product moves by nearly two whole frames instantly. Speed changes on every frame of every acceleration, so the frame rate is being nudged constantly, and the frame index effectively scrambles.
That is the racing, the stuttering and the tempo changes. One expression.
The fix
Stop thinking about time. A walk cycle belongs to the ground.
One full cycle should cover a fixed distance, about a body height, and the phase should advance by how far the character actually travelled this frame. Nothing else.
The consequences fall out for free:
- Tempo is exactly proportional to ground speed, always, because that is now the definition rather than an approximation.
- The feet cannot skate, because the cycle and the floor are measuring the same thing.
- No frame can be skipped, because the phase only ever moves by the small distance covered since the last frame.
Walking backwards works. Slow motion works. Being pushed works. None of them need special cases, because none of them are exceptions to the rule.
The related trap: running
Here is a smaller version of the same problem, from the same build.
Nobody had drawn a separate run cycle, so running fell back to the walk frames from a legacy set. The effect was that crossing about three hundred units a second swapped the character onto a different drawing of himself mid-stride. A visible pop, and a second tempo underneath the first.
The fix is conceptual rather than technical. A run is not a different animation from a walk. It is the same cycle with a longer stride. So it uses the same frames, and the distance-per-cycle does the rest. The pop disappears because there was never a reason for a second set of art.
Sizing: every drawing is a different scale
A separate problem that looks like an animation bug.
Artwork arrives at whatever pixel size it was drawn at. One sprite is 298 pixels tall, another 218, another 192. Draw them at their pixel size and a character changes height whenever he jumps, because the jump drawing has less empty space above the head.
So a sprite does not carry a pixel size. It carries the height it should occupy in the world. Edward is 132 units tall, B.Bear is 82, a pigeon is 30, a lamppost is 300. Each drawing also carries where its feet are and where its centre line sits, because a mid-stride frame is not centred the same way a standing one is.
The renderer then asks how tall this thing should be in the world and scales the picture to match. Art can be redrawn at any size and nothing downstream changes.
Building before the art exists
The last piece is the one that matters most commercially, because it is what lets a commission run to a deadline.
A character has a facing and a state. Four facings: right, left, away from the camera, toward it. Ten states: idle, walk, run, jump, fall, land, crouch, climb, reach, cheer.
That is forty possible sets, and no build starts with forty sets of artwork. So each lookup falls down a chain: the exact directional sheet if it has been packed, otherwise the nearest thing that exists, all the way down to a single standing frame. The game never blanks out while the art is still arriving.
The other half of the arrangement is a naming contract. Pack frames as ed_right_walk0 through ed_right_walk7, or the same with away or toward, and they are picked up automatically. Left is mirrored from right unless a left sheet exists. Nothing else has to change: no code edit, no configuration.
That is what makes partial deliveries safe. The game is playable from the first week with placeholder poses, and every batch of finished art simply appears in it.
What to take from this
A walk that looks wrong is usually a measurement problem. Before redrawing anything, check what the animation is keyed to. If it is the clock, the art is not the issue.
Frame count is not the lever people think it is. Four frames timed to the ground beat twelve timed to a stopwatch, every time.
A good pipeline lets art and code arrive separately. Fallback chains and a naming contract are unglamorous, but they are why a commission can be built and approved while the paintings are still being made.
The build most of these examples come from is written up in full in the build diary, and what decides a game's size covers why some characters are painted and others are drawn in code. Two finished builds are playable in the arcade.
