简介Mindustry 是一款用 Java 编写的开源沙盒塔防游戏融合塔防、即时战略与沙盒建造玩法支持桌面端与移动端跨平台运行兼具较强的可扩展性。这份压缩包约 65.79MB主要包含项目源代码、资源文件以及 Gradle 构建配置便于开发者在 Windows、Linux 或 macOS 环境下自行编译与运行也可据此生成自定义版本。当前已有 444 人浏览学习特别适合游戏开发初学者、塔防爱好者以及希望研究开源游戏架构的开发者。通过阅读源码可以学习 Java 游戏工程的结构设计、多平台打包流程、关卡与单位的数据配置思路以及模组扩展的实现方式在此基础上还能尝试添加新敌人、设计地图或调整数值深入理解沙盒塔防游戏的完整开发流程。1. Mindustry 沙盒塔防游戏别被“塔防”骗了这是一座要维护的工厂Mindustry 沙盒塔防游戏第一次打开时我以为就是个造炮塔守家的休闲图结果第三关就被敌人绕了侧路第七关彻底卡在铜不够用上。后来我去翻了它的源码和社区方案才明白这游戏本质上是“塔防 RTS 工厂流水线”三合一炮塔只是输出端前端的采矿、冶炼、输送、供能才是真正的战场。它用 Java 写成桌面端和移动端共用一套核心逻辑服务端还能独立跑在无头模式下因此特别适合两类人来拆一是想研究沙盒建造类游戏如何组织大量实体与寻路逻辑的开发者二是想找个能玩又能改的跨平台开源项目练手。这篇笔记就把我拆过的架构、编译方法、服务器部署和常见翻车点一次说清。2. 核心玩法拆解为什么说它是流水线模拟器2.1 资源链铜、铅、钛、煤到炮塔弹药之间隔着什么Mindustry 里不存在“点一下炮塔就自动开火”的简单逻辑。每个炮塔要工作背后必须有一条完整的资源链路采矿钻头从矿脉里抽出矿石矿机把矿石喂给熔炼炉熔炼炉产出材料再由装载器或传送带把材料送到炮塔的弹药槽里。中间任何一个节点断掉炮塔就会哑火。这条链路的前几关尤其露骨铜矿和铅矿往往分布在基地两侧你得规划传送带走向煤需要先挖出来再送进发电机发电机同时要消耗水降温不然过载会爆炸。也就是说玩家的核心工作不是“布阵”而是“规划物流”。我之前玩到钛矿解锁时光是把钛和煤按 2:1 的比例送到材料厂就重新铺了三次传送带因为传送带的优先级会互相阻塞。从技术实现角度看这条链路对应的是 Entity 组件化的数据流钻头、传送带、炉子、炮塔都是独立实体各自维护输入输出缓冲区和状态标记由游戏主循环每帧驱动它们升级更新。传送带上的物品并不在物理世界里运动而是以“物品条目”的形式在不同实体的缓冲区之间传递位置和方向。理解了这一点你就能明白为什么很多资深玩家建议“先建吞吐模型再造传送带”这游戏的核心逻辑其实是一张有向图节点是生产和消耗实体边是输送路径。2.2 指挥官系统从被动防守到主动反击的输出切换塔防模式打得再稳也只是守住了而已。Mindustry 成长到中后期后每张地图的胜负手往往是一波主动反击用指挥中心批量生产作战单位指定集结点和攻击目标把敌人的生成点直接拆掉。这套指挥官系统比表面看起来复杂。你需要建“单位工厂”来生产地面或空中单位用“指挥块”设定单位的作战模式跟随、巡逻、攻击指定目标。单位本身也需要补给要么回基地装弹要么由运输机直接空投弹药。我第一次尝试大规模反攻时生产了 20 台近战机甲结果因为没有设巡逻路径它们全部挤在集结点上打了转被敌人的一波空袭全灭。这里有一个很典型的 RTS 设计折中单位的寻路开销极大所以游戏对地面单位采用了“区块导航网格 拉普拉斯势场”的混合方案。简单说地图被划分成大格子每个格子预计算一个朝向目标的引导场单位只需要朝数值下降的方向走再在近距离用碰撞避让修偏。这样一来就算战场上同时存在几百个单位寻路计算也只是每帧做一次一维梯度下降而不是每个单位单独跑 A*。作为对比生成器里的敌人 AI 反而更“笨”——它们直接锁定基地核心的坐标前进遇到墙才会绕行这也是你能用墙体改变敌方路线的底层原因。2.3 沙盒模式的真正意义无限资源下暴露的是物流瓶颈沙盒模式提供无限资源和全科技解锁的开关很多人以为这是“作弊模式”玩起来才发现它更像一个“压力测试工具”。资源无限了你就无法再用“矿不够”来解释炮塔哑火剩下的问题几乎全是物流设计缺陷传送带交叉点拥堵、路由器发散到死路、装载器输入输出速率不匹配。我做过一个实验在沙盒模式里只靠传送带把 6 台熔炼炉的出料统一送到一个炮塔弹药库结果炮塔的射击速度还不到理论峰值的三分之一。挨个检查后发现瓶颈出在“路由器 → 装载器”这一步路由器会把输入均分给所有相邻格子当一条线路上既有炮塔又有储物箱时物品被均匀分流掉一半炮塔只能吃剩下的部分。这个场景在生存模式里同样存在只是一般会被掩盖在“铜不够”的大问题下。所以沙盒模式对拆项目的人很有用它允许你把某一张地图导出、复制、改测试变量然后反复跑同一波次的敌人入侵观察炮塔输出曲线和库存变化曲线。这种可重复的实验环境是理解整套生产链路参数最好的入口。3. 技术架构拆解Java、跨平台与游戏循环3.1 为什么用 LibGDX跨平台诉求下的合理选择Mindustry 从第一行代码起就定了 Java LibGDX 的技术组合。LibGDX 是一套成熟的跨平台游戏框架底层把 LWJGL桌面端和 Android 原生接口移动端封装成统一的窗口、输入、音频、OpenGL 渲染接口。你写一套游戏逻辑桌面端和手机端共用只需要各自做一小层启动代码。游戏循环被封装成一个标准的主循环每帧固定调用一次update()更新全部实体状态再调用一次draw()把画布渲染到屏幕。服务端运行时LibGDX 的渲染部分会被剥离进入 headless 模式只保留update()和网络同步逻辑。这就是为什么同一个 Jar 包能同时承担单机、局域网联机和服务器三种角色。// 简化的游戏循环骨架理解主线程与渲染线程的关系 while (!window.shouldClose()) { float delta timer.delta(); // 本帧时间间隔单位秒 world.update(delta); // 更新所有实体单位AI、传送带物品、炮塔冷却 renderer.render(world); // 收集实体渲染指令交给GL线程 network.tick(delta); // 同步玩家输入与实体状态给远端 }这段代码看起来简单实质上决定了整个项目的架构走向world.update()是纯逻辑计算不触碰任何渲染状态renderer.render()只读世界状态生成绘制命令network.tick()负责把本地操作序列化后发给服务端或客户端。因为逻辑和渲染分离无头服务器才可以安全地只跑前两行。你如果动手改代码保持这条边界是最重要的一条军规我在第四章节还会展开讲。3.2 存档与 HJson为什么地图文件不是纯 JSONMindustry 的地图存档后缀是.msav很多人直接用文本编辑器打开以为能改出一堆 JSON实际看到的是乱码。它的结构是两层外层用 ZIP 压缩解开后内层是一个 HJson 文件你可以把它理解成“允许注释且带类型信息的 JSON 变体”。HJson 本身是简化版序列化格式适合人读写也方便程序从字符串直接反射成对象。地图里每个实体矿脉、钻头、传送带、敌人出生点都是一条记录附带坐标、朝向、所属队伍和自定义状态字段。因为这个格式高度结构化很多地图编辑器才能实现“复制选中的一片炮塔”和“整块平移建筑”的操作。存档压缩这一步并不是为了省空间而是为了隐藏内部字段长度并让非法修改的门槛更高。实际拆包时正确步骤是先解压拿到内层文本文件再按 HJson 规则编辑最后重新压缩并把扩展名改回.msav。如果你在下载的地图资源里想看看对方用了哪些 Mod 专属块这就是唯一的途径。我也见过有人直接改存档给战役模式解锁全科技原理并不复杂找到科技树节点树里的unlockedtrue标记把值一改重新打包放回存档目录就行。3.3 移动端与桌面端的性能边界跨平台听上去划算实际坑全在适配层。同一张大型地图在桌面端渲染和移动端渲染消耗差距极大。移动端 GLES 2.0/3.0 与桌面 OpenGL 有差异Mindustry 的做法是降低移动端默认的视距和粒子数量同时把 OpenGL 的绘制调用合并成批次减少状态切换。游戏里的像素单位世界看起来轻量但实体数量上万后会成为瓶颈。一个 512×512 的战役地图玩家铺满微型钻头和传送带后实体数很容易到 8000 以上。每帧每个实体都要做状态更新再加上单位和弹药的计算CPU 压力会迅速盖过渲染压力。手机端实际表现明显弱于桌面端是因为手机 CPU 在多线程调度的策略上更保守而游戏主循环对单线程吞吐的依赖很重。这意味着你在手机端玩大型生存地图卡顿往往不是因为渲染而是因为实体数量过多。想验证这一点有个土办法游戏内开启显示 FPS 和实体数的调试面板播放同一波敌袭实体数从 2000 涨到 6000 时帧率下降的幅度基本和实体数量成正比。做地图或者做 Mod 时控制单张图内的实体总量是提升体验最有效的手段。4. 动手复现从源码编译到服务端部署4.1 拉源码和构建环境的准备Mindustry 的源码托管在开源社区仓库里项目用 Gradle 做依赖管理和构建。构建前需要确认本机装了 JDK 17 或更高版本新版本构建要求 JDK 21 也很常见遇到编译器报错就先升一下Android SDK 只在打包移动端时才需要如果只跑桌面端和服务端可以跳过。# 拉取源码并切换到稳定分支 git clone https://github.com/Anuken/Mindustry.git cd Mindustry # 查看可用任务列表确认构建入口 ./gradlew tasks --all | grep -E run|jar|server这里我一般会先跑一次./gradlew build验证整个工程能编译通过这个任务会执行单元测试和资源打包耗时取决于网络情况首次构建要下载 LibGDX 和 Android 插件的依赖5 到 15 分钟都正常。如果这一步报错优先检查两个地方JDK 版本是否匹配Gradle 下载的依赖仓库是否被网络策略挡住。后者可以用--stacktrace看到具体是哪个依赖拉取超时。4.2 本地启动游戏与调试模式桌面端启动命令是 Gradle 任务直接拉起 LWJGL 窗口运行起来后可以在游戏内打开控制台验证实体状态。# 直接启动桌面端 ./gradlew desktop:run # 服务端专属构建产物 ./gradlew server:jar java -jar server-release.jardesktop:run适合边改代码边看效果它会监听资源目录的变化改完assets里的配置或地图后按快捷键重载不一定要重启进程。server:jar打包出来的 Jar 是无头服务器不依赖图形环境可以扔到云主机上跑。第一次启动服务器 Jar 会在当前目录生成config文件夹里面有server.properties端口默认 6567是 UDP 协议端口别和 HTTP 端口混为一谈。部署到云主机时安全组策略放行 UDP 6567 才能被其他玩家搜到。调试模式我习惯用 JVM 参数开一个远程调试端口# 开启远程调试端口方便 IDE 断点追踪实体更新逻辑 java -agentlib:jdwptransportdt_socket,servery,suspendn,address5005 -jar server-release.jar启动后在 IDE 里配一个 Remote JVM Debug指向云主机的 5005 端口就能断点看服务端的实时实体状态。这个技巧对排查“为什么某条传送带不工作”这类问题特别有效直接在update()的入口加条件断点等物品走到指定坐标附近再触发比打日志高效得多。4.3 服务器端地图与权限配置解读服务器运行起来后控制台输入map可以查看地图列表map 名称切换地图config查看或修改运行参数。这些都能在server.properties里预设。几个关键参数我要单独说明一下配置项作用常见踩坑port玩家连接端口UDP被误配成 TCP 端口导致搜不到主机mapName启动时加载的地图名称写错会启动失败换map命令修复antigrief是否开启反破坏关闭时玩家可以拆任意建筑PvP 容易被炸家rateLimit每个玩家的消息频率限制默认值太低会导致打字聊天被吞whitelist白名单开关开启后不在名单的玩家会被卡在载入界面我实际部署时碰到过一次“玩家能进入房间但立刻掉线”排查到最后是云主机安全组只放行了 TCP 6567UDP 6567 是关闭状态。因为游戏联机用的是 UDP 做状态同步TCP 只负责登录握手握手成功但状态同步失败就表现为进入后秒退。这个现象迷惑性很强因为服务器日志上没有任何报错。从那之后我每次架设完都会用另一台机器执行nc -u 主机IP 6567主动发包测试连通性省掉很多远程开机调试的时间。5. 避坑与排查那些让人想砸电脑的常见问题5.1 实体失踪或建筑消失区块卸载边界带来的数据丢失现象某个区域里的传送带和炮塔在玩家离开视线一段时间后回来发现不见了但基地核心还在。原因Mindustry 的实体更新有分区调度策略区块的外圈实体在网络同步中可能只保存了“坐标和类型”没有保存附属的内部缓冲数据比如传送带上正在运送的物品队列。当区块被卸载再重新加载时这部分数据恢复到默认空状态看起来就像建筑被拆了。解决把关键生产线尽量放在靠近基地核心的区块内核心区块永不卸载。另一个办法是导出地图存档用前文提到的 HJson 编辑方式检查丢失区块的实体记录确认是“记录还在但状态字段为空”还是“整条记录都缺失”。前者可以补一个物品队列初始值后者只能回滚存档。建议自动备份周期设短一些我习惯每 20 分钟覆盖一份autosave这个习惯救过两次大档。5.2 服务端无限重启循环地图文件损坏却没有任何提示现象服务器进程启动后前几秒正常随后刷出一堆 NPE 堆栈接着进程自动退出又被systemd拉起来反复循环。原因损坏的地图文件在加载时会触发实体构建器的数组越界异常这个异常没有进入全局错误日志而是被服务端当作“普通未知错误”处理导致启动流程没走完就异常退出。服务托管脚本检测到进程退出就自动拉起于是形成了重启循环。解决先停掉服务手动用java -jar server-release.jar在终端前台启动把错误堆栈完整打印出来。堆栈里会指向具体哪一张地图的哪一个实体类型出错。把启动命令里的默认地图换掉能立刻恢复。如果必须保留原地图就用存档工具打开.msav找到异常实体对应的坐标把那条记录的类型改成“空气”重新打包加载。前台启动、后台托管是我现在部署所有 GameServer 的一致流程省得日志和进程管理混在一起互相干扰。5.3 逻辑处理器不执行 jump行号从 0 开始带来的脚本混乱现象按教程抄了一个传单逻辑逻辑处理器指示灯正常但单位就是不按预设路线走且没有任何报错。原因逻辑处理器的jump指令目标行号是从 0 数起的和大多数高级语言的 1-based 行号习惯完全不同。如果你把第 1 行当成行号 1 使用跳转会指向下一行逻辑上就等于跳错了位置。解决写逻辑脚本养成两种检查习惯。第一注释里同时标上行号和内容比如// 0: 读取敌人距离。第二用游戏内的逻辑处理器编辑器边写边单步执行编辑器会高亮当前的执行行一眼就能看出跳转目标是否符合预期。我一般会在脚本开头加一行jump 0的占位真正常跳时jump 目标行号 - 1。5.4 Mod 加载失败版本号比想象中更敏感现象从社区下载的 Mod 放进mods文件夹后游戏内能识别到但启用后立刻弹回主界面并提示某个方块类型不存在。原因社区 Mod 目标版本和当前游戏主版本不一致新版本删除或重命名了某些方块 ID。更隐蔽的是 Mod 之间互相依赖你先启用了 A ModB Mod 引用了 A Mod 的某个对象但 A Mod 版本不对B Mod 加载到一半找不到依赖。解决下载 Mod 前先看它的mod.json里声明的version字段确认和游戏版本匹配。启用顺序上把基础功能 Mod 放前、依赖它的扩展 Mod 放后。加载失败时去mods目录下找日志文件里面会直接写缺失的依赖类名或方块 ID。曾经有个 Mod 问题是对方打包时没有包含纹理文件加载逻辑里对图片资源判空失败日志里给的信息只是“文件找不到”通过翻压缩包内容才发现是纹理路径大小写不一致。Windows 和 Linux 分区对大小写的敏感度不同这类问题最折磨人。5.5 移动端存档和桌面端存档互不识别现象手机上进游戏看不到电脑上的存档地图从手机导出的存档放到电脑上可以加载但所有 Mod 专属内容全部缺失。原因存档本身虽然是同一个.msav格式但移动端存档默认关掉了一些桌面端的附加数据比如声音配置和逻辑处理器脚本的调试符号。更关键的是服务器地图和一些“玩家自带存档”的地图在存档头里写入的元数据字段不同手机端加载时直接跳过未知字段等再保存一次那些字段就永久丢失了。解决跨平台传存档时不要直接用手机导出的文件当唯一副本。建议在桌面端重新保存一次生成干净的桌面端版本再复制到手机。这样一来丢失的只有调试符号不影响正常游戏内容。在移动端和桌面端频繁往返时我固定走一个中转流程桌面端读取 → 另存为副本 → 检查 Mod 依赖 → 导出 → 移动端导入。这条顺序保证了一遍到位不会出现两边各改一次后数据互相覆盖的混乱。6. 进阶用逻辑处理器写自动化脚本把规则改成自己的逻辑处理器是 Mindustry 最值得深入的功能相当于游戏内置的一个 Lisp 小程序执行器。它能读取方块状态、单位状态、环境变量并控制单位的移动、攻击和输出信号。下面这段脚本实现一个简单的自动门禁当敌人靠近基地大门时开门敌人离开后关门。// 逻辑处理器自动门禁示例 // 第 0 行绑定距离最近的敌人返回变量 enemy sensor result1 switch1 enemy distance jump 6 result1 0 greaterThan 12 // 敌人距离大于 12 时跳转到第 6 行 control enabled switch1 1 0 0 0 // 给开关方块发送“启用”信号 end // 结束本帧 control enabled switch1 0 0 0 0 // 第 6 行关闭开关 end逻辑上分三步sensor指令探测指定开关方块与最近敌人之间的距离存到result1jump做条件跳转距离大于 12 时跳到关门的代码否则执行开门的代码control enabled是真正的输出指令把开关状态改成 1 或 0。这个脚本不需要额外 Mod内置逻辑处理器方块的玩家可以照抄。实际改参数时注意distance的单位是格子不是像素判断阈值改成多少取决于敌人的移动速度和你需要提前开门的时间窗口慢速地面单位设为 10 格足够快速飞行单位建议 15 以上否则门还没完全打开敌人就已经进到门框里。比起直接给炮塔加子弹这类脚本的价值在于把“固定自动化规则”和“地图设计”解耦。你可以做一个“哨戒炮模式切换器”白天炮塔只自动攻击地面单位晚上改成优先拦截飞行单位逻辑处理器脚本里用time变量读游戏内昼夜时间配合jump分支实现。这种自定义逻辑跑在服务端所有玩家看到的都是同一个规则不会因为客户端 Mod 不同而分叉。最后分享一个我自己的检查习惯。逻辑处理器脚本最坑的不是语法而是“你以为是并发实际是顺序执行”。整个脚本每帧执行一次从上到下跑完就结束没有任何异步回调。所以你写脚本时如果用变量 X 存了一个计算结果本帧往下走引用的是新值但下一帧开始时又恢复成初始值。这导致很多新手写“状态机”类逻辑时以为变量会保持结果发现状态永远停留在上一帧。我后来强制自己在每个脚本前先把所有输入变量读一遍、在所有出口处写一遍中间过程不依赖跨帧记忆这个习惯让脚本稳定了非常多。如果你也打算复现这套流程建议先跑通第 4 章的本地构建再去沙盒模式里造一个逻辑处理器试上述门禁脚本最后才改服务端参数。有了这几步Mindustry 对你来说就不再只是一个塔防黑匣子而是一套看得见、拆得开、改得动的沙盒系统。希望帮到你。本文还有配套的精品资源点击获取