Hello folks, we are going to continue talking about the work the Freaky team does, but today we are focusing on the animations inside To Leave. For those who have tested the game recently, you could’ve noticed how sometimes a scene with so many little animated objects in-game can run so smooth on PS Vita, well, it wasn’t so easy. It took learning some basic guidelines about how animations work, 3D animations, 2D animations, understanding what the engine does in background with your code, knowing what the guy who models/paints the animations can do and of course, a lot of hard work.
As we know, To Leave is being made with the Unity Engine and today, Jorge Blacio and Javier Ron, both developers, are going to tell us what the process they followed is, and how it led them to the animations that you can appreciate today inside To Leave.
Before To Leave
When the team started to prototype some ideas for games, they came out with one that made them learn how the Unity 3D animation system worked, let’s call this project codename Springg, then Jorge Blacio started to work with the Unity Animations System to make animations work for this project:
Let’s say we know how a simple animation works, what you need first is a mesh – a 3D model, with animations, and since we are programmers and, usually, at least for me, it’s impossible to create meshes out of nowhere, an artist gives you the mesh. You then import this mesh into Unity and since it already has a 3D Animation System in place, if you wanted to reproduce a single animation, you can just call it in code by its name.
Back then, with its legacy system, Unity let you control a few things like the animation status, how fast it reproduces, its length, smooth transitions and blending between animations. Even if you are not an animator, you need to learn animation concepts, it’s your responsibility that the animations show the character behavior without strange movements or expensive performance. You also need to communicate a lot with the animator, understand his way of work and what he can do. This benefits both of you, since if you both can really understand each other, you can end up saving him some animations and he can end up saving you some tedious coding.
Example of a mesh with its skeleton.
After this the team decided to make codename Springg a 2D game instead. There was a learning phase again: how do you make the stuff you used to do in 3D, now in 2D? How the artist should give these animations? A really big sprite sheet or a lot of images one per frame?
With To Leave
Rendering one sprite of the sprite sheet at the time was kind of easy, control some properties like velocities and positions too, but then To leave came by and it had more demanding requirements and a wild problem appeared for Jorge: how do you make Harm’s (the boy) movements smooth while flying without having tons of sprite sheets for each movement?
Well, we couldn’t think about punctual statuses and positions, Harm can fly up, down, up-left while falling, down-left while going up and right and almost every direction, so you cannot make and animation for each one of these directions since its way too much work for the animator. Also you need to consider make these animation’s movements to look good when Harm has done a small displacement.
We agreed with the animator that we were going to do something like 2D blending of animations. So the need to create a 2D Animation System in Unity (We are talking about back in the time that Unity was 3D only) came up, and since blending was something we wanted, the system needed to know in which frame the animation is so if you are falling and you press to go up, the system calculates how many frames the falling animation needed to finish and then, the going up animation starts with this information, so that it knows in which frame to start to give the illusion of blending.
Some of the Harm’s movements, Up, Down, Down, Up-left
Until that moment we could do:
- Enqueue of Animations
- Reproduce a big sprite sheet or a clipped one
- Loop Animations
- Reproduce backwards within an specific stretch
- Abstraction, you can add it to any object in the engine as long as it had a renderer and a material.
- Our 2D blending
- Random loop, which means that it randomly picks a frame and loops the animation from there. (This is important, trust me)
After all this, Javier started to take upon the task of looking for something that help him optimize the game’s performance, stumbling upon 2D Toolkit, a third party tool which let the team package the game textures in a particular way:
2D Toolkit let you package the images/sprite sheets cutting them and keeping them in an atlas without transparency data, these files are reconstructed in runtime, depending on the level you are playing, separating the way it renders sprites if you decide to. This tool, also allowed you to manage animations using the packaged textures of course, and we decided to test this animation system. We noticed performance improvement so I started to migrate from Jorge 2D (yes, we named Jorge’s system Jorge 2D) to 2D toolkit, some features were just re-implemented from the ground up.
With the arrival of Unity 5, we decided to give it a try to the 2D System Unity have been upgrading since Unity 4.3 I think. We did a benchmark running some levels with 2D Toolkit and Unity 2D, for our surprise, animations run faster with Unity’s native system. So we decided to use the Unity 2D animation system to render the game’s animations and since the packer of 2D toolkit was still a major feature for us, we still use it for static textures like a level’s background for instance. This makes the game to use less resources in runtime and have better performance overall.
This is all for now about the animation side of things, I hope it helped you all gain a little bit more insight of what has been like so far developing To Leave. Next time I’ll try to catch on the musicians of the team or maybe the writer/lead level designer, who knows. See ya!