JVM Mods

RWX JVM mods are loaded from jar files. A mod depends on the platform-independent mod-api module and implements com.corrodinggames.rts.gameFramework.mod.JvmMod on desktop builds.

The API module contains only stable contracts and data models. It does not expose internal game classes, so the same mod-facing code can be reused by future desktop, Android, server, or tooling hosts.

Mod Jar Layout

my_mod.jar
├── mod.toml
├── com/example/MyMod.class
├── assets/
│   ├── units/
│   ├── textures/
│   ├── sounds/
│   └── shaders/
└── localization/
    ├── en.properties
    └── zh.properties

mod.toml

The desktop loader currently reads these top-level keys:

id = "my_awesome_mod"
name = "My Awesome Mod"
entrypoint = "com.example.MyMod"
version = "1.0.0"
author = "Your Name"
description = "Adds new units and rendering effects."
minGameVersion = "1.0.0"
dependencies = ["another_mod"]
priority = "0"

entrypoint must be a public class with a public no-argument constructor. Dependencies are sorted before initialization when they are present in the same loading batch.

Entrypoint

package com.example

import com.corrodinggames.rts.gameFramework.mod.JvmMod
import com.corrodinggames.rts.gameFramework.mod.api.LocalizedText
import com.corrodinggames.rts.gameFramework.mod.api.ResourcePath
import com.corrodinggames.rts.gameFramework.mod.api.ShaderDefinition
import com.corrodinggames.rts.gameFramework.mod.api.ShaderTarget
import com.corrodinggames.rts.gameFramework.mod.api.UnitDefinition

class MyMod : JvmMod() {
    override fun initialize() {
        // The loader injects api before this method is called.
    }
}