|
The advent of smartphones has opened up an entire new range
of platforms for game development, particularly for independent game
developers. The iPhone's App Store model has been enormously successful, with a
recent estimate of $2.4 billion in annual sales.
From a developer's perspective, app stores have the
incentive of a distribution channel with powerful search and marketing capabilities.
They also provide an intermediary that handles the logistics of selling and
downloading -- generally for a cut of 30%.
You've probably heard the Cinderella stories of developers
like Steve Demeter, whose triangular variant on match-3 games, Trism,
reportedly earned him $250,000 in just two months in the iPhone App Store. Take
also Ethan Nicholas' iShoot, which
reportedly earned $600,000 in a single month. With the gold rush mentality and
the iPhone's undeniable success with the App Store, why would a game developer
choose to make a game for any other smartphone platform?
About six months ago, I started developing games for Google's
Android OS, somewhat by chance. A friend who works for Google gave me a G1
developer's phone as a gift. At that point, I hadn't even heard of Android. In
the process of learning about the OS, I came across the Android SDK, and
downloaded it to give it a spin. I was instantly hooked.
While iPhone apps are written in Objective C, the Android
SDK uses relatively more programmer-friendly Java. The iPhone store charges
developers $99 a year to distribute their apps, while Android has a one-time
$25 fee for developers. And the review
process for iPhone apps grows increasingly lengthy -- sometimes weeks or more
-- and it's somewhat arcane. Android apps go live as soon as the developer hits
the publish button. Google handles the review process post-hoc, and is much
more lax in terms of content.
 With the greater ease of producing and distributing apps
through the Android Market, why aren't game developers large and small
clambering to produce quality games for the system? There are a number of
reasons, but number one is, of course, money.
Mobile ad company AdMob released its July 2009 report (pdf) which
notes the following:
-
45 million estimated combined iPhone and iPod
Touch users, compared to 3 million Android users
-
50% of iPhone users bought at least one paid app
during a month period, compared to 19% of Android users
-
The estimated market value of the iPhone App
Store is about $200M per month, compared to an estimate of about $5M per month
for the Android Market
So a major part of the equation is pure size. But another
factor is the population makeup of Android users and their perception of the
platform. The iPhone user population is likely much more diverse, with a greater
cross-section of users representing more diverse demographics, while the
Android user population is still likely predominantly tech-centric early
adopters. Since Android is an open-source system, the perception may also be
that the software that runs it should follow the same model. Thus many users
may be reticent to spend money on apps.
|
Printer-Friendly Version
I have been meaning to check out Android.
However I do take some issue with this line:
"While iPhone apps are written in Objective C, the Android SDK uses relatively more programmer-friendly Java."
Without getting into some religious jihad over how gross Java is, I will point out that the amount of Objective C you have to deal with on the iPhone is minimal, especially for games. Currently we have a code base that runs on iPhone, Win32, OS X, and just about any other platform that has a C++ compiler.
99.99% of it is written in C/C++, which is indeed 'programmer-friendly'. The Objective-C layer is minimal about 100 lines of code. So the statement about Objective-C on iPhone, especially for game development where you potentially won't be doing much with the App/Gui Kit other than making a window, isn't significant.
Personally I would take nice, native C++ development over Java any day. In fact, I would take Objective-C or even C# over Java, but that is just me.
With that said, thanks for the article, I plan on looking at Android at some time. It has been a long time since I had to deal with Java, perhaps its better than I remember. Android would be a good excuse to get into it.
(I'm intending to learn Scala sometime.)
Of course, if you're just making a match three game you probably don't worry so much about it. But when you're trying to do high quality games like what you see on the iPhone, PSP, and even DS, it's a major issue.
"One advantage of programming for the iPhone is not having to worry (much) about hardware compatibility. This could potentially be a problem for Android game developers as new handsets emerge. The possibility of a backlash exists if users buy a new Android smartphone only to find that the most popular games in the market don't render properly on their screen, or that the control scheme for the game doesn't work."
the biggest diference between the iphone and android, and the reason android has failed is simply that google do not believe in native applications, or even client side applications for that matter.
we've all learned the mistakes of virtual machines, the write once debug everywhere approach that came with the extra interpretation layer added headache upon headache to j2me developement, garbage collection on embbeded devices, seriously!
code portability for the iphone being from c++ means 90% of appications we use and are happy with can be relativly painlessly ported to the iphone, google could've exploited portability from j2me, which would've been a waste of time as we'd all rather forget the games of that era, however they delibetatly broke thier java compatability to avoid paying royalties to sun, negating the only, arguable strength of thier new platform.
i don't agree that target platforms is a big deal anyone who works with higher end devices consoles and pc's will tell you that targeting differant screensizes or even processors is a breeze if you're running nativly, when running on top of a foggy poorly implented interpreter it's a different matter and i'm sure we'd all agree 90% of porting issues with j2me were introduced by the jvm.
i'm aware of the java native interface, it shouldn't be nessisary, and i don't trust google not to rewrite it serveal times over like everything else, i don't think they're interested in the platform, there's a reason there's no iphone quality games on the market and the shops riddled with people trying to charge for pdf readers.
- The Open GL ES 1.0 Java implementation supported by Android is a standard, not something that Google invented. You can read about it here: http://java.sun.com/javame/reference/apis/jsr239/javax/microedition/khronos/open
gles/package-summary.html
- The NDK (Native Development Kit), as mentioned by Android Developer above, allows you to write native-code libraries and call into them from a Java frontend. As of the most recent version (NDK 1.6), this includes the ability to call directly into OpenGL ES (previously you were limited to just libc/libm). The NDK is here: http://developer.android.com/sdk/ndk/1.6_r1/index.html
- Applications that do not use private APIs (that is, APIs that are not included in the public SDK or are undocumented, including calling Android framework code from native libraries) may very well break from system update to system update--that's why they are private. Public APIs are ready for prime time and will not break between versions; the reason that the original release of the NDK did not support OpenGL ES bindings was because time was required to ensure that native code libraries are future-proofed.
- Of course, if you use native code you tie yourself to a particular CPU architecture. You can support multiple architectures in a single binary, and at the moment all of the handsets on the market are pretty much the same internally, but the advantage to a pure Java application is that it should run on any hardware.
- There are already a number of 2D and 3D games on Android Market that are written in pure Java. Here's the trailer for one that I like: http://www.youtube.com/watch?v=TcYFe_hf1IA . If you are interested, you can also look at (shameless plug) the SpriteMethodTest sample, which shows several ways to draw sprites (pure CPU vs various GL implementations) and profiles them. That code is here: http://code.google.com/p/apps-for-android/source/browse/trunk/SpriteMethodTest .
There are a few other games with physics, but not very many at all. The iPhone has plenty that are successful, which indicates players love physics-based games. I would love to see more of them for Android and Yakloin intends on helping out.
I think this was a great article. Very well written and researched! Thanks!
Ooops looks like I only read the first page. Thanks for the correction!
RT
www.complete-privacy.at.tc
I was able to build a prototype of my game in less than a week, (thanks for all your notes Chris!)
The biggest hurdles have been the level editor (C++) and the backend server. (Not Android related, obviously)
Having never used Java before, I find it really easy to work with. Threads and message passing are handled beautifully and google has paid attention in implementing it in a way where GUI lag is minimal.
However, my experience with the iPhone has been minimal at best. Simply because I can't afford the contract expenses, and neither do any of my friends. This makes the upcoming android phones that much more viable and interesting to me. I've seen a lot of G1s in the wild in 'poor' communities.
I don't understand what the big problem with different screen resolutions and input devices is. With openGL screen resizing pretty much comes for free and if your game logic can't bear with changes in the screen size than you should revise it. Again, I've dealt with this and it wasn't really a big deal, I just programmed defensively by keeping in my mind that not all screen resolutions are going to be the same.
Same with the input devices, why can't you simply write your code to have different interfaces to the game which can be mapped at runtime? Give the user full control as to how to control the game as it should.
Of course, companies are not really interested in making something new, they want to make something safe that'll make them a buck. I think google is trying to offset this by easing developer access to the market, that way regular developers with no need for a 'budget' or overhead can product unique and exciting games.
So, if you want to make a buck and make some short-shelf-life game for the iphone please go right ahead.
If not, Android seems to be like it's going to be around for a while and seems like a safe bet when aiming to build a community and a solid game.
The flagship of course is the Motorolla Droid, which has very high resolution, both a software and hardware keyboard, a great processor, and comes standard with a 16 gig microSD. I've got mine on order from Amazon Wireless, and I'm definitely interested in diving headfirst into game development on this platform.
The Droid Eris is 100$ less from verizon, but it also has pretty significant hardware.
As far as concerns about market share, we'll have to see what happens as these newer phones flood the markets. The Droid may not be an iPhone killer outright (quite a few complaints about its keyboard for example), but combined with the much more extensive 3g coverage of Verizon, it might start making some inroads.