Making a custom game engine vs libGDX

[badlogicgames]

They are actually decaprecating the JOGL backend. I think it's because LWJGL gives you the ability to ship as an applet.

Of course JOGL supports applets. If there is something wrong in the JOGL backend of LibGDX, it has to be fixed.

We fixed all Jogl related issues by deprecating the Jogl backend.

[Nate]

R.D., an editor would be neat. One issue is that in an effort to keep scene2d relatively simple, the styles generally just contain the images for a widget. Other features like text alignment and padding aren't in the styles and is generally something that has to be customized via code.

ReBirth, we're all for the community doing the hard work. The problem with a wiki is some of the quality can be low, the articles tend to not mesh very well, and few people contribute. If a handful of people would contribute many articles each, it would probably turn out pretty good.

scene2d itself is a nice clean API.  The documentation is the rough spot.  I figured most of it out from the source.

What part of the documentation is lacking? I'm especially interested as I think it is pretty well documented. Maybe it needs more practical examples to go along with the relatively quick start-to-finish tour?

Having both a JOGL and an LWJGL backend is nice for the choice it provides, but also means twice as many potential bugs. Since libgdx abstracts the backend for most apps, most users don't care for the difference. I personally find LWJGL's API a little easier when I need to dig into it, eg for embedding in Swing. This is probably possible with JOGL, but I haven't dug into it. As a result, the LWJGL libgdx backend has an easy to use OpenGL frame, canvas, multiple canvas with the same GL context, etc. Ultimately though, JOGL hasn't seen updates and we haven't found time to update to JogAmp, so deprecation makes sense right now.

[ReBirth]

ReBirth, we're all for the community doing the hard work. The problem with a wiki is some of the quality can be low, the articles tend to not mesh very well, and few people contribute. If a handful of people would contribute many articles each, it would probably turn out pretty good.

So that's the problem. I believe this was what happened to user wiki

Games published by our own members! Check 'em out!

[Jimmt]

I think the tutorials on badlogicgame's youtube are outdated....uses JOGLApplication to launch...or maybe everything else is the same...

[65K]

Ok, I already mentioned the good, here is some of the bad I came across so far:

Setup/Deployment

3rd party libraries like LWJGL or JOrbis should not be bundled together with LibGdx' own classes.
The benefit is small, potential problems are big if you get version conflicts if other libraries do the same or if you have to switch versions manually.
I had to downgrade OpenAL, upgraded LWJGL and had to remove duplicated JOrbis classes due to using Pauls's SoundSystem.
Furthermore, attaching source code for gdx-backend-lwjgl.jar to both LibGdx and LWJGL is not (directly) possible with Eclipse.

Same is true for bundling and extracting native libraries. Core application files should be installed under one roof (except user data). No auto extraction.
For installing, the most simple solution is the best. Supply the path to the libraries. Clean and simple.

Each library should get auto generated build entries with date, time and version number.

I might be the first who is not using the official lifecycle stuff. Unfortunately, constructors of LwjglGraphics are not public, neither is it possible to create a LwjglInput on your own.
LwjglGraphics#setupDisplay is not public, etc.
It is ok to offer an easy-to-use setup and lifecycle, but people should not forced to use it, unnecessarily. I can assure you LibGdx works fine without
So, I had to take the ugly way, create a com.badlogic.gdx.backends.lwjgl package and move three of my classes into it.
Just upgrade the package scope to public. It is a framework, people are inventive of how to use it...
"Don't be forced to use anything, pick and choose."

I have to provide Gdx with a GdxApplication although it is just an empty class skeleton, a NullPointerException is the reply if omitted.

UI

I don't understand the inheritance hierarchy of Actor. First of all, its long. Then, why is a Button a table ? Seems like widgets and layout are mixed up.
And if so, why are the other widgets like Label e.g. no tables ?

In my code to build a screen with a few centered button I put this line months ago:
button.padBottom(20); // oddly high value required
Without that the text was painted outside the button borders. At least it used to. Today with Libgdx 0.9.6 the behaviour changed.
Back then, I couldn't figure out whether I was doing something wrong or whether it was buggy.

I have no idea how to convert an existing complex Swing UI into Libgdx.

Documentation

I started with "Beginning Android Games" which is quite good even though I still don't have an Android device.
But I learned all need to know about OpenGL from it.
An updated version for Libgdx with all of its features would be nice (don't know if its possible, I vaguely remember reading about some legal issues)
Eventually, there need to be complete (yes!) JavaDoc. The web site states it is full, which is, well not quite true.
There are too many places between you have to jump back and forth to find required information.
I did not find a history document listing all changes between versions.

Various

Feeding the sources to a dependency analyzer like JDepend shows a dependency mess only excluding 3 of all packages.
While not all shown dependencies are first level, there are cases like com.badlogic.gdx.math which relies on com.badlogic.gdx.math.collision
or com.badlogic.gdx.graphics needing com.badlogic.gdx.graphics.g2d
Pixmap seems to be more generic than Gdx2DPixmap but in fact it messes a lot with Gdx2DPixmap.
Generally there should be no dependencies pointing deeper into the package hierarchy, only the other way round.

This is very important for a library design. For the ongoing development when LibGdx evolves and grows, for splitting into modules and choosing only parts to use, to prevent from becoming an unmaintainable monolith.

There are a lot of public fields which is owned AFAIK to the slow nature of Dalvik. I never messed with Android, so I can't really argue against it. But it's not nice. From looking at it, the information you get is "so all of this is being modified from all places of the library".

Methods with 17 (!) arguments are just unusable.

[badlogicgames]

Ok, I already mentioned the good, here is some of the bad I came across so far:

Setup/Deployment

3rd party libraries like LWJGL or JOrbis should not be bundled together with LibGdx' own classes.
The benefit is small, potential problems are big if you get version conflicts if other libraries do the same or if you have to switch versions manually.
I had to downgrade OpenAL, upgraded LWJGL and had to remove duplicated JOrbis classes due to using Pauls's SoundSystem.
Furthermore, attaching source code for gdx-backend-lwjgl.jar to both LibGdx and LWJGL is not (directly) possible with Eclipse.

We made that decision early on. For 95% of our users it makes live a lot easier.

Same is true for bundling and extracting native libraries. Core application files should be installed under one roof (except user data). No auto extraction.
For installing, the most simple solution is the best. Supply the path to the libraries. Clean and simple.

See above.

Each library should get auto generated build entries with date, time and version number.

That's a good idea, i'll add that if i find the time.

I might be the first who is not using the official lifecycle stuff. Unfortunately, constructors of LwjglGraphics are not public, neither is it possible to create a LwjglInput on your own.
LwjglGraphics#setupDisplay is not public, etc.
It is ok to offer an easy-to-use setup and lifecycle, but people should not forced to use it, unnecessarily. I can assure you LibGdx works fine without
So, I had to take the ugly way, create a com.badlogic.gdx.backends.lwjgl package and move three of my classes into it.
Just upgrade the package scope to public. It is a framework, people are inventive of how to use it...
"Don't be forced to use anything, pick and choose."

I have to provide Gdx with a GdxApplication although it is just an empty class skeleton, a NullPointerException is the reply if omitted.

We can't anticipate all funky use cases of course. The only assumption we make is that you use Application and ApplicationListener. XNA is a framework as well, i'd like to see how you can rip out such a part from it

Furthermore, we try to keep the public API as slim as possible. Exposing internal methods is bad (both public and protected), we might change things in the future, people will cry rivers if their stuff breaks.

UI

I don't understand the inheritance hierarchy of Actor. First of all, its long. Then, why is a Button a table ? Seems like widgets and layout are mixed up.
And if so, why are the other widgets like Label e.g. no tables ?

Because Buttons are composite widgets with children which need to be laid out (e.g. labels, images etc.).

In my code to build a screen with a few centered button I put this line months ago:
button.padBottom(20); // oddly high value required
Without that the text was painted outside the button borders. At least it used to. Today with Libgdx 0.9.6 the behaviour changed.
Back then, I couldn't figure out whether I was doing something wrong or whether it was buggy.

As announced on the blog and twitter multiple times (our only way to get info out to folks), the scene2d API changed quite a bit. We generally do not break APIs, in scene2d's case we made a big exception. We were diligent to inform everyone of this change.

Also, bugs get fixed occasionally, i hope you don't hold that against us

I have no idea how to convert an existing complex Swing UI into Libgdx.

Not exactly something we can help with. I have no idea how to convert a complex Swing UI to QT, wxWidgets, Tk etc. either.

Documentation

I started with "Beginning Android Games" which is quite good even though I still don't have an Android device.
But I learned all need to know about OpenGL from it.
An updated version for Libgdx with all of its features would be nice (don't know if its possible, I vaguely remember reading about some legal issues)

The book has nothing to do with libgdx. Granted, the framework developed therein looks familiar, but that's about it. A book of similar scope using libgdx is out of the question.

Eventually, there need to be complete (yes!) JavaDoc. The web site states it is full, which is, well not quite true.

Ya, working on that ourselves and via 3rd party pull requests. Again, we aren't doing to terrible compared to similar offerings. Which is not to say we won't invest more time in making it better.

There are too many places between you have to jump back and forth to find required information.

Not sure what to say to that. That's the nature of big APIs i guess?

I did not find a history document listing all changes between versions.

We list those on the blog, giving an overview. We also have release tags in the SCM repo, if you want to know the exact details you can run through the commit history.

Various

Feeding the sources to a dependency analyzer like JDepend shows a dependency mess only excluding 3 of all packages.
While not all shown dependencies are first level, there are cases like com.badlogic.gdx.math which relies on com.badlogic.gdx.math.collision
or com.badlogic.gdx.graphics needing com.badlogic.gdx.graphics.g2d
Pixmap seems to be more generic than Gdx2DPixmap but in fact it messes a lot with Gdx2DPixmap.
Generally there should be no dependencies pointing deeper into the package hierarchy, only the other way round.

This is very important for a library design. For the ongoing development when LibGdx evolves and grows, for splitting into modules and choosing only parts to use, to prevent from becoming an unmaintainable monolith.

Yes, there are some dependencies that i'd like to losen up. However, the mantra that a package shouldn't rely on a deeper package just isn't always applicable nor useful. I'm 100% certain that math doesn't rely on g2d, unless someone else (NATE) did a bozo. Pixmap is a wrapper around Gdx2DPixmap so we aren't dependent on the concrete JNI APIs of Gdx2DPixmap. Changing native methods has a cost, changing wrapper methods is trivial.

There are a lot of public fields which is owned AFAIK to the slow nature of Dalvik. I never messed with Android, so I can't really argue against it. But it's not nice. From looking at it, the information you get is "so all of this is being modified from all places of the library".

Yupp, we try to reduce those one by one were possible and were performance on Dalvik won't get hurt. There are still tons of 2.x devices out there, and all suffer from poor method invocation performance. We do sacrifice cleanliness for performance on Android.

Methods with 17 (!) arguments are just unusable.

Agreed, which method are you refering to?


Thanks for taking your time writting this up. I'll try to incorporate a few of your suggestions as time permits.

[nsigma]

We made that decision early on. For 95% of our users it makes live a lot easier.

Absolutely understand and agree with that statement.  However, as I'm in the 5%, I ended up forking about 20 classes from the GL stuff (SpriteBatch, Mesh, Shader, FBO, Texture, etc.) and refactoring to call LWJGL directly.  There's definitely the potential for a lightweight and useful LWJGL util library in there!  Also might offer a good middle ground for the OP.

Generally there should be no dependencies pointing deeper into the package hierarchy, only the other way round.

Sounds like a weird mantra to me, but then I'm used to working with module systems (NetBeans platform, OSGI, etc.)  Doesn't seem unusual to use sub-packages to provide API's or tidy up implementation code, particularly when you've got a good way to control package visibility. 

[65K]

3rd party libraries like LWJGL or JOrbis should not be bundled together with LibGdx' own classes.
The benefit is small, potential problems are big if you get version conflicts if other libraries do the same or if you have to switch versions manually.
I had to downgrade OpenAL, upgraded LWJGL and had to remove duplicated JOrbis classes due to using Pauls's SoundSystem.
Furthermore, attaching source code for gdx-backend-lwjgl.jar to both LibGdx and LWJGL is not (directly) possible with Eclipse.

We made that decision early on. For 95% of our users it makes live a lot easier.

I don't get it. What is easier, deploying 1 instead of 3 files ? The introduced problems are far bigger.

We can't anticipate all funky use cases of course. The only assumption we make is that you use Application and ApplicationListener. XNA is a framework as well, i'd like to see how you can rip out such a part from it

Furthermore, we try to keep the public API as slim as possible. Exposing internal methods is bad (both public and protected), we might change things in the future, people will cry rivers if their stuff breaks.

That's what users are good for: pointing to new possible use cases. And that's what designing libraries makes it so difficult.
Making the described methods public does not expose anything dangerous, it just extends the usability of LibGdx.

Because Buttons are composite widgets with children which need to be laid out (e.g. labels, images etc.).

Yes, but why only buttons, seems not consequent to me.

Yes, there are some dependencies that i'd like to losen up. However, the mantra that a package shouldn't rely on a deeper package just isn't always applicable nor useful. I'm 100% certain that math doesn't rely on g2d, unless someone else (NATE) did a bozo. Pixmap is a wrapper around Gdx2DPixmap so we aren't dependent on the concrete JNI APIs of Gdx2DPixmap. Changing native methods has a cost, changing wrapper methods is trivial.

For example, math relies on utils which relies on g2d.
Utils should be splitted.
If Pixmap is a Gdx2DPixmap wrapper, just move into the g2d sub package.
To me, deeper packages are more specific than higher level packages. Thus, no pointing down.
But the real problem are cyclic dependencies. Those can and should always be removed. As you cannot cut the way from nested to upper packages, it can only be down as mentioned.
Another example: math.collision offers stuff for a a special use case, but math should be deployable without that, which is currently not possible.

Methods with 17 (!) arguments are just unusable.

Agreed, which method are you refering to?

Sorry, don't remember.

Btw, Blog, my contact lenses are no good any more but I think there is no link to the blog.

I think, its time to get me a Nexus 7 as my first Android play thing and see how it's doing with programming 

[gimbal]

Sure, not every single thing is documented, but a large amount is and for that which isn't, you have the forums, IRC, example code, and the library source at your disposal. We opened up documentation to the world and saw an unsurprising influx of almost no one who wanted to write anything. So, before you complain, consider writing some documentation yourself.

I am willing because I love LibGDX (I'm crazy like that, I actually like to write documentation), but I still have to complete at least one game before I consider myself qualified to be of service :/

Thanks for that nice overview of stuff to look at though, it is incredibly helpful.

[Nate]

Because Buttons are composite widgets with children which need to be laid out (e.g. labels, images etc.).

Yes, but why only buttons, seems not consequent to me.

As mentioned, a button is a composite widget. It is a table with up/down/over/checked/disabled states and corresponding background images. Because it is a table, you can put anything in it: label, image, image + label, etc. You can align the contents in 9 directions and do the other flexible layout stuff that table can do. Other widgets are not tables because they are not composite widgets and don't need the layout flexibility provided by table. You don't put other widgets in a label or selectbox. Also, there is nothing wrong with using a container for layout.

It appears only one class in utils (ScreenUtils) uses g2d and should probably be moved into g2d (and this wasn't my fault, yay!).

Packages are for organization but have no rules. The rules that you made up are fine enough, but I don't think they would really have much of a tangible impact. I'm all for organizing things cleanly, but your rules seem a bit strict.

Games published by our own members! Check 'em out!

[ReBirth]

I am willing because I love LibGDX (I'm crazy like that, I actually like to write documentation), but I still have to complete at least one game before I consider myself qualified to be of service :/

THIS! THIS! thanks for saying that for me!

[sproingie]

Table is just a confusing name -- it should really have just been called Container or something like that.

[gouessej]

They are actually decaprecating the JOGL backend. I think it's because LWJGL gives you the ability to ship as an applet.

Of course JOGL supports applets. If there is something wrong in the JOGL backend of LibGDX, it has to be fixed.

We fixed all Jogl related issues by deprecating the Jogl backend.

It is not a fix because JOGL supports applets. If you decide to drop JOGL, let us know so that I provide another backend based on JOGL 2.0 (which would be hosted and maintained by the JogAmp foundation if you refuse to do it).

[badlogicgames]

I'd love to have the time get a Jogamp backend going, sadly i have other priorities. If you fork libgdx and want to work on a Jogamp backend i'd be happy!

[gouessej]

I'd love to have the time get a Jogamp backend going, sadly i have other priorities. If you fork libgdx and want to work on a Jogamp backend i'd be happy!

I can do it before the end of this year but please can you tell me whether you would like to host it? I have several ports to do...

[Jimmt]

the level of pro-ness in this thread is rising...

[gouessej]

What do you mean Jimmt? pro-ness? professional?

[Jimmt]

yup.

[Nate]

Table is just a confusing name -- it should really have just been called Container or something like that.

Group is the generic container. Table is a Group that lays stuff out in rows and columns.

[ReBirth]

Table is just a confusing name -- it should really have just been called Container or something like that.

Table is quite right name.

[vaishnavsm]

ok.... i just decided to use libgdx

Most of this thread was hijacked 

please close the thread, otherwise its going to become a full scale war

[ReBirth]

libgdx ftw!

[nsigma]

Most of this thread was hijacked 

Not been around here long, have you? 

[vaishnavsm]

nop, lost my intrnet connection. Damn my ISP

[ags1]

Most of this thread was hijacked  :

Take me to Cuba!!!

[DrHalfway]

LibGDX is indeed good, this was a question me and my partner in crime asked 8 months ago, make an engine, or go with libGDX.

We went the route of making an engine. After 24,000 lines of code later we are somewhat ready to makes games. It took us monday to friday, programming 9 - 5:30 for past 8 months to get to this point. We have an editor, our own scripting language (incomplete) and an Engine that can port to pc (incomplete) via LWJGL and Android (complete). And unfortunately after all this hard work, we don't even come close to the features that libGDX provides.

Making an engine is not easy, it will require dedication, skill and utmost motivation. I recommend is go with libGDX or equivalent and don't waste time, start making games.
If you're still keen on making an engine i can recommend a few good reads.

Beginning Android Games - We started with this early on, an excellent book, based on early libGDX design.
Game Engine Architecture - Again, excellent read, it will pummel your mind on various ways to approach engine design.
Ericson Real-Time Collision Detection - If you're making an engine, you will need good collision detection that's both accurate and fast, this book is a very good read. Its examples are written in C though.
Programming Game AI by example - Very beginner friendly book, also a very good read for AI.
Game Physics Engine Development - If you plan to have physics and are not very good at math (like me) this book is also a very good read. The engine it develops is not optimal but it does give very good examples.

I hope I didn't scare anyone off. Making an Engine can teach alot. This past 8 months i've learned more developing this software than I did in 4 years of University doing Computer Science.

[princec]

It's a fabulous way of learning. Sometimes learning is the only way to really do it right. Shame it costs 8 months but as you say... you learned more in that 8 months than you did in 4 years of Comp Sci. This is why engineering employers pay people with experience and no degrees far more than they pay people with degrees and no experience.

Cas

[badlogicgames]

Not where i live, i hate my job prospects...

[princec]

Wanting a job is a trick played on your mind by The Man. I've spent the last 20 years figuring out how to not have a job!

Cas

[ags1]

I describe my game project as my tunnel outta here. Writing game engines does not shift dirt.