个人游戏技术方案案例：解谜游戏为什么从 Unity 改选 Godot

写在前面：引擎选择不是投票题

很多个人开发者选引擎时，会把问题变成“Unity 好还是 Godot 好”。

这其实问错了。

更准确的问题应该是：
对这个项目、这个开发者、这个发布目标来说，哪个方案能用更低风险把游戏做完？

叶棠做过一款 2D 机关解谜游戏。
玩家控制一名邮局修理员，在老城的气动管道系统里切换阀门、改变气流方向，把信件送到不同房间。

最早原型用 Unity 做。
两周后，他改用 Godot 重新搭了一版。

这不是因为 Unity 不适合 2D，也不是因为 Godot 天然更先进。
真正原因是：这个项目的核心风险不在渲染、不在平台、不在复杂插件，而在关卡制作效率和系统可理解性。

Godot 更贴近他的实际约束。

一、先定义项目的技术需求

叶棠没有从引擎功能表开始选。

他先把游戏拆成几个确定需求：

• 纯 2D，固定分辨率适配
• 目标平台只考虑 Steam 桌面端
• 无联网、无排行榜、无创意工坊
• 大约 80 个手工关卡
• 每个关卡由管道、阀门、压力门、信件、计时器组成
• 需要快速重置、撤销一步、关卡内状态回放
• 美术以手绘贴图和少量骨骼动画为主
• 开发者本人熟悉 C#，但也能接受 GDScript

这个列表很重要。

它让选择不再抽象。
如果游戏要做复杂 3D、主机移植、大量插件接入，结论可能不同。
但当前项目是中小型 2D 解谜，最重的工作是关卡和规则迭代。

二、Unity 原型暴露的问题

Unity 原型一开始跑得很快。

叶棠用 Tilemap 做房间，用 ScriptableObject 配置机关，用 Prefab 放置阀门和管道。
基础玩法两周就能跑。

问题出现在第三周。

他发现自己开始被几件事拖住：

• 场景里对象层级越来越深
• 关卡状态分散在多个 MonoBehaviour 中
• 撤销系统需要从各个组件回收状态
• Prefab Variant 变多后，查问题很烦
• 编辑器运行和停止之间，有些临时状态容易混淆
• 小功能经常要在 Inspector、脚本和场景之间来回切

这些问题不是 Unity 的错。
Unity 足够强，但它也鼓励开发者把逻辑散落在组件上。

对一个需要精确状态回放的解谜游戏来说，状态分散是隐患。

叶棠意识到，如果继续这样做，后期每加一种机关，都要担心撤销、重置、序列化和测试。

三、Godot 方案的关键优势

Godot 吸引他的不是“开源”这个标签，而是几个具体点。

第一，场景和节点结构更轻。
每个机关可以是一个小场景，组合关系直观。关卡也是一个场景，但运行状态可以集中交给一个 LevelState 管理。

第二，GDScript 写迭代逻辑很快。
解谜规则经常需要调整，脚本热重载和较短的语法让他更愿意频繁试错。

第三，资源格式相对透明。
Godot 的 .tscn、.tres 对文本 diff 更友好。虽然不是所有冲突都好解，但个人项目里阅读和排查资源变化更轻松。

第四，2D 工作流足够直接。
这个项目不需要复杂渲染，不依赖 Unity Asset Store，也不需要大型动画系统。Godot 的 2D 节点、TileMap、AnimationPlayer 已经够用。

最终不是 Godot 功能更多，而是它减少了项目不需要的重量。

四、核心架构如何设计

换引擎后，叶棠没有把逻辑继续分散在节点里。

他定了一个原则：

关卡对象负责表现和输入，关卡状态由集中数据结构负责。

大致结构是：

• LevelController：控制关卡生命周期
• LevelState：保存每个格子的压力、机关状态、信件位置
• RuleSystem：根据玩家操作推进一帧逻辑
• EntityView：根据状态刷新动画和视觉
• UndoStack：保存操作前后的轻量状态差异
• LevelData：保存关卡初始布局和元数据

这样做有两个好处。

第一，撤销和重置变简单。
撤销只需要回滚 LevelState 的差异，而不是让每个节点自己记忆过去。

第二，测试更方便。
规则系统可以在没有完整场景的情况下跑一些简单测试，比如“打开阀门后压力是否按方向传播”。

个人游戏不一定需要很复杂的架构。
但只要玩法依赖精确状态，就应该尽早把状态边界划清楚。

五、为什么没有继续用 C#

Godot 也支持 C#，叶棠本来想继续用。

但他最后选择 GDScript。

原因很务实：

• 项目规模不大，性能压力低
• GDScript 与编辑器集成更顺
• 导出和工具链少一个变量
• 官方示例和社区问题更容易对应
• 他需要快速改规则，而不是写大型业务层

他把性能敏感点留了余地。
如果后期压力传播算法真的慢，可以再用 C# 或 GDExtension 优化。

但在项目早期，他不想为了“可能的性能问题”增加真实的工具链复杂度。

这是个人项目很重要的判断：
不要为尚未出现的问题提前支付过高成本。

六、迁移成本怎么控制

叶棠没有一次性重写所有东西。

他先做了一张技术验证表：

每项通过后，才正式放弃 Unity 原型。

这避免了“引擎切换循环”。
换引擎不是情绪决定，而是验证决定。

七、最终取舍

Godot 方案也有代价。

叶棠放弃了 Unity 更成熟的插件生态。
某些编辑器扩展需要自己写。
如果未来要做主机移植，路径也不如 Unity 熟悉。

但这些不是当前最重要的问题。

当前最重要的是：

• 一个人能否持续做 80 个关卡
• 规则系统是否容易理解
• 撤销和重置是否可靠
• 美术和关卡迭代是否轻
• 项目半年后还能不能维护

在这些指标上，Godot 更合适。

结语：选让项目变小的技术

叶棠的案例不是“解谜游戏都该用 Godot”。

它说明的是：技术方案应该服务项目风险。

如果你的风险是 3D 性能、插件生态、商业平台支持，Unity 可能更稳。
如果你的风险是 2D 规则迭代、关卡制作、状态可控，Godot 可能更轻。

个人游戏选技术，不要选让自己显得专业的方案。
要选让项目变小、变清楚、变可完成的方案。