LGame is a Java 2D engine built around OpenGL and a single setup class

A Java engine with three language ports behind one name

LGame is described as a cross-platform Java game engine, or framework, offering comprehensive foundational modules for 2D games, with 3D support planned for future releases. The supported platforms are Windows, Linux, macOS, Android, web browsers and iOS. The interesting part is what sits alongside the Java implementation. The project provides native implementations in C# and C++, along with syntax conversion, to accommodate as many systems as possible, and the repository layout confirms it. There are top level directories named Java/, JavaScript/, C#/ and CPort/, so a JavaScript port, a C# port and a C++ port sit in the same tree as the Java source. The engine itself has a formal name, Loon, and the README's own framing is that it is a fast, simple and powerful game framework powered by Java, also supporting C# and C++. There is a Korean readme alongside the English one, and the README notes the project was restarted, with the game's just started. That restart note matters when reading the release history, because the current version line descends from a 2019 beta rather than from a long steady release cadence.

The package tree is the feature list

The README prints the source tree, and it is the most useful description of the engine's scope. The core loon package is organised by concern. Under action there is a sprite actions and events package, an avg package for the visual novel template with its own drama scripts, a behaviors package for character behavior control, and a camera package for global 2D camera control. Map management is the largest area, with collision methods and traversal, a map-based battle system with its own base scripts, map collision management, a heuristics package described as a collection of pathfinding methods, map items and character setup, and two map format integrations, ldtk and tmx, the latter with subpackages for objects, renderers and tiles. Elsewhere there is a sprite package with default skeletal animation and a pixel effects collection including explosions, an XNA-like SpriteBatch, a 2D pixmap rendering package, a desktop UI component set with layout, skin and table components, an events package, a font package, a geometry and physics package, an OpenGL rendering core with light and mask management, a particle effects package, and a utilities package holding cache, HTML and CSS handling, JSON handling, file parsing, game processes and events with a state handler, a QR code component, reflection wrappers, data reply utilities, resource loaders, time management and XML handling. For a reader deciding whether to use the engine, that tree says the answer quickly.

A game boots from one class and a settings object

The stated design goal is that the initial setup of a game consists only of making a single class. The example in the README shows how that works in practice, with a settings object carrying the whole configuration and a registration call that hands the engine a lazy loading callback that returns the first screen:

public class Main  {

	public static void main(String[] args) {
		LSetting setting = new LSetting();
		setting.isDebug = true;
		setting.isDisplayLog = false;
		setting.isLogo = false;
		setting.logoPath = "loon_logo.png";
		setting.width = 480;
		setting.height = 320;
		setting.width_zoom = 640;
		setting.height_zoom = 480;
		setting.fps = 60;
		setting.fontName = "Dialog";
		setting.appName = "test";
		setting.emulateTouch = false;

The settings cover display and debug behaviour, the startup logo, the original window size and the zoom target, frame rate, font, application name, and touch event simulation for desktop. The engine is registered with Loon.register and a LazyLoading.Data implementation whose onScreen method returns the game's first Screen, which is the part that lets the framework own startup while the game owns the content. The README also claims the interface is entirely documented for fast learning, and that the engine is built around the idea that beginners should start with the basics and then move into more complex development, all on the same platform.

Project creation ships as an executable jar

There is a project generator, and it is packaged as a runnable file rather than a set of instructions. The README says LGame comes with a file called LGameProjectMake.jar, which is an executable UI and command line tool, and that executing the JAR opens the setup UI. Alongside it there are two templates, an Android Studio template named androidstudio-template and an all-Java run template named loon-gradle-template, with the note that the task run call invokes the main method and the task dist packages the game to a jar. The repository root confirms the build tooling. There is a build.gradle, a gradle.properties, a settings.gradle, a gradlew and a gradlew.bat pair, a pom.xml for Maven, and a Loon-Build/ directory. Two archives of HTML5 demos are also committed, one described as a web server demo and one as a no-cross-domain demo, which is a reasonable way to see what the JavaScript port produces without setting up a local server. So the entry paths are covered: a JAR-driven setup UI for a new project, a Gradle template for Java, an Android Studio template, and a set of runnable samples.

Samples and examples live in their own directories

The README links two separate collections, and the distinction between them is a small but useful signal. The Samples link points at the Java/samples tree and is labelled game sample, while the Examples link points at Java/Examples and is labelled game example. Sample projects and example projects are usually not the same thing, with samples tending to be complete playable games and examples tending to be isolated demonstrations of one feature. The README also provides a curated link to free game resources under dev-res/README.md, described as free game resources for the project, and there is a DEV_MANUAL.md at the repository root. A CITATION.cff file is present, which is the citation metadata format for a project that wants to be cited in academic work. For a reader assessing the engine, the practical question is whether the sample games run on their machine, and the answer is best found by compiling one of them rather than by reading the tree, since the tree only shows what modules exist.

Where LGame is the wrong choice

The 3D gap is the obvious one. The README describes the engine as offering foundational modules for 2D games, with 3D support planned for future releases, and no release in the list suggests that changed. Anyone whose game design depends on 3D is looking at the wrong project. The second limitation is the release history. The three most recent releases are LGame-0.5-Beta from 2019-04-20, LGame-Java-0.5-Beta from 2019-06-01 and LGame-0.5-Beta-fix1 from 2019-06-14, so the newest tag is more than seven years old, while the last push to the repository was on 2026-06-05, which is inside the last six months but well after the last release. That combination, commits without releases, means the master branch is the only artifact to use and there is no versioned build to point a release pipeline at. A third point concerns the environment. The engine is built around OpenGL and OpenGLES, so it needs a working graphics stack on the target machine, and its browser and mobile support implies a per-platform build path rather than a single jar. The alternative approaches differ in kind. A modern JVM game engine gives you an editor, a scene format and a maintained release train, at the cost of the small codebase and the low setup that LGame offers. Building on a bare OpenGL binding gives you the rendering but none of the module set, and a project like this one is largely the module set.

Editorial conclusion

LGame is worth evaluating if you write Java and want a 2D engine that boots from a single class and already ships map loading, pathfinding, particle effects and a Tiled importer, since assembling that set from scratch is a large part of the cost of a small game. It is the wrong choice for anything 3D, since the README describes 3D support as planned for future releases, and the wrong choice for a long-lived commercial product, since the newest tagged release is LGame-0.5-Beta-fix1 from 2019-06-14 while the last push was on 2026-06-05. Verify first that the branch you clone still builds with the JDK you have, that the OpenGL path works on your platform, and that the sample projects under Java/samples run before you commit to the engine. The last push was on 2026-06-05.

Frequently asked questions

Official sources

1. cping/LGame on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases