Hello readers and newcomers!

Last week’s blog post somehow evaporated itself in the midst of us working intensely on MEGATROID, so I apologize for that and blame Peter.

Starting today, I will do a series of posts about what we’ve learned thus far when it comes to optimizing our Unity 3D games for the various mobile devices that populate today’s mobile market. I will use our own games as examples of how TO, and how to NOT do things, as they are closest to heart and do serve as good examples. For those of you who aren’t developers, things might get a little technical at times, but I’ll try to describe the problems and solutions as best as I can to give you all a clear picture of what’s going on.

Mobile phones are still quite, if not very restricted in terms of how advanced your game graphics can be. Since Unity 3D is a 3D-engine, you’re already playing with fire; 3D is a lot more expensive than 2D. This fact still applies if you’re developing a 2D game in Unity 3D; your graphics may look 2D, but they are represented in a 3D-space in a 3D-engine.

I’ll start where we started: Thunder BANG. Our first mobile game and you can tell it shows. The game looks like an early era 2D iPhone game, but it is done in Unity 3D. We chose Unity because of its capabilities to publish games on both Android and iOS “with the click of a button”. Of course it’s not that easy, but that’s what we believed roughly one year ago.

Thunder BANG has several layers, roughly divided in characters and objects layer, 3 scrolling background layers and one static background layer.

Thunder BANG Screen Shot

Thunder BANG Screen Shot


The game runs absolutely terribly, compared to titles developed in 2D-engines, with similar graphics. For the longest time we didn’t know why.

It turns out that mobile phones have very poor ”fillrate”, that is, they don’t like drawing the whole screen a lot of times in a single frame. In Unity, we had to use sprites to animate everything, which are square images with an alpha channel for transparency. A transparent object has to be drawn in its entirety, including the “empty” pixels. Since the whole game consists of these transparent objects, the phone has to more or less draw on the whole screen for the static background, the whole screen for all the moving background layers and lastly, large portions of the screen for the animated characters. Drawing things on top of each other like that is called “overdraw” and is very wasteful of the phone GPU’s processing power.

Below is a screenshot from Thunder BANG where Overdraw is enabled in the Unity 3D editor view. You can clearly see where the GPU has to draw things multiple times; black means there’s no overdraw, and the brighter the brown, the more overdraw is caused.

Thunder Bang Overdraw Example

Thunder Bang Overdraw Example

Thunder BANG is a real good example of how to NOT do a 2D style game in Unity 3D, at least when it comes to the graphics implementation. I personally still feel that the game has a degree of fun in it; it’s just that it runs very poorly on a lot of devices. Still, it was a harsh but real good lesson for us.

An excellent example of how you SHOULD do a 2D-style Unity 3D game for mobile phones is Zombieville USA. They have several 2D layers, just like Thunder BANG, but the game is running very smoothly.

As far as I’ve gathered, they can achieve such good performance simply because they aren’t using any sprites for their animation. Instead, they use 3D-meshes, which have been modeled like card-board cutouts and then animated. The 3D-engine doesn’t have to treat anything like a box with transparent pixels in them, so the GPU doesn’t have to draw anything more than once a frame. This sounded so fantastically ingenious when I first heard about and I was really impressed!

That’s all I have for today!

See you next time!

- Marcus