2D Game Development – Sprite Animation (Redux)
Day 064 #100DaysOfCode
Day 018 #100DaysOfGameDev
Yesterday’s lessons on sprite animation, while productive and successful, left me with my head spinning as I struggled to actually grasp what I had been taught. I am the kind of person that doesn’t like to move on to something new until I really feel like I have my head wrapped around a concept or lesson. As such, I decided today to revisit sprite animation and really make sure I have the code part of it completely nailed down.
EnemyController
The first script I wrote was for the enemy robot in the game. His movement is simple and linear, only walking back and forth either vertically or horizontally at a set interval. To this end, the robot’s animation only needs to match whatever route he is walking and loop accordingly.
To set this up the Animator component from Unity is referenced and a variable is declared that will be used to interface it. After that, the data from the Animator component is retrieved in Start, which gives the baseline for where everything will begin.
Next, in Update, the real meat of the animation control is set up. The direction of travel has already been determined by previously-written script and movement is occurring. The robot’s animation state has been mapped out by its Blend Tree and the command SetFloat is used to send parameter data back to the Animator. This tells the Animator to play the proper animation for either Up, Down, Left, or Right movement.
RubyController
Just like with the EnemyController, the RubyController gets the Animator component variable. After that, something new is added: a Vector2 type variable called lookDirection, which is declared with the values 1 for x and 0 for y. This variable will save the direction Ruby is looking as it is possible for the player to change direction at will and the controller will need to know what animation to call depending on that direction.
Rather than calculating separate x and y positions, like had been done previously, a Vector2 variable called move is now used to store both of these coordinates in the same line.
Because Ruby is player-controlled, this means she can not only move in any direction at any time but possibly not move at all. When this happens her movement coordinates become (0, 0) and we need the code to tell the controller (and animator) to not play and to keep her facing in the last direction she was moving in. This is done with the assistance of the Mathf.Approximately function. Approximately is used to indicate a number is close to zero without it being absolute zero, which may not always be the case as we are using float variables for positioning.
Movement now gets calculated based on x and y vectors which will extend out based on her speed. This is known as the vector’s magnitude. These factors are now used to determine the character’s new position.
The final part of the newly-revised RubyController is having the Hit animation play whenever Ruby makes contact with a damage-causing object such as the spikes or the enemy robot. This is nothing more than a simple trigger.
Now that I have fully broken down how sprite animation is handled up to this point, I feel like I have a much better handle on how and why it is coded this way.
Also, I forgot to put the trigger for the Hit animation in my code yesterday so here it is at work:
