Bounden on Android delayed, needs help(gameovenstudios.com)
gameovenstudios.com
Bounden on Android delayed, needs help
http://gameovenstudios.com/bounden-on-android-delayed/
8 comments
Device proximity and calibration could absolutely be an issue in that video.
In regard to their solution (having to whitelist devices based on user feedback), I feel it's going to be a long, uphill battle. It's been tried before via a device knowledgebase and open-source analyzer app [1], but unfortunately, Android is just too ubiquitous for this to be feasible long-term (without direct AOSP support).
My suggestion: the devs should create a free, trial version of the game that takes advantage of all of the hardware it requires. If it checks out, offer the sale.
[1] https://code.google.com/p/android-analyzer/
In regard to their solution (having to whitelist devices based on user feedback), I feel it's going to be a long, uphill battle. It's been tried before via a device knowledgebase and open-source analyzer app [1], but unfortunately, Android is just too ubiquitous for this to be feasible long-term (without direct AOSP support).
My suggestion: the devs should create a free, trial version of the game that takes advantage of all of the hardware it requires. If it checks out, offer the sale.
[1] https://code.google.com/p/android-analyzer/
Thanks! This information should be more known really. I always assumed that either the compass in my nexus 5 is just crap or approximated from gps or something like that. But no - wave it around and it becomes accurate! It's really sad that the information doesn't come with the device itself.
Whitelist away! As an Android supporter the best way to force the environment you want is to target the environment you want. Once people see certain devices do not support the features they need they'll choose ones that do, and that encourages others to add it as well etc etc.
Your Vine does a great job showing the problem and its clear that you have done your part to try to make it work.
Best of luck!
Your Vine does a great job showing the problem and its clear that you have done your part to try to make it work.
Best of luck!
An alternative to whitelisting would be a generous refund policy [beyond the standard window]. I've paid for more than a few apps that said "This might not work on your phone because of XYZ. If it doesn't we'll give you a refund."
This is a very good reason why, as much as I want to, I can't support Android. As a developer it's a complete pain in the ass to support. The webcam/media codecs are very similar to this and there are many other types of apps like this. Google really needs to step and figure out a way to fix this issue if it wants to challenge iOS's position as a favored dev environment.
The differences in development environment aren't as important as the money factor, for me. Apple's market consists mainly of people willing and able to pay the premium for associating with the Apple brand, and consequently it's a no-brainer to publish apps on that platform.
Edit: I also don't write apps that involve very specific use cases for hardware; my apps are utilities and entertainment (games). Consequently the differences in environments are actually quite trivial. I can easily control for "fragmentation" on Android by targeting 4.0 or later, which serves the majority of Android phones, in a (mostly) uniform way.
Edit: I also don't write apps that involve very specific use cases for hardware; my apps are utilities and entertainment (games). Consequently the differences in environments are actually quite trivial. I can easily control for "fragmentation" on Android by targeting 4.0 or later, which serves the majority of Android phones, in a (mostly) uniform way.
How are these problems any different from developing for PCs?
Because, Microsoft and even linux have hardware abstractions that mostly conform to a spec. The spec in Android is complete crap and largely ignored by the hardware vendors. In Windows and linux you get the complete OS from the OS owner (MS, or ubuntu or red hat etc...) and each driver has to match the spec exactly or the driver will fail, with Android you are getting custom forks of the OS. Each one is customized to the hardware and has a different behavior.
In short it's MUCH easier to support different hardware in the PC world because the OS vendors have standardized the specs and in Android it's very wild west, each hardware vendor is supplying their own version of Android which is mostly the same but has subtle but key differences.
In short it's MUCH easier to support different hardware in the PC world because the OS vendors have standardized the specs and in Android it's very wild west, each hardware vendor is supplying their own version of Android which is mostly the same but has subtle but key differences.
In the interest of total disclosure, this is not my project and I am not in any way involved with Bounden. I just found it interesting and passed it along.
I hope that's not bad form; if it is, I'm genuinely sorry for the error.
I hope that's not bad form; if it is, I'm genuinely sorry for the error.
It's not bad form to post a link to someone else's content. On the contrary, on Reddit, posting only self-promotional links is considered spammy, though I'm not sure what people would say about it here.
There's nothing wrong with sharing interesting things about a project that belongs to somebody else.
Even Google can't cope with this on phones that they themselves (or rather their Motorola subsidiary) have manufactured. Ingress has really annoying known issues with getting the user's heading from the compass on some devices, including some Motorola ones.
That tends to be Ingress in general... unless one of the updates in the past few months has changed the landscape, I stopped trying to use the compass orientated maps in my N5 and N7 a long while ago.
That's a minute gripe though for an otherwise really engaging game.
That's a minute gripe though for an otherwise really engaging game.
Try to avoid a whitelist. It will drive you nuts maintaining it. Specify app requirements as tightly as possible, in terms of which hardware capabilities are required, and blacklist devices known not to work. If you catch all the popular broken devices, your rate of irritated customers should be very low.
This will, initially, require the same level of testing effort as making a whitelist, but will be much easier to maintain.
You may want to have the first thing in the product be a validation test and/or calibration. But you risk confusing your customers.
This will, initially, require the same level of testing effort as making a whitelist, but will be much easier to maintain.
You may want to have the first thing in the product be a validation test and/or calibration. But you risk confusing your customers.
[deleted]
The answer is to say "no, fuck you, iOS only, bitches". Apple made DAMN sure that their platform is of consistently good quality. If Google can't make that same guarantee, why in the hell should you develop for their platform?
Because you're losing out on 80% of the mobile market.
Most of which are rinky-dink dumbphone replacements that see few, if any, app purchases.
If you're developing a mobile app, iOS is still where you'll find the majority of your audience, and it's less of a money sink when it comes to development and QA.
If you're developing a mobile app, iOS is still where you'll find the majority of your audience, and it's less of a money sink when it comes to development and QA.
A market of disgruntled customers.
Here's a link explaining this from one manufacturer of electronic compasses (and the biggest one, so there's a very good chance your smartphone has an AKM compass - I know mine does): http://www.s3sensor.com/en/s3/calibration/