Before jumping into the programming aspect of game development, it is important to understand the overall structure of a game program: the major stages that a game program progresses through and the tasks that a game program must perform in each stage. The stages are as follows:

The flowchart in Figure 2-2 illustrates the order in which these stages occur.

Some game developers may include additional stages in the game loop, such as the following:

Most of these stages are handled by a corresponding method in LibGDX. For example, the startup stage is carried out by a method named create, the update and render stages are both handled by the render method,² and any shutdown actions are performed by a method named dispose.

In fact, when your driver class creates any kind of application (such as a LwjglApplication ), the application will work correctly only if given an object that contains a certain set of methods (including create, render, and dispose); this is a necessary convention so that the application knows what to do during each stage of the game program’s life cycle. You are able to enforce such requirements in Java programs by using interfaces.

An application in LibGDX requires user-created classes to implement the ApplicationListener interface so that it can handle all stages of a game program’s life cycle. You may recall, however, that in our example from Chapter 1, the HelloWorldImage class did not implement the ApplicationListener class; it only extended the Game class. Why didn’t this result in an error when the class was compiled? If you take a look “under the hood” (which, in the context of computer programming, typically means to inspect the source code³), you’ll notice that the Game class itself implements the ApplicationListener class and includes “empty” versions of the functions; there is no code between the braces that define the body of each function. This enables you to write only variations of the interface methods that you need to use in the class that extends the Game class, which will then override the versions in the Game class; any interface method that you don’t write will default to the empty version in the Game class. (In fact, the ApplicationListener interface requires a total of six methods: create, render, resize, pause, resume, and dispose; in our example, you wrote only two of these.)

This section will introduce the game Starfish Collector , previously shown in Figure 2-1. Before starting to write the code for this game, it is helpful to precisely describe its features: the game mechanics and rules, how the player interacts with the software, the graphics that will be required, and so forth. Such a description is called a game-design document and is explained more fully in Appendix A of this book. Since this is the first game you will be creating with LibGDX, only the following minimal set of features will be created:

One version of the code that accomplishes these tasks is presented next. Some of the code and concepts will be familiar from the HelloWorldImage example, such as the Texture and SpriteBatch classes , the purpose of the create and render methods, and the role of the driver class. There are a few new additions as well. Since the coordinates of the turtle may change, you use variables to store these values. Most significantly, you introduce some code that makes our program interactive—you will process keyboard input from the user. Finally, you’ll include a Boolean variable that keeps track of whether the player has won, which becomes true when the turtle reaches the starfish and affects when the “You Win” message is displayed on the screen.

In this section, as well as the sections that follow, you are invited to create a new project in BlueJ (after closing the previous project by selecting Close from the BlueJ Project menu) and enter the code that is presented, or, alternatively, to simply download the source code from the website for this book and run the code via the included BlueJ project files. The online source code also contains all the images that you will need, stored in the assets folder in each project, and referenced in the following code.

To begin, download the source code files for this chapter on the website for this book. Create a new project in BlueJ named Starfish Collector Ch2 (since there will be many versions of this project created throughout this book). In the project directory that is created by BlueJ, create a new folder called assets. Copy the image files from the downloaded project's assets folder into your new project's assets folder; keeping the source code separate from the images in this manner will help keep your files organized. Next, in your project directory, create a new folder named +libs. Copy the JAR files from the downloaded project’s +libs folder into your new project’s +libs folder. Restart BlueJ so that the JAR files newly added to the +libs folder are properly recognized by BlueJ.

In your BlueJ project, create a new class called StarfishCollectorAlpha . The source code for this class appears next. There are new import statements that enable you to create a variety of new objects, which are also explained in what follows:

At this point, you can compile the code; if any error messages appear, double-check that the code you entered precisely matches the preceding code. You will also need a launcher-style class to create an instance of this class and run it. To accomplish this, create a new class named LauncherAlpha and enter the code as follows. Notice that additional parameters have been included in the LwglApplication constructor to set the title that is displayed and the size (the width and height, in pixels) of the window.

At this point, the code can be compiled, after which the game can be run from the main BlueJ window by right-clicking the orange rectangle labeled LauncherAlpha, selecting the main method, and clicking the OK button in the window that appears (similar to the process for running the “Hello, World!” program from Chapter 1).

In the class StarfishCollectorAlpha, the create method initializes variables and loads textures. This program contains four images, which are stored as Texture objects: the turtle, the starfish, the water, and an image containing the words You Win. For brevity, instead of creating a new variable to store each of the FileHandle objects created by the internal method, you initialize them in the same line where you construct each new Texture object. The coordinates of the turtle’s position are stored using floating-point numbers since you need to store decimal values, and the LibGDX game development framework uses float rather than double variables in its classes for a slight increase in program efficiency. Even though the coordinates of the starfish texture will not be changing, you still store them using variables so that future code involving these values is more readable. The oceanTexture and winMessageTexture objects do not require variables to store their coordinates, as their positions will not be changing, and their positions will be specified in the render method (discussed later in this section). Rectangle objects are also created that correspond to the turtle and starfish; these store the position and size of a rectangular area and are used because the Rectangle class contains a method named overlap that can be used to detect when the turtle has reached the starfish. The Boolean variable win indicates whether the player has won the game and is initialized to false.

The render method contains three main blocks of code that roughly correspond to the game loop sub-stages: process input, update, and render.

First, a sequence of commands use a method named isKeyPressed, belonging to (an object belonging to) the Gdx class, which determines whether a key on the keyboard is currently being pressed. The names of each key are represented using constant values from the Keys class. When one of the arrow keys is pressed, the corresponding x or y coordinate of the turtle is adjusted accordingly; x values increase toward the right side of the window, while y values increase toward the top of the window.⁴ Note that if the user presses the left and right arrow keys at the same time, the effects of the addition and subtraction cancel each other out, and the position of the turtle will not change; a similar situation also applies when the user presses the up and down arrow keys at the same time. Also note that a sequence of if statements is used rather than a sequence of if-else if statements, enabling the program to respond appropriately if two keys are being pressed at the same time.

The second set of commands performs collision detection, determining whether the rectangular region corresponding to the turtleTexture image overlaps the rectangular region containing starfishTexture . The turtle’s rectangle must be updated (using the setPosition method), since the position of the turtle may have changed. If the two rectangles overlap, then the Boolean variable win is set to true, which in turn affects which textures are drawn to the screen. As you test this game, you might notice that the starfish seem to disappear before the turtle actually reaches it. This is because rectangular shapes are being used to check for overlap; some of the transparent parts of the images may be overlapping, as shown in Figure 2-3. (This situation will be addressed and improved upon in the next chapter.)

Finally, the third set of commands in the render method is where the actual rendering takes place. The glClear method draws a solid-colored rectangle on the screen using the color specified in the glClearColor method (in terms of red/green/blue/alpha values). The screen must be cleared in this manner during every rendering pass, effectively “erasing” the screen, because the images from previous render calls might be visible otherwise. The order of the draw method calls is particularly important: textures that are rendered later appear on top of those rendered earlier. Thus, you typically want to draw the background elements first, followed by the main in-game entities, and then the user interface elements last. The Batch class, used for drawing, optimizes graphics operations by sending multiple images at once to the computer’s graphics processing unit (GPU).

In the previous example—our first iteration of the Starfish Collector game—you saw that each game entity (such as the turtle and the starfish) has a lot of related information that you need to keep track of, such as textures and (x,y) coordinates. A central design principle in an object-oriented programming language like Java is to encapsulate related information in a single class. While you could create a Turtle class, a Starfish class, and so forth to manage this information, this approach would result in a lot of redundancy in your program, which is both inefficient and difficult to manage. Since another guiding principle in software engineering is to write reusable code, you want to implement a single class that contains the basic information common to all game entities, which you can then extend when necessary.

The LibGDX libraries provide a few different classes that can be used to manage the data associated with a game object; you will use the LibGDX class Actor as a foundation. This class stores data such as position, size (width and height), rotation, scaling factors, and more. However, it does not include a variable to store an image. This seeming “omission” in fact gives you greater flexibility in allowing you to specify how the object will be represented. You can extend the Actor class and include any additional information you need in your game, such as collision shapes, one or more images or animations, custom rendering methods, and more. The constructor for such an object should call the constructor of the class that it extends; this is accomplished by including the statement super(). For example, a game object that just requires a single Texture could use the following code:

For a more complex example, your game might feature a character that has health points, and you might want to use different textures depending on how much health the character has. Such an object could be created with the following code:

There are a few additional features of the default Actor class that should be mentioned here. First, in addition to a draw method, the Actor class has an act method that can serve to update or modify the state of an Actor. Second, the Actor class was designed to be used in concert with a class called Stage (which you will be using in the near future). The main role of the Stage class is to store a list of Actor instances; it also contains methods (named act and draw) that call the act and draw methods of every Actor that has been added to it, which frees you from having to remember to draw every individual Actor instance yourself. The Stage class also creates and handles a Batch object, which reduces the amount of code that you need to write.

The next goal is to write an extension of the Actor class; this will require accessing and overriding methods already present in the Actor class.

The extension of the Actor class that will be created for use in this chapter is called ActorBeta. It will be used to store a TextureRegion (which builds upon the functionality of the Texture class) and a Rectangle (used for detecting overlap between two objects). In the same BlueJ project, create a new class called ActorBeta with the following code:

The following are some observations about this code:

Next, you will build upon the functionality of the ActorBeta class. Create a new class named Turtle with the following code:

The code for the StarfishCollectorBeta class is as follows:

These changes make the code simpler to understand and will make it easier to incorporate additional elements in the future. At this point, you should compile the code you have written to verify that it is error-free. In order to run this game, create a new launcher class called LauncherBeta with the following code:

In the rest of the chapter, you will reorganize this code in accordance with programming design principles.

An important programming design practice is that each method should correspond to a single task. If a single method is handling multiple tasks, then it should be broken up into multiple methods. In the first section of this chapter, when the life cycle of a video game was discussed, you learned that in LibGDX, the render method is the method that is called repeatedly as the game is running, and therefore all the code related to the game loop is contained in that method. However, the game loop has multiple tasks: processing input, updating the state of the game world (such as determining what happens when two objects overlap), and drawing the graphics to the screen. These tasks should be separated into different methods if possible. Using the act method of the Actor class to process the input that affects each actor is a step in the right direction.

The next step is to separate the code used for updating and the code used for rendering into different methods. At the same time, you can also streamline future development projects by including commonly used code in a base class that can be extended when necessary, as you previously did with the Actor-derived classes. In particular, all future game projects will need to declare and initialize a Stage object and run its act and draw methods. You can use the method getDeltaTime to determine how much time has elapsed since the previous iteration of the game loop (which is typically 1/60 of a second, as discussed previously, but may fluctuate depending on the computer being used and the complexity of the program). Also, you typically clear the screen before redrawing the graphics in each iteration of the game loop.⁵

To accomplish these tasks, create a new class named GameBeta as shown next. However, there will be a few modifications made to this class later on in the chapter for reasons that will be explained.

With this code in place, the StarfishCollectorBeta class could be changed to extend the GameBeta class. In the StarfishCollectorBeta class, the methods create and render would be changed to initialize and update (overriding the corresponding methods from the GameBeta class), and the redundant lines of code from the StarfishCollectorBeta class (those that also appear in the GameBeta class) would be removed.

However, before continuing on, there is one final topic that needs to be discussed to make this code more robust. In practice, any program that uses this class as a basis should be required to provide its own versions of the initialize and update methods. This brings to mind the concept of an interface (discussed earlier in this chapter), but an interface is not suitable in this situation because an interface can only declare the required method, and does not include any actual code. In this situation, there is code that would be helpful to reuse. What you need is a structure that combines elements of both an interface and a standard class that can be extended. Java provides exactly what is needed for this situation: abstract classes .

Using an abstract class will require any class that extends GameBeta to provide implementations of methods to initialize and update the game world. This also helps developers avoid potential mistakes such as misspelling the names of the methods that they are supposed to be overriding.

The changes that need to be made to the GameBeta class, presented previously, are as follows. Note in particular that the bodies of the initialize and update methods are removed, and there are semicolons added to the lines where these methods are declared.

With the GameBeta class serving as a base, the StarfishCollectorBeta class can be greatly simplified, as previously explained. The changes to the class are explained in the commented code that follows. Note that as you change the code in one class, other classes that depend on it will appear to have errors until the changes have been completed.

Congratulations on creating your first game in LibGDX!

This chapter introduced many features of the LibGDX library. You began with an overview of the life cycle of a game program and learned how the stages of the life cycle are performed by methods with a particular naming convention, enforced by an interface. You learned how to process keyboard input by using the Gdx class and how to encapsulate game-entity data with the Actor class. You learned how the Stage class can be used to manage Actor instances, and how to extend the Actor class for greater functionality. You also learned how to reorganize the game flow and simplify future game development projects by extending the Game class.

In the next chapter, you’ll create a more polished version of the Starfish Collector game powered by a new extension of the Actor class (which will replace ActorBeta) that supports animation, physics-based movement, improved collision detection, and the ability to manage multiple actor instances with lists.