NRF SDK 0.9Créer un mod
Organiser un projet de mod
Séparez déclarations, règles, interface et ressources tout en conservant un projet Gradle simple.
Donner un rôle à chaque dossier
Prérequis : le projet du premier mod. Vous pouvez commencer avec Entry.kt seul, puis extraire les règles et ressources lorsque le modèle grandit. Les noms de dossiers ci-dessous décrivent une organisation possible ; le plugin impose les racines de sources et le point d’entrée, pas votre architecture métier.
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/| Élément | Contenu attendu |
|---|---|
| Entry.kt | package nimby.mod, createMod() et composition des modèles ou outils. |
| bal/ | Un domaine du mod avec son modèle, ses règles et ses images. Les autres domaines gardent leurs propres types. |
| common/ | Seulement les comportements réellement partagés entre plusieurs domaines. |
| tools/ | Événements, panneaux et orchestration des actions de vos outils. |
| src/test/kotlin/ | Tests purs et jeux de données explicites pour chaque règle. |
| assets/ | Fichiers copiés à la racine du paquet ; assets/imgs/closed.svg se référence comme imgs/closed.svg. |
Séparer calcul et effets
Une règle reçoit des observations et produit une décision explicable. Les fonctions d’apparence et de conduite interprètent cette décision. Un outil conserve séparément ses données copiées et l’état de son opération. Cette séparation permet de tester les calculs sans partie ouverte et d’identifier les lectures ou actions réellement nécessaires.