BatteryTech has been an interesting experiment so far. In case you don't know what it is, it's a software library I developed last year for Battery Powered Games that makes it way easier to write cross-platform games, assuming they are targeted at PC, Mac, Android and iOS. BatteryTech is not free, but instead goes for a one-time purchase with lifetime upgrades. This model is nearly opposite from most of the competing products which opt for a subscription model, getting you in the door cheap and taking that chunk of change from you each year to keep using their product. It's difficult to figure out what the best marketing strategy is for a product like this, so today I set up the $99 experiment, which I'll explain further.
A few weeks ago I began prototyping a new game, tentatively titled "Project 7." It's called that because it's my 7th game, but that's just a working title. This will be a featured BatteryTech game and will utilize Bullet Physics, Lua, OpenGL ES 2.0 and will run on Android and iPhone. The game idea was conceived by Ryan Foss who did the art, level design and much of the overall game design on Deadly Chambers. The idea is to have a game world where you, the player, control a race of characters that are in danger of being swarmed and killed by another, much meaner race. Originally we were going to go for Humans and Zombies but right now the art team is working on a cuter alien race vs some scary indigenous monsters. I love the art concepts they are coming up and will post some of them below. Keep reading for those and then some videos of the prototype running on Windows and Android.
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.
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.