LibGDX makes use of several other libraries to interface the specifics of each platform in order to provide cross-platform support for your applications. Generally, a backend is what enables LibgGDX to access the corresponding platform functionalities when one of the abstracted (platform-independent) LibGDX methods is called; for example, drawing an image in the upper-left corner of the screen, playing a sound file at a volume of 80 percent, or reading and writing from/to a file.

LibGDX currently provides the following four backends:

Lightweight Java Game Library

Lightweight Java Game Library (LWJGL) is an open source Java library originally started by Caspian Rychlik-Prince to ease game development in terms of accessing the hardware resources on desktop systems. In LibGDX, LWJGL is used for the desktop backend to support all the major desktop operating systems, such as Windows, Linux, and Mac OS X.

For more...

LibGDX provides six core modules that allow you to access various parts of the system your application will run on. What makes these modules so great for you as a developer is that they provide you with a single Application Programming Interface (API) to achieve the same effect on more than just one platform. This is extremely powerful because you can now focus on your own application and do not have to bother with the specialties that each platform inevitably brings, including the nasty little bugs that might require tricky workarounds. This is all going to be transparently handled in a straightforward API, which is categorized into logic modules and is globally available anywhere in your code as every module is accessible as a static field in the Gdx class.

The application life cycle in LibGDX is a well-defined set of distinct system states. The list of these states is pretty short: create, resize, render, pause, resume, and dispose.

LibGDX defines an ApplicationListener interface that contains six methods, one for each system state. The following code listing is a copy that is directly taken from LibGDX's sources. For the sake of readability, all comments have been stripped:

public interface ApplicationListener {
public void create ();
public void resize (int width, int height);
public void render ();
public void pause ();
public void resume ();
public void dispose ();
}

All you need to do is implement these methods in your main class of the shared game code project. LibGDX will then call each of these methods at the right time.

A starter class defines the entry point (starting point) of a LibGDX application. It is specifically written for a certain platform. Usually, these kinds of classes are very simple and mostly consist of not more than a few lines of code to set certain parameters that apply to the corresponding platform. Think of them as a kind of bootup sequence for each platform. Once booting is finished, the LibGDX framework hands over control from the starter class (for example, the demo-desktop project) to your shared application code (for example, the demo/demo-core project) by calling different methods from the ApplicationListener interface that the MyDemo class implements. Remember that the MyDemo class is where the shared application code begins.

We will now take a look at each of the starter classes that were generated during the project setup.

In this section, we will take a closer look at the actual code of the demo project. Thereafter, we will do some simple modifications to the code and also use the debugger.

public class MyDemo implements ApplicationListener {
  // ...
}

public class MyDemo extends ApplicationAdapter {
   //...
}

In this chapter, you learned a lot about LibGDX and how all the projects of an application work together. We covered LibGDX's backends, modules, and starter classes. Additionally, we covered what the application life cycle and corresponding interface are and how they are meant to work. The debugger has been used to inspect the demo application at runtime, and furthermore we made use of the JVM Code Hot Swapping feature.

We now know the basics of the LibGDX applications, so we are ready to start developing a real game. We will start at the very beginning of the development cycle step by step. As LibGDX is a framework and not a game engine, we first have to build our own engine. So, we will learn how to create an appropriate program architecture in the next chapter that is suitable to handle our game.