写在前面：支持 Mod 不是一句“开放社区”就够了
很多个人开发者希望游戏有 Mod。
这很自然。
Mod 能延长寿命，带来社区内容，也让游戏看起来更有生命力。
但技术上，Mod 支持意味着长期承诺。
你要处理：
- 文件格式
- 兼容性
- 编辑工具
- 安全风险
- 崩溃归因
- 版本升级
- 内容审核
- 玩家安装和卸载
- 官方内容与玩家内容边界
柏舟做过一款小型回合制策略游戏。
玩家在一张 8x8 的浮岛棋盘上移动工匠、修桥、抢资源，让岛屿在风暴前保持连通。
游戏很适合玩家自制关卡。
测试时，很多人问：“正式版会不会支持 Steam Workshop？”
柏舟很心动。
但他最后没有第一版就做完整 Workshop 和脚本 Mod。
他先做了 JSON 关卡导入和游戏内关卡编辑器，把 Mod 范围控制在“自定义关卡”。
这个选择让社区有创作空间，同时没有把项目拖进不可控复杂度。
一、先定义玩家真正想改什么
柏舟没有把 Mod 当成一个整体。
他把玩家可能想改的东西列出来：
- 自定义关卡布局
- 自定义风暴规则
- 自定义单位能力
- 自定义美术皮肤
- 自定义剧情事件
- 自定义胜利条件
- 自定义脚本逻辑
然后判断哪些最符合当前游戏。
测试反馈显示，玩家最想做的是关卡。
他们想设计更难的桥梁布局、更奇怪的资源点、更紧张的风暴倒计时。
很少有人真的需要改单位底层能力。
所以第一版 Mod 目标被收缩为：
允许玩家创建、分享和导入自定义关卡。
不开放任意脚本。
不开放核心规则修改。
这个边界非常重要。
二、为什么不用 Lua 脚本
柏舟懂 Lua，也考虑过把关卡逻辑开放成脚本。
这样玩家可以写复杂事件，甚至做全新模式。
但问题也很明显：
- 脚本沙箱要设计
- 错误脚本会导致崩溃
- 玩家需要学习编程
- 官方要维护 API
- 版本更新可能破坏脚本
- 恶意脚本有安全风险
对一个个人开发者来说，这些都很重。
更关键的是，玩家当前不需要这么强的能力。
如果 90% 的创作只是摆地图和调参数，那开放脚本就是过度设计。
技术方案应该匹配真实创作需求，而不是提前满足想象中的高级用户。
三、JSON 关卡格式如何设计
柏舟选择 JSON，不是因为它最适合所有 Mod。
而是因为：
- 人类可读
- 容易生成和校验
- 不需要额外解析器
- 可以手动编辑
- 和游戏内编辑器互通
一个关卡文件大致包含：
{
"schemaVersion": 1,
"id": "wind_bridge_01",
"title": "风中的断桥",
"author": "player",
"boardSize": [8, 8],
"turnLimit": 18,
"tiles": [],
"units": [],
"resources": [],
"storm": {
"startTurn": 6,
"pattern": "clockwise"
}
}
他没有允许 JSON 里写表达式或代码。
所有字段都是数据。
游戏只解释白名单字段，未知字段忽略或报 warning。
这样安全很多。
四、校验比导入更重要
玩家自制关卡一定会有错误。
比如：
- 起点被障碍挡住
- 目标点不存在
- 风暴规则无效
- 单位放在水面上
- 回合数为负数
- 使用了旧版本字段
柏舟写了一个关卡校验器。
导入时检查：
- JSON 是否能解析
- schema 版本是否支持
- 必填字段是否存在
- 坐标是否越界
- 是否至少有一个可完成目标
- 是否引用不存在的地形或单位
- 是否可能开局立即失败
错误信息尽量写给玩家看，而不是只打印技术日志。
例如：
“第 4 行第 2 列放置了工匠，但该格子是水面。”
这比“invalid unit position”更有用。
Mod 支持的体验，很大一部分来自错误提示。
五、游戏内编辑器降低门槛
如果只支持 JSON 文件，能创作的人很少。
柏舟做了一个轻量关卡编辑器：
- 选择地形
- 放置单位
- 设置资源
- 调整风暴开始回合
- 测试运行
- 导出 JSON
- 导入 JSON
编辑器不漂亮，但足够用。
他没有做复杂的拖拽脚本、事件时间线或自定义 UI。
因为第一版只服务关卡创作。
这让玩家不需要理解文件格式，也能参与。
同时，高级玩家仍然可以手动改 JSON。
六、Steam Workshop 为什么延后
柏舟没有首发就接 Steam Workshop。
原因有几个：
- 自定义关卡系统需要先验证
- Workshop 接入会增加 UI、上传、订阅、更新逻辑
- 内容审核和举报要考虑
- 非 Steam 平台怎么办
- 关卡格式还可能调整
他先做本地导入导出。
让玩家通过社区分享文件。
如果发售后自制关卡真的活跃，再接 Workshop。
这个顺序更稳。
很多功能不是不能做，而是要等核心格式稳定后再做。
否则 Workshop 里早期上传的内容，很容易在版本升级中坏掉。
七、兼容性要从第一版考虑
柏舟在 JSON 里放了 schemaVersion。
每次格式变化，都写迁移：
v1到v2：增加天气字段默认值v2到v3：把风暴方向从字符串改成对象
如果遇到太旧的关卡，游戏会提示需要重新导出，而不是直接崩溃。
他还规定：
官方发布的示例关卡必须通过同一套校验器。
这能保证官方内容和玩家内容走同一条管线。
如果官方关卡有特殊后门，玩家关卡系统会越来越难维护。
八、最终取舍
柏舟的第一版方案是：
- 支持本地 JSON 关卡
- 提供轻量游戏内编辑器
- 不开放 Lua 脚本
- 不开放核心规则 Mod
- 暂不接 Steam Workshop
- 所有关卡走校验器
- 格式包含 schema 版本
这个方案让玩家能创作最需要的内容，也让开发者还能维护。
它不是最自由的 Mod 系统。
但它是适合第一版的 Mod 支持。
结语：Mod 支持要先开放稳定边界
柏舟后来收到一些高级玩家请求，希望开放脚本和 Workshop。
他没有立刻答应。
因为他知道，一旦开放，就要长期承担兼容和安全责任。
个人游戏做 Mod 支持，最重要的是边界。
先开放低风险、高价值、易验证的部分。
如果社区证明需要更多，再逐步扩大。
Mod 的目标不是让玩家随便改一切。
而是让玩家在稳定规则里创造更多乐趣。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。