I want to say "Me Too" here. I'm not a full time android game developer but invest a lot of my spare time in producing games as well as engines/frameworks for Android. I can only agree to all the points Robert already mentioned.
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 12 Apr., 21:00, Robert Green <rbgrn....@gmail.com> wrote: > Dear Mark Deloura, > > 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 > right now. > > 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. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using "remove me" as the subject.
