《领航员多利》开发日志

本文系用户投稿，不代表机核网观点
各位好，我们是 CATO 的制作组 Team Woll。这次我们也参加了 BOOOM Jam 2025，和大家分享下我们 21 天内制作《领航员多利》的历程。 
《领航员多利》是一款平台跳跃游戏，玩家控制多利这个角色触碰技能环制造分身，通过自爆技能把分身弹飞到高处、远处，而玩家的控制权也会在各个分身之间转移，循环交替自爆到达终点。

早在本次 gamejam 之前，我们就下定决心不做 2D 平台跳跃。这次的创意来源是 Frank 的一句话：玩家通过奉献自己把跟随者送到悬崖对面。这本来是 Frank 的废案之一，但这句话激发了我。我觉得无论从切题还是玩法角度出发都很有意思，在我们仔细讨论后，发现这个玩法还是在 2D 平台这个框架下最容易执行，所以又做回了本行。
可以说这次 gamejam 相当顺利，第一天就确定了创意和机制。jam 的第三天我用 Corgi Engine 试了一下执行难度与游玩可行性，觉得有戏，于是我们开始投入制作。接下来由 Frank 自述风格概念部份。

风格概念
以下由美术 Frank 叙述：
在 gamejam 开始之前，我就决定这次要尝试一些不一样的渲染风格。之前的作品我们一直采用 Toon Shader 的卡通渲染，这次则想看看 PBR 材质能带来怎样不同的效果。不过，PBR 流程相比之下制作步骤更繁琐，为了能在有限时间内完整跑完流程，我决定在前期概念上尽量节省时间，为后续制作留出更多空间。毕竟我们对 PBR 工作流还不熟悉，所以这次在画面呈现上的最大挑战是保证完成度。
角色因为一开始的「克隆」构想，Blasin 起了个很巧妙的名字叫「多利」，灵感来自克隆羊多莉。也就早早的定下了主角形象是个女孩，我觉得她很干练很利索很轻盈，起初，我尝试过几个类似「探险家」风格的设计，但总感觉不太合适，后来就构想了一个由贝壳曲线构成的奇装异服。

之所以选择贝壳作为设计元素，是因为我们没能找到一个现实中合理的理论，来解释游戏里「触碰能量球后克隆出一个时间错位几秒的自己」这个行为。所以干脆就想构建出一个纯粹幻想的世界好了。正巧那两天去了一个商场的贝壳展，在一堆贝壳堆叠的结构就像是一个异世界，于是就这么定了下来。

场景概念也没有用多久时间去设计，稍微花了点时间画了比较精细的概念用于沟通后，基本就是一堆鬼画符里确定自己想要的氛围和结构，尽快的进入到后面的制作过程。

最初构想的世界观是一个资源匮乏的后启示录世界。在这个背景下，一些决心向外探险的人们，抵达了一个个前文明遗落的「灯塔」。他们决定奉献自己点亮这些灯塔，让其在天空中形成繁星般的指引，为后人导航前行，这个游戏结局也算是我们切题的一个方式。
然而，仔细评估后发现，要完整呈现这些概念，所需的美术工作量实在太大。于是我重新调整了设定，将背景设定在一个地下的、犹如深海的、烟雾缭绕的、废弃的环境。在确定这一氛围后，我们就开始制作素材了。

游戏机制
以下由程序 Blasin 叙述：
游戏一开始只有外爆这个技能，我总觉得它的操作稍微反直觉了一点，玩家需要有一点路径折返的操作才能把复制人发射出去，所以我把它改为内爆，玩家只需要往目标方向前进，就能直接发射复制人，降低了一点操作门槛。
后来我们发现内爆外爆这两个技能并不冲突，他们是一种操作进阶的关系，这种进阶操作是方向翻转的感觉，让我想到铲子骑士中幽灵DLC后期体验，所以我更加确定这个机制的发展方向。再加上二段跳解锁，这三个能力足以覆盖这个体量下的游戏体验，保持新鲜感。

自爆推拉这个机制我们感觉还挺好发散可能性的，比如自爆可以直接爆破墙体，适合作为上手教程的体验。往进阶方向走，自爆又可以像原力一样推拉机关。但很可惜由于制作规模控制，没能把这些做到体验中，如果各位玩家有其他建议欢迎分享！
多亏 CATO 项目对 Corgi Engine 的熟悉，我这次的控制器搭建效率很高，在 CATO 开发初期，我会根据需求魔改框架，但后期遇上一些 BUG 之后，我老老实实花时间阅读它的代码，顺着 Corgi Engine 的架构开发自己的需求，所以这次吸取了教训。
当然，使用这种高级插件也有一定挑战，主要是学习门槛较高，而且复杂度有时超出掌控。用插件时，往往像是在一个黑盒里操作。比如这次我使用 Corgi Engine 的声音管理系统，结果打包后发现 BUG，导致游戏完全没有音效，只有 BGM。这也算是高级插件使用中的一个典型问题——当它好用时效率极高，但一旦出问题，排查和修复都不太轻松。

地图设计
在我们确定这是个 2D 平台游戏后，我们又自问了一句：能不能是银河城的地图结构？我们一直想挑战类银河战士的游戏制作，一是喜欢能力解锁感，二是喜欢地图的迂回结构。Frank 琢磨了一会设计，我们发现这次确实适合采用这种地图结构，而不是 CATO 那类独立关卡的结构，所以本次决定挑战下我们的制作能力。
在我们确定技能解锁顺序后，Frank 以他惊人的直觉完成了整个游戏的地图草图设计，在制作阶段仅有少量细节打磨，设计目的几乎没有变动，十分高效。

这段时间，我到南京玩了几天，期间我们花了点时间把整个游戏流程跑完。虽然我们已经习惯线上工作，但不得不说，线下面对面交流效率更高，很多细节沟通更顺畅。

在地图完整设计确定后，我便开始在引擎内铺设地图，每个房间边铺边验证， 执行得相当顺利两三天就完工。Frank 地图设计几乎不变，仅有少量修改打磨，我们不得感叹：比做 CATO 谜题关卡容易多了！下图左为 Frank 终稿，右为在引擎内铺完的样子。

不得不吐槽，Unity 到了最新的 6.0 版本，Tile Map Editor 依旧很难用。好在这次我们的需求比较简单，基本是静态 Tile 涂抹，勉强还能应付。我最近趁空闲时间学习了 LDtk 来铺设关卡，实时编辑与测试的效率实在太高了，期待下次项目能正式用上。

这次我也顺便公开我接入 LDtk 的关卡编辑工作流，只需要《领航员多利》的游戏本体 + LDtk 就能编辑测试关卡，感兴趣的朋友可以试试看，以下是这个关卡编辑工作流的教程视频。
开发时间过半，我们已有一个完整的关卡流程体验，虽然游戏使用 place holder 显得表现力很干，但我们对游玩体验很满意。
这次和 CATO Game Jam 时的体验完全不同，那时候我们对关卡设计很没信心，甚至到后期只想着做完就算，没有过多在意可玩性。而这次《领航员多利》发布后，我们依然觉得它真的很好玩。

这是我第一次在 jam 后期还有空修 bug，实在是种奢侈的经历。主要因为这次 Frank 给自己上了强度，花了更多时间制作美术，下面由 Frank 叙述全 PBR 流程的工作流。
美术资产制作
由于我比较喜欢在建模的过程做设计，所以在之前的几次JAM的时候都没有给自己准备草图，其实是带来了不小的时间上的压力，于是这次不论是人还是场景的建模都还是乖乖的画了点给自己看的示意图。

事实上尽管多了一个我以为没有太大意义的步骤，但其实还是给自己节省了一些时间，它的意义除了快速迭代灵感以外。还有相当于我在纸上总结记录之后建模的流程。而且它既然只承担「笔记」的功能，所以也不需要画太精细，自己能看懂即可，其实也并没有花多少时间。
多利的角色模型花掉了不少不必要的功夫，而且这还是第一次在 jam 中制作完整的人物3d模型，还很兴奋的去绘制材质金属度粗糙度贴图，但没想到在最终画面占比上这么小导致完全看不出来（本来还兴冲冲的想去制作高模烘焙一个法线，还好没有这么做）

事实上即便前期压缩了大量的时间，在实际制作的时候发现时间依然很紧张，很多东西没有做出来。为了想去充分发挥PBR带来的光影，每个单位的建模时间也增加了不少。

在PBR流程可以更方便的去利用更多的光源来制作光影效果，但同时带来的是它不像之前卡通渲染的情况下拥有完整的对颜色的控制权，在自己不熟悉的情况下为了保证有充足的调整空间，材质结构上也尽可能的省略，只保留了必要的遮罩贴图，物体的材质固有色配色都留给了在引擎的shader里做统一调整。
然而，即便如此还是出了点问题，我这次还是没画经过深思熟虑后的氛围概念，本来色彩感觉就不是很好的我在引擎中去直接调整色彩成了难题，消耗了不少额外的精力去调整，还好最后的呈现还算不太糟（看来以后的制作中氛围概念图也逃不掉了）

AI 编程助手 Cursor
以下内容由程序 Blasin 自述：感谢 AI 时代，这次编程助手 Cursor 帮我做了不少体力活。要讲清楚 Cursor 的用例其实挺难的，因为在使用这个工具时，很多操作几乎是直觉反应，不需要太多逻辑思考。如果硬要归纳成文字，反而显得琐碎。不过我觉得分享它的潜力很有意义，所以还是尽量整理了一些使用体验和成果：
- 编写技能环自转，用上 sonnet 3.7 MAX
- 创建基于帧插值的动画系统
- 编写角色位置回放与慢放插值系统
- 编写音频处理小工具
- 编写 Unity Editor 工具方便美术对接工作
Cursor 编写的技能环自转
在讨论技能获取的环状物体时，我们设想它缓慢自转，玩家互动时有种拨动的感觉。起初，我把这些描述交给 Cursor，让它生成脚本，但运行后发现，物体在缓慢自转时，方向切换过于生硬。
经过几轮对话后它仍然无法满足需求，以我目前使用经验，要么是我说的需求不对，要么是他智商不行，于是我尝试手动换 sonnet 3.7 MAX，果然达到了理想效果。在调整完动画后，我还让 Cursor 编写了一个 Manager 类，统一管理 update，从而减少性能消耗。

Cursor创建基于帧插值的动画系统
在 GDC 上，我学到了基于帧插值的动画工作流，《Very Very Valet》这款游戏也提到了这种工作流。它的好处是给予更多程序控制动画节奏的空间，使得角色控制器更及时响应玩家的输入，获得更好的操作手感。但这两个教程都只有思路，没有提供具体实现。

Cursor 很擅长快速搭建架构，这回我正好用它试试，不出意外它成功帮我搭建了这个动画架构，使用的是 Unity Playable，而在这之前我对这个 API 一无所知。区别于 Unity 的旧 Animation 和新 Animator 动画系统，Playable 没有可视化界面，更依赖代码对 Animation Clips 的操控。
我一直想在 jam 使用这个动画工作流，因为它可以节省美术程序联调的时间。比如跳跃动作，美术只需提供几帧关键帧，程序可以直接调整动画节奏，灵活高效，非常适合异步协作。摆脱 Animator 的意大利面管理后，在代码中也可以有更灵活的动画过渡写法，更接近自然语言描述。
通过 Cursor 的交互，我还学到新知识，Avatar Mask 其实并不是什么底层功能，而是 Humanoid 动画的标准化处理，可以自动传入骨骼 Transform。

Cursor 编写角色位置回放与慢放插值
在游戏中，玩家身边有一个跟随分身，本质是一个回放玩家路径的系统。我一开始使用的是按帧记录和回放，虽然理论不严谨，但 Jam 阶段勉强够用。后来手感验证发现，我们还需要一个 slow motion 慢放系统，来降低玩家的输入门槛。
在 AI 时代前，我肯定会直接放弃这个功能，因为这种精细控制的编程工作耗时费力。这次有了 Cursor，我直接让它修改现有系统：位置回放改为基于帧插值，适配不同的 TimeScale。等我上个厕所回来，Cursor 已经帮我搞定了，开箱即用。

Cursor 编写音频处理插件
音频处理一直是我们 Game Jam 制作的痛点，最常见的问题无非就是：1.上网找到的音频音量太大 or 太小，2. 音效的触发时机不符合需求。解决这两个问题往往需要笨重的剪辑软件工作流，又或者写耦合性高的代码处理音频的音量和播放时机。
实际上，要解决上述的问题，我的需求无非就是：1. 把所有音频文件粗暴地调到一个平衡响度，2. 剪掉音频前 0.1s 的空白音频。我总觉得我得写出这样一个小工具解决这些 jam 阶段的音频痛点，而这次 Cursor 终于给予了我勇气，最终我花了一下午就把音频处理工具搞定。

整个工具基于Python 脚本，调用 ffmpeg 库进行音频处理。Unity 编辑器作为前端界面，调用脚本处理音频文件。Cursor 甚至顺手帮我安装了 ffmpeg 和 Python 3，省去了不少麻烦。
有了这个音频编辑小工具，我现在的工作流是直接在游戏内操控角色跑跑跳跳，边使用音频编辑器对齐音效触发时机。这样一来，音效的调整也变得 WYSIWYG（所见即所得），免去了来回修改和验证的繁琐过程。这与之前提到的动画工具搭建目的如出一辙——都是为了在创作过程中**减少工具阻碍、提升反馈效率**，让我能更专注于调试和完善细节。

Cursor 使用体验总结
能在 Game Jam 写代码即注重功能又注重性能，是我本次使用 Cursor 最深的体会，现在我已经习惯边写功能边让 Cursor 优化性能。在 Game Jam 后，我经常把一些可复用工具类的代码提炼出来日后使用，所谓 don‘t repeat yourself。有了 Cursor，这种提取和抽象基类的体力活变得更加轻松。
和 Cursor 交流多了，我也建立起这样的直觉：对于定制化较强的需求，我会拆分问题跟它多轮对话，这样更容易得到准确的结果；而对于一些通用优化或者偏向范式的编程任务，我则倾向于直接一句话说明，省时省力。总的来说，还是得和它多用多交流，建立起自己的工具直觉，才能真正发挥它的潜力。

结尾
这次 Game Jam 的成果我们整体上还是挺满意的，虽然测试下来大家普遍觉得上手有点难，但这一点我们反而不太担心。毕竟有了CATO 项目的经验，如果未来把它做成完整版，我们有信心把引导和手感做好，希望各位再多多提意见！
写完这篇文章，这个项目也算是告一段落了。回过头来看，能明显感受到我们在CATO 项目两年里积累的能力得到了提升和运用。希望在接下来的商业作品中，我们还能发挥这份积累继续创作！