Structure of a libGDX game

In this post I will be discussing what a structure of a libGDX game might look. Now, let's imagine that you have already created your first libGDX project and you are ready to start making your game.

My approach is to use classes called Game and Screen. The Game class is one that handles all the Screens we are going to use. If you are wondering what the screens are, you can think them as separate parts of your game. So, a simple game might have the following screens:

• Menu Screen, this screen might just contain a Start button
• Game Screen, this screen will contain the actual game play
• Game Over Screen, this screen will be displayed once the game is over

Now, this is very much simplified. Typical additions to this structure include a loading screen that is displayed while the game's assets are loaded, an options screen for changing settings and one for displaying instructions etc. The purpose of the screen structure is to keep your game manageable and allow you to easily switch between different sections of your game.

First, we create a class called MyGame that extends Game and implements ApplicationListener. This will be the main class and make sure that in the launcher files you are creating a new instance of MyGame. Let's look at the example code below:

package com.my.game;
import com.badlogic.gdx.Game;

public class MyGame extends Game implements ApplicationListener {
 @Override
 public void create() {
  // TODO Auto-generated method stub
  setScreen(new MenuScreen());
 }
}

The very first thing your game will do when launched is the create() method and at the end of it you should set which screen you want to start. In this example we will be directly proceeding to our MenuScreen but if your game contains a lot of assets it could be better to display a loading screen first. I will show an example of that in my upcoming posts.

In the MyGame class you should implement all the handles and variables that will be used throughout all the different screens. This might include things like settings, graphics and sounds. I will show this in more detail in my later posts.

Now, lets look what our menu screen will look like. First, we create a class called MenuScreen which implements Screen. All the methods you see below are automatically generating from the screen interface. Please read through the code, I have included short explanations what each method does.

package com.my.game;
import com.badlogic.gdx.Screen;

public class MenuScreen implements Screen {

 @Override
 public void render(float delta) {
  // TODO Auto-generated method stub
                // This method is called each time your screen
                // is rendered (drawed on the screen)
                // so here you should put all your rendering
                // related code         
 }

 @Override
 public void resize(int width, int height) {
  // TODO Auto-generated method stub
                // This one is called each time you device's
                // screen size changes
                // for example when changing for landscape to
                // portrait mode
                // you might not really need this one necessarily
 }

 @Override
 public void show() {
  // TODO Auto-generated method stub
                // this method is called each time your
                // screen is set active
                // you might want to do all the initialization
                // regarding your screen here
 }

 @Override
 public void hide() {
  // TODO Auto-generated method stub
                // this method is called when a new screen
                // takes this screen's place
 }

 @Override
 public void pause() {
  // TODO Auto-generated method stub
                // this one is called though the ApplicationListener
                // when the application becomes inactive
 }

 @Override
 public void resume() {
  // TODO Auto-generated method stub
                // this one is called when the game
                // becomes active again after pause()
 }

 @Override
 public void dispose() {
  // TODO Auto-generated method stub
                // this one is used to release all the resources
                // the screen holds
 }
}

So each time your game sets a new screen using the setScreen() method the old screen will use the method hide() and the new one will be started with show(). You should note that the old screen is not removed, so you can have multiple screens loaded at the same time and you can quickly switch between them. However, you should use the dispose() when a screen is no longer needed or keeping it active would take too much memory.

Now, there are a few additions one should make to this code. First, you should make a constructor for each screen and give them a handle to the MyGame class. I prefer to do it this way, although each Screen has a method for calling it's Game class.

The constructor would look something like this:

private MyGame game;

public MenuScreen(MyGame game) {
       this.game = game; 
} 

Also you now need to pass the Game as an argument when creating a new MenuScreen. For example, when calling this in the start of the game you should use setScreen(new MenuScreen(this)); when loading a new screen in the create() method.

Now you can inside the MenuScreen switch easily to your Game screen if you wish:

this.game.setScreen(new GameScreen(this.game)); 

And that's it for this post. In the upcoming posts we will take a closer look how to implement a loading screen, load user preferences (settings) at the start of the game, how to make a menu with buttons and other stuff.

Thanks for reading and see you next time.