Adventures in iOS Unity

Up until now we've been developing our prototype for the Unity WebPlayer with a thought for the iOS devices. See our blog post about baking down textures. 

This week we decided to sworn the target platform and see how things looked on iOS. 

At first there were some issues with texture format and the bake down code. We also found some problems with getpixels throwing up errors. These didn't take long to fix and pretty soon we had the game game up and running on the simulator. 

Encouraged by this we decided to renew our lapsed iOS Dev status with Apple and build to an iPhone 4. 

The long forgotten process of provisioning profiles and all that goes with it meant a couple of hours of poking things with a stick but finally we got the game to build and run on the device. 

This is where things started to go horribly wrong. 

We use the singleton manager from the unity wiki as a place to store globally accessible variables etc. Turns out that any generic lists  that we held there were not picked up by the game and caused a crash. We fixed this by creating a new script that simply had Static instances of the script and this worked just fine.

A bigger problem was the 4D Array we were using to store all the map data. Now - this was probably a massive waste of memory using something like this - but on a desktop it didn't arise as a problem.

A few hours late we'd converted this 4D Array to a generic list which is probably much more memory efficient but not sure right now about how much of a performance hit it will be to search the list as opposed to directly referencing the index in the array. 

During the conversion we made sure to limit the amount of access needed to this new list and while in the profiler we're seeing some regular spikes, we're pretty sure we can iron them out.

Amazingly this conversion from a 4D array to a list worked first time... 100s of lines of code affected over multiple files. We were floored, but the problems weren't over.

The baking down we do is obviously hitting the iPhones memory pretty hard. Each NPC has it's own unique baked texture, as do the building and all the dropped objects. Sounds expensive but since each NPC has around 7 layers that can be unique it means that each NPC should take one draw call, not 7. The problem is more in the amount of memory being used to generate the textures.

We fudged a few things. Baked less textures for the NPCs. Stopped the baked buildings from being generated and finally got the game to run.

The framerate is far from ideal, hovering around 17fps. With the drawcalls pretty high but for 120 draw calls, 80ish are batched.

Moving forward, are map data structure problem is solved and it's really the backing down for customisation that is an issue. We're still making plans but the current thinking is to use much larger texture pages that contain, say, all of the NPC faces and then instead of backing a new texture we just reposition the UVs to the location of the chosen faces. Same for buildings, same for items.

This method will mean more draw calls on a single object, but since all similar objects use the same material they would be batched. Using our old method 20 NPCs would be 20 draw calls. using the new method the maximum would be 7 total.

We're a little surprised that draw calls are still a huge bottle neck with the iPhone and Unity. Back when we made Doki Doki Bloki we kept everything below 20 and it was fine on an iPhone 3G. We thought the iPhone 4 would have been a lot more forgiving but that assumption was wrong.

Overall we predict about a weeks worth of work to get the game fully working on the iPhone and Web Player at the same time. Not too bad considering the differences in the architectures of the platform. But really - this is more of a cautionary tale for anyone thinking Unity is a pull the switch and it just works solution.

I have to say we're pretty disappointed that the game functioned just fine in the editor and the simulator and not on the device. It probably says more about Apple's iPhone simulator than Unity but the frantic refactoring of our data structures is something we'd rather not face again...

...anyone got an Android phone they can lend to us?? :D