Project structure

Code for this tutorial is on this git branch:

git clone -b Base_project

Have a look here for help setting it up

We have the standard Libgdx projects, with all the code/logic being in the ‘core’ project, which then has wrappers – in our case, Desktop and Android. The other available options (we you can add yourself if needed) are for iOS and HTML5. If you are following this tutorial to make an iOS game don’t worry – it’s all still relevant.

N.B. I’m going to break down the structure of our project a bit, if you aren’t interested (or you would rather just work it out as you go), then you can skip over this tutorial without worrying about it.


You should have already run the DesktopLauncher and successfully run the game. The code is just a wrapper, with a little additional logic for setup.

if (packTextures) {
TexturePacker.process(settings, assets_general + "images", assets_android + "atlas", "main");
settings.duplicatePadding = true;
TexturePacker.process(settings, assets_general + "tiles", assets_android + "atlas", "tiles");

This code gives you a hint of a future tutorial – atlases. This is the way we do graphics – pack our graphics into an atlas, then load this atlas when we want to load images in the game.

This code snippet does not run currently, because packTextures is set to false. We also aren’t loading anything from atlases in game – yet. We’ll come back to it.

Core project

The core project is where all of our in-game code is going to be. Anything specific to Android/iOS should live in those respective projects (e.g. achievements) – anything they all have in common should be in core.

You may have noticed in the DesktopLauncher that we created a new instance of MainScreen and passed it to new ‘application’ we’ve created.


Here we set up our InputProcessor (PlayerInputSystem), our Stage and our Renderer (GameScreenRenderer). We also have more references to our graphics atlas – again, we’ll come back to that in a later tutorial (when we start adding some graphical elements to our game). We also have a GameController where we will keep logic for what is going on in the game. For example, we will control our zombies from here.

Input Processor – PlayerInputSystem

This is where we respond to key-presses, screen touches, the back button being pressed etc. If you have a look, you can see that you implement the InputProcessor interface, and add logic to any of the methods that you want to capture.

Renderer – GameScreenRenderer

This is where we draw all our graphics. Libgdx will keep calling the render method in our MainScreen, and from there we call the update method in our GameScreenRenderer to make sure all graphics are updated.


This is pretty bare at the moment, but we’re going to have any logic which needs running in here. For example, loop through all our zombies, work out which should be moving, work out where they should move to – this can all be controlled from within the update method, which will be called by the MainScreen every time render is triggered by the game engine.

It’s the interaction of these three elements which run the core of our game, updating logic, updating graphics, and responding to commands from the player.

The rest of it we’ll work out as we go. Notice that we’ve structured the packages of the core project to try and separate things into their logical components.

Next time we will take a closer look at one of these logical components – the map generating functionality.

If you like these tutorials, or want to see a game that was written in much the same way, please download Dinowar from the Google Play Store. It costs nothing and is ad-free.

Setting up the project

The first few tutorials will work like this: we’ll provide you a sample project, and explain the various aspects of how it works.

From there, we’ll guide you through building new features and enhancements on to the game.


We have written a little helper project, which you can find at It contains a template layout for setting up a Libgdx application, as well as various utility functions.

We install this via gradle, which you will need on your machine. Once you have got that, run the following commands:

git clone
cd MyGdxClasses
gradle install

Getting the source code

We are assuming you’re familiar with Git. To directly check out the example project, run the following command:

git clone -b Base_project

This checks out a specific branch for just the Base_project – in future we’ll check out different branches to see different examples.

Android Studio

We created this tutorial in Android Studio, and all examples are going to assume that is your IDE, but in reality most stuff should be the same with other IDEs. This may vary when it comes to exporting the project to Android or iOS.

We’re assuming you have Java set up properly on your machine – this tutorial isn’t going to cover that.

Once you’ve checked out the code and opened Android Studio, choose ‘Open an Existing Android Studio project’ and locate the project.

Run configurations

Start the game by opening the file ‘Desktop Launcher’ and Run. This will probably fail first time, but that’s just because we haven’t set up the run configuration yet. Click the down arrow next to ‘DesktopLauncher’ to open it up.

Screen Shot 2016-07-09 at 18.37.38

Make sure you have the following settings:

Main class:

Working directory:[path]/zombiegametutorial/android/assets/

(for example, on my Mac the path is /Users/dave/git/zombiegametutorial/android/assets/)

Use classpath of module: Desktop

Now try running the game again. If all has been set up correctly, you should see something which looks a bit like this:

Screen Shot 2016-07-09 at 18.41.33

If you see this – success!

What am I looking at?

This is the base project, which is just a randomly-generated map. At the moment, there’s not much you can do here. Try navigating around with the arrow keys, try zooming in and out with the Z and X keys.

Also – try pressing R to regenerate the map. Neat eh?

Why does it look so crap?

We haven’t provided any logic for drawing edges properly, so it looks quite blocky at the moment. You can decrease the ‘blockiness’ by changing a couple of parameters.

Open up and look for:

float viewWidth =32;

Try changing the value to something bigger, and you can see the effect. Have a play around with the other variables in there and see what happens. You can make it look like this:

Screen Shot 2016-07-09 at 18.51.59

Why wouldn’t you just make it really high-definition? Well, further down the line we’re going to introduce some path-finding. Each block on the map is a node, and the higher number of nodes, the slower it is going to be to generate paths. This is a real issue we came across when creating Dinowar, so we had to find a balance between the detail of the map and the speed of path-finding on a mobile device.

But in the end, you can make the map look a lot better by drawing edges properly:

If you like these tutorials, or want to see a game that was written in much the same way, please download Dinowar from the Google Play Store. It costs nothing and is ad-free.

Creating a 2-D Zombie shooter

The game that we are going to create in this tutorial is a top-down, 2-D shooter. Like Dinowar, it will feature randomly generated maps. The idea is for the player to spawn at a random point on the map, and have to make their way to another point on the map.

In the way of the player will be a number of zombies. When the player gets within a certain range of a zombie, that zombie will run at the player. We can choose to have the zombies run only in a straight line, or we can choose to have them run around things in the way (e.g. water).

The player character will always be central in the screen, and the camera will follow them. When the user touches somewhere on the screen, the player character will walk to that spot.

When zombies run at the player, the user can touch a zombie to fire a bullet at it. If the bullet hits, the zombie dies. If the zombie touches the player, the player loses health.

Screen Shot 2016-07-09 at 18.21.20

Sounds simple? Then move on to the next post to get started.

If you like these tutorials, or want to see a game that was written in much the same way, please download Dinowar from the Google Play Store. It costs nothing and is ad-free.

Welcome to our new Libgdx Tutorials

Approximately a year ago, we (Dave and George) were big fans of an Android game called Archipelago. This was a simple game in which a player controls islands, and sends planes from island to island to capture more. The player had to fight against 2-4 AI players, with the objective being to control the map.

The two of us decided that this game could be improved upon, and as we both come from a technical background and both enjoy programming, we would have a stab at it.

We settled on Libgdx as the right framework for our needs, and set about creating the game. The main reasons it took so long were (in no particular order) our inability to focus on one project at a time, our jobs, and our struggles to make the game actually look nice.

But we have finally (a couple of months ago now) released Dinowar for Android, written with Libgdx:


We’ve now decided to write some Libgdx tutorials in order to help others who might be interested in writing a similar game. Throughout this tutorial series, we will write a game which features a lot of the same gameplay as Dinowar, while trying to avoid adding unnecessary complexity. Some of the features of this series will be topics that we had to research and implement during our time developing Dinowar:

  • Random map generation
  • Efficient path-finding
  • Creating in-game tutorials
  • Rendering fonts
  • Creating and using atlases for graphics
  • Using Overlays for GUIs
  • Adding achievements and leaderboards
  • Developing AI which is engaging to play against