Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I've been testing with AndEngine for months, but still haven't produced any game prototypes. There are few reasons why I want to switch to libgdx:
- AndEngine is using libgdx's INI wrapper for Box2d, but updates reach Andengine slowly
- I'm primarily targeting Android, but having option for easy porting to other platforms could come handy
- Documentation! AndEngine has absolutely no documentation, except for examples.
- I would like to get as high performance as possible and that seems easier on libgdx.
Few things I am concerned about libgdx is that I will need to write lower level code and that development for full game will take longer? But then again, sometimes I lost few days to understand how some parts of AndEngine work, so is it possible that I'll even write code faster with libgdx since it's fully documented?
What should I be aware about libgdx before switching? What is main difference when coding game and designing code?
You should be aware of the following things:
- It is more performant, thats a fact and widely known. Libgdx uses
native code for the more difficult tasks.
- Development on it is very fast, I dont get why (some) people say it
takes a lot of lines to do simple tasks, thats simply not true. The
library is very high level with the possibility of programming as
low level as you would need. Especially the ability to test on
desktop immediately, instead of waiting for the app to deploy to an
android device or worse... the emulator. That makes the development
time way faster.
- The library gives a lot of freedom, you can make the things as you
want it. For example I made a template that I use for every new
game, that makes things even faster for me.
- You dont have to know opengl, androidsdk or lwjgl, actually you just
need to know the abstractions of the library. But you can make
platform specific code if needed. And thats well documented.
- complementing P.T. point, libgdx has a wrapper for box2d physics and
bullet (3d) physics which are pretty easy to use (except bullet :S
nah kidding). And I would say, the new 3d api is almost complete,
not much will change for the next stable release, I even read on irc
that it is pretty much done. I use it and can tell you its very easy
to use.
In conclusion, Libgdx is a very fast library to develop on. Its very performant, and complete. Has a good and helping community, plus great documentation. I would recommend you to change :)
Both P.T. and Lestat make very good points in their answers. But for me, I think there is just one thing that you need to know about libgdx, which is simply that libgdx is a toolkit not an engine or framework. This one fact means that you are not locked in to a particular way of doing things. If you want a micro-framework, write one with libgdx. If you want to write "Unity 2D", write it with libgdx. If you want to put everything in one file, throwing object oriented principles to the wind, you can do that with libgdx.
- It helps that it is well documented.
- It helps that it is fast.
- It helps that it has a strong, knowledgeable community.
- It helps that the source code is available and is well-written.
- It helps that it comes with examples.
- It helps that it is a platform abstraction layer so the same code will run on multiple platforms.
- It helps that it is actively developed.
But fundamentally it is a toolkit, albeit an excellent one. What you choose to do with that toolkit is up to you.
If you're having problems finishing prototypes, I would concentrate on the usability of your tools (over performance, for example) to produce prototypes. So, the speed of updates to Box2d shouldn't be important (its in a good enough state). The ability to do development on your desktop should be important (build/test time is much quicker) without an Android device in the loop. Documentation and examples should be very important. High performance does not matter on a prototype that is never completed. Worry about that later. (Goal #1 should be completing something.)
Libgdx has a broad set of libraries and wrappers, mostly around graphical APIs (e.g., Scene2d, or SpriteBatch or the TiledMap infrastructure). There is a 3d API, but it is still moving pretty quickly, and not yet a stable place to develop on. I want to say that it doesn't have a lot of "gamey" abstractions (though it does have some), but I really don't have enough experience with other higher-level libraries to compare.
Instead of trading your current tool's short comings and pitfalls for a new tool's shortcomings and pitfalls, you are probably better off sticking with the tool you know.
