NRF SDK 0.9Creating a mod
Organise a mod project
Separate declarations, rules, interface and resources while keeping a simple Gradle project.
Give each directory a purpose
Prerequisite: the first mod project. Start with Entry.kt alone, then extract rules and resources as the model grows. The directories below show one possible organisation; the plugin requires source roots and an entry point, not a particular domain architecture.
Example layout, adapt it to your mod
mod.json
settings.gradle.kts
build.gradle.kts
gradle.properties
src/main/kotlin/
Entry.kt
bal/
BalModel.kt
BalRules.kt
BalAppearance.kt
common/
NetworkRules.kt
tools/
PlacementTool.kt
src/test/kotlin/
BalRulesTest.kt
assets/
translations.json
imgs/
closed.svg
open.svg
licenses/| Element | Expected contents |
|---|---|
| Entry.kt | package nimby.mod, createMod() and composition of models or tools. |
| bal/ | A mod domain with its model, rules and images. Other domains keep their own types. |
| common/ | Only behaviour actually shared across multiple domains. |
| tools/ | Events, panels and action orchestration for your tools. |
| src/test/kotlin/ | Pure tests and explicit data sets for each rule. |
| assets/ | Files copied to the package root; assets/imgs/closed.svg is referenced as imgs/closed.svg. |
Separate computation from effects
A rule receives observations and produces an explainable decision. Appearance and driving functions interpret that decision. A tool separately retains copied data and operation state. This separation lets you test calculations without an open game and identify the reads or actions actually needed.