8.
May
2011

Why we switched to libGDX

9

JAGEN is our first Android project. Before I began with the coding I spent a little time looking around for a suitable engine and ended up with AndEngine (http://www.andengine.org/). AndEngine is in a lot of ways similar to Cocos2d and was very easy to get into. It also had quite a few titles on the market already using the engine so I knew that it’s ready to release a game with.

At that stage I really didn’t know a whole lot about Android & mobile development in general. Still I was able to produce a prototype of the game within a few days and had a complete first version ready after a about a month. So far so good. Problems became more evident once I started testing this project on various mobile phones out there. The first generation phones didn’t stand a chance (running at about 1-2 FPS). Even some better phones like the Motorola Droid/Milestone were struggling to get above 5 FPS. Of course, I was not happy with that performance at all. I spent quite a significant amount of time reading up on optimizing my code. Unfortunately, it seemed that I had hit a performance ceiling with AndEngine.

Eventually my journey led me to libGDX. Funnily enough, I first heard about libGDX (http://libgdx.badlogicgames.com/) through the AndEngine Forums. Judging by the things I had heard about libGDX I was fearing a very low level framework. I was afraid that my knowledge wouldn’t be enough to actually build a game with that thing. Well, I was wrong.

Here are the main points that won me over:

  • Performance: After switching over to libGDX I was able to get a constant 25-30FPS on a G1. Compared to the depressing 1-2 FPS before, I was ecstatic to see the performance. For whatever reason libGDX scales way better across different devices. The numbers speak for itself.
  • Desktop deployment: This must be one of the best features of libGDX. You can actually test and develop your whole application/game on the desktop and with a few lines of code you’ll be running the same beast on an Android device. It’s as incredible as it sounds. Developing Android applications can be extremely painful because you either have to use the really slow emulator or deploy to the device. Both of them are horrible solutions and waste a lot of time. Using libGDX’s jogl backend makes it incredibly quick to test and debug things. And of course it also allows you to deploy your apps for Windows, Linux, OS X, etc.
  • Community: The libGDX community is fantastic. I’ve met some brilliant people and I’m amazed at the knowledge & experience coming together in that community. The devs are heavily involved with the community and features/bugfixes are released almost every other day.
  • Code design: Hot topic. I personally just like the way things are done in libGDX. AndEngine makes heavy use of abstraction and inheritance. While that in itself isn’t a bad thing, working in a mobile environment is actually a bit different than a traditional software environment. I found that AndEngine’s design decisions aren’t necessarily the best for a mobile environment and quite restricting on how you can actually write your games. LibGDX let’s you decide how you’d like to code your game.
  • Examples and Documentation: libGDX comes with a great set of fully functional game demos. That was all I needed to get going. In addition to that, the code is fully documented with Javadocs.

Let me be clear: AndEngine is not a bad engine. If you’re after making some simple games you can be up and running in no time.

LibGDX it is for us.

9 comments on “Why we switched to libGDX

  1. Pingback: Badlogic Games » Why The Grey Studios Switched from AndEngine to libgdx

  2. Pingback: Mr. Android » Blog Archive » Why The Grey Studios Switched from AndEngine to libgdx

  3. Pingback: Why The Grey Studios Switched from AndEngine to libgdx | LetAndroid | Android News

  4. Pingback: AndEngine vs Libgdx | Space Tale

Leave a Reply

Your email address will not be published. Required fields are marked *

*


*

You may use these HTML tags and attributes: <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>