[Click here for the video version]
Hello everybody, welcome to this week's game developer log on The Stars our Destination. Been working on the 3D flight section mostly, specifically about getting one animation system working.
When animating characters, with the sprites or models is usually no problem because the animations themselves are stationary, and code gives the illusion of movement. Vehicles are a different story.
Okay, let me specify. Most vehicles don’t need any extensive animations outside of the wheels I guess (never worked on a racing game before). Even the ship didn’t have animations before this point. The problem arises when the animation also has to update the position and rotation of the object.
Using Unity’s animator component just resets the object's position back to its original position after the animation is finished, and doesn’t take into account the object's position and rotation in the animation, favoring the worlds position and rotation. And it’s only for one object, so the camera isn’t included unless there’s some special logic attached to it. Getting the object to end up at the exact position, and rotation is super tricky. This’ll be kind of a brief history of getting this animation function working.
I have to put up a warning, this’s one of the most overthought, over complicated solutions I tried in a long time. I thought that calling the main camera to do something would lead to some over complicated code. So I thought if I can activate both via an animation that would lead to less code and it would do its thing.
To work around the position and rotation problems, I made a new ship model, and new camera a child of the main ship game object which is empty, since the already move and rotate within the parent object.
When the conditions were met to trigger it, it would turn off the main ship model and main camera and move the “dummy” ship (Figure 1) and camera, and reorient and turn on the originals after the animation is finished.
This worked for the most part except that there’d be a whiplash like effect with the camera switching that was actually more distracting and irritating than effective or efficient. Reversed those attempts and moved one.
If the animator wasn’t going to work, I’d add coordinates to the objects current position and rotation, via programming to solve the world vector problems, but the unity rotation system thought otherwise.
I made little pieces of data holding even smaller pieces of data called scriptable objects for each “keyframe” after making test animations with the animator, and plug them into the animation handler script (Figure 2). Which would play the “animations” at set speeds, and move onto the next “keyframe” when the coordinates are close enough to the other one.
This lead to crazy movements due to how unity valued rotation vectors. If the values go over 360 it doesn’t change to 0 and reset, it just keeps increasing and makes coding complicated, specially when setting it to the negative numbers, which also don’t reset. I don’t have much to add on except that this was an experimentally terrible idea.
The answer was in the engine already, the Unity Timeline window (Figure 3). It’s usually used to make cutscenes, and manipulate multiple objects at once. I was able to take what I learned, and not learned from the other attempts, and adjust how the camera follows the ship and it’s now silky smooth with no camera snapping.
The camera smoothing needs some work but that’s easier to manage.
This was a loaded first developer log, I wanted to try a different approach and make summarizing a little more interesting. That’ll be it for this week. Let me know if you have any questions of feedback, take care of yourselves and have a good week.
[Click here finished result]