Cross-platform mobile game and stick in the wheel from Android

In this article I want to share with you our experience in developing a mobile cross-platform (iOS / Android) game.

We wrote the game on Unity, and the graphics itself was sprite. But much of what is said below will also be true for other cross-platform engines, as well as for high-grade 3D.

I will begin my story with a delusion.
')

The myth of cross-platform.

When the team and I started developing this project on a large and very cross-platform Unity engine (which also supports Win, Mac, XBox, PS3, PSP, etc.) - we hoped that Unity would take all the care cross-platform on ourselves, and our task will only be to press “publish” for different platforms and drink coffee.

Yes, of course, we knew about the fragmentation of the platform, but for the most part we expected to see the sharpening for android in the graphics area (adaptation for different resolutions, diagonals and dpi) and performance (it is clear that something that one droid pulls to another force).

But not everything is so simple.

Memory and textures.

If you have already encountered the development of mobile games, then you know that most likely, your worst enemy will not be a lack of CPU / GPU resources, but a lack of memory. It is about the memory you need to think in mobile development always and everywhere.

For example, iPad 2 gives the application a little more than 100 MB of RAM for resources. And if you are developing a game in which a fairly large number of sprites (laid, of course, in atlases) - then you will sooner or later think about the number of these atlases and texture compression.

The standard atlas, with which more or less self-respecting devices work, is 2048x2048 pixels. That in uncompressed form (32 bits per pixel) will take up as much as 2 * 2 * 4 = 16 MB of memory. Yes, there are 16 more bits per pixel, but on the one hand it’s still 8 MB, and on the other hand it’s not always acceptable. For example, on gradients you will see very unpleasant dithering.

Then texture formats come to the rescue. Under iOS, this is a PVR of 4 and 2 bits per pixel. PVR2 is scary as hell, but you can pack something in PVR4. 2 MB for the atlas 2x2k - not bad.

And everything would be fine, but in android you are in for a surprise!

A surprise in the form of 4 different chips, each of which supports its own format of texture compression and does not support the others!

(Here, however, it is worth making a reservation, since all the chips under the android still support the ETC format. But in our case it is of little interest, because it is a format without an alpha channel. Yes, of course, you can write a shader composing two textures (in one store RGB, in the other - A), but this is quite a chore both in terms of implementation, and considerably complicates your pipeline preparation of graphic assets).

So, what chips make us happy on the droid:
* PowerVR (Samsung Galaxy Tab 2) - PVR compression
* nVidia Tegra, GeForce (Asus Transformer) - DXT compression
* Adreno (some Nexus) - ATC
* Mali (all Samsung Galaxy S) - does not support compression with alpha channel

So if you release an APK under Android, in which all (or part of) the textures will be shaken in PVR, as you would do for iOS, then you will encounter crashes on a bunch of devices, since if the device sees an unsupported format, then it tries to unpack it in advance in 32bpp, and as a result it crashes through memory.

Most of all in this picture I was surprised by Samsung’s flagship Galaxy S3. The GPU used there does not support compression with the alpha channel! But it saves the fact that androids have a different attitude to memory. And on powerful devices, they are quite ready to give you 400 meters for unpacked textures. But the thing is not only in memory! The fact is that speed also depends on the size of the textures. After all, to drive all these megabytes back and forth is also not a quick pleasure.

Well, okay, with Mali - here it’s either perverted with shaders and 2 textures, or to score. It seems like it works and fits in memory.

But what to do with weaker devices? And nothing. Just pre-press all the textures in different formats, individually for each GPU and then either make several applications on Google Play, or after starting, load the necessary texture pack from the server.

Needless to say that all these dances with textures make pipeline very difficult? But often in asses you need to make changes. As a result, we will have to compress each atlas several times ... By the way, the packaging of one atlas 2x2k in PVR, for example, lasts about 10 minutes.

Individual characteristics.

In the first days after the launch of the project, we began to receive tons of reviews in Google Play with unique, unique bugs on different devices. And all the problems were different from each other.

True, most of them were explained by the compression of textures. But not all. Someone does not fit in the memory. Someone conflicts with other applications installed (there is even a couple of topics where people discuss that, for example, Asus' shell likes to conflict with applications on Unity).

Someone - generally slows down the sound (!).

Did you know that Notepad tablet phones - in fact - have two screens? One tachevym (capacitive), and the second - for the stylus (resistive). And they are processed in different ways. And in Unity, in order for the stylus to work, you need to write a separate code.

After the release, you will see how everyone, at his unique and inimitable device of unknown origin, will catch some bug and will definitely complain about this in the reviews.

And you have to dig into the settings of your project on Google Play and turn off some obviously fake devices. Well, or have an unreal park of devices.

Strange and not subject bugs.

Think you control everything? But figushki!

In the same Unity, every now and then they patch up some bugs that lead to crashes under the android. More recently, some of them were very common and fatal.

And then there is the inexplicable behavior. For example, the game works perfectly fine. But if you roll it up and then return to it, then half of the textures are replaced with black squares. What is it? Unity bug? Or the core of a specific droid? Unknown ...

Do not forget about protection!

Here, unlike the previous points, there is nothing particularly scary and confusing. Just keep in mind that there are far more lovers who delve into the memory of a droid than those on iOS. So be sure to verify the payments (for iOS, too, does not interfere). And also - encrypt all important stored digits (the amount of money from the player, etc.), because programs a la ArtMoney under the droid is also missing.

But in general - gain patience - and go!