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.