Hello, I’m Seith and I’m the main developer of Ghost of a Tale. I supervised animation at Dreamworks on quite a few movies (both 2D and 3D) and served as animation director on a couple more (including Despicable Me).
Developing a game is a new experience for me but I think using Unity made the experience that much more enjoyable (I tested a few other game engines before I went with this one).
I often get questions related to how characters are made in Ghost of a Tale, so I hope this will answer some of them.
What makes game development different from my past professional experiences is that when I was working on movies I was concentrating solely on acting and animation. But on GoaT, since I do a lot of different things myself (coding and animating are VERY different beasts) I’ve had to learn how to let go off a lot of details and instead keep in mind the whole picture at all times.
To speak plainly I have had to go fast and cut corners as much as possible (as long as it still looks acceptable)!
I usually create the models in Maya and then use Zbrush to do surface details when necessary. I tend to keep the meshes fairly low-rez. Most characters use a custom shell fur shader (customized by @Cosmogonies) which allows me to orient multiple fur areas in different directions, all within Unity. The number of passes varies depending on distance to the camera.
Rigs are created in Maya using “The Setup Machine” (http://www.anzovin.com/tsm/). The animation rig is relatively complex and wouldn’t be exportable to Unity as-is. So that rig acts as a master rig while a simpler “all-FK” skeleton is derived from the animation rig. That slave rig (joints + mesh) is the one that gets exported to Unity.
Oh and the nice thing with fur is it's very forgiving with crappy weighting. :)
Mecanim then drives the character’s animation as its parameters are dictated by the behavior scripts (based on gamepad/keyboard inputs for the player, AI behaviors for the enemies).
I also implemented a dynamic props system that uses the characters’ joints hierarchy to attach items (be it rigid or skinned) using a custom version of this asset.
Once again all those fancy systems only come alive within a certain distance threshold to the camera. So the overhead is fairly limited. That’s actually a very important part of the optimization process: only doing nice things around the camera, reverting to crappy/cheap stuff as soon as possible!
I apply this principle to everything in game including static sets and dynamic objects, like this vegetation bend behavior (which is still WIP):
In this precise case I reuse the character’s cloth/props colliders so the footprint of the system remains minimal. A rudimentary skinned model is used for plants deformations. I chose this approach because often using a shader for dealing with collisions ends up with a "vertices-warping-to-avoid-a-capsule" effect. And also because I'm not a shader wizard. :)
As a closing remark I would say that adapting the game to consoles was an eye opener; on a good gaming PC you can be sloppy in your coding and the game would still run kind-of-okay. Not so on consoles. It takes a lot of optimization to get the game to run for example on Xbox One at 30fps while still looking exactly the way it does on PC (minus the resolution of course).
But that would be a topic for a different story… ;)