Building a Turn in Gameplay Animation: Pitfalls, Adjustments, and Best Practices
- Vanessa
- 3 days ago
- 14 min read
In the previous article, we explored why the turn matters: the boundary between cycle and rotation, the angle eaten by the engine, the necessary trade-off between responsiveness and credibility, and banking as psychology rather than aesthetics.
Here, we leave theory behind and step into production.
Idle, walk, stop, and start already exist.
The system can turn, at least on paper.
What remains is no longer understanding why the turn is a sensitive brick: it is building a turn that actually holds inside the real engine of the project.
And this is where things get complicated, more than for any other transition.
A turn is never built the same way twice.
The method changes depending on whether the engine follows the animation or the animation dresses the engine.
And this shift is not a binary choice: it has degrees, contexts, and different pitfalls depending on the game.
This is what makes the turn a brick apart: a transition that immediately exposes the coherence, or the incoherence, of the system.
Download the Turn Production Kit PDF
(Pipeline section )
Everything you need to produce solid turns
Calibration, debugging, and planning
Angle conventions, transition matrix, integration checklist, and typical red flags: the production companion to this article.
Before getting into the practical side, I need to state something clearly: I have never seen a completely invisible turn. There is always a compromise.
If you push responsiveness, you lose a bit of credibility. If you push realism, you lose a bit of control.
That is the deal. It is the very nature of the turn.
Once you know how to read a locomotion system, you can see exactly where that compromise hides.
A useful map
People often present the topic as a simple opposition: anim-driven versus capsule-driven.
In practice, I have encountered several different terrains, and each one requires its own way of approaching the turn.
This is not an exhaustive list, just a map that helped me understand what I was doing, and where things were breaking.
1. Classic anim-driven
This is the terrain where I have spent most of my time: Beyond: Two Souls, Ghost Recon, Assassin's Creed.
Root motion drives the rotation, and the engine follows.
You know exactly what breaks, why it breaks, and how to fix it.
It is a very readable terrain, but demanding on the animation side.
2. Capsule-driven in 2D
In Prince of Persia: The Lost Crown, locomotion is capsule-driven, but the game is side-scrolling.
No angles, no banking, no directional cone.
The turn becomes almost binary: either you turn, or you don’t. It is capsule-driven, but stripped of most of the constraints that make the topic difficult in 3D.
3. Capsule-driven in 3D with free angles
This is my current worksite, in Unreal.
You can adjust the capsule’s rotation speed, but you then need to build an animation that dresses that rotation without betraying it.
It is a constant back-and-forth between responsiveness (gameplay) and credibility (animation).
There are many possible settings, and finding the right compromise takes time.
4. Hybrid systems
And then there are cases that mix both. In PoP, locomotion was capsule-driven, but actions remained anim-driven. Depending on the movement, one or the other would take control.
The turn sits at the boundary between locomotion and action, and I am still exploring that terrain.
Across projects
After five engines and eighteen years of gameplay, I have mostly learned one thing: with every new engine, you have to break what you think you know and learn again.
It is normal, and it is one of the aspects of the job I enjoy the most, even when it requires more back-and-forth than expected.
Turns remain the weak spot for many gameplay animators, even seniors.
Every project reveals new cases, new pitfalls, new ways to approach them.
It is not a simple topic.
It requires craft, time, and a real understanding of the system.
The map above is a useful way to understand where you stand, and why a turn behaves differently depending on the engine, the system, or the context.
It helps identify the pitfalls, the constraints, and the zones where the turn becomes sensitive, including in hybrid systems that we sometimes use without naming them.
Production rule: do not look for a universal method to cut a turn. Look for the terrain you are standing on, because the method changes depending on the answer.
Anchoring against real terrain
In anim-driven systems, setting the entry pose and the exit pose of a turn is fairly simple in theory: an entry pose that connects cleanly to the current cycle, and an exit pose that returns into the cycle.
The real challenge is not choosing these poses. It is making them hold against terrain that never matches exactly what you animated.
On Ghost Recon, NPC slope locomotion was handled fully in animation: no heavy corrective IK, no complex layering system, just a complete locomotion set.
It worked well as long as the character stayed on a consistent slope axis.
With turns, the limits appeared.
A character can end up sideways on a slope, without matching the exact degree of inclination the turn animation was built for.
The anchoring defined in preproduction no longer fits the actual ground in the level.
Fortunately, this situation happened rarely for open‑world NPCs, so the mismatch remained mostly invisible in practice.
We added a bit of IK to fix the most obvious cases, but kept it intentionally light: animation still accounted for about ninety percent of the visual result.
Fixing more would have required a much heavier system to maintain, for a gain that almost never showed on screen.
And slopes are only one example.
An anchor can break on any irregular ground: a ledge, a height difference, an approximate collision, or a blend triggered at the wrong moment. A ground that is never as clean as in Maya.
Real terrain is always more chaotic than the terrain imagined in preproduction.
Placing an anchor in production is not just about choosing a clean pose, but deciding how far you will protect it against terrain that will never perfectly match what you animated.
Production rule: an anchor is not evaluated on flat ground in preproduction. It is evaluated on the worst terrain the player will encounter, and on what you are willing to correct, or not, when that terrain drifts away from the plan.
Understanding the logic of a turn
A useful clarification before going further, especially if you read the article about the start just before this one: the turn does not work like a system of directional starts.
A start needs to exist at almost every angle.
From idle, the player can push the stick in any direction, and the engine must cover the full cone. It is a continuous blend system, with strict conventions: harmonized durations, consistent step counts, clean transitions between all variants of the same group.
A turn is not an angle system like the start.
In most games, you do not build a 45‑degree turn, a 90‑degree turn, and a 180‑degree turn meant to blend together.
You focus on a very small number of cases, often just one, because gameplay does not need a full combinatorial set.
In the simplest systems, there is only one turn: a generic 180‑degree turn, triggered as soon as the player requests a sharp rotation. In more advanced systems, you add a variant per support foot, or a left/right angle distinction.
But even then, the logic remains very compact: it is not a cone of angles to harmonize, it is a targeted trigger.
This choice is not just a production convention, it is also a gameplay decision.
Anything that is not a 180‑degree turn falls into a grey zone where the system must decide: should it trigger a real turn, or simply reorient the cycle with banking?
A 45‑degree or 90‑degree turn cuts control, suspends input, and forces an invasive animation for an angle that banking can often handle without ever blocking the player.
This changes the nature of production work.
In a start system, the difficulty comes from the coherence between all the variants of a group.
In a turn system, the difficulty moves elsewhere: toward the robustness of a small number of animations facing a player who repeats, interrupts, and chains the same action in unpredictable ways.
Production rule: before producing a turn, decide how far your project wants to push it. One single turn? One per foot? One per direction? Or more? A turn covers a choice, not a cone.
Turn by movement speed
A turn does not behave the same way when it starts from a walk, a jog, or a sprint.
It is not just a matter of timing: the entire reactivity‑versus‑credibility compromise shifts depending on speed.
In walk, or at low speed, it is the most difficult case.
Support feet are perfectly visible, the rotation can take more time, and the player feels every frame of lost control.
Every imperfection, a slide, a bad connection, a slightly wrong angle, becomes obvious, precisely because nothing else is there to mask the movement.
In running, the margin of maneuver widens.
You can afford more reactive, more decisive solutions, because the character’s speed and the rhythm of the game hide part of the imperfections that walking would expose without mercy.
In sprint, the cursor goes even further.
You can assume slides, a sharp rotation, almost a brutal one, and it works, because the context calls for exactly that register. At that speed, the player expects fluidity and impact, not biomechanical precision.
On every production I worked on, we built a different turn for each speed range, precisely because the expected feeling changes completely between the three.
A single generic turn, calibrated for one speed, ends up either too soft in sprint or harsh and incoherent in walk.
Production rule: never calibrate a turn for locomotion in general. Calibrate it for a specific speed range, and always start with walk. It is where defects are most visible, and it is where the rest of the system must hold.
Calibrating banking in production
The banking is a system for directional correction of locomotion.
Its quality depends entirely on how you calibrate it.
In many projects, this calibration is done by feel: a threshold chosen “because it works”, an amplitude copied from another game, a rise speed left at default.
It works, but it is not designed for the feeling of the project.
In practice, banking relies on three levers:
trigger threshold: the angle or input at which banking starts
amplitude: how far it can go
rise speed: how it goes from zero to its maximum value
These three parameters define the personality of the character: nervous, stable, realistic, readable, permissive, or very reactive.
To improve the feeling, it is useful to explore both extremes: a hyper‑sensitive banking that reacts to the slightest micro‑input, and a very progressive banking that only triggers from a wider angle. Between the two lies the zone that serves the game.
On Beyond: Two Souls, we took the time to explore this.
On one side, we tested a very sensitive version: the slightest micro‑input triggered the strongest banking value. It was readable, but the character oscillated strongly when switching sides. Too nervous, almost unstable as soon as the player corrected direction continuously.
On the other side, we refined a more progressive trigger threshold, more coherent with the character’s actual movement, to match the realism expected in this type of narrative game. Banking triggered from a small angle, with a progressive rise instead of an all‑or‑nothing behavior.
This is a setting you find by playing, by testing both extremes, then searching for the balance between immediate readability and credible movement.
In the previous article, we saw that there are two main ways to produce banking: with additive poses or with animation cycles.
A small clarification about additive layers: their role depends heavily on the project.
On Ghost Recon NPCs, they mostly handled the upper body for weapon postures, and did not touch locomotion. What the feet do remained in the pure locomotion layer.
In production, the choice between the two methods is not only technical, it is also a question of visual tolerance.
On a stylized or permissive rendering, the lighter version is more than enough.
The more the rendering aims for realism, the more it shows its limits, because it modifies the silhouette without touching the actual mechanics of the cycle: weight, support, the logic of the attacking foot.
That is when the version with real animations becomes necessary.
Production rule: the trigger threshold of banking is specific to each game. You explore, you adjust, then you lock it. It is a cursor you move between two extremes until you find the zone that works in real gameplay, not just in a presentation scene.
Camera in production
I will be honest rather than pretend to have expertise I do not have: at Quantic Dream and at Ubisoft, the camera was not handled by animators.
So it is not a topic I am deeply knowledgeable about.
The real issue I observed at my level is not about fine coordination between animation and camera. The camera is generally attached to the character or its capsule, so that part does not create any particular problem.
The problem lies elsewhere, in tight environments.
The camera can clip through walls, or on the contrary get stuck if you add collisions to prevent that. It is already not easy to solve cleanly for basic locomotion, in narrow corridors or spaces filled with walls.
The turn adds an extra layer of difficulty to this already existing problem, by imposing a full 180‑degree rotation in a space that sometimes does not have enough room to accommodate it properly.
Production rule: always test your turns in the narrowest spaces of the game, not only in an open test area. This is where camera issues related to turns reveal themselves, even if you are not the one who handles the camera itself.
The transition matrix
This is the core of producing a turn: what happens when it does not stay isolated, when the player breaks their intention mid‑pivot, or when the system needs to chain it with something else.
Turn → turn :stick spam
In Beyond: Two Souls, turn → turn chaining required careful testing to ensure Jodie could repeat them cleanly.
Several parameters had to align:
the turn speed
the entry and exit foot of each variant
the trigger threshold, high enough to confirm the player really wanted a 180° and not an accidental input
the pure spam handling
and the coherence between left and right angles when the player alternated rapidly between them
None of these settings work in isolation.
A trigger threshold that is too low makes spam unmanageable. A bad foot match between two chained turns creates a visible pop. The reliability of chaining comes from the agreement between these settings, not from any single one.
Turn → jump, hit, stop : the philosophy of interruption
In Prince of Persia: The Lost Crown, the logic is different, deliberately more radical.
The turn must be interruptible very quickly so the player always stays in control, whether transitioning into a jump, a hit, or a stop.
The capsule rotates fast, and there is no real loss‑of‑control window like in a classic turn. You do not wait for the character to be on the correct foot; you simply wait for the capsule rotation to finish, which takes very few frames.
This philosophy works because the context allows it:
In ultra‑fast 2D, there are no complex angles, no cover constraints, no heavy inertias to manage.
Cheating is easier, and reactivity completely outweighs biomechanical fidelity of the pivot.
These two examples, Beyond and PoP, do not tell the same story of the turn.
One protects a short but real window of non‑control, to preserve foot coherence in a 3D narrative game.
The other almost removes that window, because the game’s context allows it and because the player should never feel they have lost control.
Neither approach is more correct than the other. Each responds to its own matrix of constraints: genre, camera, inertia, style, rhythm, and design intention.
Production rule: before adjusting a single frame of transition, decide the exact duration of non‑control your game can accept during a turn. The entire transition matrix follows from that tolerance.
Tools and iteration workflow
Gameplay is always a story of cross‑team collaboration. A turn is never tuned alone in its corner.
The general workflow: you review together, you align on problems and possible solutions, then you split the work.
Game design and animation handle the conception.
Gameplay programming and animation handle production, the concrete implementation.
On Beyond, we already had a solid foot system when we started working on turns.
The real challenge was making the capsule and the animation converge: getting a result that ended at the correct angle, with enough reactivity for the player and enough realism for the game.
That happened through many back‑and‑forth iterations with gameplay programmers, not in a single pass.
Banking followed the same distribution logic.
Engine settings, like the trigger threshold, were handled by gameplay programming.
I handled the animation layer.
The final result depended on our ability to iterate together until both layers told the same story, instead of each of us optimizing our own part without looking at what the other was doing.
A turn that only works in isolation, tested solely by the animator in their own tool, has never proven anything.
It only becomes reliable once it has gone through multiple perspectives, multiple disciplines, multiple pad‑in‑hand test sessions with the people who control the settings you do not control yourself.
Production rule: never consider a turn “finished” until it has been tested pad‑in‑hand with the person who handles integration and engine settings. A turn that has never left your animation tool has not proven anything yet.
What I look at first, and why
In integration, a turn can fail for a thousand reasons: feet sliding, the wrong foot blending, the angle being eaten by the engine, the rotation not matching the animation, or a loss of control that lasts too long.
But these problems do not have the same weight, nor the same cost to fix.
I always start with angle accuracy and reactivity, because these are the two points that are the hardest to correct once production is advanced.
If the turn does not reach its target angle, the player immediately feels that the character “is not really turning.”
If the rotation lags behind the input, the player feels an inertia that was not intended.
In both cases, no amount of animation polish can save it: you have to rebuild the movement itself, the pivot logic, the capsule, the cycle, the attacking foot.
By contrast, foot issues are easier to fix once the foundation is solid.
A bad foot match, a slide, or a pop can be corrected in animation.
These are finishing problems, not structural ones.
But an angle that never lands where it should, or sluggish reactivity, breaks the entire turn: the sense of control, the biomechanical coherence, the readability of the pivot, and even the credibility of the character.
Production rule: validate angle and reactivity first. They are what lock the structure of the turn.
Red Flags : the typical errors
🚩 Feet sliding → the visual grounding does not match what the engine is actually doing. The cycle shows a planted foot, the capsule shows something else.
🚩 Wrong foot blending → the animation triggered does not correspond to the real support foot at the moment of the turn. Result: pop, imbalance, or biomechanical incoherence.
🚩 Eaten angle → part of the rotation is absorbed during a blend. The character ends up facing a direction different from the intended one, even if the animation itself is correct.
🚩 Rotation not matching the animation → the rotation speed imposed by the capsule and the rotation rhythm of the turn animation tell two different stories. The player feels friction between their intention and what the pivot expresses visually.
🚩 Loss of control too long → the non‑control window is not calibrated for the game’s rhythm. The player feels like they are undergoing a micro‑cutscene instead of a responsive pivot.
Conclusion
A turn is never built the same way twice.
The settings may look similar, the engines may be identical, two projects may share the same technical constraints… but the construction always depends on the actual terrain of the game: its speed, its inertia, its camera, its tolerance for loss of control, and what the player needs to feel at every pivot.
What does not change is the discipline: calibrate, test, break, rebuild, until the rotation becomes invisible.
Turns are demanding.
They require trials, adjustments, and a lot of pad‑in‑hand testing.
After five engines and rebuilding turns for every project, I know this is simply the normal process to reach a result that holds.
And if turns remain the nightmare of so many gameplay animators, even seniors, it may simply be because there is no shortcut: only method, time, and many back‑and‑forth pad‑in‑hand.
A small note before the summer break: the blog is pausing for the entire month of August.
It will return in September with the final chapter of the grounded locomotion series: turns on spot.
Enjoy your holidays if you’re taking some! :)
Download the Turn Production Kit PDF
(Pipeline section )
Everything you need to produce solid turns
Calibration, debugging, and planning
Angle conventions, transition matrix, integration checklist, and typical red flags: the production companion to this article.
Discover the Locomotion Foundation Kit:
All the tools you need to frame and produce Idle, Walk, Stop, and Start.
Comments