Hello everyone! I’m almost a month into the 3D Platformer Udemy course now! This week, I will be covering Player Rotation, Idling, and Running. Let’s dive into Unity right away!
We’ll first start off with the relevant C# script (this is the same “PlayerController” script attached on our player object that we started working on last week):
Now, I mentioned last week that I would not go into dissecting C# scripts. However, there is one class of functions in Unity of relevance to 3D game development that I feel would be remiss if I didn’t highlight here. This key class of functions is called the ‘Quaternion‘. The Qua-what now?! To simply put, a quaternion is used to represent rotations. It forms methods such as Quaternion.Euler, Quaternion.LookRotation, and Quaternion.Slerp. These methods (all used in the script above) allow us to do the following three things, respectively: to move our player in the appropriate direction according to the rotation of the camera, to rotate our player, and to do so in a smooth manner. With the use of quaternions in our script, the following result is produced:
Next, let’s breathe some life into our robot! We’ll implement some animations to make our robot appear to look around (while standing still) and run as well. First, we create an Animator Controller and attach that to our player object. In the animator window (see below), we create two different states for the robot: ‘Idle’ and ‘Run’. We also create two transitions between the two states (as represented by the white arrows) as well as a parameter called ‘Speed’ to manage the conditions for these transitions to trigger later on:
By clicking a state, an animation can be assigned to that state. The player robot model has built-in animations that can be used. For example, the “Robot_Idle” animation is assigned to the ‘Idle’ state as shown below:
It is important to note that for the transition from the ‘Idle’ to the ‘Run’ state, it should not have an exit time (meaning the transition can occur before the animation of the idle state is complete). Also, the transition should have a fixed duration (meaning it takes a specified amount of time to go from the ‘Idle’ to the ‘Run’ state):
The opposite also holds true (exit time should be disabled and there should be a fixed duration) for our player to go from its ‘Run’ state to its ‘Idle’ state:
In the last two screenshots above (on the bottom right), you may notice that we’ve assigned the “Speed” parameter we created earlier to the transitions. This allows us to set conditions that would trigger those transitions. If the speed for the ‘Idle’ state is 0 (zero), then for the ‘Idle’ to ‘Run’ transition, we want to set a condition that this transition would occur only if the ‘Speed’ parameter is – say – greater than 0.1. And for the ‘Run’ to ‘Idle’ transition, the condition for ‘Speed’ should then be less than 0.1.
Finally, in our player controller script, we create an Animator class to allow us to assign the animator controller we created to our player object. In our script, we also determine the value of the ‘Speed’ of the player based on whether the player is pressing/holding down any of the movement directional keys:
Essentially, if the movement keys are being pressed, then the ‘Speed’ would be greater than 0.1 causing the ‘Run’ state/animation to trigger. If the movement keys are not or no longer being pressed, then the ‘Speed’ would approach zero and the ‘Idle’ state/animation will trigger. Our robot player looks a lot more lively now, don’t you think?
I hope this week’s blog was a good read for everyone! I look forward to next week where I will finish setting up the player robot by giving it a jumping animation, fixing some ‘game logic’ issues with the robot’s speed and jumping ability, and start managing some of the game controls and general aesthetics. Stay tuned!