《Project Survivor》开发日志 10-22

上一个坑因为玩法问题需要回（diu）炉（dao）重（yi）造（bian），并且因为前段时间Unity整了个大活，一直想试试Godot引擎。正好小伙伴们说想要做个幸存者like游戏，于是就挖了这个新坑《Project Survivor（暂名）》。

Unity vs. Godot

首先是比较值得关注的 Unity vs. Godot 问题。关于Unity的活就不链接了，网上能搜到各种来龙去脉。然后现在的问题是，Godot在2D独立游戏开发方面能不能替代Unity？ 我在此冒昧总结一下一周的Godot使用经验。先叠个甲：本人非专业 Unity / Godot 开发者，以下内容皆为实际使用感受，欢迎指出错误/改进之处，但如果要搞引擎宗教战争那就是你对。

Godot优点

- 2D支持。虽然Unity理论上也能直接上2D模版并且我一直就是用Unity做2D游戏，但毕竟两个引擎的“根”不太一样，一个是3D一个是2D，很多细枝末节的地方就有顺手和不顺手的区别，例如想要把RPG Maker格式的角色行走图做成四方向角色行走动画，Unity的animator要费老大劲，Godot的切片/Frame支持就很简单直观。

- 版本控制（对于Git而言）。Unity的Scene文件在版本控制中一直是让人十分头痛的问题，网上找到的建议都是说要多切prefab和同时载入多个scene，但这些操作本身也很繁琐和易出错，尤其是在多人非专业合作场景下。Godot因为它强制性的Node / Scene Tree结构，观察下来每次的改动都会限制在比较小的范围内，对版本控制很友好。当然Unity也有官方的Collab，或者用Perforce之类的，但我不想付费/设置服务器。

- 轻量。从历史和功能覆盖面来看，Godot无疑是要比Unity轻量许多的。当然这个对一部分人来说不一定是优点，但对我这种玩票型开发者来说轻量化带来速度优势的同时又够用就行了。最明显的例子，我现在用的是Godot+C#，从编辑器编译启动游戏的时间小于两秒，同样体量的游戏在Unity下动辄5秒+的编译启动时间（项目已禁用Reload Domain）。这其中的差距不是简单的3秒钟，因为我经常在这3秒里面走神去刷视频然后半小时过去了。如果用Godot+GDScript那编译时间是趋近于零，不过我还是比较习惯用静态语言。

- 开源。这个就很明显了。上市公司对股东负责，而开源项目对开发者负责。免费项目很可能在人力支持上比不上商业项目，但一旦路线错误，功能也可能沦为堆砌（例如IMGUI vs. uGUI vs. UI Toolkit，半成品ECS，砍掉第一方游戏，隔三差五的需要登录才能使用引擎）。

Godot缺点

- 输出平台限制。这个对很多游戏来说应该是死穴。目前来说Godot主要比Unity少了主机输出支持，要上主机的话比较普遍的解决方案是购买第三方服务。另外Godot 4.1的HTML输出在MacOS和iOS上直接卡死（!!），C#也不能上HTML和移动端，所以我目前用Godot 3.5。

- 打磨问题。主要体现在一些日常小地方上打磨不足，例如我的 Godot 3.5 + C# + Visual Studio Code 的开发环境需要把编译程序改成dotnet CLI才能不让VS Code崩掉，但这个问题没有在Godot设置教程中提到。还有就是九宫格切片（Nine Patch Rect）默认的边缘缩放方式居然是xy方向同时拉伸而不是平铺。

- 社区支持。Godot的社区明显比Unity要小很多，从搜索引擎数据上就能从侧面反映出来。社区小就意味着教程和讨论更少，对于我这种水平一般的开发者来说还是有不少不便的。当然得益于Unity整活，不少2D独立游戏开发者把目光投向了Godot，所以未来可期。

Project Survivor

断断续续一个星期下来，Godot的使用体验还是可以的，还没碰到过不去的坎。至于项目本身的进度，目前就如图2所示，实装了简单的玩家/敌人移动，下一步就是武器系统了。感谢有幸存者和各种幸存者like珠玉在前，可以好好分析一下怎样的武器数据结构才能兼容开发的扩展性和易用性。