Menu Close

Introduction to Mobile Game Development using libGDX & Kotlin | #1

I’m telling you about the fact why I use libGDX as a mobile game development framework and Kotlin as a programming language. In short, libGDX is just a great framework and Kotlin is a very smooth and concise language / alternative to Java. In the following posts I will tell you what you have to think of (at least what I think you have to think of), before you start creating your (maybe first) cross-platform mobile game.

About the Game Development Framework you choose

If you do not already have a preferred game development framework, you should compare the pros & cons of the most common ones. For example, there is Unity, Unreal Engine and libGDX, which are all free to use. But the Unreal Engine 4 requires you to give a 5% royalty if you have more than $3,000 of revenue per product per quarter.

libGDX is an open source cross-platform game development framework, maintained by BadLogicGames. It is contributed by many (358 contributors on GitHub repo).

  • The project is Java based which it perfectly for Android developers to start building games with.
  • Due to the cross-platform feature, it is possible to build your game easily for Android, Windows, Linux, OS X, HTML (WebGL) and iOS (using for example the open source Multi-OS-Engine). iOS (especially if you do not work on a Mac) might be it a bit tricky, but I managed to get it working on an iPhone / iPad device.
  • You are completely free to do what you want, there is no official game structure template, for better or worse.
  • The framework has many extensions, like the physical engine Box2D, network and assets management APIs and many more. You also have access to the low-level openGL methods if you want to use them.

Unity on the opposite to libGDX, is a closed source project, which means that there might not be as many free contributors. But Unity is still heavily developed on and continuously improving and extending its features.

  • The project is C# (C Sharp) / JavaScript based, former is quite similar to Java and has some additional features (for example it is deeply integrated into Windows, if that is what you want).
  • There is a very huge amount of possible targetable platforms (many more than libGDX supports). You are able to build your application for iOS, Android, Windows, OS X, HTML (WebGL) and even to the Play Station 4 or virtual reality players like Oculus Rift, Steam VR or Microsoft Hololens. (See the whole list here)
  • In most cases the free version of Unity will be enough. For those who want more customization (own splash screen or higher revenue cap than $100k in the free version) there is a Plus-Plan or Pro-Plan.
  • One main feature is the GUI editor, which allows you to drag and drop stuff like game objects. So you do not have to write that much (or even no) code for your first game.

I think you will not be wrong choosing either of the two frameworks (or other, just use Google search and you will find plenty). If you want to build the next Pokemon Go (which requires you to do some virtual reality related work), my recommendation is Unity, like for any 3D game. The libGDX framework is a good choice to build 2D games, for example the next Doodle Jump or Flappy Bird.

The idea is the key

Like for every product, if the idea / concept behind the product is bad, you (most likely) can not make it successful. I, for myself, just liked the idea of creating my own game. I really had the dream since I was a young teenager. The feeling of finishing or just working on creating a game is great, so just start with it.

 


 

This is how my example game “Splinter Sweets” looks like on a Linux desktop:

splintersweets-linux-desktop-spawn

 

The game looks and behaves the same way on every platform. This is achieved using the libGDX framework.

splintersweets-desktop-linux-hit

 

On a iPhone 7 device:

 

Leave a Reply

Your email address will not be published. Required fields are marked *

twenty + 5 =

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