Decisions, Decisions Pt.1

Prologue: This is Part One of a bigger issue. It was originally one long post, and has since been edited for brevity.

I've had a new issue come up. Maybe issue isn't quite the right word though, quandary sounds like it might be more accurate. I need to make my models animated, there's two different ways to do it, and I'm not sure which one is the better choice. Unfortunately, it's not as clear cut as it sounds. Both have bigger implications further than 'do the animations, save, and apply'. The issue at it's core is whether the animations should either be

* Done in Blender, then imported to Unity, or
* Done entirely in Unity, by way of scripted events

Normally, this is a matter of personal preference; whichever program you're more comfortable in is what you use and you get roughly the same result. The result I'm looking for is controlling the way my models move in various situations: specifically I need an idle state (doing nothing), walking (moving slowly), running (moving fast), and death/respawn. This particular situation has an issue with what happens after you do the animation; how do you handle the movement and physics of these objects? This changes depending on which way you go, so let's just look at both cases individually to see what happens.

Animating in Blender, Importing to Unity
Animating in Blender is a little convoluted to explain, but pretty straightforward to do. In the animation window you select what frame you want to end at, position your object(s) at the beginning, reposition them how you want them to end up, and Blender does the rest. It's called Linear Interpolation, and the easiest way to explain it is that Blender measures the position, rotation, and scale of the object at the beginning and end of the sequence, then changes all the values linearly to turn State 1 into State 2 over a set amount of time. You can take it a bit further and change the Bezier curves too. Those are the "line" part of "linear"; it's a visual way to see how the changes move over time. For example, if the beginning is 0% and the end is 100%, maybe you want it to dip up to 110% right before it settles at the end. You can do that!

Rest assured, there's several dozen horizontal lines going on here. See all that stuff on the left?

Curves can get tricky though. Each possible value has it's own curve you can alter. That means for each object (the unicycle, for example, is 11 objects), you can alter Location, Rotation, and Scale for each of the 3 axes. There's also transparency, diffusion, shaders, and a few other traits that can all be changed in animation. If you're keeping count, that a minimum of 132 possible traits to be altered for an animation for a single (simple) object. If you were doing an entire scene, not only do you have to keep track of however many other multiple objects in the scene but also the camera, lighting, and the headaches involved with staging the scene properly. Thankfully I'm not, and most of my animations will be pretty simple.

Give it a little flourish!

Now let's skip ahead a bit and assume I've got my unicycle's 4 animations done and ready. Once I go back to Unity everything will be there waiting for me. All I have to do is write some scripts to say 'if this is happening, play this animation', then make sure they all work. A little fine-tuning later, and that's pretty much it.

It doesn't lurch forward yet, but look at it go!

Animating in Unity through scripts
This one's completely different, obviously. I still have to tell it 'if this is happening then do this' but I have to specify what 'do this' means. Like with most scripting problems, there's a dozen or so different ways to do it, but I only know one or two. Here's a (very dirty) quick pseudo mockup of what 1 animation state would look like for a "running" unicycle:

if (getButtonDown == "Right") {
   xVelocity = vehicleSpeed + xVelocity;
   if ((xVelocity > thisSpeed) && (xVelocity < thatSpeed) {
      gameObject.wheelAssembly.rotate (0, (xVelocity * 3.60), 0);
      gameObject.pedalLeft.rotate (0, (xVelocity * -3.60), 0);
      gameObject.pedalRight.rotate (0, (xVelocity * -3.60), 0);
      gameObject.yFrame.rotate (0, ((xVelocity / 10) * 3.60), 0);
      gameObject.yFrame.transform (localX + (xVelocity / 15), localY + (xVelocity / 15), 0);
      gameObect.seat.transform (localX + (xVelocity / 12), localY + (xVelocity / 12), 0);
   }
}

You can see sort of what's going on here. If the player is pushing 'Right', then increase speed. If the horizontal speed of the object is in a certain range, the wheel assembly rotates around, the pedals rotate backwards (to stay parallel to the ground), the frame tilts and lurches forward, and the seat moves to match the frame. Since this is being written from scratch, I can make it as versatile as I want. I could probably get the walking and running animations under the same set of conditions, I can change the values to fit whatever I need to on the fly (as opposed to going back and forth between programs testing values). I can also use this as a template for vehicles later. Copy, Paste, change a few variables around, and my next vehicle is animated and ready to go too. It takes a little more creative thinking to solve, but could easily save a lot of time.



There is a common issue to both choices though, and that's trying to make the animations and their physical movement line up properly. The appearance of sliding around just looks bad, as does awkward wheel-spin. While a big part of that is just tweaking the animation so things match up, an equal amount is handled by the physics in the game itself. That's for the next section though; it has it's own pair of choices to decide between.