Libgdx Cross-platform Game Development Cookbook
Libgdx is a very popular open source, cross-platform, Java-based game development framework built for the demands of cross-platform game development. It simply lets game developers write lines of code just once which you can then deploy to a huge range of platforms, including Windows, Mac, Linux, Android, iOS, and browsers.
From the basics aspects of LibGDX to more advanced issues, this book features practical solutions to a wide range of 2D game development tasks and challenges. Beginning with an overview of the framework and project creation, the book moves on to the 2D graphics API that enables you to create efficient and visually rich games. With tips and guidance on building and rendering LibGDX bitmap fonts you can be confident you'll give your projects a quality visual experience. You'll also find more recipes on input detection and audio and file handling, as well as details of how to make use of amazing features such as Box2D rigid body physics, lighting, and artifical intelligence techniques to name a few. With further insight on how to modify Libgdx to suit your needs and how share your creation with the world, this game development cookbook is a vital resource for anyone looking for a simple solution to cross-platform development.
Read an Extract from the book
Asynchronous asset loading
Imagine what will happen if a Triple-A RPG game has to load a graphically awesome world where the final boss is waiting for you while spitting tons of different hungry flunkies. That’s a 10 second loading time with a decent machine. The player is freaking out because of the hype generated by his friends. You cannot disappoint him with an eternal black screen, or he will panic thinking the game is broken. However, if you satisfy him a little by providing a dynamic loading screen where some kind of teaser is revealed, his adrenaline will start pumping. What's the moral of the story? The player needs to receive continuous feedback. Nonresponsive interfaces are not okay.
The sample shown in this recipe will illustrate how to take advantage of loading resources asynchronously by displaying a reactive loading screen while our AssetManager class is working on it.
How to do it…
This sample is hosted by the ProgressBarSample.java file. In order to build a reactive loading screen, you must make the player feel that something is changing and, at the same time, show the progress of the change, making its end clear. To this purpose, a progress bar will do the trick.
Next, we will explain a very easy and simple way to develop a progress bar by rendering a gray base image container; on top of this, we have the real progress bar image setting its width to the current progress of load.
First and foremost, let's declare all variables that will go into action:
The trivial matter is that progressBarBaseImg will contain the gray base image bar; progressBarImg will contain the front width-changing bar. Since the only dynamic element on screen will be the related-to-progress width of the actual loading bar, it is a good idea to cache its coordinates, pbPos.x and pbPos.y, instead of calculating them for every frame.
The next figure illustrates what we intend to do:
Within the create() method, once AssetManager is instantiated, just load the aforementioned textures:
The images used to draw the progress bar need to be loaded synchronously before starting to bring the required resources for the next screen from the disk, on another thread. Consequently, we should not forget to write the following line of code:
Then, retrieve the textures:
It is a good idea to display elements relatively to other components on the screen in order to fit any resolution. In this case, the loading scene will contain a Libgdx logo that will be placed in the center, taking into account the application's width and height. The progress bar will be positioned below the logo:
To close the create() method, queue the real bulk of resources needed for the next screen:
The next step is to draw the progress bar, but this is not that simple. To carry out the visual effect, it is necessary to know the current loading progress. This is achievable in two different ways. The first way is more laborious, but also more interesting. It starts by adding a private int loaded field to your class. Add the following code to your create() method after calculating the coordinates of the progress bar:
The reason to do this is to know how many assets have been loaded only for the loading screen. It allows us to get the current progress by using the following code:
As you can see, we introduced a new method called getQueuedAssets() that returns the number of currently queued assets.
The second way of getting percent is as follows:
Regardless of the way you choose, percent will store a float between 0.0 and 1.0 with the loading progress. Now that the real-time value is known, all we have to do is render, but with a slightly different method from SpriteBatch:
Apply the following code to the context and at the end of render():
Note that the order of drawing is important to keep the progress bar rendered on top of the base container.
To conclude, still within render() and right after drawing the progress bar, you must make sure that the loading screen does not last forever and it gives way to the next screen.
The update() method will return true, once the progress bar reaches 100 percent:
In the meantime, you have a wide range of possibilities to keep the player's attention. Lots of games understand the loading screen as a fantastic moment to show some gameplay tips or relate story bits. Other games such as Call of Duty prefer to take advantage of the space by displaying a mission briefing. FIFA titles offer an interactive training mode; classic load screens such as Metal Gear Solid 4's warns against smoking.
How it works…
Reading a resource from disk is slow, and during the time the computer takes to retrieve
It is important to make two key concepts highly bound to this chapter clear:
Every asset that you queue into the manager is treated as a task, or called AssetLoadingTask in Libgdx. It implements the AsyncTask interface that entails a public call() method to submit it to AsyncExecutor. This class is in charge of allowing asynchronous executions of AsyncTask instances on a worker thread.
The AsyncExecutor class internally relies on the java.util.concurrent package to manage threads. It is widely used in concurrent programming.
The AssetLoadingTask class is ruled by its update() method, which, if the asset is asynchronously loaded, calls the loadAsync(...) function from the loader on a separate thread. At the end of its execution, the rest of the asset is loaded on the rendering thread by calling loadSync(...).
The TextureLoader class is a good example of loading the asset, making use of both methods. The asynchronous concept loads the pixel data, whereas Texture is created synchronously. Do not hesitate to take a look at its source code, which is available on https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/assets/loaders/TextureLoader.java.
So far, we have covered the usual flow of managing assets in a general application, but in some cases, you might want to offer support to pause and resume the app. It means that some assets must be reloaded whenever the user restarts playing, since OpenGL-context was lost. This issue is seen in Android when sending the app to the background by pressing the home button or receiving an incoming phone call, causing all OpenGL-associated resources (such as textures) to be deleted.
Resuming the app can take a few seconds, so why not give some feedback and say what the app is doing through a loading screen? You can carry out this once you have instantiated your AssetManager class and call the next function for each asset type:
Libgdx give us a resume() method when implementing the ApplicationListener interface. This is the place to locate your call to the loading screen and wait until update() returns true.
If you decide not to manage this scenario with AssetManager, all resources will be reloaded on the rendering thread, causing your app to be unresponsive for some seconds.
|Course Length||15 hours 28 minutes|
|Date Of Publication||29 Oct 2014|