Slashdot Mirror
Battleheart Developer Drops Android As 'Unsustainable'
mr100percent writes with this excerpt from Electronista: "Battleheart's creator Mika Mobile in an update explained that it was dropping Android support. Google's platform was losing money for the company, since it spent about 20 percent of its time supporting the platform but only ever made five percent or less of the company's revenue. Much of the effort was spent on issues specific to Android, where the diversity was only creating problems rather than helping.
'I would have preferred spending that time on more content for you, but instead I was thanklessly modifying shaders and texture formats to work on different GPUs, or pushing out patches to support new devices without crashing, or walking someone through how to fix an installation that wouldn't go through,' one half of the husband and wife duo said. 'We spent thousands on various test hardware. These are the unsung necessities of offering our apps on Android.'"
Good choice
Battleheart? What? Never heard of it.
The developer feels he's spending more to develop for Android than he's getting back - so he decides to stop developing for Android.
I suppose that's interesting at some level, given past stories about Android developers not making money; but, in the end, it's just the free market operating rather than some amazing news item.
#DeleteChrome
So they've done the right thing. They're not interested in sympathy; they found that a particular product on a particular platform was unprofitable, so they dropped it.
Quidnam Latine loqui modo coepi?
Development isn't a test of machismo or stoicism. The Android version wasn't making any profit for them. Time is money, and when you're having to do more more work than the sales you are making, it's a business decision to stop doing it.
iPhone is less work for much bigger sales.
That's not the real problem, if the GPU doesn't support a feature you can fall back to another implementation. The problem arises when they don't properly advertise what features are available. OpenGL has this in the API, but most mobile drivers say they support features they actually don't have.
App development for any mobile platform is a lottery. Most developers make very little from it. A few make tons of cash. Even on Android.
Android has what, four versions in the wild? iOS has 3, 4 and 5 taking up something like 15, 20, and 65% roughly. Not a great deal of difference there.
You've conveniently ignored the hardware diversity.
This sounds like a complaint from a guy who is basically saying "Development is hard, and I don't want to work to make things good". Just as well he's calling it quits, shape up or ship out I say.
Yeah, fuck him for having limited resources and wanting to make a living out of a small business.
/. really is a pile of freetards who think they know everything. Do you really think Android has only four versions in the wild? Have you ever developed for Android? How about for iOS? Until you release some apps on both platforms you are officially ignorant of what is actually required and your opinion is not valid.
It's not that iphone is less work. They started with a focus on IOS. It's more work to port a highly focused piece of software and they just couldn't handle multiple platforms being a 2 person team. What they ended up porting to Android was such a bug ridden POS that it didn't sell at all. That doesn't mean App's dont sell on the Android. Developers just have to make decent software for it. It's just as easy to make software for Android as it is IOS, given that you plan your project to include both. They obviously relied heavily on IOS frameworks. There is nobody to blame but themselves.
Version diversity isn't the only kind. Implementation and hardware diversity matters too - for instance, I've run into a crash bug when attempting to start a new Activity from within a TabHost that only occurs on Galaxy S devices. That sort of thing is really incredibly frustrating, and makes QA far more of a pain in the ass than it should be.
using Unity? so the real news here is that Unity must be crap on Android because that must be the work of the engine developer. Why do they write about different textures types support on each handset and things like that? Unity must be able to abstract all that if they want to be called a cross platform game engine
If they are spending more money than they are getting then what do you want them to do?
The stats provided are damn near useless.
Let's hypothesize and say I develop some app. Let's count the app-specific dev time/costs as a separate baseline cost (cause that's how comparison of cost to maintain a port should start).
Now, out of my remaining monies, I spend 20% supporting "Android", and the rest (80%) supporting iOS.
Would it surprise anyone if the platform receiving SIGNIFICANTLY less of my attention ran into more problems, bugs, bad reviews, fewer purchases, etc?
I have no idea if that's what they meant by "20% of its time", but the other side of the coin is not even mentioned. It would be FAR more significant if they stated that they spent 5% of their time supporting iOS specific issues, 20% supporting Android specific issues, and 75% of their time improving core app and server functionality, and were still seeing 95% of their revenue come from iOS and 5% from Android.... but we just don't know.
The only fact I can see is that their software had numerous issues on Android. Maybe if they fixed those they'd actually be able to turn a profit - people don't like to pay for shoddy work.
It's EXTREMELY easy and common for businesses to spend more than they're making (ex. see restaurant turn-over). Plenty of people ARE making money though... so either you're spending too much, or you're not spending enough (assuming you're otherwise competent).
This company had other viable options, such as:
* go the hulu route - pick a small handful of officially supported devices, and add in device model restrictions. Only support those you can support well.
* spend more time/money, and make sure you've got everything supported so people don't hate on your product.
* combine those, and add devices as the beta/demo results show them working well.
IE. this isn't as much an Android story as it is a business story (and a really poor one at that - no real details at all).
And for the fanboy's ready to flame this... note I didn't say Android costs less to develop for or support. I'm only saying this "article" is for shit and doesn't provide enough to make any conclusions.
It seems to be the other way around to me.
iOS is like IE6: one particular implementation with a huge market behind it. It has its own particular set of bugs, but they're well-known and apply consistently everywhere, so the devs are used to working around them.
Android is like standard HTML 4: A definition of how things should be defined, and many implementations following that specification. Each implementation comes with its own set of bugs, so when your program expects a certain undefined behavior, it fails on other implementations than what you tested.
As with web development, there are two solutions. You can stick with the "one implementation to rule them all" model, and ignore the rest of the world hoping it will go away, or you can write your program from the ground up to be compliant with the One True Spec, and you can port over to other implementations more easily.
You do not have a moral or legal right to do absolutely anything you want.
You're obviously not very good at math. If you're spending $X on development but still making $2X in returns, you end up losing $X by discontinuing development. That doesn't change just because you spent $4X on development on another platform and then made $20X. Losing $X is losing $X.
On top of that, have you considered that spending 20% of the time on a platform that has 50% of the users may be a bad idea? How about spending equal time on it, so that your app doesn't suck on that platform and your sales don't keep dropping?
Have you looked at the specs of modern smartphones? Dual core CPUs are increasingly commonplace, with quad core on the way - in fact, already here in some of the high-end tablets. We're talking about Android devices here, not sub-£50 "feature phones". Comparing the tricks needed on this sort of hardware with what was required to squeeze performance out of DOOM-era PCs is an insult to the ingenuity of the programmers behind the early ground-breaking titles. OpenGL ES 1.0 has been available since API level 4 (Android 1.6), and 2.0 available since API level 8 (Android 2.2).
The primary language for Android development is Java. You *can't* go "pretty deep into the guts" from so high up; that's the very reason you can run the same bytecode on x86 and ARM devices. Yes, there's always the NDK if you really want to use C/C++, but if you stray outside the realm of the supported libraries then you deserve everything you get.
MASSIVE DISCLAIMER: I'm only just getting started with Android development myself. Still, I have to wonder how many of the problems lie with the platform, and how many lie with developers not really understanding what they're working with, assuming that the size and nature of the audience automatically turns mobile game development into some sort of free lunch.
* We all know that GPUs have driver issues, but don't rule out the possibility that issues are really to do with your own code: in my limited experience with OpenGL on the desktop, it's easy to write something that only works on certain hardware because you have unintentionally violated the spec, for example by setting something outside its officially specified range of values, or assuming some default piece of state which the standards don't mandate. Unless you're writing the next Unreal, this is more likely than uncovering driver issues with your 2.5D platformer or simplistic first-person engine. Keep your rendering pipeline as simple as it can be.
* Apps published on the marketplace had (until very recently) a size limit of 50mb. Anything above that had to be installed via a follow-up download within the app itself, which adds complexity, and increases the chances of failure. This limit has now been raised to 4GB, but before that, any developer blowing the limit ought to have thought long and hard about whether they really needed to before going down that route. Even if you get it right, there will still be scores of complaints from users who just don't understand that trying to download several hundred megabytes (non-resumable) over a patchy GPRS connection is just not going to end well, no matter how much care you take to warn them up front.
* I could be missing something here, but it appears to me that Android doesn't hand-hold your application through state management, especially if you're using OpenGL. This isn't just about saving basic state such as high scores, but the much lower-level business of simply writing something which is robust in the face of how Android handles multi-tasking. Read up on what events can and cannot cause an app's EGL context to get trashed, and what exactly you need to do when that happens. Remember the bad old days not so long ago, when alt-tabbing was a good way to crash full-screen games on Windows? Well, those days are still with us, just not on the same platform.
* Another good thing to understand is how to use the manifest. Declare what screen sizes and orientations you support, what texture format support you expect from the hardware, and so on. I have no evidence of this, but it wouldn't surprise me if some devices claim support for texture formats which they can't actually handle (those pesky GPU vendors), but hey, sometimes issues are out of the developer's hands - that's what trial versions are for, right?
I'm not saying it's easy. I don't fully understand how to navigate my way around most of the above issues myself, but rather than le
Ah no, that is also not the real problem.
The real problem lies with people who have the mentality that we should be even attempt to code 3D FPS games on devices that were designed to make phone calls and occasionally surf the web.
A tablet or cell phone is not a gaming machine. "Smartphone" is an oxymoron. And the only people trying to convince you otherwise are the people selling them.
FFS, get over it. It's 2012. Your fantasy about these being incapable devices ceased to be convincing three years ago.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
You're all being ridiculous.
The Android OS isn't really the major issue that these guys are facing. The biggest issue is how many different variations of hardware there are for Android devices and the fact that when you expect to be able to write it for one platform and then have it work perfectly well on other platforms (hardware specifically, though software does come into play with the modifications to the Android OS that all of the major manufacturers like to do like crazy), your plan is going to fail. You can see some of these same issues on PCs at times (I see it a little bit more in open source programs that haven't reached stable yet and have issues across different hardware it's being attempted to run on, to be specific).
And that's a pretty stupid rename, IMO.
I go to the market to BUY stuff. I go to the playground to PLAY. If I were an Android developer I'd be very unhappy about this.
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
What's the point of targeting a base of three hundred million people who are statistically unlikely to ever spend money on apps? Better to target the numerically smaller group of people who spend LOTS AND LOTS OF MONEY on apps.
You may want to actually read the site that you cite, because it doesn't support your claim, at all.
The author of the article said that the ad-supported version of Angry Birds makes more money for them than the paid version, and is only speculating that based on a predicted $1m in ad revenue per month. There was further speculation that this may be because Android's marketplace is limited in scope and "not too great."
Seriously - that leap you made to your conclusion is over an awfully large gap.
Quo usque tandem abutere, Nimbus, patientia nostra?
The link doesn't say anything about them making more money with Android.
It says on Android they go with Ad based model, because the pay model doesn't work as well on Android.
There is no comparison with iOS.
I am the author of projectM, a much more complex graphical application that the game in question here. Android fragmentation is an issue for me, but ONLY because of live wallpapers. The "standalone" version of my app is amazingly consistent across the different Android GPUs. I suspect their developers are not very experienced with OpenGL and shaders. The entire point of OpenGL is to abstract the GPU away from the developer. It works. projectM is profitable. What I take from this article is that an iOS port could bring me to Apple levels of profitability!
In my experience new developers are very bad at adapting to new ways of doing things and very good at blaming the system for their own problems. They'll do something that is not the right way to do it on this system, hasn't been for a long time, is documented on how to do it, and then blame the system.
Two of my favourite examples of developer laziness:
1) Lack of 64-bit apps for Windows. While I realize most apps don't need to be 64-bit, and 64-bit Windows provides flawless 32-bit support, you should still have 64-bit version available. They do run a tiny bit faster and it is just the right way of doing things. Let's start getting rid of the legacy stuff. What's more, it isn't hard to do, at least according to the developers I hang out with. You set the compile target for 64-bit and go. Maybe a couple things to correct but all in all the compiler takes care of the details. However most don't. The reason is they were doing shit in the code they never should have, like casting pointers in to 4 byte integers and so on. They write bad code, and it makes 32/64-bit porting a problem.
2) Drivers. Back when Windows 2000 came out, it introduced a whole new audio driver model, a much better one, called WDM. It supported the old NT drivers for legacy, but WDM was the way to go. Well the pro sound card I had wasn't getting WDM driers. They claimed WDM couldn't work for pro software because of a built in delay. That sounded wrong so I checked the docs and sure enough, there was a mode (KS) that bypassed it. Finally the driver came out and supported only 2 of the 8 channels. They claimed it was a limitation of WDM. Again checking the docs revealed that wasn't true. Eventually they got a fully working WDM driver but it took a long time, over a year, and much blaming the new format.
So I could see it often being the case for Android too. Developers know one way of doing things, it asks you to do things a different way. Developers ignore that and do it their way, and it leads to problems.
While I'm not saying Android is 100% blameless here, you need to make sure you are doing things the way the platform wants, regardless of if that is the way you like to do things.
Finally there's just the fact that people need to accept that maybe mobile phones aren't as profitable as they want them to be. Yes I know, Angry Birds made eleventy kajillion dollars. You aren't angry birds, you aren't going to make so much. Some people have the right combination of luck, timing, and talent to make a shitload. Many others will not make a ton. That's life.
It might help if Android had some sort of built in performance metric similar to the Windows experience index, that can measure the CPU/GPU/memory/etc... and spew out some easy to understand numbers that a user can use to compare to minimum specs listed in the Android store. Something like you need a minimum score of 3, recommended 4, you check your phone, see it only has a 2.2 and skip buying that particular game. No confusing GPU series numbers, memory amounts, CPU Mhz or Ghz or core count numbers, just a simple score the user can compare (or even the device automatically compares and lets the user know). As far as I know nothing like that exists just yet but it would be simple to implement and really solve the problem of different device capabilities for game developers.
I don't think that is what he is saying at all. Basically, don't try to turn a can opener into a rocket launcher, is what he is trying to say.
He does have a point. The form factor alone, combined with several other technical flaws (or challenges) such as processing power and battery life, make using cell phones as anything other than a phone, just plain foolish. We have ended up with very expensive devices that don't do any particular function really well, have a piss poor form factor for web surfing (in standard page layouts) and applications.
As far as the tablet goes, I disagree. Tablets do have a form factor suited for gaming and applications. That extra size allows for more processing power and battery life.
I understand the desire though. One device. Dock it at home, have a different form factor and inputs, take it with me, have different functions, etc. Multiple devices really suck. Going back to the days of a cell phone, Palm, MP3 player, etc. is not something I want to do.
The biggest gripe in the article is a problem plaguing Android right now. That is inconsistency in the hardware and platform itself. It seems to be less consistent and reliable than a PC as far as software and drivers go. Gaming is a bleeding edge industry anyways, and Apple has always had that benefit of homogeneous hardware. I don't really see the point in griping about it. If it does not make financial sense to develop on it, stop doing it. That will send a message to the manufacturers to get their shit together and start working with a standard a little more seriously.
At this point I am ready to go back to a clam shell phone. I really, really don't want something that operates so terribly because it is trying to be too many things at once. While I would like one device, I am thinking that a tablet and a phone might just be the way to go here.
The form factor just sucks and trying to slam more and more power into it to do something else in a mediocre fashion that is also just a losing battle as far as battery life is concerned seems rather pointless to me.
So it's not that I don't want to try something new. We have. I call it a failure. Now, let's try something different. Perhaps, modular devices and flexible displays that expand. Allow me to just take a very very small phone device with me, and choose when to dock into a tablet. Retinal displays, or displays built into my glasses. Basically anything other than the form factor and inputs on the standard smartphones today. They just plain suck to me.
So in essence the whole article is bitching about the difficulty of developing games for these devices, and have encountered the same problems PC game developers have struggled with for decades: inconsistent driver level support for OpenGL features and buggy implementations.
To imply that this is a problem with the Android platform is disingenuous. The problem is the graphics programming stack, not the operating system, it's languages, or it's libraries.
And quite frankly, the "problem" is irrelevant to anyone doing "real world" applications instead of graphical eye candy for video games. Had this been someone doing a "news reader" or some such other common style of application, it would have made me sit up, take notice, and question the sanity of Android as a platform.
But as it is, it only makes me question the sanity of a game developer being surprised that there are differences between the hardware and driver stacks for different machines/cards.
I do not fail; I succeed at finding out what does not work.