A little about the LibDGX framework
Have you ever wanted to create a game from scratch? If so, then LibGDX might be the framework for you. It provides cross-platform support and runs on JVM, however, if you want your game to run on consoles such as Xbox or PS4 that will probably never happen, since they don’t support JVM.
I would recommend this framework to anyone who likes to code a lot and create 2D games. 3D is also supported, but it requires much more knowledge. For any Java fans, this framework is mainly Java-based, but it also supports Kotlin, Python, and a few others.
Starting out?
When I started out using GDX I had some basic knowledge in creating a game. I learned a lot about GDX from a book called Learning Libgdx Game Development by Andreas Oehlke, which I’d strongly recommend if you want to try out this framework and have no prior knowledge in creating a game. It will take you through it step by step. I chose GDX because I didn’t want to use a complete engine, like Unity or Unreal Engine, and I became quite a fan of it.
If you are doing this by yourself, your first step would be to stop and think about your skills. Are you more of a programmer or an artist? If you’re a programmer, try to challenge yourself more in the functionality part of the game instead of trying to make it the best looking game out there. An artist, perhaps? If so, then try not to stress yourself out with too much coding and make the game as simple as you can, focusing on the game assets making it look good. You will find that it is not so hard to begin creating prototypes, it’s providing enough or extra game content, polishing and removing bugs that will take most of the time. Don’t try to fool yourself into believing that it won’t be a challenge if you are new at this. I would recommend that your first game is not too big, especially if you don’t have an exact idea of what will your game be like. Use it as a learning project, not the actual release game that will make you rich. Test your skills first.
Short presentation of code
ApplicationAdapter is just the implementation of ApplicationListener, which is an interface for your application. The only difference between the two is that if you use Adapter you do not need to implement all methods. They are empty anyway and it is up to you to handle them.
This code creates SpriteBatch, loads an image as texture and renders it on the screen. Don’t forget to dispose SpriteBatch and texture. And if you want to move this image, you just do this:
It’s that easy!
Game Object
But, of course, you will want to have some sort of structure for your game object. I usually create an AbstractGameObject class that provides the basic functions and properties of my game objects. Example:
Now you could extend a new class from AbstractGameObject and give it a texture, then render it in your game.
TexturePacker
TexturePacker is a tool for LibGDX that can join your images together to create a texture atlas that you can read from in the game. This means that it will create one image, a JSON file with an atlas file extension containing locations of joined images on the atlas image. It is always recommended to use an atlas because it saves space in the RAM, taking up the space of one large image. So, for instance, for the game menu you could use an atlas containing the background image, buttons and other elements.
Animations
There are a few approaches you can take to create animations in your game:
First approach:
One would be to create multiple sprites of your character and create an atlas with them. Animating them in this way would be fairly simple, depending on how much you want your characters to move.
You could also use a tool to animate moving and rotating elements of your images, something like Spriter.
You must take into account the RAM usage your game might have if you do everything this way. The more characters you have with multiple animations of higher resolution might be too RAM consuming. That is why a lot of game developers and animators use this second approach, at least for characters.
Second approach:
You can use something like Spriter or Spine, which are 2D bone-based animators. To animate your character you will need to layer it separately (hands, feet, body, head…) and import it into the animator tool. They both support LibGDX with their runtime implementations and they allow you to move, rotate, and scale parts of your character for easier animation editing. These usually export assets into something like an atlas and write animation data to a file. You will need to add these two files to your game and then use the provided runtime implementations in your game code.
Keep in mind that this will reduce RAM consumption but will increase CPU usage. One of the most consuming operations is scaling, so try not to do too much image scaling in your animations if you intend to render many of these objects on the screen at the same time. But you can always test where the limit might be for your specific case.
One tip:
Rendering on SpriteBatch takes time, so if you want your game world larger than the screen you will probably be using OrthographicCamera class. This class allows you to move the camera to achieve scrolling, instead of moving game elements. That said, you might want to check if the game object is visible on camera, otherwise you will not want to render it in the batch.
You can check out one of my simple projects on GitHub: https://github.com/stickymadness/libgdx-tutorial-demo And don’t worry about the missing AbstractGameObject – I used only one game object to render on screen so I didn’t think it’s necessary.