LITIENGINE: a Java 2D engine with a map editor

A library and an editor, not just an engine

LITIENGINE is described as a free and open source Java 2D game engine, and the thing it provides is a full Java library and a dedicated map editor to create tile-based 2D games.

The map editor is the part that distinguishes it from a rendering library. Tile-based 2D work means authoring a grid of tiles, with layers, object layers and collision volumes, and doing that in an engine that also renders and simulates means the editor has to agree with the runtime about the file format. LITIENGINE's answer is .tmx, the format of the Tiled Editor, so a map you make in Tiled opens in the engine, and there is a dedicated editor of its own for the same job.

The feature list reads as a complete engine rather than a set of utilities. Basic game infrastructure covers the game loop, configuration, resource management and logging. The 2D render engine covers GUI components, spritesheet animations, ambient lighting and a particle system. There is a 2D sound engine supporting .wav, .mp3 and .ogg, a 2D physics engine, support for tile maps in .tmx format, player input via gamepad, keyboard and mouse, and an entity framework.

The project is Java, MIT licensed, on the main branch, with the site at litiengine.com. The last push was on 2026-10-18, and the releases are 0.10.7 in November 2024, 0.11.1 in December 2025 and 0.12.0 on 2026-06-02.

It is written by two Bavarian brothers known as gurkenlabs, Steffen Wilke and Matthias Wilke, and the repository carries a CITATION.cff, which is a small sign that a research or academic use of the engine is expected.

The layer list tells you what the engine covers

The main features list is short, and each line covers a subsystem you would otherwise have to source separately.

Game infrastructure is the foundation layer: the game loop that drives update and render, configuration, resource management and logging. Everything else in an engine is a consumer of that loop, and having the loop, the logger and the resource cache in one library removes a class of integration problems that are tedious rather than hard.

The render engine is the part that decides what a 2D game looks like. GUI components for menus and a heads-up display, spritesheet animations, ambient lighting, which is a 2D lighting model rather than a shader trick, and a particle system. The sound engine handles .wav, .mp3 and .ogg, and the format list is a hint about the platform, since those are the three formats a Java sound stack can cover without a native codec dependency for each.

Then the parts that make it an engine rather than a drawing library. A 2D physics engine, tile map support, an entity framework, and input handling for gamepad, keyboard and mouse.

The entity framework is worth singling out, because in 2D the question of what a game object is, where its behaviour lives and how it is updated, is the one every engine answers differently, and an answer you inherit is worth reading before you write your own.

Java 25, and a launcher flag for the gamepad path

The installation section has one line that will decide whether you can use the engine at all, and it is worth quoting in substance. LITIENGINE requires Java 25 or later, and Java 22, 23 and 24 are no longer supported.

That is an aggressive floor for a library, and it is the kind of requirement that arrives when a dependency needs a modern runtime. The next sentence explains why, and it is the more interesting part of the README.

Applications that enable gamepad support should be launched with --enable-native-access=ALL-UNNAMED to grant Input4j access to the Foreign Function and Memory API. The reason is that Input4j, the library the engine uses for gamepad support, talks to the operating system's input facilities through that API, and modern Java has been closing the door on unauthorised native access. Java 25 allows it with a warning by default, but the README notes that --illegal-native-access=deny and future Java releases reject it.

So the situation is: the engine works on Java 25 today with a warning, and the flag that silences the warning is one your launcher has to pass, and a future release will require that flag rather than merely warning. If your project launches the JVM itself, that is a launch configuration change, not a code change.

If you do not use a gamepad, none of this applies, and it is worth saying that the engine's input layer covers keyboard and mouse as well, so the native access path is opt-in rather than central.

Maven Central, with a version number that has moved on

The library is on the Maven Central Repository, and the README gives the Gradle coordinates in both common syntaxes.

In Groovy:

repositories {
    mavenCentral()
}

dependencies {
  implementation 'de.gurkenlabs:litiengine:0.8.0'
}

And in Kotlin:

repositories {
    mavenCentral()
}

dependencies {
  implementation("de.gurkenlabs:litiengine:0.8.0")
}

The group id, de.gurkenlabs, is the German package naming convention that Maven Central supports, which is a small detail but explains why the artifact path looks unusual next to the GitHub organisation name.

The version in both snippets is 0.8.0, and the current release is 0.12.0. That gap is the reason to read the getting started guide rather than copy the snippet, because the coordinate format has not changed but the version certainly has, and the Java requirement in particular is different from what an 0.8.0 user would have had.

The README also says that for alternative ways of downloading and applying the engine to your project, the getting started guide is the place to look, which suggests there is more than one supported route, such as a project template or a Gradle plugin.

Two libraries do the sound and the theming

The Libraries Used section is short and says more about the engine's design than a dependency list normally would.

Input4J provides the gamepad support, which is the library the native access flag exists for. The Ogg Vorbis SPI provides.ogg support, which explains the format list in the sound engine: the other two formats are handled by the Java runtime, and Ogg needs a service provider because it is not built in.

Then there is utiLITI, the project's dedicated map editor, and the README says it uses Darklaf for theming support, so the editor's own interface is themed by a library rather than hardcoded.

Under Other Recommended Libraries there is Steamworks4j, for supporting the Steamworks SDK, which is a sensible suggestion for a 2D engine aimed at commercial indie releases on a storefront.

The README also includes a star history chart that compares the project with other 2D Java libraries and engines, naming FXGL, mage, lionengine, FastJ, LGame, LWJGL, playn and mini2Dx. That comparison is about popularity rather than capability, but it does place LITIENGINE in a field where most of the alternatives are frameworks and libraries rather than complete engines with an editor.

The repository is a multi-project Gradle build

The top-level listing shows how the code is arranged, and it is a Gradle multi-project build rather than a single module.

There is build.gradle and settings.gradle at the root, gradle.properties, the gradle/ directory with the wrapper, gradlew and gradlew.bat, and a buildSrc/ directory for the build logic. The main modules are litiengine/ for the engine itself, utiliti/ for the utiLITI map editor, which carries the Darklaf theming support, and shared/ for code used by more than one of them, plus config/ for the shared build configuration.

The separation of litiengine, utiliti and shared is the interesting part. It means the map editor is kept apart from the engine, so the engine library does not carry the editor's interface code.

Around the build there is the usual set of project files: an.editorconfig,.gitattributes, a.gitignore, a.github/ directory for the workflows, CODE_OF_CONDUCT.md, CONTRIBUTING.md, a CITATION.cff and the LICENSE. The README badges match that setup, with a build workflow badge, a SonarCloud quality gate badge, a Maven Central version badge, an MIT licence badge, a Discord badge and an OpenCollective badge for financial supporters.

The contribution route is stated as two steps, agreeing to the code of conduct and reading the contribution guidelines, and both files are in the repository root, so the process is in version control rather than on a website.

Editorial conclusion

Adopt LITIENGINE if you want a complete 2D stack in Java rather than a rendering library you assemble yourself, because the engine ships the game loop, the resource and configuration handling, the renderer with spritesheet animation, ambient lighting and particles, the sound layer, the physics and the entity framework, plus a map editor that speaks the Tiled format. Do not adopt it if Java 25 is not available in your build environment, because the engine has dropped 22, 23 and 24 and says so plainly, and check the gamepad story before you commit, because it needs a launcher flag for native access that future Java releases will reject by default. Before you start, read the getting started guide, since the Gradle snippet in the README still pins an older version than the current release.

Frequently asked questions

Official sources

1. gurkenlabs/litiengine on GitHub
2. License: MIT
3. Project website
4. README
5. Releases