6月我们带着一款名为《墓地轨道》的小游戏参加了Steam NextFest。这是我们尝试制作一款有趣的空间采矿增量游戏，具有实际的建造选择，而不是随机的技能树。无论如何，我们很喜欢这个Demo的机制和氛围，但Demo中可开采的结构较小：仅有几千个格子。对于正式游戏，我们希望有一系列从小型到25万格子的结构。游戏旨在让人更满足而非更具挑战性，类似于《高压清洗机》的风格但发生在太空中。所以如果玩家喜欢这个机制，我们希望他们有一些厚实的结构可以逐步推进。
NextFest的Demo是用Godot制作的，在那个规模下运行得很好。我们三人有15年的Unity专业使用经验，但非常喜欢Godot的发展方向，想做一些实验。但随着NextFest结束，我们意识到想要在游戏中加入更好的特效，同时在合理性能下实现那些大型结构目标。这是一个大问题。
以下是Godot版本的预告片供参考：
https://youtu.be/9otz9z1lUzY
切换到Unity进行性能测试只花了一两周时间。这次我们改用3D，虽然仍然是2D或2.5D的呈现方式，但使用3D意味着我们可以利用所有优化、我们已有的资产商店特效库以及自身经验。测试结果非常明确，于是我们下定决心，完全重建了游戏——这次使用Unity和3D。两个月后，我们有了新的Demo，对结果非常满意。
除了性能之外，对我而言一个真正的风险是失去Godot版本的“Demo魔力”和氛围。我在Godot版本中花了两个月时间，用像素艺术和2D图形构建美学。到NextFest时，我对最终效果和游戏手感非常满意。
游戏的氛围和感觉往往是难以捉摸的因素。我们花数小时打磨机制，几乎没有任何视觉元素。我们不得不紧紧抓住脑海中那个不断变化的、模糊的最终游戏概念。正因如此，一旦找到自己喜欢的东西，就很容易变得珍贵。有时结果像是幸运的巧合，你不想搞砸它。在我们的案例中，我们可以保留Godot版本作为备选，并启动一个新的Unity项目尝试复现已有内容。我认为强迫自己去重建但做得更好，或者在已经满意的基础上进行改进，需要我们分解那些让我们喜欢的东西的要素。
我们通过Game Jam来练习整个游戏开发周期的迭代，但那些风险较低。我认为在已经喜欢的东西上进行优化、重建和迭代，能让我们获得同样的练习收益，但更精确、更精致，因为难度和风险都高得多。
无论如何，我认为这对那些因任何原因考虑重做游戏的开发者可能有帮助。涉及的工作量可能带来风险，但如果直觉告诉你必须改变，那么相信直觉并至少尝试一下是好的。我们唯一的风险其实是那两周的实验时间。我们本来很可能不满意，然后回头以有限的方式完成Godot版本。我很高兴最终成功了。
另外，对于Godot粉丝们，我也是其中一员。我把Godot的问题更多地归咎于自己的无知和平台不熟悉，而非Godot的实际能力。最终，我们在Unity生态系统中的经验和资产库也同样是重要因素。
以下是我们从这次转换中获得的一些具体好处：
- 实现了我们想要的结构规模。最大的一个结构有25万个六边形格子。在Unity中，这只是一个通过属性块实现逐实例颜色的实例化绘制调用，运行流畅。下面还有一些注意事项。
- 改用3D但仍保持俯视视角。真实光照、URP泛光效果实现霓虹风格，我们终于可以使用之前购买的特效包，而不是手动制作每个效果。
- UI Toolkit。基础部分有7个空间站界面加上一个完整的飞船建造器。用UXML/USS配合一个共享控制台框架完成所有这些工作，比之前的方式快得多——只要熬过那些奇怪的阶段。
- 新的Unity CLI。重新编译、播放模式、为Steam、itch和Mac测试构建，全部从终端运行。一个项目，三个目标，无需点击构建窗口。
- 网页构建。因为性能更加流畅，所以可以尝试为itch等平台构建网页版本。虽然只能展示Demo大小的结构，但总比没有好。
一些小问题，主要来自网页构建。这里详细说明，因为我昨天刚完成网页构建。
- WebGL 2有一个16KB的统一块限制。一些资产商店着色器的GPU实例化变体超过了这个限制，而失败模式是静默的：物体根本不绘制。在这些材质上关闭实例化。
- 浏览器拒绝非点击触发的全屏请求，而itch嵌入的Unity会将该拒绝转化为一个巨大的错误弹窗。在网页上不要在启动时应用保存的全屏偏好。
- 使用默认异常设置时，网页上的空引用会导致WASM陷阱，而非记录的异常。有玩家因此丢失了80%的进度。改用“Full without stacktrace”选项修复了该问题。
新的Demo现已上线，欢迎尝试：
评论 (0)