KorGE: a Kotlin game engine that targets JVM, Web, Android and iOS from one codebase

The problem KorGE solves for Kotlin teams

Most small game projects end up maintaining two or three codebases: one for desktop testing, one for the browser, one for mobile. KorGE's answer is a single Kotlin codebase compiled to several targets. The README states that the KorGE gradle plugin allows targeting JVM for Android, JS and WASM for the Web, native code for iOS, and JVM/JS for Desktop. That is the whole pitch, and it is a narrow one: it is aimed at developers who already write Kotlin and do not want to learn a second language or a second build system to ship a game.

The engine is not a standalone runtime. The README describes it as "the last layer of a larger stack (Korlibs) for multimedia development", so audio, graphics and platform bindings come from the Korlibs libraries underneath. That matters when you evaluate it: you are adopting a stack, not a single artifact, and the repository layout reflects that with separate modules such as korge-core, korge-gradle-plugin, korge-ipc and korge-reload-agent.

How the Gradle plugin, hot reloading and KProject fit together

The build-time entry point is the Gradle plugin. It is what turns a Kotlin Multiplatform project into something that can produce the platform targets listed above, and it is published on Maven Central under org.korge.gradleplugins, per the badge in the README. The runtime side is split across modules in the repository: korge-core holds the engine, korge-reload-agent and korge-ipc support the reloading path, and korge-sandbox is the in-repo module used for experiments.

Hot reloading is the feature the README leads with. It says KorGE supports hot reloading "to see changes immediately without having to restart the application". The presence of a dedicated korge-reload-agent module and a korge-ipc module suggests the mechanism is an agent plus an inter-process channel rather than a simple file watcher, though the README does not document the protocol. A debugger is also listed, described as live-debugging your games.

KProject is the sharing layer. The README says KProject support lets you "share & re-use source code and resources via GitHub", and notes that traditionally KorGE modules were published to Central with source in this repository, but are now available via kproject in separate repositories. The KorGE Store catalog at store.korge.org is marked deprecated and the README states it will be discontinued in release 7, with additions to be made as a Gradle submodule in a Kotlin Multiplatform context instead.

Installing KorGE and running the sandbox

The README does not give a from-scratch install command for a new project. It points at two starting points: install KorGE Forge from forge.korge.org, or clone the "Hello World!" project. It also points at the korlibs/korge-hello-world repository as the reference for the current application setup after the Gradle 9 and Android Gradle Plugin 9 update described in the 08-Sep-2026 news entry.

The one concrete build command the README gives is for publishing KorGE to your local Maven repository, which is how you check out local changes and consume them from your own application:

./gradlew publishToMavenLocal

After that, your own project resolves KorGE from the local repository instead of Maven Central. If you would rather experiment inside the engine repository itself, the README points at the korge-sandbox module and the file shared/src/commonMain/kotlin/org/korge/application/Main.kt, and lists these run tasks:

./gradlew :korge-sandbox:runJvm
./gradlew :korge-sandbox:runJs
./gradlew :korge-sandbox:runAndroidRelease
./gradlew :korge-sandbox:runIosDeviceRelease

Each task builds and launches the sandbox on the matching target, so runJvm is the fastest loop and runIosDeviceRelease requires a real iOS device. For dependency configuration, the README gives this excerpt for gradle/libs.versions.toml, showing the old namespace commented out and the new one in use:

[plugins]
#korge = { id = "com.soywiz.korge", version = "6.0.0" }   <-- Old namespace, latest official version
korge = { id = "org.korge.engine", version = "7.0.0-SNAPSHOT" }   # <-- New namespace, use latest snapshot version

Note what you are choosing between: the old namespace at a released version, or the new namespace at a snapshot. That is a real decision, not a formatting detail.

The namespace migration is the biggest current risk

The 02-May-2026 news entry states plainly that Korge is moving from com.soywiz.korge to org.korge on Maven Central and that this is a breaking change. Dependency coordinates are not cosmetic. Every build file, version catalog and CI cache that pins the old group will need editing, and the new coordinates are published as 7.0.0-SNAPSHOT rather than a release. If your process forbids snapshot dependencies, you are effectively on 6.0.0 in the old namespace until 7.0.0 ships.

There is a second disruption in the same window. The 08-Sep-2026 entry says Korge was updated to Gradle 9 and Android Gradle Plugin 9, and that this brings changes in the application setup. The README defers to korge-sandbox and korlibs/korge-hello-world for the new shape. Anyone following an older tutorial should expect the application setup section to be wrong, and the README does not document a migration guide for either change.

The Store deprecation compounds this. If you built a workflow around pulling extensions from store.korge.org, the README says it will be discontinued in release 7 and that additions should instead be Gradle submodules in a Kotlin Multiplatform context. That is a different dependency model with different update mechanics.

Where KorGE is the wrong choice

KorGE is a poor fit if you need a settled API surface right now. The two most recent news items both describe breaking changes, one to dependency coordinates and one to the application setup, and the new namespace is only available as a snapshot. Projects with long support windows and slow upgrade cadence will spend their time on migration rather than on the game.

It is also the wrong tool if your team is not on Kotlin. The engine is 100% Kotlin, and the README's productivity argument rests on targeting the JVM so you can develop, try, debug and test in IntelliJ IDEA. Bring a C# or C++ team and you lose the main advantage while inheriting the migration work. The same applies if you need an editor-driven workflow: the README describes a code-first engine with a debugger and hot reloading, and does not describe a visual scene editor.

Finally, the README does not document rollback, version pinning policy or a deprecation timeline for the Store beyond release 7. If your adoption decision depends on those guarantees, the documentation is silent and you would be reading the source in korge-gradle-plugin to find out.

KorGE versus libGDX: same targets, different language bet

The comparison people reach for is libGDX, and the split is clean. libGDX is a Java-first framework with a long history and a large body of third-party material; it targets desktop, Android, iOS and web through a similar backend-per-platform model. KorGE makes the same multiplatform promise but bets on Kotlin as the language and on Gradle as the only build path, with the Korlibs stack underneath instead of libGDX's own modules.

The practical difference shows up in two places. First, code style: KorGE is designed, in the README's words, "from the ground up to embrace modern and easy coding styles", which in practice means Kotlin idioms throughout rather than a Java API with Kotlin conveniences layered on. Second, dependency management: KorGE extensions now come through kproject repositories and, going forward, Gradle submodules, while libGDX extensions are conventionally consumed as ordinary artifacts. Neither is strictly better, but they fail differently. A libGDX project breaks when an extension stops being published; a KorGE project breaks when a namespace moves, which is exactly what is happening now.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-19, so work is ongoing. The release history is uneven rather than steady: v6.0.0 landed on 2025-05-16, preceded by v6.0.0-beta4 on 2024-09-15 and v6.0.0-beta3 on 2024-08-27. Between betas and a stable release there was roughly eight months, and the 7.0.0 line is still a snapshot. Plan for long gaps between stable releases and for the snapshot channel to be where new work appears.

Upgrade cost is dominated by the two breaking changes described above: the group ID move to org.korge and the Gradle 9 / Android Gradle Plugin 9 application setup. Both touch build configuration rather than game code, which limits the blast radius but makes them unavoidable.

The licence field on the repository is reported as NOASSERTION, so the machine-readable metadata does not resolve to a standard SPDX identifier. A LICENSE file exists at the top level of the repository. If you need to know the terms before shipping, read that file directly rather than relying on the metadata; this is not legal advice and the licence text is the only authority.

Editorial conclusion

Adopt KorGE if your team already writes Kotlin and you want one Gradle build to produce desktop, web, Android and iOS targets, and you are comfortable tracking the namespace move to org.korge. Do not adopt it if you need a stable, frozen API today, or if your team is not on Kotlin and IntelliJ IDEA, since the engine is written in Kotlin and the README points at JVM tooling as the productive path. Before starting, verify which namespace and version your build resolves (the README lists 6.0.0 as the latest official release and 7.0.0-SNAPSHOT as the current snapshot), and check that the Gradle 9 and Android Gradle Plugin 9 setup described in the 08-Sep-2026 news matches your build files.

Frequently asked questions

Official sources

1. Issues
2. korlibs/korge on GitHub
3. Project website
4. README
5. Releases