I’ve decided to change course. Drastically. The fluid engine works nicely, and although it’s fun to play with, it’s not exactly a game just yet. I had this idea, which I alluded to in my previous post, of making it into a creative construction game. You’d be a beaver, and you’d have to use twigs and branches, floating in the water, to build a dam.
But as always, the devil is in the details. I thought about how all this would work exactly, then thought some more, and concluded that I just didn’t see it all coming together. For the time being, I shelved this project.
Instead, I’m continuing with the shopping cart game. It works more or less on a PC, but controlling the cart with the keyboard turned out to be pretty difficult. It would work so much better with analog input, like a dual-joystick Xbox controller… or a touch screen!
Through a lucky accident, I happen to have a Nexus One phone. The e-mail conversation that got me this phone went something like this:
- Google: “Hello, we appreciate your participation in the Android community. We’d like to send you a free phone!”
- Me: “Ehhh, sure… some of my friends have an Android phone, does that count?”
- Google: “Oh, there’s been a mistake. But if you send us your address, we’ll send you the phone anyway. We sincerely apologize for the inconvenience.”
- Me: “Don’t worry about it.”
Shortly after the phone arrived, I had already learned the basics of Android development. In fact, the first program I installed was one I wrote myself, that showed a spinning Cobra Mk III:
Porting the shopping cart prototype to the Android mobile platform turned out to be surprisingly easy. The hardest part was to get the Box2D physics engine to work. It’s written in C++, whereas Android apps are written in Java. Fortunately, there’s the Android NDK (Native Development Kit), which can be used to compile C and C++ code into a library that can be invoked from the Java side. Since the NDK ships with a crippled version of the C++ standard library, I had to make some changes to the Box2D source, but nothing very exciting.
However, to talk to C (C++) from Java, you still need to write some glue code on the C side. This consists of a wrapper function for each and every C function that you intend to use. The wrapper does the conversion from Java types to C types, among other things. Writing these wrappers is not my idea of fun, but fortunately, some amazing people wrote SWIG, the Simplified Wrapper and Interface Generator. You give it a header with the declarations of classes you want to wrap, and out pops a 100 kB C++ file with all wrapper functions you’ve requested. SWIG is really one of the most powerful and useful pieces of software ever written. It works for many more languages than just Java: Python, Ruby, Perl, .NET… and it’s flexible and well-documented to boot.
After some hacking, I had the game running on my phone. And it worked! The cart is far easier to control than in the PC version. Obligatory screenshot:
Publishing a mobile game instead of a desktop game has several advantages. Payment and distribution are trivially easy. The threshold for buying is much lower. Racing games are a proven concept, it’s easy to borrow ideas from existing games, and I’ve many great and concrete ideas of my own lined up. So, compared to how far I still had to go with the water game, I haven’t really lost anything.