Before diving into the APIs provided by libGDX, let’s create a very simple “game”, that touches each module provided by the framework, to get a feeling for things. We’ll introduce a few different concepts without going into unnecessary detail.

A Simple Game - 图1

In the following, we’ll look at:

  • Basic file access
  • Clearing the screen
  • Drawing images
  • Using a camera
  • Basic input processing
  • Playing sound effects

Project Setup

Follow the steps in the Generating a Project guide. In the following, we will use these settings:

  • Application name: drop
  • Package name: com.badlogic.drop
  • Game class: Drop

Now fill in the destination. If you are interested in Android development, be sure to check that option an provide the Android SDK folder. For the purpose of this tutorial, we will uncheck the iOS sub project (as you would need OS X to run it) and all extensions (extensions are a more advanced topic).

Once imported into your IDE, you should have 5 projects or modules: the main one drop, and the sub projects android (or drop-android under Eclipse), core / drop-core, desktop / drop-desktop, and html / drop-html.

To launch or debug the game, see the page Importing & Running a Project.

If we just run the project, we will get an error: Couldn't load file: badlogic.jpg. Your Run Configuration has to be properly configured first: Select as working directory PATH_TO_YOUR_PROJECT/​drop/android/assets. If we run it now, we will get the default ‘game’ generated by the startup app: a Badlogic Games image on a red background. Not too exciting, but that’s about to change.

The Game

The game idea is very simple:

  • Catch raindrops with a bucket.
  • The bucket is located in the lower part of the screen.
  • Raindrops spawn randomly at the top of the screen every second and accelerate downwards.
  • Player can drag the bucket horizontally via the mouse/touch or move it via the left and right cursor keys.
  • The game has no end - think of it as a zen-like experience :)

The Assets

We need a few images and sound effects to make the game look somewhat pretty. For the graphics we need to define a target resolution of 800x480 pixels (landscape mode on Android). If the device the game is run on does not have that resolution, we simply scale everything to fit on the screen.

Note: for high profile games you might want to consider using different assets for different screen densities. This is a big topic on its own and won’t be covered here.

The raindrop and the bucket should take up a small(ish) portion of the screen vertically, so we’ll let them have a size of 64x64 pixels.

The following sources provide some sample assets:

  • water drop sound by junggle, see here
  • rain sounds by acclivity, see here
  • droplet sprite by mvdv, see here
  • bucket sprite by mvdv, see here

To make the assets available to the game, we have to place them in the Android assets folder. I named the 4 files: drop.wav, rain.mp3, droplet.png and bucket.png and put them in android/assets/. We only need to store the assets once, as both the desktop and HTML5 projects are configured to ‘see’ this folder through different means. After that, depending on your IDE you may have to refresh the project tree to make the new files known (in Eclipse, right click -> Refresh), otherwise you may get a ‘file not found’ runtime exception.

Configuring the Starter Classes

Given our requirements we can now configure our different starter classes. We’ll start with the desktop project. Open the DesktopLauncher.java class in desktop/src/… (or drop-desktop under Eclipse). We want a 800x480 window and set the title to “Drop”. The code should look like this:

  1. package com.badlogic.drop.desktop;
  3. import com.badlogic.gdx.backends.lwjgl.LwjglApplication;
  4. import com.badlogic.gdx.backends.lwjgl.LwjglApplicationConfiguration;
  5. import com.badlogic.drop.Drop;
  7. public class DesktopLauncher {
  8.    public static void main (String[] arg) {
  9.       LwjglApplicationConfiguration config = new LwjglApplicationConfiguration();
  10.       config.title = "Drop";
  11.       config.width = 800;
  12.       config.height = 480;
  13.       new LwjglApplication(new Drop(), config);
  14.    }
  15. }

If you are only interested in desktop development, you can skip the rest of this section.

Moving on to the Android project, we want the application to be run in landscape mode. For this we need to modify AndroidManifest.xml in the android (or drop-android) root directory, which looks like this:

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <manifest xmlns:android="http://schemas.android.com/apk/res/android"
  3.     package="com.badlogic.drop.android"
  4.     android:versionCode="1"
  5.     android:versionName="1.0" >
  7.     <uses-sdk android:minSdkVersion="8" android:targetSdkVersion="20" />
  9.     <application
  10.         android:allowBackup="true"
  11.         android:icon="@drawable/ic_launcher"
  12.         android:label="@string/app_name"
  13.         android:theme="@style/GdxTheme" >
  14.         <activity
  15.             android:name="com.badlogic.drop.android.AndroidLauncher"
  16.             android:label="@string/app_name"
  17.             android:screenOrientation="landscape"
  18.             android:configChanges="keyboard|keyboardHidden|orientation|screenSize">
  19.             <intent-filter>
  20.                 <action android:name="android.intent.action.MAIN" />
  21.                 <category android:name="android.intent.category.LAUNCHER" />
  22.             </intent-filter>
  23.         </activity>
  24.     </application>
  26. </manifest>

The setup tool already filled in the correct values for us, android:screenOrientation is set to “landscape”. If we wanted to run the game in portrait mode we would have set that attribute to “portrait”.

We also want to conserve battery and disable the accelerometer and compass. We do this in the AndroidLauncher.java file in android/src/… (or drop-android), which should look something like this:

  1. package com.badlogic.drop.android;
  3. import android.os.Bundle;
  5. import com.badlogic.gdx.backends.android.AndroidApplication;
  6. import com.badlogic.gdx.backends.android.AndroidApplicationConfiguration;
  7. import com.badlogic.drop.Drop;
  9. public class AndroidLauncher extends AndroidApplication {
  10.    @Override
  11.    protected void onCreate(Bundle savedInstanceState) {
  12.       super.onCreate(savedInstanceState);
  13.       AndroidApplicationConfiguration config = new AndroidApplicationConfiguration();
  14.       config.useAccelerometer = false;
  15.       config.useCompass = false;
  16.       initialize(new Drop(), config);
  17.    }
  18. }

We cannot define the resolution of the Activity, as it is set by the Android operating system. As we defined earlier, we’ll simply scale the 800x480 target resolution to whatever the resolution of the device is.

Finally we want to make sure the HTML5 project also uses a 800x480 drawing area. For this we modify the HtmlLauncher.java file in html/src/… (or drop-html):

  1. package com.badlogic.drop.client;
  3. import com.badlogic.gdx.ApplicationListener;
  4. import com.badlogic.gdx.backends.gwt.GwtApplication;
  5. import com.badlogic.gdx.backends.gwt.GwtApplicationConfiguration;
  6. import com.badlogic.drop.Drop;
  8. public class HtmlLauncher extends GwtApplication {
  9.    @Override
  10.    public GwtApplicationConfiguration getConfig () {
  11.       return new GwtApplicationConfiguration(800, 480);
  12.    }
  14.    @Override
  15.    public ApplicationListener createApplicationListener () {
  16.       return new Drop();
  17.    }
  18. }

All our starter classes are now correctly configured, let’s move on to implementing our fabulous game.

The Code

We want to split up our code into a few sections. For the sake of simplicity we keep everything in the Drop.java file of the Core project, located in core/src/… (or drop-core in Eclipse).

Loading the Assets

Our first task is to load the assets and store references to them. Assets are usually loaded in the ApplicationAdapter.create() method, so let’s do that:

  1. package com.badlogic.drop;
  3. import com.badlogic.gdx.ApplicationAdapter;
  4. import com.badlogic.gdx.Gdx;
  5. import com.badlogic.gdx.audio.Music;
  6. import com.badlogic.gdx.audio.Sound;
  7. import com.badlogic.gdx.graphics.Texture;
  9. public class Drop extends ApplicationAdapter {
  10.    private Texture dropImage;
  11.    private Texture bucketImage;
  12.    private Sound dropSound;
  13.    private Music rainMusic;
  15.    @Override
  16.    public void create() {
  17.       // load the images for the droplet and the bucket, 64x64 pixels each
  18.       dropImage = new Texture(Gdx.files.internal("droplet.png"));
  19.       bucketImage = new Texture(Gdx.files.internal("bucket.png"));
  21.       // load the drop sound effect and the rain background "music"
  22.       dropSound = Gdx.audio.newSound(Gdx.files.internal("drop.wav"));
  23.       rainMusic = Gdx.audio.newMusic(Gdx.files.internal("rain.mp3"));
  25.       // start the playback of the background music immediately
  26.       rainMusic.setLooping(true);
  27.       rainMusic.play();
  29.       // ... more to come ...
  30.    }
  32.    // rest of class omitted for clarity

For each of our assets we have a field in the Drop class so we can later refer to it. The first two lines in the create() method load the images for the raindrop and the bucket. A Texture represents a loaded image that is stored in video ram. One can usually not draw to a Texture. A Texture is loaded by passing a FileHandle to an asset file to its constructor. Such FileHandle instances are obtained through one of the methods provided by Gdx.files. There are different types of files, we use the “internal” file type here to refer to our assets. Internal files are located in the assets directory of the Android project. As seen before, the desktop and HTML5 projects reference the same directory.

Next we load the sound effect and the background music. libGDX differentiates between sound effects, which are stored in memory, and music, which is streamed from wherever it is stored. Music is usually too big to be kept in memory completely, hence the differentiation. As a rule of thumb, you should use a Sound instance if your sample is shorter than 10 seconds, and a Music instance for longer audio pieces.

Note: libGDX supports MP3, OGG and WAV files. Which format you should use, depends on you specific needs, as each format has its own advantages and disadvantages. For example, WAV files are quite large compared to other formats, OGG files don’t work on RoboVM (iOS) nor with Safari (GWT), and MP3 files have issues with seemless looping.

Loading of a Sound or Music instance is done via Gdx.audio.newSound() and Gdx.audio.newMusic(). Both of these methods take a FileHandle, just like the Texture constructor.

At the end of the create() method we also tell the Music instance to loop and start playback immediately. If you run the application you’ll see a nice pink background and hear the rain fall.

A Camera and a SpriteBatch

Next up, we want to create a camera and a SpriteBatch. We’ll use the former to ensure we can render using our target resolution of 800x480 pixels no matter what the actual screen resolution is. The SpriteBatch is a special class that is used to draw 2D images, like the textures we loaded.

We add two new fields to the class, let’s call them camera and batch:

  1.    private OrthographicCamera camera;
  2.    private SpriteBatch batch;

In the create() method we first create the camera like this:

  1.    camera = new OrthographicCamera();
  2.    camera.setToOrtho(false, 800, 480);

This will make sure the camera always shows us an area of our game world that is 800x480 units wide. Think of it as a virtual window into our world. We currently interpret the units as pixels to make our life a little easier. There’s nothing preventing us from using other units though, e.g. meters or whatever you have. Cameras are very powerful and allow you to do a lot of things we won’t cover in this basic tutorial. Check out the rest of the developer guide for more information.

Next we create the SpriteBatch (we are still in the create() method):

  1.    batch = new SpriteBatch();

We are almost done with creating all the things we need to run this simple game.

Adding the Bucket

The last bits that are missing are representations of our bucket and the raindrop. Let’s think about what we need to represent those in code:

  • A bucket/raindrop has an x/y position in our 800x480 units world.
  • A bucket/raindrop has a width and height, expressed in the units of our world.
  • A bucket/raindrop has a graphical representation, we already have those in form of the Texture instances we loaded.

So, to describe both the bucket and raindrops we need to store their position and size. libGDX provides a Rectangle class which we can use for this purpose. Let’s start by creating a Rectangle that represents our bucket. We add a new field:

  1.    // add this import and NOT the one in the standard library
  2.    import com.badlogic.gdx.math.Rectangle;
  4.    private Rectangle bucket;

In the create() method we instantiate the Rectangle and specify its initial values. We want the bucket to be 20 pixels above the bottom edge of the screen, and centered horizontally.

  1.    bucket = new Rectangle();
  2.    bucket.x = 800 / 2 - 64 / 2;
  3.    bucket.y = 20;
  4.    bucket.width = 64;
  5.    bucket.height = 64;

We center the bucket horizontally and place it 20 pixels above the bottom edge of the screen. Wait, why is bucket.y set to 20, shouldn’t it be 480 - 20? By default, all rendering in libGDX (and OpenGL) is performed with the y-axis pointing upwards. The x/y coordinates of the bucket define the bottom left corner of the bucket, the origin for drawing is located in the bottom left corner of the screen. The width and height of the rectangle are set to 64x64, our small-ish portion of our target resolutions height.

Note: it is possible to change this setup so the y-axis points down and the origin is in the upper left corner of the screen. OpenGL and the camera class are so flexible that you use have pretty much any kind of viewing angle you want, in 2D and 3D. However, this is not recommended.

Rendering the Bucket

Time to render our bucket. The first thing we want to do is to clear the screen with a dark blue color. Simply change the render() method to look like this:

  1.    @Override
  2.    public void render() {
  3.       ScreenUtils.clear(0, 0, 0.2f, 1);
  5.       ... more to come here ...
  6.    }

The arguments for ScreenUtils.clear(r, g, b, a) are the red, green, blue and alpha component of that color, each within the range [0, 1].

Next we need to tell our camera to make sure it is updated. Cameras use a mathematical entity called a matrix that is responsible for setting up the coordinate system for rendering. These matrices need to be recomputed every time we change a property of the camera, like its position. We don’t do this in our simple example, but it is generally a good practice to update the camera once per frame:

  1.    camera.update();

Now we can render our bucket:

  1.    batch.setProjectionMatrix(camera.combined);
  2.    batch.begin();
  3.    batch.draw(bucketImage, bucket.x, bucket.y);
  4.    batch.end();

The first line tells the SpriteBatch to use the coordinate system specified by the camera. As stated earlier, this is done with something called a matrix, to be more specific, a projection matrix. The camera.combined field is such a matrix. From there on the SpriteBatch will render everything in the coordinate system described earlier.

Next we tell the SpriteBatch to start a new batch. Why do we need this and what is a batch? OpenGL hates nothing more than telling it about individual images. It wants to be told about as many images to render as possible at once.

The SpriteBatch class helps make OpenGL happy. It will record all drawing commands in between SpriteBatch.begin() and SpriteBatch.end(). Once we call SpriteBatch.end() it will submit all drawing requests we made at once, speeding up rendering quite a bit. This all might look cumbersome in the beginning, but it is what makes the difference between rendering 500 sprites at 60 frames per second and rendering 100 sprites at 20 frames per second.

Making the Bucket Move (Touch/Mouse)

Time to let the user control the bucket. Earlier we said we’d allow the user to drag the bucket. Let’s make things a little bit easier. If the user touches the screen (or presses a mouse button), we want the bucket to center around that position horizontally. Adding the following code to the bottom of the render() method will do this:

  1.    if(Gdx.input.isTouched()) {
  2.       Vector3 touchPos = new Vector3();
  3.       touchPos.set(Gdx.input.getX(), Gdx.input.getY(), 0);
  4.       camera.unproject(touchPos);
  5.       bucket.x = touchPos.x - 64 / 2;
  6.    }

First we ask the input module whether the screen is currently touched (or a mouse button is pressed) by calling Gdx.input.isTouched(). Next we want to transform the touch/mouse coordinates to our camera’s coordinate system. This is necessary because the coordinate system in which touch/mouse coordinates are reported might be different than the coordinate system we use to represent objects in our world.

Gdx.input.getX() and Gdx.input.getY() return the current touch/mouse position (libGDX also supports multi-touch, but that’s a topic for a different article). To transform these coordinates to our camera’s coordinate system, we need to call the camera.unproject() method, which requests a Vector3, a three dimensional vector. We create such a vector, set the current touch/mouse coordinates and call the method. The vector will now contain the touch/mouse coordinates in the coordinate system our bucket lives in. Finally we change the position of the bucket to be centered around the touch/mouse coordinates.

Note: it is very, very bad to instantiate a lot of new objects, such as the Vector3 instance. The reason for this is the garbage collector has to kick in frequently to collect these short-lived objects. While on the desktop this not such a big deal (due to the resources available), on Android the GC can cause pauses of up to a few hundred milliseconds, which results in stuttering. In this particular case, if you want to solve this issue, simply make touchPos a private final field of the Drop class instead of instantiating it all the time.

Note: touchPos is a three dimensional vector. You might wonder why that is if we only operate in 2D. OrthographicCamera is actually a 3D camera which takes into account z-coordinates as well. Think of CAD applications, they use 3D orthographic cameras as well. We simply abuse it to draw 2D graphics.

Making the Bucket Move (Keyboard)

On the desktop and in the browser we can also receive keyboard input. Let’s make the bucket move when the left or right cursor key is pressed.

We want the bucket to move without acceleration, at two hundred pixels/units per second, either to the left or the right. To implement such time-based movement we need to know the time that passed in between the last and the current rendering frame. Here’s how we can do all this:

  1.    if(Gdx.input.isKeyPressed(Input.Keys.LEFT)) bucket.x -= 200 * Gdx.graphics.getDeltaTime();
  2.    if(Gdx.input.isKeyPressed(Input.Keys.RIGHT)) bucket.x += 200 * Gdx.graphics.getDeltaTime();

The method Gdx.input.isKeyPressed() tells us whether a specific key is pressed. The Keys enumeration contains all the keycodes that libGDX supports. The method Gdx.graphics.getDeltaTime() returns the time passed between the last and the current frame in seconds. All we need to do is modify the bucket’s x-coordinate by adding/subtracting 200 units times the delta time in seconds.

We also need to make sure our bucket stays within the screen limits:

  1.    if(bucket.x < 0) bucket.x = 0;
  2.    if(bucket.x > 800 - 64) bucket.x = 800 - 64;

Adding the Raindrops

For the raindrops we keep a list of Rectangle instances, each keeping track of the position and size of a raindrop. Let’s add that list as a field:

  1.    private Array<Rectangle> raindrops;

The Array class is a libGDX utility class to be used instead of standard Java collections like ArrayList. The problem with the latter is that they produce garbage in various ways. The Array class tries to minimize garbage as much as possible. libGDX offers other garbage collector aware collections such as hash-maps or sets as well.

We also need to keep track of the last time we spawned a raindrop, so we add another field:

  1.    private long lastDropTime;

We’ll store the time in nanoseconds, that’s why we use a long.

To facilitate the creation of raindrops we’ll write a method called spawnRaindrop() which instantiates a new Rectangle, sets it to a random position at the top edge of the screen and adds it to the raindrops array.

  1.    private void spawnRaindrop() {
  2.       Rectangle raindrop = new Rectangle();
  3.       raindrop.x = MathUtils.random(0, 800-64);
  4.       raindrop.y = 480;
  5.       raindrop.width = 64;
  6.       raindrop.height = 64;
  7.       raindrops.add(raindrop);
  8.       lastDropTime = TimeUtils.nanoTime();
  9.    }

The method should be pretty self-explanatory. The MathUtils class is a libGDX class offering various math related static methods. In this case it will return a random value between zero and 800 - 64. The TimeUtils is another libGDX class that provides some very basic time related static methods. In this case we record the current time in nano seconds based on which we’ll later decide whether to spawn a new drop or not.

In the create() method we now instantiate the raindrops array and spawn our first raindrop:

We need to instantiate that array in the create() method:

  1.    raindrops = new Array<Rectangle>();
  2.    spawnRaindrop();

Next we add a few lines to the render() method that will check how much time has passed since we spawned a new raindrop, and creates a new one if necessary:

  1.    if(TimeUtils.nanoTime() - lastDropTime > 1000000000) spawnRaindrop();

We also need to make our raindrops move, let’s take the easy route and have them move at a constant speed of 200 pixels/units per second. If the raindrop is beneath the bottom edge of the screen, we remove it from the array.

  1.    for (Iterator<Rectangle> iter = raindrops.iterator(); iter.hasNext(); ) {
  2.       Rectangle raindrop = iter.next();
  3.       raindrop.y -= 200 * Gdx.graphics.getDeltaTime();
  4.       if(raindrop.y + 64 < 0) iter.remove();
  5.    }

The raindrops need to be rendered. We’ll add that to the SpriteBatch rendering code which looks like this now:

  1.    batch.begin();
  2.    batch.draw(bucketImage, bucket.x, bucket.y);
  3.    for(Rectangle raindrop: raindrops) {
  4.       batch.draw(dropImage, raindrop.x, raindrop.y);
  5.    }
  6.    batch.end();

One final adjustment: if a raindrop hits the bucket, we want to playback our drop sound and remove the raindrop from the array. We simply add the following lines to the raindrop update loop:

  1.       if(raindrop.overlaps(bucket)) {
  2.          dropSound.play();
  3.          iter.remove();
  4.       }

The Rectangle.overlaps() method checks if this rectangle overlaps with another rectangle. In our case, we tell the drop sound effect to play itself and remove the raindrop from the array.

Cleaning Up

A user can close the application at any time. For this simple example there’s nothing that needs to be done. However, it is in general a good idea to help out the operating system a little and clean up the mess we created.

Any libGDX class that implements the Disposable interface and thus has a dispose() method needs to be cleaned up manually once it is no longer used. In our example that’s true for the textures, the sound and music and the SpriteBatch. Being good citizens, we override the ApplicationAdapter.dispose() method as follows:

  1.    @Override
  2.    public void dispose() {
  3.       dropImage.dispose();
  4.       bucketImage.dispose();
  5.       dropSound.dispose();
  6.       rainMusic.dispose();
  7.       batch.dispose();
  8.    }

Once you dispose of a resource, you should not access it in any way.

Disposables are usually native resources which are not handled by the Java garbage collector. This is the reason why we need to manually dispose of them. libGDX provides various ways to help with asset management. Read the rest of the development guide to discover them.

Handling Pausing/Resuming

Android has the notation of pausing and resuming your application every time the user gets a phone call or presses the home button. libGDX will do many things automatically for you in that case, e.g. reload images that might have gotten lost (OpenGL context loss, a terrible topic on its own), pause and resume music streams and so on.

In our game there’s no real need to handle pausing/resuming. As soon as the user comes back to the application, the game continues where it left. Usually one would implement a pause screen and ask the user to touch the screen to continue. This is left as an exercise for the reader - check out the ApplicationAdapter.pause() and ApplicationAdapter.resume() methods.

The Full Source

Here’s the tiny source for our simple game:

  1. package com.badlogic.drop;
  3. import java.util.Iterator;
  5. import com.badlogic.gdx.ApplicationAdapter;
  6. import com.badlogic.gdx.Gdx;
  7. import com.badlogic.gdx.Input.Keys;
  8. import com.badlogic.gdx.audio.Music;
  9. import com.badlogic.gdx.audio.Sound;
  10. import com.badlogic.gdx.graphics.OrthographicCamera;
  11. import com.badlogic.gdx.graphics.Texture;
  12. import com.badlogic.gdx.graphics.g2d.SpriteBatch;
  13. import com.badlogic.gdx.math.MathUtils;
  14. import com.badlogic.gdx.math.Rectangle;
  15. import com.badlogic.gdx.math.Vector3;
  16. import com.badlogic.gdx.utils.Array;
  17. import com.badlogic.gdx.utils.ScreenUtils;
  18. import com.badlogic.gdx.utils.TimeUtils;
  20. public class Drop extends ApplicationAdapter {
  21.    private Texture dropImage;
  22.    private Texture bucketImage;
  23.    private Sound dropSound;
  24.    private Music rainMusic;
  25.    private SpriteBatch batch;
  26.    private OrthographicCamera camera;
  27.    private Rectangle bucket;
  28.    private Array<Rectangle> raindrops;
  29.    private long lastDropTime;
  31.    @Override
  32.    public void create() {
  33.       // load the images for the droplet and the bucket, 64x64 pixels each
  34.       dropImage = new Texture(Gdx.files.internal("droplet.png"));
  35.       bucketImage = new Texture(Gdx.files.internal("bucket.png"));
  37.       // load the drop sound effect and the rain background "music"
  38.       dropSound = Gdx.audio.newSound(Gdx.files.internal("drop.wav"));
  39.       rainMusic = Gdx.audio.newMusic(Gdx.files.internal("rain.mp3"));
  41.       // start the playback of the background music immediately
  42.       rainMusic.setLooping(true);
  43.       rainMusic.play();
  45.       // create the camera and the SpriteBatch
  46.       camera = new OrthographicCamera();
  47.       camera.setToOrtho(false, 800, 480);
  48.       batch = new SpriteBatch();
  50.       // create a Rectangle to logically represent the bucket
  51.       bucket = new Rectangle();
  52.       bucket.x = 800 / 2 - 64 / 2; // center the bucket horizontally
  53.       bucket.y = 20; // bottom left corner of the bucket is 20 pixels above the bottom screen edge
  54.       bucket.width = 64;
  55.       bucket.height = 64;
  57.       // create the raindrops array and spawn the first raindrop
  58.       raindrops = new Array<Rectangle>();
  59.       spawnRaindrop();
  60.    }
  62.    private void spawnRaindrop() {
  63.       Rectangle raindrop = new Rectangle();
  64.       raindrop.x = MathUtils.random(0, 800-64);
  65.       raindrop.y = 480;
  66.       raindrop.width = 64;
  67.       raindrop.height = 64;
  68.       raindrops.add(raindrop);
  69.       lastDropTime = TimeUtils.nanoTime();
  70.    }
  72.    @Override
  73.    public void render() {
  74.       // clear the screen with a dark blue color. The
  75.       // arguments to clear are the red, green
  76.       // blue and alpha component in the range [0,1]
  77.       // of the color to be used to clear the screen.
  78.       ScreenUtils.clear(0, 0, 0.2f, 1);
  80.       // tell the camera to update its matrices.
  81.       camera.update();
  83.       // tell the SpriteBatch to render in the
  84.       // coordinate system specified by the camera.
  85.       batch.setProjectionMatrix(camera.combined);
  87.       // begin a new batch and draw the bucket and
  88.       // all drops
  89.       batch.begin();
  90.       batch.draw(bucketImage, bucket.x, bucket.y);
  91.       for(Rectangle raindrop: raindrops) {
  92.          batch.draw(dropImage, raindrop.x, raindrop.y);
  93.       }
  94.       batch.end();
  96.       // process user input
  97.       if(Gdx.input.isTouched()) {
  98.          Vector3 touchPos = new Vector3();
  99.          touchPos.set(Gdx.input.getX(), Gdx.input.getY(), 0);
  100.          camera.unproject(touchPos);
  101.          bucket.x = touchPos.x - 64 / 2;
  102.       }
  103.       if(Gdx.input.isKeyPressed(Keys.LEFT)) bucket.x -= 200 * Gdx.graphics.getDeltaTime();
  104.       if(Gdx.input.isKeyPressed(Keys.RIGHT)) bucket.x += 200 * Gdx.graphics.getDeltaTime();
  106.       // make sure the bucket stays within the screen bounds
  107.       if(bucket.x < 0) bucket.x = 0;
  108.       if(bucket.x > 800 - 64) bucket.x = 800 - 64;
  110.       // check if we need to create a new raindrop
  111.       if(TimeUtils.nanoTime() - lastDropTime > 1000000000) spawnRaindrop();
  113.       // move the raindrops, remove any that are beneath the bottom edge of
  114.       // the screen or that hit the bucket. In the latter case we play back
  115.       // a sound effect as well.
  116.       for (Iterator<Rectangle> iter = raindrops.iterator(); iter.hasNext(); ) {
  117.          Rectangle raindrop = iter.next();
  118.          raindrop.y -= 200 * Gdx.graphics.getDeltaTime();
  119.          if(raindrop.y + 64 < 0) iter.remove();
  120.          if(raindrop.overlaps(bucket)) {
  121.             dropSound.play();
  122.             iter.remove();
  123.          }
  124.       }
  125.    }
  127.    @Override
  128.    public void dispose() {
  129.       // dispose of all the native resources
  130.       dropImage.dispose();
  131.       bucketImage.dispose();
  132.       dropSound.dispose();
  133.       rainMusic.dispose();
  134.       batch.dispose();
  135.    }
  136. }

Where to go from here

This was a very basic example of how to use libGDX to create a minimalistic game. There are quite a few things that can be improved from here on. Your next steps should most certainly entail looking at Screens and Games. To learn about these, there is a second tutorial following on from this one.