Pages

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.

5 comments:

  1. Interesting observations. One common argument against FP has been performance and excessive memory allocation. As far as I know these problems have been largely addressed by recent advances in runtime and compiler implementations..

    Have you looked at the implementation of Scala's collection library? Does it avoid creating new collections when filtering?

    ReplyDelete
  2. So far I've mainly used Android's DDMS tool to monitor game loops object allocations, and based on those findings done some tweaking.

    I haven't checked the current implementation of filter. From what I've read, filter does create intermediate objects and so you'll have to be careful with big collections with your operations. But afaik both performance and memory consumption are very close to Java. Atleast close enough that your own choices of algorithms matter way more than the underlying implementations.

    ReplyDelete
  3. You can avoid intermediate collections with "views", which are umm.. like lazy collections, that get materialized only when actually needed, but apparently there can be so pitfalls in those too.

    ReplyDelete
  4. Amazing post.I like your blog features.Your blog is providing good entertainment.Supper.
    Android app developers

    ReplyDelete
    Replies
    1. Thanks! Feedback such as yours makes this worth the effort.

      Delete