A few days ago I made an introduction to the framework we are using to develop the game (libGDX), we set up a workspace, spoke about the game we are going to develop and managed to go through a bit of code that renders the background. If you haven’t already done so, I suggest going through part I before continuing with this one.

In this part of the tutorial we will implement most of the game’s features! I can feel the excitement already!

Before we begin, make sure you set up your assets correctly, like so:

eclipse

Let’s go ahead and try to draw some food on the screen, shall we? First, we need to create our Food class so we can create objects out of it. Create a new class in the model package called Food.java:

This class has 3 attributes. The first two (Size and rectangle) will directly influence the Food objects and the third one (ArrayList) will be used to manage our objects. Keep in mind that it is not a good practice to manage the objects from their own class. I did this just because it is easier to explain how it works, but don’t worry, we will modify the code as we go and make it look better.

Notice that I said that the SIZE is 1.0f and in the constructor I multiplied the value by Gdx.graphics.getPpcX(). This means that the size of the food rectangle will be 1 unit long. PpcX() means pixel per centimeter on the X axis. This is very handy because if we have a screen with a different resolution because the rectangles will be scaled accordingly.

The class also has a method addFood() which will create a new rectangle based on the specified position and it will add it to the list. The others are getters and setters.

Now that we have our food class, let’s go ahead and create objects out of it and draw them on screen. To do this, we have to modify our GameRenderer class:

We made quite a few changes in this class, so I added some comments in the code to help you understand how it works. The most confusing part for you might be the atlas so I will talk about it a bit.

If you go inside assets>models you will see that there is a sprite sheet containing all the images models.png and a *.pack file models.pack (there are also the individual images with the food but they can be deleted, I forgot to do that after I created the sprite sheet). The pack file contains all the information needed for the atlas to extract the images from the sprite sheet. Notice that in order to get a texture for the goodTexture variable I used the atlas to get me the region called “food0” which is the name of the first good food item in the sprite sheet. This is a great libGDX feature – it makes things simple. In order to create a pack file you will need a tool that libGDX offers called TexturePacker. You can follow the link and download it but make sure you check how to use it. I’m not going to get into details about that here.

So can you guess what our game will do now? If you look in render() you can see that after each second, a new food item will be added to the list, after that we check if the touched area is inside a food rectangle and if it is remove it from the list, then the game will be drawn. I created the drawFood() method to keep things clean. All the method does is to go over the list and draw all the food items currently in there using the texture that we got from the atlas.

If you run the game now, you should be able to see the food appearing on the screen, and if you touch it it will disappear. We are getting closer, right?

foodgame

Let’s think a bit about how to proceed and what we’ll need for our game next. The game should have different types of food, right? So the Food object can have different states; it can be Good, Bad or Covered. Keep in mind that the covered food cannot be picked until the food gets uncovered, so we will need another state for that to be able to award extra points, so another state will be uncovered. Also note that only if the uncovered food is good, the user will get those extra points. If the food is bad, the player will lose a life.

Another important thing we will do is to implement a handler class that will take care of our food objects. That means the GameRenderer will communicate with the food objects through the handler. It is a good practice to do this and it will make our application more organised.

First, let’s go ahead and modify our Food class:

There are a few changes here. You can see that now we have a state for our objects and a texture index. This index will be used to give each object a texture. We have 5 textures for each type of food to make the game more diverse. It is set to -1 and that means that it has no texture at first. The SIZE is now 0 because we will implement that scaling feature to make the game more interesting. If you don’t know what I’m talking about, make sure you watch the video in the first part. We also added two new getters and setters for the index and state. Also notice that we don’t have a list anymore; that’s because we are going to implement a handler class that will take care of that.

Let’s go ahead and create our handler class (which will be a singleton) . Create a new class in the model package called FoodHandler.java:

This class being a singleton will restrict the instantiation of objects to one which is the right thing to do when we have a class that handles entities. It is not necessarily useful in this small game, but if for example we need to get access to the same list of food items in multiple classes, then the singleton pattern is the best approach.

In this class we have the array list of food items as an attribute that has a getter and setter, we have a method getInstance() that will return our handler object, a method used to add food based on a position and state, and an animate(delta) method which will scale our food with the value delta passed to it. If the food will be bigger than 1.2 units, then it will be removed from the list.

Now it’s time to update our GameRenderer class. Since this class will be quite long I will post the methods separately and explain what each does.

These are the global variables:

 

We update the loadItems() method:

Notice that we have Arrays of textures for the good food and bad food (5 each).

Now we update the render() method:

We made significant changes in this part of the class, but don’t worry, I will go over it and explain how it works. Let’s divide this into sections:

  • Adding the food to the list

In the first part of the method we are adding food to the list by calling the addFood() inside the handler. We are specifying the position (which is random) and the state of the food. Also notice that we have 3 timers (timeGood, timeBad and timeCoveredAppearance). These timers are used to add new food at certain intervals of time(we don’t want to add food every frame, do we?).

  • Animating the food

In the next part we “animate” the food by calling the animate() method inside the handler. The value inside the brackets specifies how fast the food grows. Next we check if the covered food reached a certain size (0.8 units in this case) and if it did then we change its state to either GOOD_UNCOVERED or BAD. Notice that I used a random value (rand) to choose between states.

  •  Collision detection

This is the part where we check if the touched area hit the food. To check this, basically we check if the touched location is inside the rectangle we used to draw the food in. We get the rectangle bounds by calling the getters inside the Food class, getBounds(). You probably noticed that we don’t get the touch coordinates anymore. We actually do that, but not here; we’ll get to that in a moment.

 We go over the list and if the player touched any food inside the list then we act according to the food state. If it’s GOOD then we award one point and remove the food from the list, when is BAD the user looses a life and the food gets removed from the list, when the food is COVERED nothing happens and if it’s GOOD_UNCOVERED the player gets 10 points and the food gets removed. At the end we update the list using the setter inside the handler and then check if the user still has lives. If he doesn’t, then the game will reset and the resources will be disposed. Here is the dispose() method (add this at the end of the class):

  • Drawing

The next area is where we draw the models on screen. The only new thing here is the drawing of lives in the top right corner.

And now let’s see the drawFood() method:

As you can see, the method changed a lot, but it is very simple to understand. We go through the items in the list, check if a texture has been assigned (remember the textureIndex attribute in the Food class), assign a texture if the food object doesn’t have one (a random number between 0 and the length of the texture array) and then draw the food according to its state.

The last thing we have to add is a setter for the touchedArea variable. Yes, we are going to set the value from outside the class.

And that’s it! The GameRenderer class is ready. To make sure everything is in order I included the whole class here:

Now in order to get the coordinates of the touched area we will need to update our GameScreen class. We will make it implement another interface called InputProcessor that will create some new methods for us. Here is the updated class:

The new methods are implemented by the new interface (InputProcessor), but we only use the touchDown() and touchUp() methods. in touchDown() we set the touched area to the coordinates where we touch the screen (note that the Y axis is inverted and that’s why I had to substract the touched Y out of the total height of the screen). In touchUp() we set the coordinates to an area outside of the screen. We also need to enable the input processor by adding this line inside the show() method:

Now you should be able to run the game and see all the changes. If you get errors make sure you check your code again and if it still doesn’t work let me know in the comments.

foodgame with libgdx

This part was a bit long so if you have any question about anything let me know and I will try my best to answer. In the next part we will make this game pretty by adding sounds, effects, fonts and a menu screen and an ending screen. The third part won’t be so long, but it will be very interesting to see how much you can do with several lines of code.

Until next time!