The Grey Studios is now Robotality. This website is here for archiving purposes only. You can find our new website at http://www.robotality.com

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”

Another argument against andEngine is their licence : it is in LGPL.
It means that any application that ships with this engine must let the end user change the engine at will, and, in Android, the only way to do that is to provide free access to all sources.

I too started with AndEngine, and gave up due to lack of documentation, and the forum being full of the blind leading the blind. To be a serious contendor, a framework needs support and AndEngine had all the symptoms of a university project that had morphed into a maintenance nightmare for the author….

You simply can’t put a paid product out there, and not have support/documentation to fall back onto.

As for Libgdx, I read marios’ book first was majorly impressed, then started using libgdx.
Take is from me; it is so much easier to use and understand than AndEngine. You can also develop on the pc, and have the same code running on android with the tiniest amount of effort, bypassing the crappy android emulator…

I’ve coded games for 20 years now, and recognised loads of issues I’ve tackled in that time; LibGdx covers loads of them. It’s well put together, and bloody fast…. Top marks lads!

Wish I hadn’t wasted 2 months wrestling with AndEngine and had found libgdx from the beginning now…..

Same experience here: I was porting an already existing Java applet game to Android.
I Began with AndEngine, but the lack of javadoc, the poor performances and the existence of a real 2D sceneGraph in libGDX pushed me to restart from scratch with libGDX.

The game is not yet published, but it will soon, and at least, the performance gap between libGDX and AndEngine is just enormous in my case.

Just two big regrets about libGDX:

1/ the lack of ‘real’ font rendering (and caching) : any font must be pre rendered and integrated inside the package. That’s really annoying, especially when the rest of your app is fully capable of handling any screen resolution.

2/ The over-use of inheritance vs. composition that restricts some possibilities.