top of page

Building a Turn On Spot in Gameplay Animation

10 hours ago
9 min read

In the previous article, we laid out the questions that need to be settled before producing: triggers, angles to produce, waiting vs. interruption, the camera, and even the rarity of this block.


Here, we leave reflection behind. We build.


And contrary to popular belief, "building a turn on spot" isn't just about slapping an idle pose on the first frame, animating a rotation in the middle, and sticking an idle pose back on the end.

That recipe exists, it works, but it leaves out the real production decisions: where to cut the animation, how to distribute the rotation, how to handle asymmetric support feet, and how to preserve the feeling of control.



Download the Turn On Spot Production Kit

(Pipeline section )


turn on spot
Exerpt page 2/8

Everything you need to produce solid turns on spot

Calibration, debug & planning

Cut and rotation calibration, asymmetric idle handling, interruption matrix, debug guide, and a ready-to-use planner.





Where to cut the animation?


The first production decision isn't how to animate the rotation.


It's where to start and where to end the export.

For a long time, my approach was to cut as short as possible: the idle pose on frame 0, and right from frame 1, the foot is already starting to lift.

That was the logic on Beyond: Two Souls, about fifteen years ago.

The idea seems sound: the player needs to see the impact of their action as early as possible, so you strip out every dead frame before the movement begins.


But you can go further.

Today, I no longer start from the pure idle pose.

I start a few frames later, right before the rotation actually begins, a pose close to idle, but already in motion.

On my animation file, the idle pose might be on frame -5, and I export starting from frame 0. Those five frames aren't lost: they are absorbed by the blend-in, which creates a seamless transition from the active locomotion cycle.


turn on spot
The cut already occurs while in motion.

Finding the right balance comes down to 2 to 7 frames depending on the case, sometimes a bit more if the animation comes from mocap.

Mocap often contains softer starts than keyframe animation, with several frames that serve the realism of the movement rather than its gameplay readability. Cutting into that raw data often allows you to regain responsiveness without degrading the animation.

The risk remains, however: cut too far into the anticipation, and the player no longer understands the movement's intent before it's already underway.

The blend can absorb part of the anticipation, but not all of it.


It was Prince of Persia: The Lost Crown that really pushed this line of thinking.

As the project progressed, the further we dared to cut from the idle pose, to the point of embracing hybrid poses at export, neither entirely the idle, nor entirely the action, but a sort of in-between that, isolated on a single frame, would look almost bizarre.

Yet in the heat of the action, with the blend doing its job, it works seamlessly.

It was keyframe animation, unlike most of my previous mocap projects, and it's precisely through having experience with both that I now know how far that cut can go, and where it starts breaking readability.


Never judge a cut on a single frame. Look at how the blend behaves in motion, within the context of real gameplay. A turn on spot can look strange in Maya and work perfectly once integrated.


Conversely, a turn on spot that looks flawless in the animation file usually reveals all its flaws as soon as it goes through blends, interruptions, and actual gameplay constraints.


This is especially true for aggressive cuts, short rotations, and hybrid poses. Some decisions seem almost wrong when viewed frame by frame. Yet they become completely believable once absorbed by the system.


In the end, the engine remains the ultimate judge. Not the timeline. Not the viewport. Gameplay.



The rotation curve

Once the cut is established, the remaining question is how the rotation itself behaves between the start and end of the pivot.

My practice: a linear curve on the root motion rotation.

The curve stays flat during the blend-in, the rotation is distributed linearly throughout the turn's active window, and then goes flat again before the blend-out.

The rotation starts after the blend-in, never during it, at the risk of eating up part of the angle, and ends before the blend-out.

As short as possible, but without completely decoupling it from the rest of the animation.


turn on spot
The rotation starts on frame 2 and stops on frame 15, once the character has finished turning.

This last detail matters.

You might be tempted to make the rotation completely independent from the animation to make it easier to interrupt at any moment.

But if the rotation is decoupled, an interruption mid-turn snaps the character abruptly to their final orientation.

Keeping the rotation tied to the rest of the animation, even at the cost of a little less interruption freedom, protects the feeling of motion continuity.


A completely free rotation is easier to interrupt, but harder to make feel like a single, cohesive gesture.

The compromise is settled within the window between the two blends..



Should turns on spot be standardized?


The number of steps a turn on spot must contain depends entirely on the system selecting the animation.


If the system operates via discrete angle threshold selection, each variant is free to have its own construction.

A 90° turn can be done in two steps, a 180° in four, with no need for structural consistency between them, since no continuous blending occurs between variants.

Even so, you still try to maintain comparable durations to prevent a 180° turn from feeling noticeably more punitive than a 90° one.


If the system relies on a blend space, where the engine continuously interpolates between multiple animations to match the target angle, the game changes completely.

ou must then standardize both duration and step count across every variant in the set, just as you would for a set of starts.

Without this normalization, blending between adjacent angles breaks down instead of sliding cleanly.


This is not an animation decision, but a system-level decision made upstream.

Yet it has a direct, concrete impact on how many animations to produce and how to construct them so they remain mutually compatible.



Mirroring vs. Dedicated Animation


This is the most delicate part of producing a turn on spot, and likely the one that deserves the most attention.


In theory, you can animate a single side and generate the other through animation mirroring.

This production shortcut works well enough as long as locomotion relies on a symmetrical idle, with equivalent support on the left and right feet.

The moment the idle becomes asymmetrical, with one foot clearly ahead of the other, the nature of the problem changes.

It is no longer just a matter of producing a left or right turn: you also have to decide what happens to the dominant foot at the end of the pivot.


Take a character with their right foot forward. If they turn to the right, the movement is straightforward: the right foot lifts, places itself in its final orientation, and the left foot catches up.

Mechanically, it is simple.


If they turn to the left, the logic reverses.

The left foot pivots almost on the spot until it becomes the forward foot, while the right foot ends up behind it.

Biomechanically, the character has swapped dominant feet.


From there, two solutions exist. The first consists of accepting this mechanics and having the character end in the opposite idle: the left foot, now in front, becomes the new dominant foot.

This is generally the most natural solution and the one that best keeps the character grounded on the spot during the pivot.


The second consists of maintaining the original idle despite the weight shift.

This is entirely possible, but it usually requires compensation elsewhere: a slight additional displacement, a placement adjustment, or another movement logic to return to the original support foot.

.


Comparison between maintaining the idle and switching idles on the same asymmetrical pivot.

The most natural result in-game is often the one that accepts the idle shift.

But this choice complicates production: you have to manage variants, transitions, and their associated state changes without ever messing up the combinations. The real issue, then, isn't animation mirroring. The real issue is managing support feet within a system built around asymmetrical idles.


Animation mirroring is a production shortcut.

Changing idles is a system decision.

Not to be confused.


The real cost of the system

A turn on spot often seems like a small building block. In practice, its cost depends mainly on the constraints placed upon it.

Part of this cost stems from choosing an asymmetrical idle earlier in the system's design.

As long as the idle is symmetrical, mirroring often allows you to reuse a significant portion of the animations.

The moment one foot clearly takes the lead over the other, the question of changing idles arises.

And that question impacts starts, stops, and turns on spot just as much as it does a good portion of the locomotion transitions.



I already brought this up in the article on idles: on Beyond: Two Souls, most of Jodie's idles were intentionally symmetrical, precisely to streamline the production of her locomotion kits, over 50 full movesets, each with its own idle, start, cycle, stop (including directional stops), turn, and turn on spot.

Being able to mirror animations allowed us to deliver those kits faster, even if some manual cleanup was still required, poses were never perfectly symmetrical to maintain a natural feel.


The stealth moveset, on the other hand, was asymmetrical: Jodie crouched low to the ground, one leg bent forward, the other extended back.

We had to rethink the entire logic to accommodate idle shifts and keep stops responsive; waiting for her to return to the default idle pose before coming to a stop was impossible, she needed to be able to stop on every single step.


We implemented two distinct idle states, complete with the necessary transitions between them.

That was fifteen years ago, and it seriously complicated the animation graph architecture.

Today, we would likely opt for a different approach, such as a layer system, to handle that mirroring and cap the number of transitions.


The cost of a turn on spot, then, isn't measured solely by the number of frames it contains.

It also depends on the idle conventions chosen upstream, as well as the number of variants, transitions, and edge cases that flow from them.



The camera


The thresholds governing camera behavior during a turn on spot play a direct role in the final feel of the movement. It is an important factor to keep in mind, even if I have never calibrated them myself.

On the projects I have worked on, this task usually fell to a dedicated team. At best, we test together and tweak certain settings alongside gameplay programmers and the camera team whenever the result feels too aggressive or too subtle.

As is so often the case in gameplay animation, the quality of the result never rests solely on the animation itself. A good turn on spot is above all the product of a collaborative effort between animators, gameplay programmers, game designers, and the camera team to build the best possible game feel for the player.


If a turn feels bad, check first whether it is actually the culprit.

The final feel often stems from the interaction of multiple systems working together.



What I check first


In blocking, before even thinking about polish, I verify several things in a very specific order.


First, that the chosen movement seamlessly fits the character's continuity.

A turn on spot must reflect their current state, slow, stealthy, observant, or action-ready, and never feel generic.

In mocap, this risk is real: it's easy to default to a neutral movement that tells you nothing about the character. In keyframe, the vigilance is centered on strictly adhering to the characterization established elsewhere in the project.


Second, that the pivot doesn't break gameplay flow: is the responsiveness there, and are the transitions to the states required to move out of it ready?

This is intentionally given a higher priority than polish.

You don't build a beautiful animation first and then try to make it playable afterward. You validate the feeling of control first, then you dress it up. In gameplay animation, functionality comes before cosmetics.

The player feels the quality of the control well before they ever notice the quality of the poses.


And finally, that the intended angle is actually reached. A turn can look visually convincing yet fail its primary function if the character doesn't land exactly where the system expects them to be.


All of this is verified during blocking, without polish. Once these three points hold up, I can focus on refining the poses and detailing in spline.



Conclusion


A turn on spot relies on very few frames, yet every single one of them carries a decision: where to cut, how to distribute the rotation, how to manage body asymmetry, how to preserve the feeling of control, and how to make the animation coexist with the system surrounding it.


Most of these decisions are made very early on.

Once the movement enters production, they nevertheless continue to dictate a large part of the final result.

That is also what makes turns on spot so interesting to build.

They stand right at the crossroads of animation, gameplay, and system design.


A small building block that happens to be an excellent litmus test for how a locomotion system was conceived.

And as is so often the case in gameplay animation, the best decisions are rarely the most spectacular. They are the ones the player never notices.

Comments


Services

Consulting

Coaching

Courses

Courses

Contact :

60 rue François 1er

75008 Paris

Mon. - Fri. : 8h30h - 19h 

06.21.44.27.59

Policy

Legal information

TCS

Privacy policy

Refund policy

Cookie policy

Terms of Use

FAQ

© 2025 by AniMotion. Created with Wix.com

bottom of page