Android is a desolate wasteland when it comes to games
wired.co.uk
wired.co.uk
On iOS, I can have a build running and drop into a debugger directly on device in a single button click. On Android? Ha. First I have to boot up Eclipse, set a breakpoint in our Java bridge code, start debugging on a device (assuming it connects when I plug it in), manually attach GDB, now set my native code breakpoints, then resume in Eclipse. If I'm lucky and the stars have aligned, GDB will break where I want it to and maybe give me a stack trace that is accurate.
Here's another example. On iOS there is a wonderful OpenGL debugger. At any point in my game, I can hit the snapshot button and I am presented with a state-change-by-state-change list of every single command I have sent OpenGL. I can step through each of these and see my framebuffer get built one draw call at a time. Totally invaluable for finding errors and inefficiencies. I can even have a code breakpoint trigger this debugger.
On Android? Well this is much, much tougher. I first have to find out which GPU series the device is running (PowerVR, Tegra, Adreno, ARM), then I have to search the vendor's website for their native debugger. When I find it, it is of course, Windows only. So I have to now boot up my VM. To connect my Android device to the Windows VM, I have to first disconnect it from my host OS (meaning I can no longer debug), then re-connect it. Then, I have to locate special Windows drivers for the specific device (most don't work out of the box on Windows).
At this point the steps vary. For a PowerVR powered Android device, for the native debugger to work, I have to jailbreak the phone and manually copy special debugging .so's (that will brick the device if it reboots with them enabled). Then once this is done, I can attach the OpenGL debugger in my VM and try to capture a frame. I say try because these tools are usually so poor that they crash outright when you try to use them. For the PowerVR debugger, it will only capture ES 1.1 frames -- the ES 2.0 will cause an instant hard crash.
What further complicates this is that the wide variety of GPUs that power Android devices vary greatly in their performance, capabilities, and their interpretation of the ES spec. The Adreno 20x series of GPUs, for instance, have a terrible shader compiler that refuses to treat compile time constants as valid indices for vertex varyings. This works flawlessly on every other mobile GPU, but on an Adreno you'll be faced with a black screen until you figure out why your shader was refused.
/end rant.
I will throw Android a bone here however. It is vastly, vastly, (did I mention vastly?) better than the develop environment that you had to use for Symbian devices. That was a special circle of hell that I hope I am never forced to experience again.
I game on my Android phone and haven't noticed a lack of quality games. I certainly haven't spent much on games, though. I've got several dozen games that I've paid for, all of which I've purchased through Google's 10 cent and 25 cent sales. I've spent more to get games through the Android Humble Bundles.
You can't use current top paid games as an example either; it's possible to get to the top of any of the mobile markets if you're willing to invest tons of money into advertising and paid installs. You need to look at overall trends to get an accurate picture of what the market is like.
Simply put, the Android Market (Google Play Store, whatever) is unusable for small independent developers. With iOS, Apple acts as the merchant for all transactions and just sends you royalties. But Google foists all the responsibility for collecting tax from each individual customer directly onto the developer.
For a real business with an accountant, that's fine, but if you're one or two people in a basement who just want to develop and market a game, that's a nightmare. For that reason alone, developing for iOS is so much more attractive.
- tons of resolutions to support
- Tegra, no tegra, OpenGL ES 1.1, OpenGL ES 2 ..
- Google banned any form of paid apps in their first year, with the reason that their payment processing wasn't ready yet. I had two apps removed from the Android Market in 2008 because they were using a form of in-app purchase (powered by PayPal), thus making people get used to free games, powered by google's advertising
- there are TONS of indie developers making good games, who can't sell apps on Google Play because google doesn't allow them to. They keep saying that's because of legal issues, but somehow Apple, Samsung, WebOS had that problem solved... Things got better with the last inclusion of some countries on the allowed list(Poland, India..), but it's still not there
These being said, a lot of money can still be made on Android with games. It just requires an amount of work that most companies aren't comfortable with.
IOS = Console Game Android = Desktop
IOS, you basically know your system, but your system limits you. You have to get permission to sell from the maker of your system. You get exclusives, because it's fairly easy to build to your system.
Android You can have a wide variety of systems which can mean a lot of potential issues, but can have a minimum and suggested specs, and can even add features if the computer supports them. You don't have to sell your application through the official store, or any store, since people can (usually) load what they want on their device.
Thoughts?
I'm not much of a gamer, but it would be interesting to see this analogy taken further, to see where Android can build on these strengths to be the preferred gaming platform.
Maybe OUYA will improve things as well.
--
[1] http://www.asymco.com/2012/06/18/a-more-precise-measure-of-i...
Unless games are your primary use case for your device I don't think it's a decisive difference the way it is for music production apps, for example.
I'm onto my second high-end Android phone and I've bought lots of apps and games. At the end of the day I couldn't give a fuck about playing games on my phone. I use the phone and the apps all the time though.
People who like games, and developers who make them.
>Maybe we have better things to do than play games on phones.
Is that a statement regarding all Android users, or your clique, or...? Because many of the most popular apps on all platforms are games. People like games.
>I couldn't give a fuck about playing games on my phone.
This doesn't necessarily hold true for everyone, which is the point being made.
>I use the phone and the apps all the time though.
So do I. But I also use the games all the time, too. If this doesn't affect you, then good. I'm glad you're enjoying your phone. But you seem dismissive of an entire market just because it doesn't suit you. That's not a good mentality to have.
I don't know if this applies to a lot of other people, but I personally think that once phone batteries are increased, we'll see more people gaming on their phones.
Allow Android games to be fully written in C/C++/Go with a fat binary format to support ARM/x86 and now we're talking. You can kind-of-sort-of do native development in Android using the NDK but it is much more of a pain in the ass than it should be because Android's userland was designed so tightly around Dalvik and Google has always treated the NDK as a bit of a red-headed stepchild (eg. it was never officially supported on the x86 Google TV boxes).
The only possible reason having better support for C/C++ development is so that ports are easier (assuming the original is written in C++).
That's kind of the point; the tooling for native development is crap compared to working in Java, which, while a fine language for lots of purposes, brings a few performance penalties that can inhibit game development. Apart from the overhead of a VM, games often require precise timings that are difficult to achieve when a garbage collector can be running at unpredictable times. And I think you're dismissing the porting angle a bit quickly. When faced with the choice between converting your entire codebase to a different language, using difficult tools with poor debugging support, or starting a new project on a platform you're already successful on, which would you choose?
If you want more people to develop for your platform let them develop for your platform the way they are comfortable. Support C, Ruby, Pascal, Lua, Lisp, BASIC and even Logo.
Not perl though, That'd just be sadistic.
Another reason why Android is losing on the developer front is that development environment setup and usage, even for Java, is worse than Apple's. It's usage of Eclipse is like duct tape and glue.
Yet, debugging with a galaxy nexus on usb is buggy for me (sometimes it works sometimes it won't). reboot might help ... I just love instruments in xcode.
As code editor I use MacVim (faster and a much cleaner look for me compared to IntelliJ as it's a coca citizen and not a Java GUI app ... ).
I can't imagine giving up all the code editing features of IntelliJ for any generic text editor though. All that java and XML without code completion and refactoring is just too horrible to contemplate. If you're determined to go that route then why not just ditch the IDE entirely and do everything from the command line?
I usually use Xcode/IntelliJ for refactoring and some more advanced functionality.
And although there are quirks (mainly performance related) in the ADT/Eclipse combo your description is far from my experience. The overall experience is better, IMO, than Xcode. The latter is the buggiest IDE I've ever used.
Frankly AppCode/IntelliJ beat both in many respects, but frustratingly don't quite cover the full range of functionality. It's difficult to make the leap when you need to go back to Xcode/Eclipse to accomplish some of your work each day.
Then when you get to single stepping its ridiculously slow. Anyone that has used or attempted to use the NDK debugger cannot say with a straight face that it is up to par with modern tools.
Oh...then there is the issue of ridiculously uninformative stack traces.
Its generally easier to build your code in an x-plat fashion in C++ and then work out as many bugs on iOS as you can and then - as the parent said - leave printf turds everywhere.
Stone knives and bear skins...
I used xcode for more than three years now, wrote a lot of object c/c/c++ and even assembler, and yet to find any major bug. This year I tried to port one of my app to Android, and the biggest challenge happens to be debugging native code. Basically you can't, there are some tutorials to set up gdb, but it shouldn't be that hard, and I don't bother. I ended up with printf, of course it is a nightmare.
If Google can deliver a xcode quality IDE, it'd already ruled the world.
It's a relatively new addition, and as warned above it still might not work in all setups in my experience. But it's worth a go.
I think this is mere perception vs reality. Android development environment is far superior to XCode. Using IntelliJ for Android Development is a true pleasure working with Android. I have no problems debugging over USB on my Mac ever.
The game industry is incredibly rigid to any change. Once they've found their horse they will not walk away from it, and show little interest in changing how they approach development ever. This isn't the first time we've seen some long article with game studios wringing their hands over any change.
Gaming on Android doesn't "stink" for me as I've found a way to play vintage games using emulators. Which I would certainly pay for if the Nintendo/copyright owners offered it as an option on Android.
It's a ranting stereotype-enforcing blather piece by some attention seeker picked up as a guest blog on Wired UK. I hate this!
Probably because neither of those things really have to do with the selection of games available.
"the author's points boil down to "there are more exclusive games on iOS","
Or rather, 'many of the best mobile titles are exclusive to iOS or first on iOS'. Which was exactly what his title indicated.
"ranting stereotype-enforcing blather piece"
Irony crits you for 700,000.