Choosing KTX

Should I use KTX?

If you already use or plan to use LibGDX along with Kotlin, then yes - definitely.

LibGDX comes without native Kotlin support. KTX tries to address this issue 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 usage guides and a smooth learning curve, KTX will speed up your development if you are already familiar with LibGDX and Kotlin.

If you are currently using LibGDX with Java, give Kotlin and KTX a try. It 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, most of which are fully leveraged by KTX. With its modern design and pragmatic approach, Kotlin honestly feels like Java 2.0 - and KTX might feel like LibGDX 2.0 as well.

In other cases, this question comes down to should I use LibGDX?

LibGDX is one of the most widely used open source Java game frameworks. Unlike most popular 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 variety of on-line tutorials and books.
• Good mobile support. Especially performant Android backend.
• Wide range of utilities, including rendering, GUI, SFX, shaders, assets management, animations, entity-compontent-systems, AI, multithreading and physics, among others.
• 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.
• An ecosystem of official and third-party extensions such as the KTX itself.

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 poor choice for games. Excessive 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, shrinking community.
• Slow framework development, increasingly rare releases. The framework is relatively 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 not the best fit for 3D games.
• Lack of an asset shop.

The ugly

• Some APIs are poorly designed and implemented. Examples of this include custom collections, which do not implement Java standard library interfaces, nor do they follow any kind of common interface, which makes them inconsistent and difficult to work with. Its modules have varying code quality.
• Some decisions made in the name of performance are considered bad practices and might not provide any notable improvements anymore on modern platforms. Examples of this include public mutable fields, which used to be faster to access than relying on getters and setters.
• Lack of rigorous tests. This is partially addressed by KTX, which provides extensive unit tests for each of its modules.
• The official HTML/WebGL backend relies on GWT and works only with a subset of Java.

Summary

LibGDX is probably the best fit for custom mobile 2D games. By supporting other platforms - including desktop - it can speed up the development compared to mobile-only game frameworks.

KTX is a good choice if you:

• are already familiar with LibGDX and plan on using Kotlin to develop your applications;
• are familiar with Kotlin and want to use it for game development;
• enjoy the relatively low level of abstraction of game frameworks and need full control over your application;
• plan on creating mobile 2D games that need a performant game engine;
• 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;
• plan on creating browser games;
• want to create a 3D game;
• do not want to deal with JVM and need something even more low-level.

Note that there really is no single correct 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 basics, you will be productive regardless of your choice.