Future LibGDX options

[Cervator]

I came across an interesting article: http://www.gamefromscratch.com/post/2016/04/15/RoboVM-is-Dead.aspx

RoboVM was used in LibGDX for enabling Java to work on iOS devices. It got bought out by Xamarin, then Xamarin got bought out by Microsoft. Having seen what is happening with Minecraft after it was bought out by Microsoft (Java version being phased out in favor for .NET) what comes next is probably not much of a surprise

I'm not going to seek out the drama but I'm sure there's plenty of popcorn opportunities online. How does this relate to Destination Sol (and Terasology) though?

One little snippet caught my attention:

Release a new libGDX version next week, that will make Multi-OS engine the default iOS backend for newly created libGDX projects

That's from a related longer LibGDX blog post going into the details with some more in the comments (discussion there still going as I write this).

This brings me to a note by @Rostyslav Zatserkovnyi over in his PR for adopting our Gestalt library for Destination Sol

This might be enough to "release" the setup to an experimental branch, but I think a proper 2.0.0 release will require refactoring the game to some extent - IMO, recreating it with a new project skeleton is the best option here.

So we could do a v2.0.0 Dest Sol for the upgrade to Gestalt stuff with a regenerated project skeleton from the LibGDX template. Maybe we can also ease into improving the structure to support modules for DS. And while we're at it we could reconsider looking at the iOS and GWT facades to get DS working in more places.

LibGDX has also more or less updated to use LWJGL 3, so that's a thing too. Actually, amusingly, a Google search for "libgdx lwjgl 3" has our "Upgrade to LWJGL 3 (or LibGDX)" item (for Terasology) on Bountysource on the first page

This is hardly critical or anything that's likely to result in DS running with modules on iOS in the near future, but it is fun to think about. There are drawbacks too, like the Multi-OS Engine (from Intel) not being open source and potentially not staying free (or even surviving in a somewhat hostile legal environment)

And maybe, just maybe, this could help us one day with Terasology on LibGDX, on interesting platforms.

 

[Rostyslav Zatserkovnyi]

Something that potentially gets Destination Sol running on two new platforms is definitely worth looking into!

There appears to be some backlash against using the Multi-OS engine in the comments for the libGDX blog post (mostly for the reasons @Cervator has mentioned: it's non-OSS and support may be straight up abandoned at some point). This is something that may delay the update if badlogic decides to use a different toolkit - probably nothing too severe, though

Some things to consider regarding the 2.0.0 release:

• The current libGDX skeleton drops the core projects and desktop/Android/iOS/HTML wrappers into the same project as gradle subprojects. Should the latter three be separated into different repositories, as is the case with the current setup? The iOS facade may require XCode (and a Mac) to deploy, which is definitely a case for separating that particular subproject.

• To what extent should the existing code be reworked? A simple checkstyle fixing / renaming spree, as well as documentation improvements, are definitely necessary, but we might also want to rework the logic behind some of the core systems.

 

[Cervator]

Project skeleton - yeah that's the kinda thing I love playing with. Current Terasology structure is actually LibGDX inspired but with the different pieces beyond the core PC setup split out. I think there even was an Android facade at some point just for looking at.

Likewise with DS I'd split out everything but the desktop facade. Right now it is nice to have Android and GWT split out since they can indeed cause havoc in some cases (like me not being able to run with the Gestalt changes with the Android facade present). Like with Terasology probably keep a Core content module in the main repo for convenience until such a time we can easily bundle and integrate with module repos proper. The nice part is we have all the Gradle magic already.

Probably we make new repos, indeed a sort of DestSolPrime, spin up a new skeleton when the LibGDX dust settles a bit, and just look at all the pieces for a bit. Maybe try a primitive shell with some Gestalt pieces integrated but no real game. Could even try it more easily on Android or even on new platforms. See if the logic / systems play out differently from a clean slate, compare with existing, then see what we might want to change first and what effort we may have available to do it within a reasonable time frame.

One nice part there is if we just play with the skeleton it doesn't matter if we take a while and even pop out a v1.5.0 or two in the meantime. Only when we actually try integrating into the main repo will we have a little timer running that's good to minimize so regular work can resume soon after.