What should be configured by the KorGE gradle plugin

[malliaridis]

Migration Plan (Proposal)

With korge 7.0 we try to improve the maintainability of the project. One of the major problems we face are the gradle plugins that currently setup and configure everything. This is very error-prone and has high effort to update. To avoid this in the future, we should remove a lot of functionality korge should not be responsible for, as it does not own most of the stuff it currently configures.

The below draft has been created with Claude for getting started:

Shared module — korge { … }

These are things that are intrinsic to the game itself and must be consistent across all targets:

Rendering engine — renderer = KorgeRenderer.OPENGL / VULKAN / METAL / AUTO. This is the most prominent example you mentioned. The shared block declares the preference, and target blocks can override it (e.g. iOS always resolves to Metal regardless).
** Game identity** — id, name, version, orientation (portrait/landscape/both). These feed into every platform's manifest/plist/config, so they belong here.

Asset pipeline — atlas packing strategy, texture compression format (ETC2, ASTC, BC), font rasterization, audio format preferences. The game author decides this once; targets just consume the outputs.

Gameplay defaults — target FPS, fixed timestep size, virtualSize. These are engine-level, not platform-level.

Input profiles — whether the game expects gamepad, touch, mouse+keyboard, or some combination. Targets use this to wire up platform-specific input correctly without the shared module caring about implementation.

Debug/profiling flags — log level, whether to enable the performance overlay. Cuts across all targets uniformly.

Per-target blocks — korge.android { }, korge.desktop { }, etc.

These are things that only make sense on one platform, or where platforms legitimately differ:

korge.android { } — minSdk, required permissions, signing config reference, play billing mode, Google Play asset delivery configuration.

korge.desktop { } — initial window size and whether it's resizable, renderer override (force Vulkan vs OpenGL on a specific machine), system tray icon, custom JVM args for the run task.

korge.web { } — canvas selector ID, wasmJs vs js target, PWA manifest options, base path for asset hosting.

korge.ios { } — bundle ID suffix, entitlements, orientation overrides (iOS has its own orientation API), Metal is forced here regardless of the shared setting.

I believe following the practices from Compose Multiplatform would lead us to a better setup and less "KorGE"-special definitions that are just mappings.

If you have any suggestions, questions or may disagree with anything from above, please let us know.