Progress on the prototype for StarCaster is proceeding at a slow but steady pace as we build up the core of the game. Here's a quick video of progress on the movement and character animation systems.

It's at this point that I'll clarify that I didn't initially have that much depth of familiarity with Unity's animation system, being that the majority of 3D games I've worked on have been in Unreal -- everything else I've done in Unity has been 2D, and usually my projects circumvent mechanim with an alternate animation system rather than using it. It was therefore necessary to study the animation state machine system and figure out some best practices for blending and transitioning animations; hence why Mark put together these models in the first place.

Per my previous post Mark built all of these characters based on a shared skeletal hierarchy. All of their skeletons use the same names for all the joints, and therefore at least in theory they should all be able to share animations.


It turns out, that's completely trivial. The Humanoid base model is the parent of all our animations, and so long as the animations Mark exports use the naming convention "humanoid@animationname" they'll automatically import associated with that parent. From there it's a matter of creating an Animation Controller for the state machine.


It's pretty simple for the time being, with a Grounded state and a Falling state at the base layer. The states thus far make use of BlendTrees, which smoothly blend between multiple animations to create a nice transition between idle, walk, and run.


The avatar's speed is not hard-set, but rather it accelerates and decelerates based on a desired value, which is given by the tilt of the control stick. If I've got it tilted past the 50% mark, it'll want to move at 6 meters per second; if I've got it tilted below that, it'll want to move at a more casual 1.5 meters per second. While our desired speeds are more or less clamped, making these intended modes of movement feel clean and usable, the acceleration of the character's actual speed combined with the blending between the different movement types makes the transition between the animations feel more smooth and natural. This is provided that the speed being fed to the animation controller as a parameter is also stable, of course.


We also have look directions, which are still additive poses that get blended on top of everything. This allows characters to look in a variety of different directions while also performing their animations.


Translating this into a system that reliably tells the character where to look is a different matter completely, but our intent is to make it so that characters can look towards different points of interest or towards each other when their center of attention changes. We've got a "point of interest" setup in the works that automates NPCs' and party members' areas of interest, inspired a little bit by how Elizabeth behaves in Bioshock Infinite, wandering from object to object and sharing observations and commentary. At minimum it allows the player's avatar to look at things that seem interesting, giving an extra layer of feedback as to what in the environment is interactable; at most, we want to make the party feel a little more alive compared to the games of yesteryear that inspired our project.

Before we can top that off, though, we've got to handle a few other things, most especially the camera. Cinemachine gives us a great head start on a camera system, but we've got to put together a layer of abstraction that will make it quick and useable to set up different camera locations in gameplay. Stay tuned, because that'll be the next update!