Firstly, Unity compiles down to a multitude of platforms. Flash is great for iPhone/iOS development, and does a passable job of creating Windows executables. But Unity does all this and a whole load more! It can compile for Linux and Mac, as well as iOS, Android and Windows, as well as consoles like XBox. And it works with native .NET code, as well as Unity-targetted sort-of-javascript.
All this meant we had to give it a try.
First up, we hit the Asset Store and bought an entire mobile-friendly sci-fi environment called Top Down Sci-Fi from Manufactura K4
While we're still not sure how to optimise for mobile (it involves creating single sheet textures, fake lighting and low-poly count objects, apparently) this kit looks great not just on mobiles, but even on our large dual-screen setup.
Using the environment was as simple as throwing some money at the screen, following the installation instructions and hitting play! It worked straight "out-of-the-box" with no coding or setup required. We're going to have a play about with that at some point in the future, but now we needed some characters to populate our sci-fi environment.
Now there are plenty of online tutorials about creating meshes, setting up skeletons and rigs and animating characters using software like 3DS Max and Blender. But this is a whole world of development that we just don't have time to invest in! Far easier to exchange some cash for some pre-made assets from the Unity Asset Store....
Over the last couple of weeks - partly out of eagerness, and partly because we've no idea what we're doing - we've done a lot of this kind of swapping cash-for-ones-and-zeros, and have a few different assets for Unity, all of varying quality.
Some of the better assets we invested in are the StarDudes by Allan McDonald.
These are not only great-looking characters, but are relatively low-poly (so ideal to put into our mobile-friendly environment). They also have a variety of head types, to easily create different character races, and different materials/textures to quickly change the look and feel of their space suits.
The characters also come with an assortment of great ready-to-go animations. These include two idling animations (where the character stands still and looks around, casually) as well as some walking, firing and drop-down-dead animations to boot.
The slightly toony looking characters don't look at all out of place onboard our 3d spaceship - which itself has a slightly cartoony feel about it, thanks to the solid black lines and bold use of colours.
There are a few different tutorials online describing different ways of creating animations in Unity. In recent releases, it uses a system called Mechanim, which uses a simple state machine to blend between animations - there's nothing to shatter the illusion of immersive game play like a character that snaps from one animation straight into another. The Mechanim system does away with this, creating "transition blends" from one (or multiple) poses into another (or others).
It has taken some time to get used to the mix of visual drag-n-drop and script/coding approaches that are required to make Unity work, but once you know what you're doing, animating a character can be quite straightforward (until you know what you're doing, it can be a horrible, confusing, frustrating experience as there's nothing immediately obvious to tell you why some characters will happily take up an animation sequence, while others stubbornly remain in their default T-pose).
Every character (that needs animating) needs an animator controller. This is a file that describes the state machine that controls the animations. "Inside" the animator controller live all the animations, and the relationships between them.
Because Unity still supports the "legacy" method of animating (by placing the animations directly onto the model, without the use of an animator controller) and also animation by scripting (where a script placed on a model manipulates the rotation and position of the rig bones directly) simply comparing two or more models to see how they work often leads to more confusion than explanation!
Here's how we animated our StarDudes characters:
First, place a character in the scene.
Create an animation controller. At this stage, it's little more than an empty file.
Drop the controller onto the model in the scene. In the model properties you should now see the controller linked to the model
It's at this point that we need to add our animations.
With the model selected, open up the "animator" (not the animation) window from the menu
Now find the animations you want to use with this model, and drag and drop them into the animator controller window. To preview an animation, expand the file containing the animation (a lot of animations "hide" inside .fbx files so click the little grey arrow to see all the contents of the file). A single click on the animation will display it in the preview window. Once you've found the animation you want simply drag and drop it into the Animator window.
The first animation placed in the window becomes the default animation. If you add in more than one animation here, you can choose which one should be the default. The animation in orange shows the default animation - all other animations appear in grey.
At this point, you can try out the game, and see the (default) animation being applied to the model. If all has gone well, instead of the default T-pose, the character should be playing your animation:
Flip back to the Animator window, add some more animations, and right-click and drag the transitions between the animations. Click on each transition arrow to set the criteria that triggers the transition.
For example, we might decide that we have our character idling to begin with, so we right-click and make our idling animation the default. We might then decide that should the player's speed increase beyond zero, the character should transition from idling to walking.
Any transition defaults to blending from one to the other after the first animation has finished playing. Exit time shows how quickly one will fade into the other.
We do this by creating a "one-way" transition from idling to walking, and set the parameter "speed" to "greater than zero". This means that as soon as our player speed is positive, Unity will gently blend the idling animation into the walk cycle animation. There's no need to do anything other than create this releationship - Unity takes care of making one animation transition smoothly into the other, without any nasty jumping or flailing limbs.
But now our character just walks and walks and keeps on walking. We need a way of getting him to stop, when his speed reaches zero again. This means we need to create a second transition - only this time the "direction" goes from the walk cycle to the idling animation; and this time we set the criteria to "speed equals zero".
That's it.
Now, whenever the player speed is non-zero (and positive) and the character is displaying the idle animation, Unity will ease the character into the walk cycle. And whenever the character is running the walk animation, and the player speed drops to zero, Unity will east the character into the standing-still-and-idling animation.
All with a bit of dragging and dropping, and not a single line of code!
No comments:
Post a Comment