After handing in the script for the Ball Brawler, we were given a couple of PowerPoint files about the animator in Unity. I’ve been interested in learning more about the built-in animator since we did out walking simulators at the beginning of the year, especially for things like doors, windows, things falling over, etc. A lot of animations I’d had in mind were suitable for empty triggers, too, which I’d learned for the walking sim, but I didn’t invest extra time to look into the animator.
In any case, we had plenty of time to try out a simple lamp swinging animation and then move on to opening a door via an OnMouseDown button click. While I do like the accomplishment that comes with being able to script these sorts of things and using tweens to do them, the animator makes everything SO much easier. To begin, I had to make a basic lamp that could swing around from its hinge on the ceiling. The odd part about Unity is where the rotation points are on a primitive object – they all are centred. I’d come across this issue before, so at least I knew how to fix it.
It was an easy matter of using an empty GameObject as the “rotation point” at the top of my makeshift lamp – the object would then be the part that’s animated, so it wouldn’t look so… staggered.
The cylinder needed to be the parent of the sphere, so the latter would move along with the former, and they then needed to be children of the empty GameObject. After that, I could open up the animation window and start keying in my rotations.
Keying in Unity is like keying in other programs we’ve used for animation (such as Maya and After Effects). The biggest difference to keep in mind was that Unity’s default FPS will always be set to 60 – so 1 second of lamp swinging would be 60 frames. I could see how, for more complicated animations, the screen could get quite busy. I decided to just test keying a couple of swings around, just to get a feel for the flow of the animation process.
The curves sheet was also very similar to Maya, in that you could use it to smooth out the animation if you needed to. My animation was actually pretty smooth just from my keying, but I did have to fix the end key so it cycled/looped a little nicer.
I think the animation is quite good for a first attempt and I could see how it would be an extremely useful tool to add some life to an otherwise stagnant game scene. However, if I decided to make my models outside of Unity to bring in and animate, it seems very important to reposition the pivot points for situations like this. Otherwise, the model could easily look very unrealistic (such as my primitive one above) and doesn’t lend credibility to the created animation.
After that, I moved on to the door animation exercise, which just goes to show how useful it is to know the animator system. While we’d learned how to tween a door at the beginning of the year, and I’ve improved my script a lot more since then, I think using the animator cuts the length of that script by about 90%.
There was also always the issue that the doors could break partway through the tween, so the pivot point would be altered if the player clicked on the door multiple times during the tween. I worked really hard on my script to put in preventions for that, but an animation prevents it automatically. The door only has three states: idle, open, or closed. If you click multiple times on the door in between the transitions, it will change (so it won’t finish opening, let’s say, and just start closing), but there is no way for it to change it’s keys and therefore won’t end up idle in the wall by mistake.
I first began by making three different door clips for each of the states. This was easily done; the only thing I had to think about was how quickly did I want the door to open. For this example, I thought over a 1 second period was fine. If I were working on a creakier door in a suspense game, that could be slower, it’s so flexible.
After that, I needed to set up the links between my states. The transitions were important and it’s all click/drag so you can keep everything in a nice work flow. While this particular animation is rather simple, I suppose many animations could get quite complicated and it would be crucial to keep everything following a nice work flow. I think back to the rogue-like tutorial I did ages ago and the animator was used to transition between sprite sheets, depending on whether the player was idle, fighting, being hit by an enemy, etc. There were a lot of connections, so it’s important to take one’s time on this step and only make connections that make sense.
Instead of just leaving the door to open/close indefinitely, I needed to take off the Has Exit Time tick box and add a trigger condition to each of the transitions. I could then set up a “button” in my scene that would, when pressed, trigger the door to open or close.
I also needed to turn off the Loop Time tick box via the clips in the Hierarchy > Inspector for the open a close clips (the door idle seems find left alone, since it will then always loop through the idle clip when the others aren’t activated.
Finally, it was a matter of adding a very simple script to the button so it would activate the toggle and thus start the animation, depending on what state the animation was left in.
While I could have left out the triggerName variable, adding it in makes the script reusable on other animations and I prefer that idea. I could have some doors open inwards and some open outwards, etc.
Overall, it works amazingly well and I quite happy with it! More importantly, I’m looking forward to progressing with the animator and either adding use of the system into my older projects or using it in my future ones. As I said, while I love learning more and/or practicing my programming/scripting abilities, this does make some things just so much easier.