I don't know what you're trying to do, but I'm pretty sure you're doing it wrong
Well, it turns out I was right to be afraid. Despite erring on the side of caution, dumbing down models and textures, limiting sound size and being cautious resource wise, it wasn’t enough. In the ways of Unity3d on mobile phones it turns out we were trying to drop a jet engine inside a soap box racer.
So rather than simply walking by us wretched souls, shielding the eyes of your children and whispering harshly “Don’t look at the poor developers,” I advise those just starting to develop for the phones using Unity3d to heed this cautionary advice lest you find yourself well into development asking “0.7 frames a second? Bu-bu-but…our polys are low!”
Tip number the first: Keep your polys low, but your enemies lower
Ok, the last bit makes no sense, but keep your polys down. I’ve read before that for the older iPhones you should keep your poly count limited to around 10k-15k. I’ve heard the iPhone 4 can handle 40k, but what use is that unless you’re only releasing on the iPhone 4? Also, keep in mind that the more memory you use for graphics, the less you have for physics and gameplay.
Tip two: Draw Calls
Try to keep your draw calls between 20-30 if targeting the phone market. For us, a problem we didn’t realize we had until later was our meshes for our character, enemies, etc were not combined. Our main character used 16 draw calls, slapping a material on each piece of geometry individually. Combine your meshes whenever possible, reuse materials for better batching and be mindful of your overall draw count.
Tip three: That damned, dirty GUI
The Unity GUI is not your friend. Full stop. I understand they are aware of this and are working on it, but in the meantime the GUI is going to slow things down like a fat man riding a pony. For our little game, two progress bars, score text and a pause and mute button ate up 13 draw calls and would often use 40-50% of our processing power according to the profiler. Turning off GUI elements would sometimes boost us up by 10-15 fps. The research we’ve done suggest a simple alternative; don’t use Unity’s GUI functions. Instead, try some middleware, like EZgui. We recently added EZgui to our arsenal. As of the time of writing I’m unable to say if it’s made a real difference to our overhead, but EZGui bills itself as being a more efficient means of implementing your GUI on mobile platforms, so we’ll see if our $200 spent will give us one less thing to worry about.
Tip four: What’s that sound? It’s the sound of your game bogging down under your audio
Holy mother of Cthulhu, but sound seems to slow down the mobile phone build of our game. Our PC build of the game featured a musical track, sounds for each firefly, sounds for each enemy, environmental sounds and the main effects for the player character. Add that all up and on our test phones it sounds like suck.
Deleting each of these sounds seemed to increase performance by nearly 5 fps despite the tiny size of each sound clip. At this point we do not have a workaround. So this one is more of a cry for help than it is a tip. The tip is, “Watch your sounds.” The cry for help is, “How on earth does anyone implement sounds on the Iphone, period? Are we really limited to only 2 audio sources per game if we want the game playable?”
Testing on the iPhone
Those are the main performance issues that we experienced as new Unity developers. Hopefully this will help someone become aware of the dangers of mobile phone development.