We've been sitting on our iOS developer license for a little while since we've been fairly occupied catering to the problematic nature of our Android apps. As soon as we can get our existing products on Android to an acceptable level we'll begin porting Bubble Zing and possibly Simple Match over to iOS.
One of the major changes in our process and code was to put as much game logic in to portable C code for Bubble Zing so that, in theory, we could just wrap the game code in to iOS objective-c wrappers and retain the java wrappers for Android. Of course, this major shift in philosophy warranted a huge time undertaking on our Android ports as we essentially had to recode everything... meaning we may as well put a lot of code in to libraries and that whole thing.
On the plus side, all this "nativeification" of game code has excellent performance indicators and should increase our product exposure to older devices that needed all the speedups (fairly badly might I add).
I suppose this process was inevitable anyways. I mean after all, Bubble Zing 1.0.3 (the latest public version as of this writing), showed that just drawing a background graphic during gameplay - JUST DRAWING THE BACKGROUND - took 60% of the processor in several test devices. That was horrendous and completely unavoidable due to the nature of java, dalvikvm, and opengl es. The only way around it was to go native code and start screwing with lower level stuff... and this has already paid off in huge ways... but it was not without its own drawbacks and tradeoffs. Specifically, things that use to work great now require extensive rework and compromises. Some things now look "worse" than in 1.0.3, but perform a ton better, yet the overall gameplay experience has been increased a lot.
Anyways, once we get Bubble Zing 1.1.0 up and in to public hands, our iOS adventure shall begin! We took a look at XCode and their iOS stuff already, and I must say it was quite welcoming from a developer's perspective and I'm going to assume from a business perspective as well once we get there!
Hopefully from here on out, all our products will see a simultaneous Android and iOS release at the same time!
Showing posts with label google. Show all posts
Showing posts with label google. Show all posts
Friday, April 27, 2012
Saturday, April 14, 2012
Complexities of Android development
As an indie mobile developer, I can personally attest that making things on Android - especially games - is pretty difficult.
I ran across this article about Battleheart's developer basically giving up on the Android platform as being "unsustainable" (original blog post by the developer here).
Now, this person has quite a lot of good points that works against Android devices in the business sense. Why would you want to support something that takes a vast disproportionate amount of money to create?
Android has lots of problems for developers, and one of which is that simply Android users are generally more frugal with buying things (to include newer devices). This means that as a developer, we should cater to old technology because a decent segment of the Android market are using old devices.
For example, I attempt to target Android 1.5 devices when and where possible so that, in theory, all newer devices should be able to run our games. That sounds good at first, but this isn't always the reality, and this is where Battleheart's developer has a good point. The only sure-fire way to guarantee that apps will work on a device is to physically test it on that device.
I wish it was an easy case were we can just load up our apps in an emulator, test, fix, deploy, but it definitely isn't that simple. Each device manufacturer seems to have implemented various things about Android in their own way; forcing developers to cater to each device maker!
For example, only Android 2.1 allows for multitouch. We created a virtual Dpad app that accepts user input on a circle (simulated analog dpad if you will) along with 2 virtual "buttons" - think like a Nintendo controller, but with a virtual directional pad.
After several days of developing and testing, it works 100% on our Motorola RAZR, but breaks horribly on Samsung Galaxy Tablet... and it all came down to the fact that Samsung implemented multitouch differently than Motorola (Motorola seemingly did it in accordance with the Android dev specs... Samsung apparently didn't?!). As a developer, there would be no way for me to know this unless I physically had both of these devices... and this is a major problem with deploying games/apps on Android without having hundreds/thousands of Android devices to test against. As a small indie shop, this means very unlikely to fork up all this cash for devices just to get meager amounts of downloads in Google Play market.
I can definitely feel what Mika Mobile is talking about as we've run in to these barriers as well. It isn't impossible, but it sure raises the bar for "quality" (ie, not crashing/breaking) apps to have widespread deployment on the Android platform.
I ran across this article about Battleheart's developer basically giving up on the Android platform as being "unsustainable" (original blog post by the developer here).
Now, this person has quite a lot of good points that works against Android devices in the business sense. Why would you want to support something that takes a vast disproportionate amount of money to create?
Android has lots of problems for developers, and one of which is that simply Android users are generally more frugal with buying things (to include newer devices). This means that as a developer, we should cater to old technology because a decent segment of the Android market are using old devices.
For example, I attempt to target Android 1.5 devices when and where possible so that, in theory, all newer devices should be able to run our games. That sounds good at first, but this isn't always the reality, and this is where Battleheart's developer has a good point. The only sure-fire way to guarantee that apps will work on a device is to physically test it on that device.
I wish it was an easy case were we can just load up our apps in an emulator, test, fix, deploy, but it definitely isn't that simple. Each device manufacturer seems to have implemented various things about Android in their own way; forcing developers to cater to each device maker!
For example, only Android 2.1 allows for multitouch. We created a virtual Dpad app that accepts user input on a circle (simulated analog dpad if you will) along with 2 virtual "buttons" - think like a Nintendo controller, but with a virtual directional pad.
After several days of developing and testing, it works 100% on our Motorola RAZR, but breaks horribly on Samsung Galaxy Tablet... and it all came down to the fact that Samsung implemented multitouch differently than Motorola (Motorola seemingly did it in accordance with the Android dev specs... Samsung apparently didn't?!). As a developer, there would be no way for me to know this unless I physically had both of these devices... and this is a major problem with deploying games/apps on Android without having hundreds/thousands of Android devices to test against. As a small indie shop, this means very unlikely to fork up all this cash for devices just to get meager amounts of downloads in Google Play market.
I can definitely feel what Mika Mobile is talking about as we've run in to these barriers as well. It isn't impossible, but it sure raises the bar for "quality" (ie, not crashing/breaking) apps to have widespread deployment on the Android platform.
Subscribe to:
Posts (Atom)