Radio Noize! DevBlog 2: The Story So Far (Continued)
Alright! The last post focused largely on the changes to Faye's design, and this post will really just serve to recap what work has already been done. As previously mentioned Radio Noize has a working character design for Faye, the games Protagonist. Faye herself has of course been 3D modelled in blender, retopoed, skinned, ik rigged (excluding face), and base textured. This is to say I have a usable 3D model of Faye with workable diffuse textures. At this time Faye also has her necessary base animations. Presently Faye's animation list includes: Walk, Jog, Run, Sprint, Base Idle, Jump, Fall, Land, Coast, Turn Wide, Turn Short, Turn Dime, TOS (Turn On Spot) 45, TOS 90, TOS 135, TOS 180, Royal, Soul, Pornstar, Unity, and Powerslide. Some animations are done with embeded root motion (such as walk, jog, run, and sprint, which are all meant to move the player) while others (such as royal, soul, pornstar, and unity, which are all grind animations) do not (more on root motion later). Though materials have not been set, Faye has been brought into Unity, and has been set up with a Third Person Orbital Character Controller and Third Person Orbital Camera. This is to say that she's set up in such a way that she orbits around the camera when she turns left or right. This allows for more fluid motion, and angles in which the player will see Faye (as opposed to always seeing her back). This is done through Root Motion. Root Motion itself is taking the translation (movement) of the player object from it's animation. In other words, rather that having Faye run on spot in her animation, I had her move set amounts. Allowing her movement in game to be largely dictated by her animation itself. This allows for very precise movements that are easily observed, but hard to put down into 3D math. One would think that this would lead to very snappy jumps from one animation to another, however Unity's mechanim (state machine system) allows for the smooth transition between any two states (animations). Further more, one can achieve a sense of locomotion (the natural way a body moves) through the use of blend trees, which allow multiple animations to count as a single state blended by a specific value passed in script. At this point, Faye can move using animation alone. Faye aside for a moment, I have also completed the bulk of how I will handle grind rails. I have implemented a system in which one can create loopable bezier splines (curved lines), and an object instantiator which will create rail components along said splines. These rail components then know which component comes before or after them in a rail (if there is one). Faye then can engage the rail when she is within range of a component. Upon engagement faye will lerp (interpolate from fer current position to a target position) to each component's position. As this is motion handled through scripts, there is no root motion for her grind animations. Faye decides her rail bias, by comparing her heading angle to that of the component. if the way she is facing is closer to the components front she will move "forward" along the rail, if her facing is closer to the components back, she will move "backwards." Faye will presently always face the direction she is moving in, and of course she can switch grind animations and grind direction mid-grind. Result of current progress:
You can find a power point dictating future plans here: https://docs.google.com/presentation/d/1ezsbqFBNR_0wn55y-Wf9e6ZeEFwQ3zSU6xWZC9b8CIE/edit?usp=sharing