Building a stop in gameplay animation: conventions, engine constraints, and concrete production examples
- Vanessa
- 2 days ago
- 12 min read
The gameplay stop: a simple animation that changes nature depending on the game’s conventions
Is the stop a difficult animation?
By itself, no. A stop is a simple animation… inside a complex system.
Its difficulty doesn’t come from the mechanics of the animation, but from the game it belongs to: the style, the locomotion conventions, the expected responsiveness, the engine logic, the blend constraints.
These decisions change how many stops you need to produce, their structure, their duration, their blend logic, and sometimes even the number of steps they contain.
In the previous article, we looked at why the stop is a critical transition: what it reveals about the system, what it costs when poorly designed, and why it can’t be validated in Maya.
Here, we shift perspective.
We put ourselves in the real situation of a gameplay animator:
the idle exists, the walk exists, speeds are defined, engine constraints are known. Now you need to produce a stop.
And that’s where the real complexity appears, in the system surrounding it.
DOWNLOAD THE STOP PRODUCTION KIT PDF
(pipeline section)
(10 pages) to produce, test, and debug stop animations: checklists, methods, and ready‑to‑use templates.
In its raw form, a stop is always the same thing
If we completely isolate the animation from the rest of the system, a stop boils down to this: one or two walking steps, then an idle pose.
Short, readable, mechanical.
Technically, it’s not a difficult animation.
But in production, that simplicity disappears instantly.
Because a stop isn’t a standalone animation, it’s a junction, a connection point between several elements of the system that sometimes contradict each other.
Locomotion, Idle, the engine, blend rules, game responsiveness, design…
Before you even start animating, there are four decisions that shape the entire production.
These are technical and design decisions that must be validated with the game designer, the gameplay programmer, and the tech animator before opening Maya.
The four decisions you need before animating
The exact engine speed
A stop fits within a precise movement speed.
If you build your stop on an approximate speed, you’ll end up either with sliding, or with a deceleration that doesn’t match the rest of the locomotion.
Even in a root‑motion–driven system, the question still applies:
“At what actual speed is this animation supposed to move in‑game?”
As long as this value isn’t clear and validated, you’re animating blindly…
As a reminder:
The support foot
The engine doesn’t “choose” anything automatically.
It simply calls the animation you give it, based on the conditions defined in the graph.
Those conditions depend directly on how many stop animations you provide.
In production, there are two common approaches:
1. One single stop
In this case, you have two possibilities:
either the character stops instantly, at the cost of visible sliding,
or the stop implicitly contains two versions: one ending on one foot, the other ending on the opposite foot, but both inside a single animation (meaning one extra step on one side, one fewer on the other).
It’s simple to produce, but less precise.
2. Two stops (left foot / right foot)
This is the clean solution as soon as you want a minimum of physical credibility.
You produce a left‑foot stop and a right‑foot stop.
The graph triggers the correct stop depending on the support foot of the previous cycle.
At this stage, there is no requirement to normalize the number of steps, the alternation, or the duration.
What matters is that each stop is internally coherent and matches the logic of the game.
Strict normalization (duration, inertia, distance, alternation, number of steps) only comes later, if:
you add directional stops,
or speed‑based variants,
or contextual stops.
It’s only at that point that all stops for the same foot must follow the same conventions.
And yes, I’ve already had to redo stop animations because I had accidentally produced… two left‑foot stops.
I only noticed it during integration: the blend didn’t work, the wrong stop was triggering, or the system kept waiting forever for the correct foot before allowing the character to stop.
You make that mistake once, never twice.
The interruptibility window
At which frame can the character respond to a new input?
This value often evolves during production, because gameplay becomes more precise over time.
It’s used to allow the player to move again even if the stop animation isn’t finished.
You still need to animate past that frame. If the player doesn’t touch anything, the animation must play all the way to the end before transitioning to Idle. So the end of the stop must exist, be clean, and be properly animated.
What changes with interruptibility isn’t the total duration of the stop, it’s the way you build the beginning of the movement.
In practice, I’ve often had to adjust:
the anticipation,
the braking,
the start of the follow‑through,
so that the animation remains interruptible without creating pops or energy breaks.
The end of the stop, however, remains essential: it’s what the player sees if they don’t give any input.
The expected responsiveness style
This is a game‑design decision that directly shapes the structure of the stop animation.
In production, you generally end up with two major families:
1. Snappy / gameplay‑driven / highly responsive games
The stop must start immediately. You accept a slightly harsh blend. The absolute priority: precision and control.
Direct consequences:
very short anticipation,
fast deceleration,
little inertia,
minimal follow‑through,
often a single stop animation (responsiveness > physical credibility).
2. Narrative / immersive / realistic games
Here, visual coherence and continuity of weight shifts take priority. You produce two stops (left / right) to cover the cases cleanly. You aim for a balance between inertia, readability, and control.
Direct consequences:
more pronounced anticipation,
progressive deceleration,
visible inertia,
richer follow‑through,
number of steps adjusted depending on the final pose.
This choice determines the amplitude of the anticipation, the deceleration speed, the amount of acceptable follow‑through, the total duration of the animation, and the number of steps you keep before the stop.
It needs to be defined BEFORE animating, to avoid having to redo the animation multiple times
The game’s conventions: what turns a stop into a stop
There is no such thing as a universal stop.
There are stops, plural, depending on the locomotion style.
Concrete examples show how drastically a stop can change from one project to another.
Case 1: The hyper‑responsive game — a single stop (Prince of Persia: The Lost Crown)
On PoP: The Lost Crown, we only had one stop. No left‑foot stop, no right‑foot stop, a single, immediate stop.
It’s a fast, precise 2.5D game where every jump, every platform, every dodge requires millimetric accuracy.
If we had added two steps before stopping, the character would never have stopped exactly where the player wanted.
In a game where gameplay takes absolute priority, that’s unacceptable.
The stop had to be instantaneous, even if that meant accepting a slight visual slide.
This wasn’t an animation compromise, it was a design choice that defined the nature of the stop for the entire project.
The duration of the stop is not an artistic decision, it’s a gameplay decision.
Case 2: The immersive game — two stops (Beyond: Two Souls, Ghost Recon)
On Beyond: Two Souls, it was the opposite: two stops, one for the left foot and one for the right. It was my first job, so to me that was “the norm.” And later on Ghost Recon, we did the same.
These games prioritize visual coherence, continuity of weight shifts, and believable movement.
The engine needed to pick the correct stop based on the current foot in the walk cycle, to avoid breaks, foot swaps, or broken blends.
The more a game values physical credibility, the more precise the stop system needs to be regarding foot placement.
Case 3: The asymmetric idle — two conventions within the same project (Beyond: Two Souls)
On Beyond, some of Jodie’s motion kits had an asymmetric idle, for example in crouched stealth: one leg forward, the other behind.
The result was this: the back‑foot stop would end immediately, while the front‑foot stop included a small extra adjustment step.
The two stops didn’t have the same number of steps.
But all left‑foot stops still had to blend with each other, and all right‑foot stops had to blend with each other as well.
So we ended up with two different conventions: one for left‑foot stops, one for right‑foot stops.
And those conventions had to remain consistent within each group so the engine could interpolate cleanly.
A stop doesn’t have a single shape, it depends on the arrival pose.
All stops within the same group must share the same logic: inertia, number of steps, foot alternation, duration, so that the blend holds together.
Case 4: Directional stops — when the stop becomes a subsystem (Beyond: Two Souls)
On Beyond, I worked on the R&D for directional stops.
Up to that point, they didn’t exist, neither for NPCs nor for the player.
The goal was to bring the character to a precise target, facing the correct direction, with minimal sliding.
At first, we tested stops in 45° increments, but that meant too many animations for a feature used only occasionally.
We reduced it to 90°: the engine’s blending was strong enough to interpolate cleanly between angles, as long as the animations were consistent with each other.
At that point, it wasn’t a stop animation anymore. It had become a locomotion subsystem, with its own production rules, its own consistency constraints, and its own validation logic.
As soon as you multiply angles, states, and speeds, the stop stops being an animation and becomes a library.
You have to design it as a system, not as a collection of independent animations.
Case 5: Non‑standard terrain — when context makes everything harder (Ghost Recon Breakpoint)
On Breakpoint, we had locomotion on slopes. Which meant: slope stops.
And here, the problems weren’t in the animations themselves, they were in the capture data.
Usually, studios use indoor optical mocap. But capturing locomotion on slopes requires long distances to handle runs, cycles, and stops on various inclines. Building that indoors was logistically complicated.
The chosen solution: outdoor capture with Xsens inertial suits.
The resulting data didn’t have the usual quality.
Feet were jittering, the hips were jumping from frame to frame, and artifacts were everywhere because of the uneven, non‑standardized natural terrain. For realistic, precise animation, this required a massive cleanup effort, and no automated solution was viable with this kind of data.
I went through the files one by one. For each animation, I normalized the hip curves to remove frame jumps while preserving the oscillations needed for locomotion, and manually aligned the feet to the ground.
In practice, we kept from the capture the velocity, the angles, the general attitudes, but we rebuilt the important points: the hips and the foot contacts.
It was elbow grease, not advanced tech.
The volume: around 200 animations. Downhill, uphill, starts, stops, turns, different speeds, different slope angles. More than two months of work dedicated solely to these animations.
This case illustrates something we don’t talk about enough: the quality of a mocap stop depends just as much on the quality of the capture as on the animation work.
A bad take means multiplied production time,sometimes by a factor no one anticipated.
What never changes, no matter the game
The five cases are different. But across all these projects, some things never change.
Start from the walk, not from an invented pose
The stop begins inside the walk. The first frame of the stop is a frame that already exists in your cycle, the passing pose of the support foot.
Inventing a starting pose instantly creates a break the engine will never be able to hide, even with a good blend.
Reconnect the endpoints
In mocap as in keyframe: start = exact pose from the walk, end = exact pose from the idle, middle = free.
This guarantees a clean transition even if the engine cuts early.
Anticipation as a decision signal
That tiny counter‑movement before braking is a signal. It tells the player the character has decided to stop.
Depending on the game, it can be very subtle or more pronounced, but it usually helps make the stop decision more readable and more controlled.
Its amplitude depends on the style, the game’s pacing, and the expected level of responsiveness.
The arrival pose as the real tension point
In most cases, the end of the stop joins the Idle.
The simplest solution is to aim for the first frame of the Idle, it’s the most stable reference.
But often, you don’t let the stop land exactly on that pose. You usually cut a few frames before, letting the blend handle the final transition.
This avoids the “hard snap” of a visible matching pose and creates a more natural continuity between the stop and the Idle.
The goal isn’t to freeze a perfect pose, but to prepare a clean arrival zone, close enough to the Idle for the engine to finish the job without breaking.
Follow‑through as the last layer, never the first
It turns a functional stop into a believable one. But it’s built last, on a separate layer, once everything else is validated.
And it must always remain interruptible, it’s the first place where you sacrifice polish for responsiveness.
Validate in‑engine: the five tests that really matter
A clean stop in Maya means nothing. What matters is how it behaves in‑game, under real conditions.
Here are the five tests that instantly reveal whether a stop actually holds up.
Walk → stop → Idle, in slow motion
A single slow‑motion playback is often enough to spot:
a pop
a slide
an energy break
an inconsistent weight shift
If something feels wrong here, there’s no point going further, the issue is structural.
Input spamming
Release the stick as fast as possible, several times in a row.
This test isn’t just for catching visible details (an arm lifting, a head bobbing). It mainly reveals:
the real responsiveness of the stop
the distance traveled before the actual halt
the consistency of stop → start transitions
micro‑accelerations or micro‑rebounds that don’t show up in normal playback
It’s one of the most important tests because it reproduces exactly what a player does when trying to finely control their character.
Interruptibility
Trigger a start in the middle of the stop, at different frames. The transition must stay clean whether the interruption happens early or late.
This is where you check if:
the anticipation is too long
the beginning of the follow‑through is too pronounced
the interruption window lacks stability
sliding appears between transitions
the traveled distance becomes inconsistent
Readability at a distance
Pull the camera back. If the weight, rhythm, or stop decision disappears, the amplitude is too subtle.
A stop must remain readable at gameplay scale, not just in full‑screen close‑ups.
Consistency at variable speeds
Depending on the engine and the project, movement speed may vary slightly: progressive acceleration, deceleration, different surfaces…
Testing the stop at +10% and -10% of the nominal speed helps verify:
whether inertia still feels credible
whether the timing deforms too much
whether foot contacts remain readable
whether the transition introduces unexpected breaks
This isn’t a test of “absolute robustness”, it’s a way to ensure the stop stays coherent under realistic gameplay variations, not only in its ideal configuration.
Mocap: the necessary reinterpretation
In mocap, the principles stay the same, but the pitfalls are different.
And the run stop is where cheating becomes the most important, and the most unavoidable.
In real life, when you run and stop, you decelerate over several steps, sometimes three or four. It’s natural, it’s physical, and that’s exactly what the capture records.
But in a game, that means the player asks to stop at a precise spot, and the character keeps moving forward four meters.
That’s unacceptable in most games.
The solution isn’t in the capture, it’s in reconstructing the deceleration.
Depending on the game’s style, you allow one or two steps before the stop to keep a minimum of naturalness, or you cut brutally for responsiveness. But in every case, you don’t keep the natural inertia of the real movement. You truncate it, compress it, reinterpret it.
The other critical point in mocap: root motion.
When you receive the raw data, the root is usually a projection of the hips onto the ground (without vertical translation or lateral rotation). An automatic pass has already removed unnecessary information.
But because it follows the hips’ trajectory, you get a lot of unwanted artifacts: parasitic oscillations, angles that aren’t exactly what they should be (89.5° instead of 90°, 178° instead of 180°).
So you always rework the root motion.
For cycles, speed must be constant. For orientation, angles must be precisely normalized.
And on a stop, as soon as both feet touch the ground before returning to idle, the root motion stops moving. It becomes fixed.
Fixing the root motion at the end of the stop is what allows the character to cleanly transition into any following action.
The system knows exactly where the character is positioned relative to the root. The next action has the same information, the feet are already in the right place, and transitions don’t slide.
If the root motion weren’t fixed, the character would slide. If it were incorrectly aligned with the root, the character would teleport between animations.
It’s a technical constraint that holds the entire system together.
Red flags
🚩 Stop built without knowing the interruptibility window → animation gets cut on a random frame.
🚩 Two stops produced for the same foot → one stop will never trigger, or the wrong one will.
🚩 Stops in the same group using different logic → the engine can’t interpolate cleanly.
🚩 Missing anticipation → the stop feels like a cut, not a decision.
🚩 Arrival pose incompatible with the idle → pose problem, not a blend problem.
🚩 Root motion not fixed at the end of the stop → character slides or teleports on the next transition.
🚩 Root motion angles not normalized
Conclusion
A stop is a simple animation. The system it lives in is not.
It’s always the meeting point of an engine, a game style, a locomotion set, an Idle, an expected level of responsiveness, and a set of conventions, sometimes explicit, sometimes implicit.
It is never “just a stop.” It is the direct consequence of the context it has to function in.
That’s why the same stop can be trivial in one project and become meticulous craftsmanship in another.
The difficulty of the animation doesn’t change, the constraints around it do.
The engine, the design, the speed, the root motion, the interruptibility, the readability, the consistency with the rest of the system.
Understanding that framework is what allows you to build a successful stop: one that naturally integrates into the game it belongs to.
That’s where the craft really happens.
DOWNLOAD THE STOP PRODUCTION KIT PDF
(pipeline section)
(10 pages) to produce, test, and debug stop animations: checklists, methods, and ready‑to‑use templates.
Comments