Thursday, March 31, 2011

Impressions of the green robot

I've been working on a mobile, physics-based game over the last five months (I'll post stuff about the project very soon) and today I started toying around with Android and porting the game. I'm not really sure what to think yet honestly. Some things are better than iOS development and other things are quite annoying. I really appreciate having command line tools for everything, and the ability to login to the device and do maintenance. Especially the ability to login and run a shell command on the device via a command line tool on the host. That way you can run scripts on your development machine that coordinate things both on the device and on the host at the same time. Awesome!

When it comes to development tools I think command line tools are far superior to graphical user interace in most cases (except for debuggers). I'm pretty happy with visual studio, but it's probably because I've been more or less forced to use it every day for the last ten years. Nothing beats having good command line tools and the ability to script everything the way you want them.

Being dependent on Java definitely sucks. They have really tried to work around it in the latest releases of the NDK, but it's still there, and you really do notice it. A lot. For a game programmer who keeps all his stuff in C++ this is no worse than Apple's stupid fascination for Objective-C though. A couple of revisions away, the Android NDK will probably be pretty complete, while iOS will always be knee-deep in Objective-C, forcing us to create horrible wrappers.

Android documentation is bad in the best case and non-existent everywhere else, and the whole development procedure is very far from streamlined with a gazillion tools and configuration files to tie everything together. Note though that I'm talking about writing native C++ apps using Open GL ES 2 here, not the Java crap you see in all the tutorials. (By the way, the NDK compiler did not support C++ exceptions until very recently. I talked about exactly this in my previous blog post)

Asset management is the part I like the least about Android so far. You throw your files in the asset folder, and it automatically gets compressed into a zipped bundle. Then you can stream access resources from this bundle using the NDK, but not quite the way you'd expect. On iOS this works beautifully by just translating the path into a location on the device and then you can use fopen, fseek or whatever you like. On Android the tools automatically compress stuff into the bundle based on the file suffix (oh please..), and there doesn't seem to be any way of accessing compressed data from the NDK unless you write your of virtual file system. Solution? Add a .mp3 suffix to all the files! Seriosly...


  1. Hi Dennis, I am a regular reader and have an unrelated question, I wasn't sure how else to ask you.

    I'm really impressed with your videos showing rigid bodies, fluids and cloth etc interacting together.

    I also found an old paper of yours where you briefly describe a framework to enable these interactions:

    I am familiar with rigid body and cloth simulations however I'm interested in how seperate simulations may be made to interact realistically as in your videos. Would you care to describe your methods in more detail?

    Thank you for the fantastic blog, its great to see that you are still active.

  2. Hi Graham, thanks for the kind words. My current work does not use separate simulations, but they all go into a unified solver. It would indeed be very difficult to get that level of stability using different solvers for each type. The tricky part is to find a way of expressing all the constraint types in the same way. I might write up how this is done some time in the future, but I need to figure out first what to do with the new engine. Cheers!

  3. Is the unified solver position based, velocity based or both?

  4. Hi Dennis, Having played Sprinkle I am a total fan of your work , very well done indeed. You have inspired me and quite honestly I have not played games for years and your game gave me the old "Lemmings Feel" that I had growing up on such games.

    My background is in Algos attributed to the Cad industry , I am behind some algos that you will find behind autocad etc, and being a game fan I always wanted to make a little game of my own, however having read your blog I am not sure how did you approach game programming for the mobile industry? how did apply the Nvidia engine into IOS , did you program on a PC visual studio and used the Nvidia libs and translated them to IOS ? or did Nvidia supplied the code. What environment would you recommend to program for both IOS and Android , are you using Lua?

  5. Hi Barry, Sprinkle is programmed in C++, mostly in Visual Studio and then "ported" to iOS and Android. For Android I'm using MacOS, the command line tools and the new NativeActivity approach, where you don't need Java. On iOS I use XCode for the actual deployment, but I don't do any actual coding in that environment. We're using Lua for level scripting. Simple things like "if this object is close to that object, open door B" and things like that. Otherwise it's mostly C++. For the next title I will move more stuff over (such as menus and GUI) to Lua for the quicker turnaround times.

  6. Yeah, reading assets with NDK is a challenge. Personally, I went with compiling raw assets into .so files that I dlopen() in my C code.