First screenshots

Our game has finally reached a point where I'm comfortable with posting few preview in-game screenshots. So here we go:

Few more shots are available from our facebook page.

TexturePacker

While working on our first Android game, I came across a tool that let's you combine all your small sprites in to a single sprite sheet that will be loaded by your game engine. The tool is called Texture Packer.

The tool will try to fit all the images you throw at it in the smallest possible spritesheet. If you want, it can also crop and rotate the images to make it possible to fit even more images to same space. Several different game engines are supported, so for example AndEngine which we currently use, the tool will create one image file, one XML data file that contains the locations, rotation etc. information of the sprites in the image file and one Java file which has a constant for each of the sprites for typesafe handling of sprite loading.

Packing all your sprites to one image has multiple benefits. OpenGL ES requires the textures dimensions to be a power of two. This way, if you have a single texture buffer for each sprite, you end up reserving lots of extra space for nothing. With single, tightly packed spritesheet you usually can get away with considerably less empty buffer space. Using a single TextureAtlas for multiple textures has performance advantages in both loading the textures as well as drawing them. Details about advantages in drawing performance are explained here.

The tool is easy and intuitive to use. The developer is friendly and fast to response to any problems you might have. And it does now have a version for Ubuntu, which was perfectly timed as I had just moved my development to Ubuntu from Windows as I kept having issues with Windows filesystem and Maven.

As I'm starting to sound like a marketing droid here, I will state here that I don't have contacts to TexturePacker or it's author, I didn't receive any payment from this post. Andreas Löw, author of TexturePacker, was kind enough to provide me with a free Pro license of TexturePacker.

Integrating Scoreloop to your Maven build

I’m a big fan of automated build process. Especially on Android where creating a release-ready package is a really multi step process: you need to compile, strip with ProGuard, dex, package, sign, verify and what not.

When it came time to integrate Scoreloop to our game, we had some problems. Scoreloops offers a nice UI ready for use. But this means you can just put it in a jar and use it like normal dependency, because UI’s need graphics, layout xml’s and other resources. Finding info on how to get this to work with Maven proved difficult. Thanks to Julien Donguy at Scoreloop for pointing me to Android Library Projects.

Here’s how you would go about adding Scoreloop to your Maven build:

Download the Scoreloop SDK and unpack it somewhere. Inside you’ll find two directories: ScoreloopCore and ScoreloopUI. ScoreloopCore contains scoreloop-core.jar which you can install to your local maven repository like any other jar:

mvn install:install-file -Dfile=scoreloop-core.jar -DgroupId=com.scoreloop -DartifactId=scoreloop-core -Dversion=2.4 -Dpackaging=jar

Next you want to create a zip file from the contents of the ScoreloopUI directory (so that AndroidManifest.xml is in the root of the zip) and rename that zip to scoreloop-ui.apklib.

We can then add that package also to your Maven local repository with command:

mvn install:install-file -Dfile=scoreloop-ui.apklib -DgroupId=com.scoreloop -DartifactId=scoreloop-ui -Dversion=2.4 -Dpackaging=apklib

Note the different packaging parameter.

Next you’ll add both of these packages as dependeciens to your pom.xml.

        <dependency>
            <groupId>com.scoreloop</groupId>
            <artifactId>scoreloop-core</artifactId>
            <version>2.4</version>
        </dependency>
        <dependency>
            <groupId>com.scoreloop</groupId>
            <artifactId>scoreloop-ui</artifactId>
            <version>2.4</version>
            <type>apklib</type>
        </dependency>

Now running mvn clean package should create an apk that includes all necessary parts from Scoreloop. You can see the apklib getting included with something like this:

[INFO] --- android-maven-plugin:3.0.0-alpha-11:generate-sources (default-generate-sources) @ YourGame ---
[DEBUG] Expanding: C:\Users\someuser\m2\repository\com\scoreloop\scoreloop-ui\2.4\scoreloop-ui-2.4.apklib into C:\ideaworkspace\examples\YourGame\target\unpack\apklibs\com.scoreloop_scoreloop-ui_apklib_2.4

We did experience problems with earlier versions of maven-android-plugin so we suggest using Maven 3 and android-maven-plugin 3.0.0 alpha’s.

Atleast for Intellij IDEA, there’s one more step to go. Apklib’s, unlike regular jar dependencies, are not visible inside IDEA, so if you start coding, you’ll find none of the classes from the scoreloop-ui.apklib available. To fix this you can add the ScoreloopUI as a module dependency inside IDEA:

• Select File –> New module.. –> Import module from external model


• Point the file explorer to the location where you unpacked ScoreloopUI.


• When it’s imported, select your game’s module and “Open Module Settings”


• Select “Dependencies” tab and click Add.. –> Module Dependency and select ScoreloopUI.

Now the sources for the UI classes are available to your IDE, and this doesn’t affect the maven build process.

From here on forwards you can follow the User Guide that comes with Scoreloop.

Comments and feedback are welcome as usual!

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.

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.

Dropbox and Git bare repository

Here's a nice tip for those who want to make development with Git but don't have a place to put their shared repository. You could use Github, but remember that any sources you put in the free version of Github are open for all users. So if you don't want to share your sources with everyone you could use e.g. Dropbox to share your code with your fellow developer(s) or just to backup your sources.

Create a bare repository

Create the directory which you want to share:

mkdir mydev.git

cd mydev.git

Initialize the repository and modify the Git config to enable shared mode (not needed for Dropbox but good to have if you move your bare repository to a proper server).

git init --bare

add sharedrepository=true to the config file.

Now you have a proper bare repository.

Share the repository in Dropbox

Copy the folder you initialized in your Dropbox folder. If you like, you can share it with your fellow developer(s).

Connect to your "Central Repository" and share your work

You can connect to your bare repository by executing the following command:

git clone PATH_TO_DROPBOX_FOLDER/mydev.git

cd mydev

Create some work to share

touch my_example_file.txt

git add my_example_file.txt

git commit -m "my first commit"

Git commit commits your work to the local repository but doesn't commit it to the central repository, so to share your work you need to push your work to the central repository.

git push

To get the work from the central repository, you need to do a pull operation:

git pull

Last I should warn you that we've had some issues with corrupting the central repository. We got everything working again by doing a new commit and push by the person who last changed the repository. However, despite the occasional corruptions in the central repository, there are several advantages to using Dropbox as the central repository, and it will make the development work a lot easier.

Adding Scala libraries to the Android emulator

After a couple of weeks' development we recognized that the compilation took vast amounts of time to complete and it really slowed us down. We tried using Android plugin's lazyunpack with rather poor results, as well as tweaking the Proguard, but clean compilation still took us almost 2 minutes.

After a short search we stumbled on a really interesting article about preloading the Scala libraries to the Android emulator. All we needed to do was predex our Scala library and create a custom ramdisk with some extra rules in the init.rc file for loading the Scala libraries during the emulator startup. Jan Berkel also had a really good tutorial about how to preinstall the Scala libaries to the emulator (and also to a rooted phone). With these resources at hand I first cloned the scripts provided by Berkel from the Github (derived from Stéphane Micheloud's scripts).

git clone git://github.com/jberkel/android-sdk-scala.git

cd android-sdk-scala\bin

createdexlibs.bat

I needed to set SCALA_HOME and ANDROID_SDK_ROOT, to get the scripts to run correctly.
set SCALA_HOME=PATH_TO_SCALA
set ANDROID_SDK_ROOT=PATH_TO_ANDROID_SDK

I also had to manually modify the createdexlib.bat, since Google had changed the location of the dx compiler.

Then I configured the Scala 2.9.0 version into my SCALA_HOME variable and ran the scipts. I also downloaded the custom ramdisk.img (avd.v10 [2.3.3]) from Micheloud's article. I tried to get the emulator to start with the new custom image by giving it as a parameter in the emulator start-up, but without success. So I had to replace the original ramdisk.img with my custom one.

The original image is located in the ANDROID_SDK_ROOT/platforms/android-10/images/ folder.

Then I started the Android emulator and ran the following commands in the ANDROID_SDK_ROOT/platform-tools/ folder:

adb.exe shell ls / (you should run this command until you get a proper list of files)
adb.exe shell mkdir -p /data/framework

adb.exe push PATH_TO_ANDROID_SDK_SCALA\config\framework\scala-actors.jar /data/framework
adb.exe push PATH_TO_ANDROID_SDK_SCALA\config\framework\scala-collection.jar /data/framework
adb.exe push PATH_TO_ANDROID_SDK_SCALA\config\framework\scala-immutable.jar /data/framework
adb.exe push PATH_TO_ANDROID_SDK_SCALA\config\framework\scala-library.jar /data/framework
adb.exe push PATH_TO_ANDROID_SDK_SCALA\config\framework\scala-mutable.jar /data/framework

After this I restarted the emulator, but for some reason the emulator couldn't load the scala libraries correctly. So I had to do this again with the Scala 2.8.1 configured into the SCALA_HOME variable. With these libraries the loading went a lot better, but I still got this weird error message: DexOpt: mismatch dep signature for '/data/dalvik-cache/data@framework@scala-library.jar@classes.dex'. Despite the message, the emulator worked alright.

Compilation times

	with Proguard	without Proguard (Scala:Provided)	without Proguard and with lazyunpackage	without Proguard with scala cc (fcs:false) and lazyunpack
mvn clean package	1 min 56 sec	35 sec	27 sec	21 sec
mvn package	1 min 32 sec	25 sec	24 sec	14 sec

If you want to try this too, I have provided the Scala libraries (2.8.1) and also the custom ramdisk.img here so you don't have to do as much work as I did to get this working.

Big thanks to:

Stéphane Micheloud for this exellent article http://lamp.epfl.ch/~michelou/android/emulator-android-sdk.

Jan Berkel for making a really clear and easy step by step tutorial on how to do the emulator customization http://zegoggl.es/2011/07/how-to-preinstall-scala-on-your-android-phone.html