Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Android Google Software Games Technology

Battleheart Developer Drops Android As 'Unsustainable' 649

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.'"
This discussion has been archived. No new comments can be posted.

Battleheart Developer Drops Android As 'Unsustainable'

Comments Filter:
  • Sounds fair enough (Score:5, Interesting)

    by lakeland ( 218447 ) <lakeland@acm.org> on Saturday March 10, 2012 @05:39PM (#39314437) Homepage

    But I can't help wondering if there is something wrong with the code that it struggled with different GPUs or crashes on new devices without special patches. Most code seems pretty robust to such things.

    • by guruevi ( 827432 ) on Saturday March 10, 2012 @05:44PM (#39314457)

      For these devices (mobile devices) though the problem is that

      1) you have to go pretty deep into the guts of these devices to get the performance required. I would compare it to some of the tricks that were used in the first 3D shooters like Doom etc. in order to render properly.
      2) Not all device support the whole subset of whatever environment you may want to use. I think that was the main problem here is that you program a specific shader through eg. the OpenGL interface (is that even available on Android?) and then device x comes along and the manufacturer decided to either drop or not implement that feature in their GPU in order to save costs, brainpower etc.

      • by Anonymous Coward on Saturday March 10, 2012 @06:04PM (#39314599)

        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.

      • by mangobrain ( 877223 ) on Saturday March 10, 2012 @06:53PM (#39314937) Homepage

        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

        • by Sycraft-fu ( 314770 ) on Saturday March 10, 2012 @09:35PM (#39315659)

          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.

      • Re: (Score:3, Informative)

        by AmiMoJo ( 196126 )

        you have to go pretty deep into the guts of these devices to get the performance required. I would compare it to some of the tricks that were used in the first 3D shooters like Doom etc. in order to render properly.

        So the problem is them trying to get console like performance out of a large variety of phones? Sounds like they just need to accept that their game won't run on the low end.

        I think that was the main problem here is that you program a specific shader through eg. the OpenGL interface (is that even available on Android?) and then device x comes along and the manufacturer decided to either drop or not implement that feature in their GPU in order to save costs, brainpower etc.

        Yes, Android uses OpenGL. You query it to see if the GPU supports the stuff you want, just like most platforms. If it doesn't support what you want then you either degrade the graphics gracefully or device not to run. There are thousands of Android games that manage to do that, I don't know why this guy is struggling.

  • Seems to be common (Score:5, Interesting)

    by trawg ( 308495 ) on Saturday March 10, 2012 @05:42PM (#39314447) Homepage

    Just spent the week at the Game Developers Conference in SF and this seemed to be a bit of a recurring theme from having conversations with a couple mobile developers. The cost of supporting Android is too high in many cases and not worth the effort.

    Once of the sessions I sat in on (can't remember who it was now, embarrassingly - I think it was PopCap talking about Bejeweled - not a bit player) pointed out that Android has many many variants on many different handsets. Even though the market size is roughly the same as iOS (his numbers were around ~250m each), iOS has way fewer variants to deal with, whereas Android had many. So you get to spend a lot of time messing around trying to make sure it's working on all platforms.

    I've noticed from flicking through app reviews in the Market, it's not uncommon to see people with complaints about it not working on their particular handset. I haven't had this problem with anything I've tried so it's hard to tell how big a deal it is, but I don't use many apps.

    The general feeling I got from speaking to a few indie developers was that they wouldn't bother doing an Android version unless their title turned out to be a big hit on iPhone.

    • by mrmeval ( 662166 )

      I've had a few flat out crash. 3D is right the hell out as is any decently functioning 2D. I can't get gingerbread because samscum won't release it as they'd have to go with stock android rather than their execrable UI extensions.

      "Pocket Gods" did the support fandango and got rid of about every cool aspect of the game for android as a work around rather than bothering to make it work.

      If I want a game machine I'll get a desktop. I won't be buying another samsung phone and will most likely stay away from thei

    • by tp1024 ( 2409684 )

      You're barking up the wrong tree. The fact is, that nobody can earn any of my money with google apps, for the simple reason that google won't take any of it. I don't have a credit card, as do a lot of people outside of the USA. I could pay for apple apps, if I had any apple products by buying coupons at a local store for cash.

      Don't you agree that giving you customers the ability to pay in a way that is even remotely convenient for them, is a bit of prerequisite for any income whatsoever?

  • by 93 Escort Wagon ( 326346 ) on Saturday March 10, 2012 @05:46PM (#39314469)

    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.

    • by Dunbal ( 464142 ) * on Saturday March 10, 2012 @05:48PM (#39314487)
      You don't get free markets with 800lb gorillas like Apple and Google in the room. Stop kidding yourself.
    • by whoop ( 194 ) on Saturday March 10, 2012 @08:43PM (#39315457) Homepage

      I bought the game last year, and this article got me to thinking. I cannot recall when I last saw an update in the market for it. So, I pulled up AppBrain page for it, and see updates were coming in from May to July 2011. Then there has been nothing since. So, I have to wonder how many tweaks to the shaders and whatever they say they really did? I mean, they gave up on the game a long time ago. It hit 50k purchases in August, so there's $150,000 in sales made. Google takes what, 30%? So that's $105,000 minimum.

      I know I've seen some nasty comments in the user reviews on the market, so I pull up their page there. I see 4991 four or five star reviews, and 383 one to three star reviews. That's just 7% of the reviews are bad. That looks quite good to me. Looking at the recent ratings, there have been many of the 196 one-star reviews posted just in the last couple of days. Since March 1, people have been giving it one star for not having updates like IOS has (Did that version just get an update?), which is an understandable sentiment.

      Now, that's considered a failure for small-time developers? They really put in more time/effort on this than to make it a losing venture?

  • Wow (Score:4, Interesting)

    by Anonymous Coward on Saturday March 10, 2012 @06:00PM (#39314571)

    And I thought Apple fanboys were bad. Android seems to be garnering its own set of rabid followers who disregard reality in favor of their favorite.

  • by bobby1234 ( 860820 ) on Saturday March 10, 2012 @06:01PM (#39314575)

    I think you will find his complaint was that he was spending all his time making up for androids fragmentation and thus not producing content.

    He uses Unity which is a great tool for doing much of the underlying work so the developer can focus more on the game. But if android is dragging him back to messing around with boring details (platform specific and multiple variation for that platform) then the cost/fun/productivity balance gets all wonky.

    • by SplashMyBandit ( 1543257 ) on Saturday March 10, 2012 @06:16PM (#39314675)

      All mobile development is platform specific, whether you like it or not. Apple in particular always has an interest in making you develop for their platform only. The fragmentation of the market is deliberate and always occurs in the current *innovation space*. Same thing happened with web 'standards' (ECMAscript and W3C standards), same thing happened with 'operating systems' (until Java came and levelled most of the differences for the developers interested in doing cross-platform stuff), same thing happened in hardware.

      At the mobile development is balkanized while the big players fight for turf. Who suffers? developers. It would have been nice to have proper Java work on the mobiles too (funny thing is, the early Apple devices actually had hardware JVM support, which Apple did not use) - that way developers would get a benefit of 'write once run everywhere, test everywhere' (which your JUnit and Continuous Integration environments help with - if you are smart enough to use them). However, every hardware manufacturer wants to do their own thing (just like sound, CPUs, disk drives, networking etc etc all used to have non-standardized interfaces in the past). The current mess on mobiles is Apple's fault as much as it is Google's. Face it, they just don't give a sh!t about developer needs, they just want to rule the mobile world and feel that trying to capture the market with non-standard interfaces helps themselves.

    • by robmv ( 855035 ) on Saturday March 10, 2012 @06:25PM (#39314729)

      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

  • by Spy Handler ( 822350 ) on Saturday March 10, 2012 @06:14PM (#39314661) Homepage Journal
    it's Google Play now. Get with it.
  • by TodLiebeck ( 633704 ) on Saturday March 10, 2012 @06:44PM (#39314865) Homepage

    And so far it's been a very profitable investment.

    I am writing applications that require extensive hardware-specific testing (file manager, network-based stuff, system tools). I certainly have plenty of complaints about Android with regard to cross-device compatibility, and I've even found plenty of egregious omissions in the API (e.g., how do you find all user-writable storage without going down to /proc/mounts). That said, I find it to be an overall excellent platform. And it seems to pay the bills.

    My only real complaint with the investment in devices is that I would love for cell carriers and/or Motorola/HTC/Samsung/etc to respond to my requests to have even slightly early access (or guaranteed release day access) to new devices. I'm sick and tired of visiting random cell phone stores who won't reserve product and lie about availability. And I'm tired of explaining that yes I want to pay full retail and no I do not want a contract no matter how much of a better deal it is.

  • by rhysweatherley ( 193588 ) on Saturday March 10, 2012 @06:50PM (#39314901)
    ... but instead I was thanklessly modifying shaders and texture formats to work on different GPUs,

    OpenGL has become a joke under Khronos. More and more of the work needed to render scenes is pushed back onto the application developer. Once upon a time you could specify the material, texture, and light parameters and IT WOULD JUST FIGURE IT OUT! The responsibility for making it run fast was up to the OpenGL implementer, not the application writer. Now you cannot draw a single triangle without a month's worth of effort to implement matrix math, texture uploading, and material lighting from first principles. And then do it all over again on the next device because the stupid chipset vendor decided that they couldn't be bothered making simple color interpolation work fast (I'm looking at you ImgTech).

    The problem is not handset fragmentation. The problem is that the OpenGL API provides no guarantees about what will actually work and work well. It's all thrown back onto the application and the chipset vendors can then brush off bugs in their design with "our examples work great - obviously you don't know how to write shaders".

    It's time the application (not chipset) developer community smacked Khronos upside the head and made them specify a USEFUL rendering API that guarantees good performance for application-level tasks, and decertify chipset vendors who are too lazy to do their damn jobs.

    • by Suddenly_Dead ( 656421 ) on Sunday March 11, 2012 @02:28AM (#39316627)

      Now you cannot draw a single triangle without a month's worth of effort to implement matrix math, texture uploading, and material lighting from first principles.

      This is complete nonsense. You're lamenting the loss of the fixed function OpenGL? This still exists if you really really want to use it, you just need to target ES 1.0.

      No one does it use it, and no one recommends that anyone use it, because it's horribly inflexible. Programming with shaders lets you do just about anything that you want, giving developers unprecedented flexibility. This push came from developers and the GPU manufacturers, not from Khronos.

      Yes, it complicates OpenGL tutorials a bit, but you can get away with using copy-pasted boilerplate when you're just starting out. Matrix math was always part of OpenGL, including the fixed function stuff, it's just a little more explicit now; that's not a bad thing, it helps make would-be OpenGL developers actually learn about matrix math instead of limping along with copy/pasted tutorial code using GLU helper functions.

  • by dinther ( 738910 ) on Saturday March 10, 2012 @06:53PM (#39314935) Homepage

    But the proliferation of so many different devices is not only causing problems for this particular software developer. The so called cross platform web-application is getting harder to test as well.

    Windows (Various versions), Linux (Various versions), OSX (Various versions), Android (Various versions)

    each running

    MSIE (Various versions), Firefox (Various versions), Chrome (Various versions), Opera, Safari and many other browsers

    And somehow developers are to write an application that runs on all these combinations. It is a bloody nightmare. I long to the days there was only windows with the Win32 API to write for. Good debuggers, great IDE's and mature software dev tools. At the moment it is one steaming pile of disjointed crap.

  • by tp1024 ( 2409684 ) on Saturday March 10, 2012 @07:06PM (#39315033)

    Sorry, but I don't have a credit card and I couldn't pay for any google apps however much I wanted to. I can't buy coupons for google market/play with cash, I can't use wire transfer, I can't use paypal ...

    It's not the quality of the apps, it's not the quality of the handsets, it's not the screen resolution or any of the other canards serving as reasons. It's the business model.

    Just take my money and shut up.

  • by Zorque ( 894011 ) on Saturday March 10, 2012 @07:38PM (#39315203)

    He's always had something negative to say about Android, but when the problem is addressed he does nothing to make use of the fixes. There are plenty of other developers who do just fine on Android and manage to not only support their apps but release new versions of them as well. Maybe they're just more talented?

  • Sad but true (Score:5, Informative)

    by billcopc ( 196330 ) <vrillco@yahoo.com> on Saturday March 10, 2012 @07:40PM (#39315211) Homepage

    All of you who are saying this developer and their code just sucks, you've never written any significant mobile apps, have you ?

    I work with IOS, Android, Blackberry, WinPhone7. IOS and Win7 are a walk in the park, compared to the other two. IOS, specifically, has stellar compatibility across all devices. I only encounted a single issue with one of my apps, when upgrading to IOS 5, and it had to do with some marginal code I was using, whose undocumented functionality had finally been obsoleted. The fix took all of 15 minutes to research and implement. Most importantly, I only need to design for two sizes: phone, and tablet. If I'm lazy, I can skip the tablet, and let it scale things proportionally. This isn't optimal, but for some apps it's sufficient.

    On Android and BB, there are as many display sizes and feature sets as there are devices. Your app might look fine on your emulator and personal device, but be completely out of whack on another, so you end up having to collect numerous devices and installing a dozen emulators to cover any significant portion of the user base. Let's not forget that these emulators are horribly slow and unstable, so if I have to test and debug a build in 10+ different environments, there goes my afternoon. That's for one build! It's quite simple: for Android or BB, I typically take the IOS budget and double it. If I were writing 3D games, I would probably quadruple it because now there are countless GPUs to target and no good middleware available to abstract away those differences. Android and BB development is at least 10 years behind, in terms of comfort and convenience. It often reminds me of writing DOS software.

    Windows Phone 7 is actually not too bad. For anyone experienced with Visual Studio, it's a very familiar workflow and has much commonality with IOS development. It's extremely fast to work with, and you can get a good sense of how your app will scale, just by resizing the workspace as you're designing it. I don't care much for the platform itself, but I don't mind developing for it - I find the toolset quite pleasant.

    • by ThePhilips ( 752041 ) on Saturday March 10, 2012 @07:52PM (#39315273) Homepage Journal

      So what you say, is that two mostly Java-based platforms have the worst portability of the bunch?

      Though not surprised, I find that quite ironic.

    • Re:Sad but true (Score:4, Informative)

      by JAlexoi ( 1085785 ) on Sunday March 11, 2012 @01:21AM (#39316443) Homepage
      Really? Are you using absolute positioning on Android? It seems that you got into mobile development via iOS, where you always know the pixel width an height of your screen. You would not be the first to say that. I tend to hear it from die-hard iOS devs. And since I come into layout development from the web, where relative positioning is used for years, I don't find it harder to develop and think the right way for Android layout development. iOS development is very much a pixel precision affair.
  • by guidryp ( 702488 ) on Saturday March 10, 2012 @08:27PM (#39315393)

    Sounds like pretty clear case of a fragmentation issue.
    From TFA:
    '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.

    It isn't a case of poorly skilled devs either; this is backed up by other Game developers like Epic and id that are avoiding the platform as well:
    Carmack(id):
    http://techcrunch.com/2011/04/15/john-carmack-ios-still-better-than-android-for-mobile-game-development/ [techcrunch.com]
    "Android is far too fragmented to develop for, both from a hardware and software point of view. "
    Sweeny(Epic):
    http://actionatadistance.net/post/4386288135/sweeney-android-fragmentation [actionatadistance.net]
    Says Sweeney, "When a consumer gets the phone and they wanna play a game that uses our technology, it's got to be a consistent experience, and we can't guarantee that [on Android]. That's what held us off of Android."

    Fragmentation is a real issue. Less so when you developing a web type, text app with some 2d bitmaps, but when you are developing more complex games and you are trying squeeze performance from the platform, fragmentation has a significant negative effect.

  • by psperl ( 1704658 ) on Saturday March 10, 2012 @09:13PM (#39315567) Homepage
    I am the author of projectM [google.com], 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!

A Fortran compiler is the hobgoblin of little minis.

Working...