If you haven't heard, the Android 2.3 SDK was released to the public today. Up until this release, Android has been a bit problematic for many game developers. While it's made steady progress in that area since the 1.0 release in 2008, there have been many things missing that we game developers have been begging for. Ask and you shall receive. 2.3 comes with the release of NDK r5 which includes a slew of game-friendly native APIs. Native Input, Native EGL and one of the biggest ones.. OpenSL!
I'll make this article short and sweet. If you have an Archos 5 Internet Tablet and wish to use ADB with it like I do with any Windows x64 variant, you'll just need the latest Android ADB driver and a little text editing skills with magic numbers. Click on for the technical stuff..
After having the story about the Nexus One multitouch flaws spread all over the blogosphere and seeing so many comments blame my test app for the problems, I figured the best way to kill that whole idea would be to just publish the source code so that people, even non-technical, can see that I do absolutely no manipulation of the touch points. All this code does is figure out what color the touch point is based on the ID and then draws those points exactly where the touch API tells it they are.
This is also a good bit of source to start with if you're interested in developing multitouch code. I still am using multitouch in the new games. This test simply allows me to understand the limitations before I design the control system. Read on for the code.
I've been using GLSurfaceView since it was introduced in Android 1.5 and I was a little let down to find that the new Live Wallpaper APIs didn't include anything like that. I like the design because it makes it very easy to quickly start working in OpenGL. Without it, there is quite a bit of tedious initialization and thread management code that isn't necessary for the vast majority of apps. Fortunately, for my first live wallpaper (Live Waterpaper), I adapted the GLSurfaceView's code and created a GLWallpaperService with a GLEngine which takes a Renderer and does the job for me.
Sooner or later in your Android game development foray you may find the need to have some code that runs faster. It turns out that Android code written in C runs 10-100 times as fast as its Java counterpart. I can verify this, as I've already moved a few major components in my newest 3D game engine into native land. That's quite a boost but let's face it - C is a pain in the ass and while Eclipse is great for Java, it's not for C, right? Wrong. Here's how to set up a super speedy NDK development environment.
The nice people at Verizon let me borrow a Droid for a few days so I'm going to take full advantage of this opportunity to bring you developers some specifications on the 3D capabilities of it. First of all, this phone is fast. How fast? It loads Light Racer 3D in 1/3 the time of my G1. Not only that, but it has a PowerVR SGX530 GPU in it (14 MPolys/s). Hello fast gaming! That's very close to the same chip used in the iPhone 3GS. Not only fast gaming, but all SGX series GPUs supposedly exceed OpenGL ES 2.0 specifications. Android doesn't currently support OpenGL ES2.0, but I have to imagine that with hardware like this on the market, it will soon. I tested Light Racer 3D on this phone and it works extremely well. 45-50 frames per second at 569x320. I have to imagine that it'd run at 60FPS if the screen were HVGA which would make it twice as fast as the G1. Read on for a list of supported OpenGL extensions and other specifications.
Real-time Android games have a few threads to worry about. You can't block up the main UI thread because it's needed by the OS. If you block it, even for a second, your app will be deemed unresponsive and users will get the dreaded "Force Close or Wait" dialog. If your game doesn't do anything in a logic or main thread then you should be in the clear. If you do use a main thread for your game and run it as fast as it can go, as is the case with 2D games that draw to the canvas or 3D games that simply have a lot of game logic to process, you may want to think about how you're handling your input.
The Android Developer's Challenge 2 has begun. The judging application is available for download on the market. If you're not familiar, the ADC is a contest sponsored by Google in which developers submit apps and games for Android. Apps are initially judged by users for a first round. Later, Google judges will be responsible for 60% of the score. The top 3 apps for any given category get a cash prize. An early version of one of my games, Light Racer 3D, is in this contest. Good luck to everyone who entered and thanks to Google for running it!
Light Racer 3D is complete! So much happened in the past 3 days that it's very difficult to write about one thing. I had decided on about day 9 to try to get Light Racer 3D finished in time for the Android Developer's Contest 2. It was a very ambitious goal, especially because that game was only partially working with about 25% of its total content just a day before. For 6 days I slept only about 4 hours per night and only took breaks when I absolutely had to. The hard work paid off because on Monday, Aug 31, we finished the game, submitted a trial version to the ADC and put the full version online on the Android market. I'm happy with how the game turned out, despite our lack of real artistic capability. While there are still a few bugs which will be fixed in a future version, the overall feel is good and the game is really fun.
Turning 90 degreees in an instant is hard on human eyes. After the game was working, I decided that the camera needs to be active and quick but also needs to be limited to a certain amount of movement. I added 4 camera modes to the world renderer: Above, Behind player, Beside player and Spinning. I then added the same code that I use to control player movement to the camera. Now, for every frame rendered, the camera checks where it is supposed to be, then tries to move there at the rate that I defined. I also really liked the way that the original F-Zero for SNES did the overhead view and zoom down to behind the player, so I added a similar sort of effect to the level intros. Besides camera work, there was a lot of modeling and texturing happening. None of us are very good at 3D modelling but by the end of the 2 days, we had already learned several tricks. All it takes is an ADC2 deadline to make you learn fast!