Choosing KTX

Should I use KTX?

As a libGDX and Kotlin user

If you plan on using libGDX along with Kotlin, then yes - definitely.

libGDX comes without native Kotlin support. KTX tries to address this by providing a wide range of fully tested utilities for various parts of the framework, some of which you would probably end up writing yourself from scratch. With detailed guides and a smooth learning curve, KTX will speed up your development if you are already familiar with libGDX and Kotlin.

As a libGDX user

If you are currently using libGDX with Java, give Kotlin a try. Kotlin might boost your performance with features such as nullable types, operator overloads, lambdas, inline methods, reified types, coroutines, type-safe builders, extension methods and many others, many of which are fully leveraged by KTX. With its modern design and pragmatic approach, Kotlin honestly feels like Java 2.0 - and by extension, KTX might feel like libGDX 2.0 as well.

As a Java programmer

If you are new to libGDX and Kotlin, but want to try out both, KTX tutorials are not a bad place to start. With IntelliJ's Java-to-Kotlin translation, as well as seamless Java and Kotlin cooperability, you could easily follow libGDX tutorials in Java and gradually rewrite them to Kotlin, which is a great way to learn the language.

libGDX is among the best 2D game frameworks in the Java ecosystem, so if you want to use your JVM experience to create games, KTX is not a bad choice overall.

As a gamedev enthusiast

In other cases, this question comes down to should you use libGDX?

libGDX is one of the most widely used open source Java game frameworks. Unlike most popular full-fledged game engines, it lacks a visual editor and instead works as a library that focuses on providing utilities and abstractions that ease game development. Let's explore some of its advantages and disadvantages.

The good

• Battle-tested APIs used in a wide variety of published games. Being the most popular Java game framework for a while, libGDX was used and tested by many game developers.
• Wide range of utilities, including rendering, GUI, SFX, shaders, assets management, animations, entity-component-systems, AI, multithreading and physics, among others.
• Good mobile support. Especially performant Android backend.
• Freedom of building the engine tailored to fit your game.
• Wide variety of on-line tutorials and books.
• Can leverage Java standard library and ecosystem.
• Customizable and relatively close to the metal. Can be very performant, despite Java's bad rep.
• Decent 2D support.
• Remains among the best options as far as JVM game frameworks and engines go.
• Has an entire ecosystem of official and third-party extensions such as the KTX itself.
• libGDX is completely free and open sourced.

The bad

• Lack of a visual editor. The code-centric approach might be appealing to some, but arguably it requires much more time and effort to actually develop and release games compared to the game engines such as Unity or Godot. Relies on third-party editors such as Tiled or Spine.
• JVM is an arguably questionable choice for games. Garbage collection can cause problems on slower machines and mobile devices. Manual resource management and pooling often produces non-idiomatic Java and Kotlin code.
• Moderate-sized community.
• Relatively slow core framework development. The libGDX framework is pretty stable, but it is not as actively worked on as it used to be. The original main developer seems to have stopped contributing and managing the releases.
• Bare-bones 3D support. It is simply not the best fit for 3D games.
• Lack of commercial support.

The ugly

• Lack of rigorous tests. This is partially addressed by KTX, which provides extensive unit tests for each of its modules.
• Varying code quality. Some APIs are poorly designed and implemented. As an example, libGDX introduces custom collections, which do not implement Java standard library interfaces or any kind of common interface, which makes them inconsistent and difficult to work with. Some Kotlin collections utilities will not work out of the box with libGDX collections, or will use the generic Iterable implementations instead of the versions optimized for specific collection types.
• Some decisions made in the name of performance are considered bad practices and might not provide any notable improvements nowadays on modern platforms. Examples of this include exposed public mutable fields like the collection sizes, which can be misused to corrupt the internal state of the objects. Accessing fields directly used to be faster to access than relying on getters and setters, especially on mobile platforms, but on modern JVMs this is no longer a problem.
• The official HTML/WebGL backend relies on GWT and works only with a subset of Java. Some third-party backends support web with other languages to a varying degree.

Summary

libGDX is probably the best fit for custom 2D mobile games. Compared to similar frameworks that target mobile platforms exclusively, libGDX might speed up the development with its fully supported desktop backend.

KTX is a good choice if:

• You are already familiar with libGDX and plan on using Kotlin to develop your applications.
• You are familiar with Kotlin and want to use it for game development.
• You need the relatively low-level abstraction of a game framework rather than a complete engine.
• You plan on creating mobile 2D games that need a performant game engine.
• You want to learn Kotlin or improve your skills with a cool hobby project.

You might want to choose a different game framework or engine if:

• You want to speed up game development with a visual editor.
• You plan on creating browser or 3D games.
• You do not want to deal with JVM and need something very close to the metal.
• You do not enjoy Kotlin as a programming language.

The only instance in which you might have to use libGDX with Java rather than Kotlin is when you'd like to target the official HTML/WebGL platform with the GWT backend. But then again, since GWT is pretty convoluted and difficult to debug, there are better frameworks for browser games out there.

---

Note that there really is no single best choice. Each framework and engine comes with its costs and downsides. The final advice is to focus less on tools, and more on game development. As you get familiar with a framework and game development principles, you will be productive regardless of your technology choices.