I see that you started your first day at Google today.
Congratulations on the new gig!
I thought as part of your first day as the new Android games guru, I
would make a concise list of things that make game development tough
for us full-time Android game developers.
1) Touch events consuming ridiculous amounts of CPU, causing 20-50%
reduction in framerates. This is very apparent in 1.6 and back and I
believe it is still somewhat there in 2.0/2.1 but it's hard to tell if
it's better just because the CPUs are much better on those devices or
if the underlying code is actually improved. Either way, I can't put
out any 3D games with a hold-your-thumb-down interface because they
drop from 30fps to 15fps when controlling and there is no workaround
(sleeping like suggested by myself and many hardly does the trick.)
2) Sound APIs are unstable and difficult to work with from a native
cross-platform engine. SoundPool is a well-designed class for doing
low latency one-shoot and looping sounds played at various rates (I
use for engines, and everything else) but it crashes now and then. I
don't see it crashing much on 2.0/2.1 but just last night I had a
segfault on my G1 (1.6) while testing a new game. AudioTrack in 2.0.1
is also reported to be unstable and has no DirectBuffer interface for
getting pcm bytes in from a native mixer.
3) Background processes destroy intense game framerates, even on
2.1. I've been asking for a game mode for a year now. Players
probably won't mind shutting off everything but incoming calls if a
game asks for it. If it made my gaming lag-free, I'd definitely play
that way. Sorry I can't check my email, I'm sort of playing a game
4) With a range of GPUs starting with "none" and going up to "PVR
SGX530 and Snapdragon" it's difficult for us to deal with comments
like "This game is unplayable" when people install and run a game
requiring GPU acceleration on a phone with no GPU. We tell them not
to, but they don't listen and then give us 1-star ratings and nasty
comments. Yes, we can specify GLES versions in the manifest (which is
great!) but both a pixelflinger phone and a G1 are ES1.0 so it's
impossible to stop the installs and bad ratings. A simple
classification system would do, where a class-1 phone is no GPU,
class-2 is MSM7200-era, class-3 is MSM7600, class-4 is SGX530 and
Snapdragon speeds, class-5 is whatever the next gen is and so forth
and so on. That would allow us to target a game at class-3 and higher
GPUs and optionally only ones that support ES2.0 if we so desire.
5) Multitouch on HTC devices is not usable for dual-axis game
controls. Perhaps that's not google's issue per se but it is an issue
for us devs, regardless of who's responsible.
There are several other bugs that are difficult to get anyone to take
responsibility for but IMO, these are some of the bigger ones plaguing
us today. Feel free to contact me for more details. I've been
working with Android game development since Oct of 2008. I'm
currently working on my 4th and 5th Android games and would be happy
to send them to you to play with.
Where did I go wrong in this analysis? And, if there are no significant
flaws in the analysis, how does that analysis jive with your blanket
statement quoted above?
Actually, I'll point out one flaw in the analysis: I failed to mention
startForeground(), which I double-checked (based on Mr. Kamp's recent
inquiry) and confirmed does pull the service into the foreground
Android Development Wiki: http://wiki.andmob.org
For me the biggest issue is the broken multi-touch which also affects
motorola devices as oposed to only HTC devices. It is of course
idiotic to blame anyone here, it would just be nice to know where to
turn to get this things looked at and potentially fixed.
Given that i'm a hobbyist i strive to rapid development times which i
can only achieve by staying as much in Java as possible. Going native
for really performance hungry stuff in small pieces is not a big deal
but writting a full game in native code without being able to rely on
a full fledged cross-platform library as many big players have is out
of scope for me given the lack of proper debugging support for native
code. It would therefore be nice if improvements of Dalvik would be a
top priority so we can stay as much as possible in Java. This includes
a better garbage collector strategy, JIT or dynamic adaptive
compilation and so on. I know that some of the things are already
worked on, so i guess there's a bright future for us Java noobs :) In
that regard it was a bit of a bummer that the bindings for OpenGL ES
2.0 were only made available via the NDK (which i worked around by
writting my own JNI bindings, http://code.google.com/p/gl2-android/).
Another thing which not only affects game developers but application
developers too: the market needs to be improved a lot. You can find
several threads on this topic here. The same is true for the developer
console which lacks a lot of information. It's a bit sad seeing how
nice Google Analytics works for example. Improvements in both areas
would really help a lot of us, especially the single person and small
development teams, as it would give us back some time we'd otherwise
need to manually manage our project statistics and user support.
Other than that (and i know it sounds like a christmas wishlist), i
think we all can agree on the fact that we love Android and want it to
become one of the most important mobile game development platforms.
Welcome to the community!
p.s.: what about a "Game Programming Gems" seeding program for poor
Android game developers? :)
On Apr 12, 2:19 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> Robert Green wrote:
> > 3) Background processes destroy intense game framerates, even on
> > 2.1.
> Where did I go wrong in this analysis? And, if there are no significant
> flaws in the analysis, how does that analysis jive with your blanket
> statement quoted above?
> Actually, I'll point out one flaw in the analysis: I failed to mention
> startForeground(), which I double-checked (based on Mr. Kamp's recent
> inquiry) and confirmed does pull the service into the foreground
> priority class.