Simplifying

With such a complex character controller, it's really important to cut down on my mecanim state machine layout - that's just what i'm working on now.

So when I started out with animations, there were no weapons - it was just about getting a GTA/APB style orbit TPC up and running, which was done and it looked pretty good.  The state machine for movement was quite simple as well, requiring only a few states for movement since in this mode there is no strafing or backing up style movements, its just run/walk forward.

Then came combat mode and in order to give combat mode a narrower but more accurate/useful perspective, my thought was to switch the player into a strafing mode with camera above the shoulder.  This meant I needed strafing movements for both standing and crouched stances and the ability to walk backwards in both standing and crouched stances.

The problem is that limiting things to just N, E, S, W movement leads to a lot of wierdness in the legs when transitioning between them.  To smooth this out and clean up motion in general, I've found it necessary to move to N, NE, NW, E, W, S, SW, SE - or 8 directions instead of 4.

That's all well and good but another problem arises with this - using the states and building a network of transitions gets real ugly real fast.  So tonight was time to figure out another approach and since mecanim only supports ONE variable PER blend tree, using blend trees was not going to be trivial.

So the approach i've taken is to build four blend trees and have each tree blend between 3 related animations for it.  In this case, I have ForwardStrafing (for example), which blends NW, N and NE strafe movement.  Then theres RightStrafing which blends NE, E, SE.

In order to facilitate these blend trees it was necessary to use a couple speed variables hSpeed + vSpeed (or horizontal aka. left/right speed and a vertical aka. forward/backward).  That worked for determining states but it still presented two issues:

1. Grabbing the input from keyboard is essentially binary in nature - it sees full values immediately, so either you are moving E or moving W, no degrees between

2. Strafing movement tended to route through idle, causing blips in the animations.

Those issues where both solved by also creating vSpeedSmooth and hSpeedSmooth.  These values "lerp" between the current smoothed value and the target h/vSpeed.  This solved (1) by more gradually switching directions for a smoother turn and (2) by checking against smoothed values to return to idle, which will only be called if the user releases the keys for long enough to lerp back down to idle.  The only issue I have with this solution atm is that the player will not stop on a dime, which often is desirable if you want to peek around a corner or over a ledge without animating past them.  Adjusting the smoothing speed should resolve that.

So here is a comparison between the new approach and old, note the left hand side is the new blend tree approach for standing strafing, while the old is the right side (to be replaced soon!) and represents crouching.