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.
Showing posts with label depression. Show all posts
Showing posts with label depression. Show all posts
Saturday, April 14, 2012
Thursday, March 1, 2012
Design to Product - Post-Production (17 / 17)
Now that the product has been released, it is time to look back, recollect on lessons learned, and already be buried in to the next adventure.
If you took a look at the game design from the previous section and took a look at the game video (or played the game itself ideally) you might notice quite a few discrepancies from what is described in the document as opposed to what actually was developed. I cannot stress enough that this is what happens. Throughout the articles I talked about stuff like requirements creep, play testing, and things like this. Pretty much all of those things happened, we applied our creative process on to the original game design, and ended up with the product you [hopefully] saw. Yes, we were bad and never updated the original document, but we also ended up preserving what we started with, and what the end result was.
During development, and using the design as a guideline, we also took a bit of time discussing what features were necessary as opposed to being acceptable for future updates. One of the fairly easy features to figure as "something for later" is code optimizations.
The game needs to be playable, some minor speed enhancements are ok during development, but finer tuning the engine performance isn't required to get the product completed. Thus, these things are "nice to haves".
We will also be tweaking some graphics, offering different qualities of game resources, and changing things like timing, based on customer feedback now that the initial product has been released. We did some basic play testing while the product was under development, but we admit that we are a bit subjective with what is and is not "good" from an outsider's perspective. Therefore, we will also not rule out "customer feedback" as a guiding principle in what we will still do to the product in to the future.
Of course, some of the blatant things we will work on is when the inevitable "omg this doesn't work on my phone/tablet" feedback comes in. This is expected to happen and we just await the first complaints. There really is no way to guarantee that our software will work on all of those device configurations short of us physically testing our product on all hundreds/thousands of them ourselves. Yes, we can use the emulators, and we do, but this is different than using the actual devices. For example, it is impossible to test application performance against an emulator if the emulator itself is at the mercy of the power of the computer in which it is run against... this complicates accuracy of the performance testing.
From here, we gaze out in to what we will accomplish with this product. Minor feature corrections, product enhancements, and possibly even small new features will likely occur and we will be delighted to integrate those things as they happen. Any major new thing will either warrant a re-release of the product in the form of "2.0" or possibly become a whole other product all together.
At the end of the day, version 1.0 shipped and now we can expect all those hundreds of pennies to come piling in over the months/years it is active in the market! The product that went from "design to product" took just over 3 weeks to go from start to finish and only time will tell how much money we will gain or lose in the bigger picture from this endeavor.
If you took a look at the game design from the previous section and took a look at the game video (or played the game itself ideally) you might notice quite a few discrepancies from what is described in the document as opposed to what actually was developed. I cannot stress enough that this is what happens. Throughout the articles I talked about stuff like requirements creep, play testing, and things like this. Pretty much all of those things happened, we applied our creative process on to the original game design, and ended up with the product you [hopefully] saw. Yes, we were bad and never updated the original document, but we also ended up preserving what we started with, and what the end result was.
During development, and using the design as a guideline, we also took a bit of time discussing what features were necessary as opposed to being acceptable for future updates. One of the fairly easy features to figure as "something for later" is code optimizations.
The game needs to be playable, some minor speed enhancements are ok during development, but finer tuning the engine performance isn't required to get the product completed. Thus, these things are "nice to haves".
We will also be tweaking some graphics, offering different qualities of game resources, and changing things like timing, based on customer feedback now that the initial product has been released. We did some basic play testing while the product was under development, but we admit that we are a bit subjective with what is and is not "good" from an outsider's perspective. Therefore, we will also not rule out "customer feedback" as a guiding principle in what we will still do to the product in to the future.
Of course, some of the blatant things we will work on is when the inevitable "omg this doesn't work on my phone/tablet" feedback comes in. This is expected to happen and we just await the first complaints. There really is no way to guarantee that our software will work on all of those device configurations short of us physically testing our product on all hundreds/thousands of them ourselves. Yes, we can use the emulators, and we do, but this is different than using the actual devices. For example, it is impossible to test application performance against an emulator if the emulator itself is at the mercy of the power of the computer in which it is run against... this complicates accuracy of the performance testing.
From here, we gaze out in to what we will accomplish with this product. Minor feature corrections, product enhancements, and possibly even small new features will likely occur and we will be delighted to integrate those things as they happen. Any major new thing will either warrant a re-release of the product in the form of "2.0" or possibly become a whole other product all together.
At the end of the day, version 1.0 shipped and now we can expect all those hundreds of pennies to come piling in over the months/years it is active in the market! The product that went from "design to product" took just over 3 weeks to go from start to finish and only time will tell how much money we will gain or lose in the bigger picture from this endeavor.
Subscribe to:
Posts (Atom)