It's been a very eventful 8 months since the first article of this series. I moved cross-country, took on my first reasonably-sized contract, bought my first house, ran deep into debt, paid all the debt off, then went way back into debt, started my first e-commerce site, worked on a book and saw it get published, developed & marketed a new software product and recently hired a full time contract developer and 2 sales roles. When I write it all out like that, it seems a little ridiculous. I like to think that everything I'm doing is making perfect sense, but if you haven't noticed, my blog updates have become extremely sparse since I became self-employed and there is a good reason for that: I never seem to have enough time anymore! So what does a person do in this sort of position?
I've always been super interested in point-of-sale systems and e-commerce, particularly the bits around inventory management, shopping carts and really slick sales integration pieces. I've never had a really good functional reason to mess around with any of this, though, outside of when I worked at IBM on an order management system for a client, until I wanted to start selling BatteryTech licenses online. The site, www.batterypoweredgames.com runs Drupal and I had some special needs so with just a little bit of module coding, I was able to piece together a fully automated sales and checkout system that requires a webform to be completed (EULA in my case), handles payment via paypal and provides the customer with access to everything once the payment is completed. This article will outline how I did it.
It's been nearly 2 years since I've received a corporate paycheck. I left that world in Jan of 2009 and haven't looked back since. Was it an easy jump? Hell no. It's been hard - very hard, but I don't regret it and still consider it one of the very best things I've ever done for myself. Read on...
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.
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.
While doing performance testing of Light Racer 2, I had to figure out how to do the fastest common operations. One problem I found was that I was drawing a static background in a 32 bit color mode with transparency when it was much faster to draw it in 16 bit with none. Another thing I wanted to check for was to see what was faster for finding half of a number: Division by two or multiplication by point-five? This matters because I do a whole lot of that in the game to place graphics and find mid-points for various physics and AI stuff. I wasn't sure which would be faster because the ARM processor in a G1 has neither a hardware divider nor a floating point unit. I wrote this little utility to tell me how many frames per second I can get with various operations. Also - Divide by two is at least twice as fast.
I was recently asked how to have objects that animate themselves (change frames) in a stable way that isn't dependent on the FPS or lag of the device. There are many ways to do this but I have a simple one which uses the difference between the last tick and the current tick to count down. My example is in Java and is suitable for most games. The first step is to use a main loop which gives the updates that info. The best way to do this is to give every thing that is updating the exact same time information and have them all use that.