Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
25. November 2015


With the upcoming LibGDX jam, it dawned on me I hadn’t done anything with LibGDX in a while.  I decided to look into doing a mini game series in advance of the Jam and decided it was a good opportunity for me to look into the Kotlin programming language.  Ironically a day later, RoboVM and IntelliJ announce a Kotlin code competition… stars aligning I suppose.


So I decided to start with Kotlin-afying a LibGDX project and see how the process went.  This tutorial is the result of that experience, although to be honest calling it a tutorial is a bit of a joke as the process was amazingly simple.


Before we begin there are a couple of things you are going to need:


Open the project in IntelliJ just like normal with a Java application.

In your project, in core create a new Kotlin file beside your main class like so:



That’s one of the cool things about Kotlin, it can exist along side existing java sources.  Once you create the Kotlin file, this popup will be shown:



Click the link and let it configure as a Kotlin module. Defaults are good, click OK.



Now this part is impressive and I discovered it by accident.  Open your existing .java file and copy the contents, then paste them into your newly created kt file.  When prompted, let it convert the Java to Kotlin code:



Now the default project will be converted to Kotlin, but there will be a pair of errors:



Kotlin does not appear to like unallocated variables.  There are a few options here.  You can move the initialization of batch and img to the KotlinDemo constructor, you can default initialize them to null (this will however cause LibGDX to explode, so not recommended ;) ) or you can add the lateinit modifer, which is the route I went.  Here is the resulting code:

package com.gamefromscratch

import com.badlogic.gdx.ApplicationAdapter
import com.badlogic.gdx.Gdx

class KotlinDemo : ApplicationAdapter() {
    internal lateinit var batch: SpriteBatch
    internal lateinit var img: Texture

    override fun create() {
        batch = SpriteBatch()
        img = Texture("badlogic.jpg")

    override fun render() {, 0f, 0f, 1f)
        batch.draw(img, 0f, 0f)

Congratulations, you’ve just created your first Kotlin application!  The mix and match nature enables you to slowly port your code over to Kotlin making the transition exceedingly easy.

Now there is one last very important step, we need to delete the original .java class. 



When you delete it, you want to make sure you don’t do a smart delete, as we want the existing references to this class to remain (as our Kotlin class is replacing it):



I’m going to continue to play around with Kotlin, so expect more coverage over the next few days/weeks.  Let me know what you think of Kotlin… any interest?


22. November 2015


As per this blog post the first ever LibGDX game jam is happening in mid December and topic voting has begun.  From the announcement:


The 10 Rules of Jamming

  1. You must use libGDX to create a game that fits the theme
  2. You may work alone or in a team. Only one submission per person/team is allowed
  3. You may use pre-existing code, e.g. libraries like Ashley, or your own code libraries
  4. You may use pre-existing art, e.g. assets from OpenGameArt, or your own art
  5. You may use external tools like Tiled or Overlap2D
  6. You must not re-skin an already existing game or prototype!
  7. You must submit your game before the end of the 18th of January via the jam’s site on (to be made public :))
  8. You must publish the source of your game, e.g. to GitHub
  9. You must submit your game to the libGDX Jam page before the end of day January 18th, UTC-12!
  10. If you want to win one of the sponsored prizes, you must tweet about your game and document its development, using the hashtag “#libGDXJam” and the handles “@robovm” and “@robotality

Prizes & Judging

We are happy to have RoboVM and Robotality as sponsors for the following prizes:

  1. Grand Prize: Mac Mini, sponsored by RoboVM
  2. Silver: iPad, sponsored by RoboVM
  3. Bronze: iPod Touch, sponsored by RoboVM
  4. For 20 random submissions: Steam keys for Halfway, sponsored by Robotality
  5. For another 5 random submissions: libGDX Jam t-shirt, by yours truely

To qualify for any of the prizes, you’ll need to follow rule 10 as outlined above. Judging works as follows:

  • The community can vote on from the 19th of January to the 2nd of February
  • The Grand Prize will be awarded to the entry with the highest community votes on This way the highest quality entry will win!
  • The Silver and Bronze prizes will be awarded to the entries with the best mixture of dev logs and tweets and community votes. Our sponsors and the libGDX core team will pick these entries. This should motivate people to make some noise on the web and document their progress for the greater good of the community!
  • The random awards guarantee that everyone has a chance to win a prize!
  • The winners will be announced on the 3rd of February!

To view suggested comments and to cast your vote, head on over here.

GameDev News

23. October 2015


If you are a LibGDX developer or even a Java developer hoping to target iOS some pretty big news just happened.  In a nutshell Xamarin acquired RoboVM (more details here).  If both of those names are meaningless to you, here’s a quick rundown.


Xamarin are ultimately the company formed around Mono, which is the open source cross platform version of Microsoft’s .NET framework.  That’s actually simplifying their history a fair bit.  Many years ago they were a company called Ximian, and their big push was trying to make Linux on the desktop happen and part of that process was the Mono project.  In between they were purchased by Novell, Novell blew up in spectacular fashion and from the ashes Xamarin was born.  Of perhaps most interest to game developers, Xamarin developed the technology that Unity is built on top of.  In fact, if you are working in a C# based game engine ( MonoGame, WaveEngine, Paradox, etc ) chances are it requires a Xamarin license to target iOS or Android.


RoboVM on the other hand are a much smaller developer that provide a very similar product, just targeting Java instead of .NET.  Basically RoboVM provide an iOS runtime for Java applications, enabling you to run Java apps pretty much unchanged on iOS.


So, why do we care?


Well first off, RoboVM is the technology that LibGDX depends on for iOS deployment, ironically chosen while moving away from Xamarin years ago.  In many ways, RoboVM owes it’s success and existence to the libGDX community.  In fact, the LibGDX founder Mario Zechner started working for RoboVM about a year ago.  Note, working for…  it isn’t his company, something far too many people seem to miss these days.


Fast forward to recent history…

  • RoboVM is now owned by Xamarin
  • the core of RoboVM, the Ahead of Time (AoT) VM is no longer open source
  • the pricing is much less indie friendly


So basically a core component that LibGDX depends on to support iOS just became closed, more expensive and owned by a company that doesn’t really seem to get game developers.  This all in a world where people don’t expect to ever pay for anything… although that’s certainly a conversation for a different day.


To Mario/RoboVM’s credit, they have offered a free license option for LibGDX developers.  You need to apply for the license, have a development team limit of 3 developers and need to activate the license on your build machines with a machine count limit attached to the license.  Of course it also adds the pain of dealing with a license were there previously was none.  The one silver lining in all of this is you get debugging support including in this license, something that was previously a paid feature.


At the end of the day, what exactly does this mean for LibGDX developers?  Well you are now basically in the same boat as C# developers.  To support certain targets you now have a pay wall in front of you.  Of course the current license offer will mitigate that for many existing LibGDX developers but how that actually turns out is yet to be seen.  With that license offer in place, LibGDX devs are still in a better place than most MonoGame/Paradox/et al developers out there, to say nothing of the fact there is no added cost to support Android.  They are however certainly in a worse place then they were before.


I’m not going to lie and say this development is great news, it certainly isn’t.  It however isn’t the end of the world scenario many are making it out to be.  If enough community demand exists, they can pick up the code for RoboVM and run with it.  Or port to another Java on iOS solution such as Codename One or Avian.  Or explore a different approach entirely like Unity are moving toward.  Of course they could also take the path of least resistance and keep working with RoboVM.


There are however two meta-points I want to mention here.


First off, no matter how much this affects you personally, some of the reactions I have seen to this have been downright off putting.  The amount of heat Mario has taken over something that is basically beyond his control is just sickening.  It really makes one wonder why people would even contribute to an open source project in the first place.   Now caustic end users in an open source is nothing new, but it’s always disgusting to witness.  Now Mario is a big boy and is handling fine so far as I can tell, but really ask yourself… if you had to put up with this crap, would you bother donating your time anymore?


Second, Xamarin, if anyone from that company happens to be reading this, I hope the entire experience is an eye opener.  When the entire indie game development industry looks at you at best as a necessary evil, at worst as the devil, it’s time for some introspection.  Part of that relates to the above paragraph… people are horrifically over entitled these days and the thought of having to pay for anything is galling.  Ignore this crowd, there isn’t much you can or should do.


On the other hand, with a more reasonable licensing, you would have a much larger community of advocates and I have to assume greater profits.  Your legacy as a tool vendor to corporations really shows in your pricing model.   Heck, look at LibGDX for example… they were using RoboVM in the first place to avoid you!  If you followed the Unity or Unreal model of geared to income licensing then suddenly your products would become much more appealing to a much larger segment of the population.  Your license fees are a bitter pill to swallow for a hobbyist looking to release a free title, while someone who was commercially successful would probably be willing to pay a greater amount.


At the end of the day this isn’t a story that is going to play out in a single day.  There is an active discussion and more information on the LibGDX forums that I think is the ideal place to discuss things.  Just keep the personal insults out of it.


EDIT: One major concern people had with the license granted for LibGDX developers was how long it would be valid.  I just had the following conversation with Nat Friedman (CEO of Xamarin) on Twitter:



Other very interesting things related to Xamarin licensing were discussed, which I will be putting in a separate post.  This announcement is very relevant to LibGDX developers however.


23. September 2015


LibGDX, the cross platform, Java based, open-source game development library just released version 1.7.  I have to admit, not the most exciting release notes ever mind you…





- Gdx.input.setCursorImage removed, replaced with and see
- Fixed an issue with UTF8 decoding in GWT emulation of InputStreamReader
- Updated to RoboVM 1.8 for iOS 9 and Xcode 7 support 

If you have a game on the iOS App Store, make sure it works on iOS 9. If not, recompile with RoboVM 1.8 and Xcode 7 and resubmit it to the App Store!

Update your project as usual. Also update your RoboVM Eclipse or IntelliJ IDEA plugin to 1.8.0!. If you are on a Mac, consider using RoboVM Studio. It will take away all the setup pain for you

Happy coding!


If you are interested in learning more about LibGDX, has two comprehensive tutorial series for you, one in text, the other in video format.


RoboVM Studio is something I very  much have to check out.  It’s basically a fork of IntelliJ 15 with the RoboVM stuff preinstalled and preconfigured.  As IntelliJ is my Java weapon of choice, next time I am working with iOS i’ll have to give this a go.


26. May 2015


As part of GameFromScratch’s ongoing A Closer look at game engine series, today we are going to be taking a look at LibGDX, a Java based cross platform game engine(sorta).  The “Closer Look” series is intended to be a cross between a tutorial, review and overview of a game engine, aimed at helping those evaluating which game engine is right for them.  We are going to go into a bit less technical detail with LibGDX, as this site already has a massive text based and video based tutorial series covering LibGDX in depth.


There is an HD video version of this post available as well, also embedded below.


Introduction to LibGDX


Let’s start with their own description:

Libgdx is a Java game development framework that provides a unified API that works across all supported platforms.

The framework provides an environment for rapid prototyping and fast iterations. Instead of deploying to Android/iOS/Javascript after each code change, you can run and debug your game on the desktop, natively. Desktop JVM features like code hotswapping reduce your iteration times considerably.

Libgdx tries not be the "end all, be all" solution. It does not force a specific design on you.

You can get a complete feature list here.


So basically LibGDX is a cross platform, JVM based 2D/3D game engine(sorta) capable of targeting desktops, iOS, Android and HTML.  It is free and completely open source.  When I say JVM based, LibGDX is written primarily in Java but your own applications code could theoretically be written in any JVM based language, such as Kotlin or Scala.  LibGDX is able to compile to HTML using the GWT compiler, while iOS support is provided using RoboVM.  For the most part, 99% of the time, the platform specific portions are pretty well hidden from you the developer.


So why do I keep throwing a (sorta) disclaimer every time I use the word “Game Engine”?  Well that’s technically because LibGDX isn’t a game engine, it’s more of a framework, similar in scope to SFML, MonoGame/XNA or SDL.  It provides the underlying “guts” required to make game a game, things like graphics, audio and input.  It however doesn’t provide a scenegraph, essentially the “heart” of a game.  However it does provide a simple 2D scene graph/ UI / Widget library named Scene2D, which is built over top of LibGDX.  The use of Scene2D is completely optional.


Getting Started


Getting started with LibGDX is incredibly simple.  If you want to use it as just another library that is of course your option.  If you are for example making a desktop only project, you can download and build LibGDX from it’s Github repository.  If you want to create a cross platform game, or like me, want to avoid Java build systems like the plague there is a handy project creation tool available right here.  Simply download and execute the linked Jar file.  It will automatically download all of the required dependencies, although you will have to have a Java Development Kit and the Android SDK pre-installed.  For more detailed installation instructions watch this.  Assuming you have a properly configured Java dev environment, you should see the following:



This will automatically generate a project for you.  Clicking Advanced allows you to have LibGDX generate IntelliJ IDEA or Eclipse projects for you.  You can also select which platforms you want to support and which extensions to you want enabled.  Once you click Generate, Maven will automatically create a project for you and download all the dependencies.  If you want the tools such as a font generator, particle tool or sprite packer, be sure to select Tools under extensions.


If you are looking for more details on working with your specific IDE, check the tutorials for more details.  There are IntelliJ and Eclipse configuration tutorial available.


A Simple Project


Let’s take a quick look at the project it generated.


The heart of your game is the platform agnostic ApplicationAdapter located in the core project.  ( More on this shortly ).  Here is the code:

package com.gamefromscratch;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;

public class MyGame extends ApplicationAdapter {
   SpriteBatch batch;
   Texture img;
   public void create () {
      batch = new SpriteBatch();
      img = new Texture("badlogic.jpg");

   public void render () {, 0, 0, 1);;
      batch.draw(img, 0, 0);


If you’ve previously worked in XNA, the overarching structure should be immediately familiar to you, XNA and LibGDX feel incredibly similar to me, and this is a good thing.


The nutshell version of what’s happening here is our game extends the ApplicationAdapter class… we will see why shortly.  In it’s create() method we create a SpriteBatch and a Texture object, the texture “badlogic.jpg” is loaded from the assets folder ( by default in the Android project, unless you didn’t create an Android project, in which case it will be in Core ).  The assets folder is basically the root where all of your game’s non-code content is located.  In render() method we clear the background color, start our sprite batch, draw the texture to it, then finish the batch, which results in it’s contents being drawn to the screen.


There are a few things to be immediately aware of.  LibGDX provides a fairly shallow abstraction over top of OpenGL ( or WebGL/OpenGL ES, depending on platform ), which can be access with calls.  Most of the GL functions are accessible this way, but in a cross platform friendly manner.  The other thing to be aware of is the coordinate system by default follows the OpenGL convention of having the origin (0,0) be the bottom left corner of the screen.


When you run the generated code, you should see:



That’s about as detailed as I am going to get with the code, if you want more details, simply go through the tutorial series for dozens of them.


Now the neat part about this whole process is, using the exact same code you could switch your run target to iOS, Android or HTML and it should just work.  Let’s look at exactly how that works.  If you look at the project, your folders should be structured like so:



Basically you have a project/module for each targeted platform, then core where the cross platform ( majority ) of your code exists.  Let’s take a quick look at the desktop project for a look at exactly how this works. Expanded, the desktop project should look something like this.



It’s the DesktopLauncher class that is of the most interest.  For desktop projects, this is your application entry point.  Let’s take a quick look inside:

package com.gamefromscratch.desktop;

import com.badlogic.gdx.backends.lwjgl.LwjglApplication;
import com.badlogic.gdx.backends.lwjgl.LwjglApplicationConfiguration;
import com.gamefromscratch.MyGame;

public class DesktopLauncher {
   public static void main (String[] arg) {
      LwjglApplicationConfiguration config = new LwjglApplicationConfiguration();
      new LwjglApplication(new MyGame(), config);


This is where you would put the platform specific code related to desktop platforms.  You can see the traditional program main() is here, inside of which we create a simple configuration object and pass it to our LwjglApplication.  LWJGL stands for Light Weight Java Game Library, and it’s the OpenGL layer that LibGDX desktop implementation is based on.  There is a similar entry point created for the Android application, the iOS application and the HTML5 application.  Each and every one creates a new instance of your game class and passes in the platform specific configurations.  Ideally, this is the extent of your platform specific code, but quite often you have to implement some details on a platform by platform basis.


If you look at the various config objects being created, you will notice each is full of properties that are specific to that particular platform, like so:



Splitting your project up into this format makes platform independence mostly an after thought for most developers.


I wont be going into depth of the functionality that LibGDX provides, it’s covered in detail elsewhere.  That said, if functionality is required by a game, but isn’t game specific, chances are its in LibGDX.  This includes graphics, audio, input, motion, asset management and much more.


LibGDX Tools


Not being strictly a game engine, the tooling support in LibGDX is minimal, but there are some tools included, many of which are command-line based.  There is no world editor, animation tools, etc…  The tools are bundled in the project if you included the Tools extension.  The tools include:



Most of the tools are Java callable and can be invoked from the command line/terminal.  This means integrating them into your build process is trivial.  The primary tools above are for font and sprite sheet creation.  Only hiero and particleeditor are GUI based:


Hiero is a tool for creating bitmap fonts from system/ttf fonts:



The Particle Editor is a GUI tool for creating particle systems:



Another critical tool, not included by default, is the fbx-conv project, which is used for importing 3D assets into LibGDX.


Built on LibGDX


Although not directly part of LibGDX, there are some tools build over top of LibGDX and provide some of the functionality typically ascribed to a full game engine.  They include:


Overlap2D  A 2D level and UI editor for LibGDX games built over LibGDX


GDX-Proto A 3D game engine built over LibGDX


BDX Another 3D engine built over LibGDX, this one built over top of Blender as the world editor.


Spine A commercial 2D IK animation tool built using LibGDX by the author of Scene2D.



Documentation and Tutorials


Of course, there is the tutorial series, which I happen to think are pretty good, but I’m biased.  On top of that, there is the Wiki, which is pretty comprehensive.  There is also a generated from code complete reference guide, that while a little shallow in spots, is generally quite useful.


There are a couple recently published LibGDX books available as well, one which I somewhat recently reviewed.  I am not sure the other books are really needed between the Wiki and tutorials available on this site.  If you want however, there are some beginner oriented books available as well.


For support, there is a quite active forum available.  Well worded questions are generally answered quite quickly.  Stackoverflow also sees a fair number of LibGDX questions.  All told, it’s got a very large community, making community based support pretty solid.




Personally I am a big fan of LibGDX, even though I am not the biggest Java cheerleader you will find.  If you are looking to create complex 3D games, or want extensive editor support, LibGDX is probably not the engine for you.  If you want a code focused, open source, free, accessible cross platform game engine capable of doing 2D or 3D, you really should check out LibGDX.



The Video



GFS On YouTube

See More Tutorials on!

Month List