2023 年 9 月，Unity Runtime Fee 政策发布的那天，我在群里跟着起哄调侃“Unity大概是嫌用户太多”。经历了很多挣扎，我逐渐踏上了学习 Godot 引擎的道路，开始了这场从商业引擎到开源世界的迁徙。
《游戏编程模式》这本书，我想很多人和我一样，在 Unity 时代翻过几遍。它把头疼的架构问题拆成了可落地的模式。在 Godot 里实践这些模式时，我意识引擎的基因差异。Unity 的 Component/GameObject 架构和 Godot 的 Node 树，决定了很多模式的落地方案需要重写。
于是有了这个指南。
这不是简单的翻译，也不是“把 C#代码换成 GDScript”的体力活。我花了一段时间， 当然也接住了，把书中 19 个经典模式在 Godot4.2 里重新实现：用 Signal 替代事件委托，用 Node 组合替代继承，用内置的动画状态机简化状态模式……每个模式都保留了核心思想，但因地制宜。代码部分提供了 C#和 GDScript 的双版本——如果你像我一样有 Unity 背景，看着 C#会更亲切；如果你想深入引擎风格，GDScript 的实现会更“Godot味儿”。
开源社区教会我一件事：贡献不是一定要做惊天动地的大项目。把踩过的坑整理成文档，让一个后来者少走弯路，就是对开源最好的支持。希望这个指南，能成为你在 Node 树里辗转时的手边小册子，或是在 C#项目里调试信号时的参考资料。
如果你刚打开 Godot，觉得 Camera2D 和 Node2D 的层级很难理解——这很正常。我的建议是：
- 从官方 Demo 开始：GitHub 上的官方 Demo 仓库是最好的教材。直接下载运行，然后用自己熟悉的语言（C#或 GDScript）重写一遍。比起看文档，这种“看到别人怎么拼积木”的方式进步更快。
- 理解 Node 的哲学：Unity 的 Prefab 思维和 Godot 的 Scene 思维是不同的。前者像零件，后者像俄罗斯套娃。当你开始用 Scene 作为资源（而不是预制体）来思考问题时，Godot 的界线就打通了。
- 不要太抗拒 GDScript：接触过静态类型语言的开发者往往抵触动态脚本。但 GDScript 和 EngineAPI 的设计是强绑定的，在某些场景下（比如快速原型和工具开发）反而更高效。建议用 C#做架构，用 GDScript 做细节，混合开发反而会让节奏更顺。
模式不是银弹，是工程师的词汇表——有了这个词汇表，才能和技术美术、策划用同一套语言沟通。我的体会是：
- 先忘掉“设计模式”四个字，从游戏系统下手。比如你现在要做的核心系统是角色移动，就把它拆成几个部分：输入监听（Command 模式雏形）、移动逻辑（Strategy 模式）、状态切换（State 模式）。代码写完后，再回头对照书看：哦，原来这坨东西叫“策略模式”。
- 别一次性重构完整个项目。新手常犯的错是：“我要把整个项目升级成事件驱动架构”，然后两周后面对几千行面目全非的代码陷入迷茫。从一个小系统（比如 Buff 管理）开始重构，验证思路，再逐步扩散。
- 把模式当成“交流工具”。当你 review 同事的代码时，一句“这块逻辑可以抽成 Observer 模式，减少 Update 循环里的耦合”比“我觉得这样不好”有用得多。模式这个词，让技术讨论有了抓手。
- 保持版本仓库干净。每次实现一个新模式，单独开一个分支。两周后用
git bisect回归测试，你会发现有些模式在真实项目中并不适用——这没什么丢人的，删掉分支就好。设计模式的本质，是让你有底气说“这段代码可以更好”，而不是“我必须让它完美”。
好了，废话到此为止。
Node 树就在那里，等着你去拼装自己的游戏世界。
—— 作者伍澄怀 2025/09