Full LibGDX Game Tutorial – Game Mechanics

Sharing is caring!

Full LibGDX Game Tutorial – Game Mechanics

Welcome to part 12 of our Full LibGDX Game Tutorial. This part will focus on adding some game mechanics such as springs for jumping higher, a scoring system and DEATH. If you haven’t seen the earlier parts of this tutorial I advise you to start at Full LibGDX Game Tutorial – Project setup as this tutorial continues from these earlier parts. For those of you who have come from part 11, you can continue on.

In the last part of this tutorial we added the simplex noise generator to our game and then used it with a level generator to create levels. In this part we will start with adding a Utils class which I stole from one of my other games which has some static methods in when can be reused in other games. We will also add a mechanic to generate bouncy springs on some of our randomly generated platforms and finally and a score and death mechanic.

Game Mechanics – Adding a utility class

Firstly lets add the Utils class so we can access then in our project.

The Utils class has some useful methods such as converting HSV colour values to RGB and Creating textures at runtime. We will be using the ones that generate textures at runtime so we can create placeholders for our entity images instead of having to create nice textures. (mostly because I suck at drawing)

Game Mechanics – Adding Springs

Now we have our Utils class lets get on with the game mechanics. We want to add some springs to some of our platforms so we will update our levelFactory’s generateLevel() method so it will use an extra 2 noise values to check if a platform should have a spring on it.

Here I have added noise5 and noise 6 to be the deciding factor for springs on platforms. I have also added noise 7 and 8 for future use. In the if conditionals I have added another if conditional for noise 5 and noise 6 and if the values fall in range we createBouncyPlatform(). Lets create that method now.

This method simply adds a small cube in the middle of the platform, sets it to a sensor so it doesn’t block the players movement and sets its type to SPRING. This type setting is important as we check for this value in our collisionSystem already, and now all we need to do to react to the touching of springs is check for it in our collisionSystem and update the player.

Our collisionSystem needs to be updated to:

In the collisionSystem we check if the player has hit a spring and if they have, we set the player onSpring to true. The last thing to do to get the player to jump from a spring is to actually make the player jump. This is done in the playerControlSystem with a simple if conditional.

Here we have added a force to the player to make the go upwards and set their state to jumping so the player can’t jump again. We then reset the onSpring flag so the player isn’t continuously getting shot upwards.

Game Mechanics – Increasing Water and DEATH.

Now let’s add the death mechanic. The player will die instantly the moment they are touched by the water coming from the bottom of the world. To do that we first need to add the water and the first part of that is to make the waterFloorComponent.

This component is simply here to identify the water. The next thing we need to do is to make a system that moves this water upwards at an ever increasing speed and that system is this:

We also need to add this to our engine like all other systems in our MainScreen class:

Here we have added the WaterFloorSystem and added the player as an argument. This is because we want to increase the speed of the water the higher the player gets so the game becomes more difficult the higher you get.

The waterFloorSystem can now control the increasing water but we haven’t created the water yet. We need to ad a method to our LevelFactory that creates and entity that can be moved and that method is:

Things to note about this is that we make the waterFloor a KinematicBody. This is a box2d body type that says this block will be moved using code and should not be effected by gravity. We also set the type to ENEMY so that if our player hits this they will be killed.

All that’s left to do is to add a call to this method to create the water floor and we will do that the same place we create the normal floor in our MainScreen method. Update your MainScreen code to this:

Here you can see we started using the DFUtils class to make some images using some HEX values instead of creating images and loading them in. You will also notice we use the PPM constant form the RenderingSystem. You will have to make this field public in the RenderingSystem class so we can access it in the above code.

Currently all that happens here is that when the player hits the water it writes “player hit enemy” and we want it to actually make the player dead. To do that we need to add a field in the player component. A simple boolean isDead = false will do. Once you have added that we can updated our CollisionSystem to flip this to true if the player hits an enemy with this code:

In this code we have flipped the isDead flag for the player so they become dead and as a bonus we also added some code to print out the score which is derived from the height the player got to before they died.

Once you are finished you should end up with something similar to this when you start your application:

Game Mechanics Expected Output

As usual the complete code up to this part is available from StorMyVids. The next part, Part 13 will go over the enemy system and how to add them to our game.

If you find mistakes with this article or have some improvements please leave a comment below

← Simplex Noise and Level Gen Contents Ashley Enemy System →


Sharing is caring!

15 Replies to “Full LibGDX Game Tutorial – Game Mechanics”

  1. diPassaggio says: Reply

    Thanks for your work, the part 13? 🙂

    1. Part 13 is about the adding enemies. I have updated the post with the link to the next part.

  2. Thank you very much, John.

  3. Caterpillar says: Reply

    Hmm, everything is pretty much working for me. Except the player when jumping is SUPER jittery.

    For some reason also, your jumping code for player movement is set to 75, for me that is way too high. Is it our screen size/resolution differences that account for that? Same with the spring code.

    Also. For some reason the Player Character can continue to jump after they have started falling. I’m not sure if that is intentional or not? I’ve gone over both the code I wrote following this, and the code you provide. I am sure I’ve dotted all my i’s and crossed my t’s, but I imagine others aren’t having the same problem I am, otherwise I think I’d see more comments.

    Not sure what’s going on.

    1. Caterpillar says: Reply

      Ah I figured out why the jumping code was 75 and spring 175, I had changed my STONE attributes.

      It’s just the jittering I can’t get rid of now. Before the Ashley ECS everything ran pretty smooth. I’m liking components though, I am thinking up some cool uses for them.

      1. jittering could be caused by low FPS. What sort of FPS are you getting when you run the app?

        1. Caterpillar says: Reply

          Uh, not sure what FPS I get, but this is using the GPU isn’t it? I have a quad core hyperthreaded 4770k, and a 4GB Nvidia GPU.

          So the computer isn’t the problem. I’m still going through the code again to see if I made a mistake. How would I go about getting a FPS count anyway? Is that fraps you were using in the picture? It works with this?

          Also I was wondering. Can Ashley be used to create background systems, like for a crafting system with components, for building modular weapons, or setting up attributes and skill systems, and then attach them to Scene2D’s actors/actions/stage?

          1. I use Nvidia’s GeForce Experience to show FPS.
            As for Ashley, you can use it however you see fit. The component-system does fit well with a modular item system.

          2. Might be a bit late, but I noticed I had the gittering too. For me the solution was to change the order of adding systems to the engine.

            engine.addSystem(new AnimationSystem());
            engine.addSystem(new CollisionSystem());
            engine.addSystem(new PhysicsSystem(lvlFactory.world));
            engine.addSystem(new PhysicsDebugSystem(lvlFactory.world, renderingSystem.getCamera()));
            engine.addSystem(new PlayerControlSystem(controller));

            I’m not sure if the framework is “ordered” like this, but I would think that rendering should happen after all other systems did their thing.

            Hope this helps.

          3. Building on JohannisK reply, the issue is that the PlayerControlSystem comes after the renderSystem. Using the renderSystem at the end makes it so that the enemies are not removed when hit, instead it takes a few frames.

            What I have:
            engine.addSystem(new AnimationSystem());
            engine.addSystem(new PhysicsSystem(lvlFactory.world));
            engine.addSystem(new PlayerControlSystem(controller, lvlFactory));

  4. Caterpillar says: Reply

    There somewhere I can send you a video of what it;s doing?

    1. You could put it on youtube and post the link here

  5. How can we add images to the floors?

  6. //player = lvlFactory.createPlayer(atlas.findRegion(“player”),cam);
    //engine.addSystem(new WallSystem(player));
    //engine.addSystem(new WaterFloorSystem(player));

    el player lo declaro de que tipo?
    de donde sale la clase wallSystem? me sale error
    el metodo createWalls?

  7. Hi my game doesn’t work when i add the water, i think there something wrong into createWaterFloor method, and i don’t know what put into createWalls method, also i visited your github for have some answer, but the levelfactory class is missing, please i need help, answer me as soon as you can.
    Best regard Stefano

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.