Trying out Skeletal Animation for Top Down Characters

Making 2D top down characters for a 2-player game, how hard could it be? Pretty hard but not impossible as we found out in the course of four months developing Goon School. What follows is an account of the roller coaster ride the team at Zebu had building these little thugs. (This blog post appeared earlier on Zebu Games)

The Concept

It was early September when I first showed a prototype to the rest of the team. Aptly called 'Tug of Words' it had two players playing against each other on the same screen. The objective was simple: be the fastest to uncover a hidden word and 'tug' it towards your side of the screen. Crossing a line meant you won. There were few issues with the real estate, but the game mechanic worked. We had to now figure out how to make the game more lively.

The past two games made by us were very much on the minimalist side and so I made my case for making this one as un-zennish as possible. There would be player avatars that took some action with every word uncovered.  Debates raged on what this action could be. Everything from cowboy shooters to raccoons to rope tugging minions were put on the table. But it just wouldn't fit. The first few prototypes failed miserably to engage players. Most wouldn't even notice the extra action. A week went by, then a month without any breakthrough.  Finally, it dawned on us that we were too fixated on making a realistic

connection between what the players did with the letters and what could happen in the game world. Not necessary we realized!  Anything can happen in a cartoon, so can in a game!

Since all it mattered that a player relates their tile tapping action to a consequent avatar response we needn't have the two physically linked. A fairly simple story ensued: Two street thugs pitted against each other with the faster player triggering his thug to land a punch on the opponent. Partly inspired by the (failed) 1984 NES game Urban Champion, the aim would be to 'push' the opponent towards impending doom, say a manhole on the street.

Easier Said Than Done - Sprite Sheets

All pepped up, I set out to create the artwork for a street boxer in top view. I was no artist or designer but with the help of a cheap graphics tablet and the wonderful painting suite Krita, I managed to get a crude walking, punching, and tumbling character at 1 frame per second. Not bad for a guy who applied most of his sketching skills to flowcharts and block diagrams.

Sprite sheet of the home made street boxer

It was the first step in the right direction after a bad month. After getting the team and our inner circle of friends and family excited by the fresh prototype, we decided to go with the thugs and goons story. At this stage certain requirements were already beginning to come out:

Implementing the animations in Unity, our game engine of choice, was fairly straight forward. Mecanim handled the internal animation states unique to a character but a standard interface was defined to ensure compatibility between different characters. More on that later. The animator also controlled external variables to control movement, for example to sync with walking motion.

Sprite sheets gave a lot of freedom to the character behavior but came with a big drawback: creating the actions at 24fps needed enormous effort which no single artist that we approached was willing to do (the artwork being in top view made it even harder).  With a minimum of 5 poses, there would be hundreds of high res memory hogging sprites. We had to drop this approach.

Spine or Spine-less

Skeletal animation for 2D characters is commonplace in side scrolling games, but I found very few games using that technique in the top-down games. One notable example is the heist game,  The Masterplan. The robbers in the game consist of body part sprites layered in the z-order and hierarchically parented (e.g. hips->torso->head->cap). There weren't many detailed movements but it gave me the confidence to try out top down skeletal animation. To begin with I got the free edition of Spine, the de-facto skeletal animation toolkit and tried tinkering around. Spine boasts of some wonderful features like character skinning, animation blending, free form deformation among others. It looked like the perfect tool for the job and I almost bought it at first sight.

But as I delved deeper into the workings of Spine and skeletal animation in general, several challenges cropped up:

Spine brought its own set of specific issues. The default spine animation system required a separate runtime where there were no means to animate external variables (remember I needed these variables to control the movement of the character). A 'baked' version was available that used the native Unity Mecanim system, but here the FFD (mesh deformation) capability was lost. All put together I found that Spine wouldn't be of much help, or any skeletal animation plugin for that matter. So I had to build a system from scratch.

A Bare-bones System

If we drop out the bones and IK from a skeletal animation system there isn't much left other than a hierarchy of game objects controlled by an Animator. Keeping flexibility in mind, I built a game object hierarchy with every game object having an extra child object that contained a set of sprites. This way I could combine sprite switching with regular transform manipulations.

Each of the sprites was arranged in z-order (sorting layer order in Unity speak) such that they layered correctly over one another to resemble a human body from top view. I set the pivot points of each sprite to approximately reside on the joint of that body part. The body part sprites, of course, had to individually created  by me as it was deemed too risky for an external artist to take part in this experimental system. With the initial posing done I was ready to animate life into the body.

Fun with Animation

It was my very first time animating a character and I must say the whole experience was quite rewarding. It was akin to puppetry but far more constrained. Having a hierarchy mapped to human anatomy sped up the process quite a lot. I made a total of 5 different animations (just like for the sprite sheet based character) and wired them up to Mecanim's state machine. As an added bonus I could smoothly transition between two animations (blending). The final animation ran at a butter smooth 60fps letting our first goon put up a hilarious performance.

Mecanim State Machine of 'Duh Goon'

Duh Goon hitting another

Satisfied with this technique it was now time to acquire professional artwork

Chasing The Artist

Getting the right type of artist to do the top down artwork was far harder than we expected. Most of

the game artists we approached either backed out or quoted ridiculously high prices once we showed the top view samples. We had to look elsewhere. Scouring the vast underbelly of image stocking sites we came across a few goon mugshots that a Serbian artist had put up. The cartoon-ish art style was close to what we wanted so we reached out to him. He had never worked on games before but was willing to take up the project to build his portfolio. It was a risk worth taking so we signed him up.

We made a short project brief for him to understand the requirements and also introduced him to basic concepts in game building. He turned out to be an excellent character artist; crisp artwork for the first goon was delivered within a week. Sadly the images were not decomposable into individual body parts. This was an important requirement that got missed so I had to ask him to redo assets no matter how upset he got. Surprisingly he took it pretty well and the corrected assets were in my inbox the next day!

 I now had 9 different poses of our first goon Mad Marcus from which I had to create my entire animation set.

Putting it Together

Dissecting the 9 poses got me close to 300 different body part sprites (sounds little gross!). The artist had found it easier to recreate some parts for each pose. This presented a problem as switching so many sprites would lead to jerky animations. Thankfully many sprites were very similar to each other; I discarded such sprites arriving at a minimum set of about 50. These I placed on the earlier skeleton hierarchy, making sure the similar sprites were aligned with each other. At any time, only one of the sprites would be enabled for a particular body part. To allow batching of draw calls in Unity, all of them were given the same packing tag.

While animating, I would look at the various poses and try to make a smooth transition betweenthem. E.g. for the walk cycle I would start with the idle pose transition then theleft foot ahead pose then back to idle then right foot ahead and so on. The legs were the hardest to animate since the ahead-leg sprites were different from the behind-leg ones; I had to switch them just as they went under the torso. The recoil pose also proved to be challenging to animate. There was no backward movement in the animation; instead, Mecanim animated external variables that controlled character position. [Mecanim only works with absolute values, we needed relative values, in this case, hence the arrangement]. So I had to imagine the character falling backward as I tweaked the animation keys. In total, I spent about 30 hours doing all the poses.

They rest of the characters took less time to animate as I got the hang of the whole process. Also,

our artist used the same body part sprites for all the poses in the latter characters (I asked him to do so) making initial rigging easier. I also wanted the characters to look up when idle to give a better connect with the player. This meant an additional head transition (to look straight before hitting) was required. I got the artist to make head poses at 3 different angles. While animating between the three poses, I used a combination of scaling and cross-fading to get a smooth transition. [I believe having mesh deformations would have given a better result here, but I felt the current transition was good enough.]

Making Them React and Interact

Since there was no physics applied, we had to hardwire reactions into the characters. This was achieved mainly using animation events. E.g. At a precise point in the hit animation, a onHitReaction(variant) event would be triggered.  The variant parameter identifies the type of hit action (e.g. punch_upper, baton). The opponent's character would then run a recoil animation with a matching variant. After that completed it would trigger a onRecoilComplete() upon which the first character would walk towards the other. Similar events were triggered for the background items to react (e.g. water splash). These events also let us add sounds to the action. The event-based interaction allowed the characters and background to be independent of each other. A new character or background could now be very easily downloaded (via Unity's AssetBundle system) and added to the scene at runtime without any compatibility issues.

One final challenge that I mentioned earlier was dynamic layering. When one goon moved his fist over another that part had to appear above the other goon. I picked the simplest  solution: The hitting goon would have all his body part sprites layered above the other goon (by changing the sorting layer in Unity) during the hit action and then moved back when in idle. This ensured that fist/weapon war drew above the opponent. In the future, a more sophisticated solution will be required to handle hits to specific body parts (say the abdomen). But for now, we were good to go.

And Finally - Thug Life

After all the work put in, the characters began to come to life. A lot of tuning was needed, though. The speed at which a thug swung his arm wouldn't be right or the way the head moved in a walk cycle. Sometimes fixing one movement issue would break something else. There is no end to perfection so I had to stop somewhere. I shared the somewhat-finished characters with the rest of the team and they seemed to be quite pleased. That was a relief! There were many places I had to get creative to handle out of plane animations (like retracting the arms to make them smaller while swinging). The winning poses were put together with complete liberty at my part. I accessorized our only lady goon (Wily Wilma) with a baton to add to the variety. Finally, it was effort well undertaken. Even our Serbian artist was quite happy with the animation.

Of course, it is up to the rest of the world to decide whether our animated thugs are appealing enough or not. While that is something that we all look forward too, there were some important lessons learned here:

We hope this experience of ours becomes useful to at least some of you so that you are not lost when trying to attempt building top down animated characters. If you have any question please add them in the comments section below, we'll be happy to reply.

See our goons Mad Marcus, Boxer Ben and Wily Wilma in action, try out the web preview!