Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
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.
Initial concept - Tug of Words |
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
Another failed prototype called backyard wars |
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.
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:
The characters had to be true top down (slight tilt was tolerable) and not isometric as two players would play on opposite sides of the screen.
Every hit would move the characters a fixed distance till the losing character fell into a manhole or a pool.
The movements would be completely controlled by animators, no physics would be applied. This was because movements were fixed and deterministic.
The recoil response had to closely match the hit action. E.g. a hit to the head would have a different response than a hit to the abdomen.
Layer orders had to be changed dynamically to ensure that the hitting characters arm/weapon were drawn above the hit portion of the opponent.
Close combat action meant the animations and artwork had to be detailed to the level of a side scrolling character.
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.
One animation & artwork requirement |
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.
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.
The Spine skeletal animation toolkit |
But as I delved deeper into the workings of Spine and skeletal animation in general, several challenges cropped up:
Unlike their side view counterparts, top down characters have a lot of motion which is perpendicular to the viewing plane. E.g. head looking up and down, arm swinging, tumbling etc. Animating such motion only through affine transforms (translate, rotate, scale) is quite difficult. A combination of sprite switching, affine transforms, and mesh deformations is required.
Bone manipulation becomes hard as most of them are concentrated in a small area.
Many sprites had to slide under another, e.g. shoes sliding under thigh, which meant the bone joints were no longer fixed. It also meant that IK (Inverse Kinematics) could not be applied correctly.
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.
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.
Game object hierarchy of a character in Unity |
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.
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
Getting the right type of artist to do the top down artwork was far harder than we expected. Most of
Goon mugshots by our Serbian artist on iStock Photo |
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.
A table from the artwork requirements given to artists |
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!
Some poses of Mad Marcus |
I now had 9 different poses of our first goon Mad Marcus from which I had to create my entire animation set.
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.
Mad Marcus minimum sprite set |
Mad Marcus walk cycle |
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,
Wilma looks straight before hitting |
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.]
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.
Wily Wilma finishing off Mad Marco |
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.
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:
Anything can happen in a cartoon or in a game. Get rid of unnecessary realism when trying to connect player action to a reaction or response in the game world.
In a true top down game skeletal animation takes less time and money to set up than sprite sheet based animation. They also take up less memory and run smoother.
Be aware of limitations of top-down skeletal animations (out of plane movements are difficult to animate).
Before jumping into an animation tool look at simpler options; they might work equally well. Also, check whether the features offered by the tool really work in your case.
Consider reaching out to artists outside the gaming industry. They are surprisingly capable and could offer better rates. But be sure to ramp them up on gaming concepts before starting the project.
Make the character behavior as independent as possible. This really helps in scaling up the game and maintaining a clean structure.
Finally, don't be afraid to try out something different, no matter how wacky it sounds. A small change can bring the world's attention.
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!
Read more about:
Featured BlogsYou May Also Like
