Pages

Thursday, August 25, 2011

Proguard optimize for Scala and Android

Our game is progressing nicely and we are planning on starting closed beta phase soon. So it was time to get ProGuard’s optimize and obfuscate features working. So far they had been disabled.

Optimizing seemed to go through just fine but dexing the end result failed with:

[INFO] UNEXPECTED TOP-LEVEL EXCEPTION:
[INFO] com.android.dx.cf.code.SimException: local variable type mismatch: attempt to set or access a value of type java.lang.Object using a local variable of type long. This is symptomatic of .class transformation tools that ignore local variable information.

So I knew I needed to limit the optimizations, but what exactly I didn’t know. Most of the exceptions referred to different Scala classes like

[INFO] ...at bytecode offset 00000022
[INFO] locals[0000]: Lscala/collection/IndexedSeqOptimized;
[INFO] locals[0001]: Lscala/collection/Iterable;
[INFO] locals[0002]: I
[INFO] locals[0003]: Lscala/collection/IndexedSeq;
[INFO] locals[0004]: Lscala/collection/mutable/Builder;

and one exception from AndEngine’s classes.

I finally got my solution by combining the typical optimization flags for Android with something I found from the simple-build-tool wiki. Resulting string to add to your proguard.cfg is:

-optimizations !code/simplification/arithmetic,!field/*,!class/merging/*,!code/allocation/variable

That did it for me, so I thought I’d share it.

Tuesday, August 9, 2011

Functional Programming and Android Game Development, a Happy Couple

For the past few months I’ve been writing a game for Android using Scala. I’ve been really impressed with the syntax of Scala after almost 15 years of Java programming. When we started doing the game, it seemed like proper object-orientation and game programming didn’t really fit. Doing nice object constructs and class hierarchies, although easier to read, develop and debug, is not well suited for a mobile device with limited memory and the tips that Google gives on Android development (avoid unnecessary objects, getters and setters etc) seems to guide you away from good OO principles too.

But the more I learn from the functional programming side of Scala, the more I feel that it goes well together with mobile game development.

Garbage collection seems to be your worst enemy in real-time gaming on mobile devices. It’s the one thing that can bring your game to grinding halt in the middle of best action and surely drive your gamers away.

FP concepts and Scala’s syntax help you to avoid unnecessary objects and garbage collecting. Creating and loading objects is expensive so in game programming you load and create in advance and pool what ever you can instead of creating on the fly and discarding after using.
Different collections and operating on them directly are in the heart of Scala and functional programming. So in game programming, pool what resources and game objects you can and instead of taking single objects from the pool, use Scala’s different advanced collection operations (filtering, mapping, collecting etc.) directly on the pools.

Scala’s syntax also allows returning values/objects/functions from pretty much any code block. With value-returning if/else blocks and object yielding for loops you are able to avoid using a lot of unnecessary temporary variable and mutable states.

One Scala's feature that wasn't a good idea with regards to memory and garbage collection was implicit conversions. I was using AndEngine library for the game and wanted to richen the Sprite implementation with few convenience methods. So I created a RichSprite and made and implicit def that when needed, converted Sprite to RichSprite. This unfortunately uses a constructor call to create a RichSprite. So you'll end up with one Sprite instance and one RichSprite instance, so you'll have more memory usage and eventually more garbage collecting. So I just ended up using the traditional class RichSprite extends Sprite which is a bit of a disappointment but works better for this purpose.

I’ll try to give you some code examples in the future blog entries, but in the mean time I’m happy to answer any questions, comments and would love to hear your opinions on using Scala on game programming.