Prediction is Guessing

I explored prediction because we needed a way to calculate a rotational velocity for blending in lean poses. The implementation we had seen for that was calculating a rotational velocity over several frames or just using the difference between input stick direction and current movement direction. I thought we could do better than that so we moved towards storing a history of positions and rotations. Using the history of positions to calculate an angle instead we could weigh that towards the beginning or end of that history depending on the reaction we needed.

It worked well, it allowed us to get a reaction that suited the movement of the character since it was tied to the distance moved and then eased out as the character straightened out his direction. So gentle turns would introduce a gentler lean and a tight turn would trigger a strong reaction.

The next step was inspired by seeing Assassin’s Creed doing stabilization on facing in their runs to keep facing in the general direction of movement instead of reacting directly to the stick. That was to us an awesome improvement but we wanted something more reactive than what those games generally had at the time.

So we utilized the history of positions to also calculate the facing of the character with a tunable weight that worked together with the leaning. This meant we could tackle and clean up the motion where the player deflects the stick left and right rapidly. It worked and greatly helped stabilize the result.

These were small incremental improvements but in animation systems every little bit helps to create a more believable motion. To be able to use that particular stabilization improvement we also used strafing animations, it’s enough to have 45 degree animations in your moving animation blend space if you don’t want to create an entire strafing set.

How you utilize those strafing animation is by sending the stabilized facing as the facing direction in strafing and then using the direction velocity as angle of movement in the strafing blend spaces.

For landing we’ve implemented a solution that comes from other games that predicts the time to land by extrapolating the falling velocity to create a parabolic arc and doing raycasts to find the time to ground impact.

The animation solution using that is basically a blend space for falling that brings in an anticipate landing pose the closer the character gets to the ground, in games where you have air control you want to bring this in dynamically as the distance to ground can change. Currently we’re also doing this anticipation together with another dimension for how far the character has fallen.

This system was relatively easy to understand and it served the very important purpose of connecting the animations to the path of the character. So I thought it would be possible to use this system for more since there are many problems to solve in animation systems.

That connection was key to realizing gliding, banking and reactive switches in direction and a smooth transition from gliding to swimming.

Connecting the pitch and yaw of the gliding blend spaces to this history meant that we could calculate a smooth flight path and by adding on tracking of acceleration we could bring in reactions to changing banking direction and angle of descent which added nice details.

When we tweaked the physics this system was automatically giving out a path that followed that arc and similarly to on ground if the player was flicking the stick left and right the path was filtering that noise out. There were some issues that came in from having to renormalize the blend values from the system on large physics code or setting changes.

However, the cherry on top was the transition from gliding to swimming. The physics code for swimming simulated water resistance and slowed the character down on entering and as the path changed we just kept tracking the movement and applied the same pitch and yaw tracking to the swimming blend spaces. There were additional tweaks for that state specifically but since the prediction was active through multiple states it became a fluid transition.

The limiting thing about this system is that it is just using history to predict and that’s not very useful for acceleration and deceleration so if you can expose the functions that calculate velocity to this you can predict acceleration and using the history you can extrapolate rotation that is filtered.

With that you can then accurately predict stop location and starts. If you then add collision checks to this you can anticipate running into and around walls.

The next step is to feed this path and additional data to a motion matching controller.