This will be a semi-technical piece, in a departure from the normal things I write about. It was initially a reply to a facebook post, but having poured all my knowledge into a single, comprehensive reply, I discovered I’d misread the initial question posed. So instead I’m posting it here. The question I thought I was answering was “What should I know about putting my Unity game on Android”
There are a few odd little technical things that can crop up when you first switch platform to Android in Unity. Mostly it’s solveable stuff though and no more than a couple of day’s work to get a build running on an Android device (or less if you’ve already downloaded and set up all the Android SDK’s, installed java sdk, set up environment variables etc). You may also find as you release, certain devices have odd bugs that are unique to them. They’re usually fixed after a quick search of stackoverflow but not before some user has got pissed off and left a 1 star review. You can head that off to an extent by looking up the lists of the most common Android devices, and using them against services that let you remotely test on different devices. But you’ll still be getting crash reports from your analytics package and/or messages from users of the most obscure devices for months after launch.
The big problem is resolution and screen size. In Unity you can force the game to stick in landscape or portrait, so you don’t need to account for both. But really, you need to have designed the game and especially the UI to be flexible and work at any given resolution and dimensions. (I prefer to do all my UI layouts in percentages of width and height when possible, but even then, things like text being too long for its surrounding box can easily crop up).
The game needs to work with a touch screen interface as well. Unity has Input.touch, which is fairly easy to figure out and Unity’s in built UI elements will mostly pick up touch automatically and treat it broadly the same as a mouse click. Some things will likely break or need some fixing from you though (e.g. drag & drop. Mouse hover doesn’t make sense either in a touch environment).
If you’ve made the game to use console controls, the good news is that Android supports many 3rd party Bluetooth controllers and Unity will automatically pipe through that stuff into your existing code, again using the Input class! Bad news is few people bother to connect their controller as it’s a pain to set up outside the game and can be really flakey in terms of reliability. So you’re going to have to do horrible stuff like virtual dpads (not recommended) or have a major rethink of your whole UI, both for gameplay and menus etc. As said before, Unity’s touch input is easy to get, but having to retrofit code to use it has potential to be a right pain depending on what you’ve done before and how much UI code their is to modify.
Performance is also an issue for many people with older or cheaper devices. You could pitch the game at the “check out how shiny this game on my brand new super expensive xyz phone that I just bought is!” Or you can, in the web portal you use to upload your game to Google play (app store), specify that you need a minimum Android OS version. Usually, lower end phones can’t handle an OS upgrade, so you naturally filter them out. You can also filter so only owners of particular devices can download the game but the list is as long as my arm and 5 columns wide, and you’ll always disappoint some users. Plus so many new devices are coming out, you’ll be continually be adding to the list forever after. I don’t recommend that approach.
There is no approvals process. You just sign up for an account with Google, pay a one time fee, upload your game, and a couple of hours later, your game is available to everyone in the whole world, from Poland to Pitcairn island.
There is some extra effort to put in In app purchase or advertising API’s, but it’s fairly easy stuff with a bunch of tutorials on the web on how to do it in Unity. (Forget premium pricing on Android. It just doesn’t work). Same with leaderboards and achievements, which take maybe a couple of days to do tops. You can spend more time putting in analytics engines, and again, all the good ones have quick, easy to implement Unity API’s or plugins you just download from the asset store.
Different countries also have different expectations of how to pay. India for example is all adverts and no one pays by IAP, whilst other countries IAP is the norm. Many places don’t have credit cards or don’t use Google Play, so telco/carrier billing is the way. Again there are a myriad of companies offering to help with that, all with their own API’s that if they’re worth their salt, will run in Unity.
Piracy is an issue. Even with Unity, it’s fairly easy for someone to reverse engineer your game, get hold of all your assets or hack the game to circumvent IAP checks. Pirating premium games is as simple as copy-pasting the right file from someone who has bought the game. You have to be prepared that once your game is out on Android, you may be unable to stop people using everything in it however they want.
Also, don’t forget stuff like Amazon app store and other odd non-google play 3rd party app stores, which can be more profitable than Google play (or totally useless depending). Don’t forget either Android TV stuff like FireTV or NVidia Shield or other Android set top boxes. They’re all a risk but could get you some good sales for just a few day’s work if your game is a good match. Again, they’ll all have their own API’s and plugins or packages you can download from the asset store or their websites, for Unity, with instructions, and should only take a couple of days to implement.
So overall, Android with Unity is easy to get started, but there are lots of little things to consider, depending on how professional / in deep you want to get.