1. 先搞清楚 Mindustry JSON Mod 到底解决什么问题如果你在找 Mindustry 的 JSON Mod大概率是想自己定制游戏内容但又不想从零写 Java 代码。JSON Mod 的核心价值就是让玩家能用相对简单的 JSON 或 HJSON 格式文件来添加新星球、单位、区块、物品而不用碰复杂的源码编译。但这里有个关键区别要先弄明白Mindustry 社区里说的 JSON Mod 其实分两种。一种是纯用 JSON/HJSON 定义游戏内容的轻量模组另一种是仍然需要 Java 项目结构但把大量配置移到 JSON 里的混合模组。从输入材料里的 GitHub 示例来看Slotterleet/example-planet-json 属于前者——它几乎完全靠 JSON 文件来定义一个新的星球和恒星系统。这种方式的优势很明显修改起来快不需要重新编译直接改文本文件就能看到效果。但边界也很清楚它适合添加静态内容比如星球属性、资源分布、基础单位数据。如果要实现复杂的逻辑或交互还是得回到 Java 模组开发。2. 环境准备不是所有 Mindustry 版本都支持 JSON Mod在开始之前先确认你的 Mindustry 版本。JSON 模组支持需要较新的游戏版本通常建议使用 Mindustry 7.0 或更高版本。老版本可能不支持完整的 JSON 行星定义功能。你需要准备的基本环境Mindustry 游戏本体Steam 版本或独立版本均可文本编辑器VS Code、Notepad、Sublime Text 等建议用支持 JSON 语法高亮的模组存放目录通常位于Mindustry/mods/文件夹内验证环境是否就绪的最简单方法启动 Mindustry进入模组菜单如果能看到已安装的模组列表说明模组目录结构正常。如果这个菜单是空的或报错先检查游戏文件完整性。我个人习惯先创建一个测试模组来验证环境在 mods 文件夹里新建一个文件夹随便放一个 icon.png 和 mod.hjson 文件然后重启游戏看是否能识别。这样可以排除路径和权限问题。3. 从示例项目开始理解 JSON 模组的基本结构以输入材料中提到的 example-planet-json 项目为例一个完整的 JSON 行星模组通常包含以下文件结构你的模组文件夹/ ├── mod.hjson # 模组元数据 ├── icon.png # 模组图标 └── content/ └── planets/ ├── 你的星球.json # 行星定义 └── 你的恒星.json # 恒星定义可选mod.hjson 是最关键的入口文件它告诉 Mindustry 这是一个模组{ name: 你的模组名称, displayName: 游戏中显示的名称, author: 你的名字, description: 模组描述, version: 1.0, minGameVersion: 140, // 最低支持的游戏版本 hidden: false }这里最容易出错的是minGameVersion字段。如果设置过高低版本游戏无法加载设置过低可能无法使用新特性。我一般会先查当前游戏版本号然后设置一个稍低的兼容版本。行星定义 JSON 文件是内容的核心。示例项目中包含了几乎所有可用的字段{ name: custom-planet, localizedName: 自定义星球, description: 这是一个通过 JSON 定义的测试星球, sectorSize: 5, allowSectorInvasion: true, allowWaveSimulation: true, allowBuildLoadout: true, startSector: 15, alwaysUnlocked: true, // 更多配置字段... }第一次实验时不要试图理解所有字段。先复制示例的基本结构只修改name、localizedName、description这几个必填字段确保能正常加载。4. 实际创建和测试一个简单的 JSON 行星我建议按这个顺序来创建你的第一个 JSON 行星模组4.1 创建基础文件结构在Mindustry/mods/下新建文件夹比如my-first-json-planet。然后创建以下文件mod.hjson{ name: my-json-planet-mod, displayName: 我的JSON行星测试, author: 你的名字, description: 学习JSON模组开发的测试项目, version: 0.1, minGameVersion: 140, hidden: false }content/planets/test-planet.json{ name: test-json-planet, localizedName: 测试JSON行星, description: 我的第一个JSON行星, sectorSize: 6, alwaysUnlocked: true, allowSectorInvasion: false, allowWaveSimulation: true }4.2 测试模组加载启动 Mindustry进入模组菜单在本地模组中应该能看到我的JSON行星测试启用这个模组重启游戏重要很多模组需要重启才能完全加载如果模组没有出现检查文件夹是否放在正确的 mods 目录下mod.hjson 语法是否正确可以使用在线 JSON 验证器文件编码是否为 UTF-8避免中文乱码4.3 验证行星是否生效模组加载成功后开始新游戏在选择星系的界面中寻找你添加的行星。如果一切正常你应该能看到测试JSON行星。如果行星没有出现排查顺序先检查游戏日志Mindustry 安装目录下的日志文件确认行星 JSON 文件路径和名称是否正确检查 JSON 语法错误缺少逗号、引号不匹配等确认模组确实已启用5. 理解关键配置参数的含义和影响JSON 行星模组的威力在于丰富的配置选项但这也意味着需要理解每个参数的作用。以下是一些核心参数的实际含义5.1 基础属性参数{ sectorSize: 6, // 区块大小影响地图尺寸 startSector: 15, // 起始区块编号 alwaysUnlocked: true, // 是否始终解锁无需研究 allowLaunchLoadout: true, // 允许自定义出发装备 allowLaunchSchematics: true // 允许携带蓝图 }sectorSize是最容易误解的参数之一。它不代表行星的实际大小而是划分的区块数量。值越大行星的区块越多探索内容越丰富但对性能的要求也越高。新手建议从 4-6 开始测试。5.2 游戏机制参数{ allowSectorInvasion: false, // 是否允许敌方入侵 allowWaveSimulation: true, // 是否生成敌人波次 allowBuildLoadout: true, // 是否允许建造装备 captureWave: 10, // 占领所需的波次 difficulty: 2 // 难度等级 }allowWaveSimulation设置为 false 可以创建一个纯建设性的沙盒星球适合新手练习建筑布局。而captureWave参数决定了需要抵御多少波攻击才能完全占领一个区块。5.3 资源生成参数{ generator: { type: SerpuloGenerator, // 生成器类型 seed: 12345, // 随机种子 oreScaling: 1.0 // 矿石生成比例 }, startingItems: { // 起始资源 copper: 500, lead: 500 } }generator.type决定了地形生成算法。除了默认的 SerpuloGenerator还可以尝试其他生成器来获得不同的地形特征。seed参数允许你创建可重复的地图布局适合制作特定挑战关卡。6. 高级功能从简单行星到复杂星系当基础行星能正常工作后可以逐步添加更复杂的功能6.1 添加恒星系统单个行星可以升级为完整的恒星系统// content/stars/test-star.json { name: test-star-system, localizedName: 测试恒星系, description: 包含多个行星的恒星系统, planets: [test-json-planet, another-planet] // 引用行星名称 }恒星系统的优势在于可以组织多个相关行星创造连贯的游戏体验。比如创建一个专门的教学星系每个行星介绍不同的游戏机制。6.2 自定义规则和条件通过条件判断创建独特的游戏体验{ rules: [ { condition: wave 10, // 条件波次大于10 action: unit-spawn, // 动作生成单位 unit: dagger, // 单位类型 amount: 5 // 数量 } ], requirements: [ // 解锁要求 { type: sector-captured, // 类型区块占领 sector: 15, // 目标区块 planet: test-json-planet // 所在行星 } ] }规则系统允许你创建动态的游戏体验比如在特定条件下触发特殊事件或奖励。6.3 资源平衡和科技树集成对于更复杂的模组需要考虑资源平衡{ resourceDistribution: { coreItems: [copper, lead], // 核心资源 rareItems: [thorium, titanium], // 稀有资源 abundance: { // 丰富度调整 copper: 1.2, lead: 0.8 } }, techTreeIntegration: { // 科技树集成 parentPlanet: serpulo, // 父级行星 researchRequirements: [ // 研究要求 unlock-item-copper, unlock-turret-duo ] } }资源平衡是模组设计中最重要的环节之一。我建议先用默认值测试然后根据实际游戏体验逐步调整。7. 调试和问题排查实战指南JSON 模组开发中最常见的问题通常源于简单的配置错误。以下是我总结的排查清单7.1 模组无法加载症状模组列表中看不到你的模组排查步骤检查 mods 文件夹路径是否正确验证 mod.hjson 文件语法特别是逗号和引号确认文件编码为 UTF-8 无 BOM检查模组文件夹名称是否包含特殊字符查看游戏日志中的错误信息常见错误// 错误示例缺少逗号 { name: test-mod version: 1.0 // 这里应该有个逗号 } // 正确写法 { name: test-mod, version: 1.0 }7.2 行星不显示或显示异常症状模组已加载但行星不出现或显示错误排查步骤检查行星 JSON 文件路径必须在 content/planets/ 下验证行星名称唯一性不能与现有行星重名检查必填字段是否完整name、localizedName、description确认字段值在有效范围内如 sectorSize 不能为负数资源引用问题 如果行星使用了自定义图标或资源确保资源文件存在且路径正确。相对路径基于模组根目录。7.3 游戏崩溃或性能问题症状加载模组后游戏崩溃或运行缓慢排查步骤逐步注释掉 JSON 中的配置块定位问题字段检查数值型参数的合理性避免极端值验证数组和对象结构的正确性测试内存使用情况大型模组可能需要更多内存性能优化建议大型行星系统分阶段开发先完成核心功能使用合理的 sectorSize避免过大影响性能复杂规则系统先在小范围测试8. 生产环境建议从实验到可发布模组当你的 JSON 模组功能稳定后可以考虑将其完善为可发布的版本8.1 版本管理和兼容性建立版本管理习惯{ version: 1.0.0, // 使用语义化版本号 minGameVersion: 140, compatibility: { supportedVersions: [140, 141, 142] } }语义化版本号Major.Minor.Patch让用户清楚版本间的兼容性变化。同时明确支持的 Mindustry 版本范围避免用户在不兼容的环境中使用。8.2 文档和示例为你的模组提供清晰的文档README.md 文件说明模组功能和用法示例配置文件展示各种功能用法更新日志记录每个版本的变更好的文档不仅能帮助用户也能让你在几个月后回顾代码时快速理解当时的设计思路。8.3 测试和反馈收集发布前进行充分测试在不同游戏版本上测试兼容性验证各种游戏条件下的稳定性邀请其他玩家进行体验测试建立反馈渠道如 GitHub Issues及时修复用户报告的问题。JSON 模组的优势之一就是修复问题后用户只需要更新文本文件无需重新下载大型文件。8.4 发布和更新策略发布到 Mindustry 模组仓库或 GitHub 后制定合理的更新计划定期更新以适应新游戏版本根据用户反馈添加新功能保持向后兼容性或提供清晰的迁移指南JSON 模组开发最大的成就感来自于看到其他玩家享受你创造的内容。从简单的行星定义开始逐步扩展到复杂的星系系统和游戏机制这个过程本身就是一种创造性的体验。最关键的是保持迭代思维先做出最小可用的版本然后基于实际测试和反馈持续改进。不要试图一次性实现所有想法而是让模组随着你的技能增长而自然进化。
