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.'"
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?
Which is why they're making good money on the Apple market, right?
Justice is the sheep getting arrested while an impartial judge declares the vote void.
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.
If only your lack of knowledge meant the problem didn't exist.
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.
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.
Apparently, a whole range of devs can't release a quality product on Android while they do just fine products on iOS. Coincidentally, it's all the devs that needs 3D Rendering.
Go figure. It cannot be that Apple's platform is much more leveled. Nah. Can't be.
Write boring code, not shiny code!
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.
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.
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.
developers need 100's of different pieces of hardware to sort out android issues. or one new apple model a year.
Every android vendor is releasing 6-12 new models a YEAR. each one with different OS, hardware, and generic software configurations.
Those vendors charge each developer for every phone they buy. Why? because 99% of the developers don't have the reputation to earn free hardware.
i thought once I was found, but it was only a dream.
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.
Funny isn't it. When iOS development is in question, $99 to join the developer programme is too much money. But when it's Android, spending $thousands on test hardware is neither here nor there. It's even waved away with fantasies of free test hardware for developers.
Android cheerleaders just don't live in the real world.
As usual, the summary distorts TFA, but TFA clearly states that the developer's main complaint is a 50Mb limit to the download cache for Market apps. They then state that they don't want to commit resources to making game data a separate download.
Think about that for a scond.
This is not a challenging task, even for a moderately skilled coder - it's a solved problem. Now I have no doubt there's good reasons why this one developer can't support Android, despite 250,000 apps making it there, but the reason given in TFA is not the real reason.
In reality, what's happened is that Google, recognising the need for larger apps and data, has increased the size of downloads from the Market as Expansion files. They did this so they could track when large in-game downloads were completing, because unscrupulous dvelopers were using large/slow downloads to make sure the user had no opportunity to finish the download before the refund period expired. Now the Market tracks that the user has completely finished downloading large applications, then starts the refund period. Most newer devices should download expansion files automatically, but older ones download them when you first run the application.
I'm not suggesting that a developer with a poor quality port from a different platform might want to deny users the opportunity for a refund. Though, if they are really having trouble implimenting something as simple as in-game downloads, I might question the quality of their other work...
"I've got more toys than Teruhisa Kitahara."
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.