多重身份下的自我迭代：独立游戏开发过程中一些创作流程的再设计

本文系用户投稿，不代表机核网观点

《语默行间》（Steam 链接）是一款操作老款手机收发短信的文字冒险游戏。它由我独自开发，所以需要一人扮演多职，包括但不限于项目管理、程序设计、剧本创作等。由于已经陆陆续续开发了六年多，一些过去作出的决定，到后来会显得不够成熟。这篇日志记录了我在扮演以上提到的这几种身份时，做出的几处创作流程上的改进。
项目管理：从更适合头脑风暴的 Miro 到结构化的 Fibery
最开始设计这个游戏时，我使用的是 Miro，一个支持多人协作的在线白板。我看中的当然并非它的协作功能，而是……那块无限拓展的白板。
在初期，有关这个游戏的各种点子都会时不时地跳出来，它们互相之间可能没有任何关联——这个点子和某段剧情有关，下一个点子和某个彩蛋成就有关，再下一个点子和载入界面的 UI 有关……我把这些点子全都记在 Miro 中唯一的一块大白板上，并尽量让同类点子挨得近一些。
这块白板的进化史大概是这样（具体文字已模糊化处理）：

看完截图很难不注意到越来越混乱的布局，最后这张截图甚至还不是我弃用 Miro 之前的最终版本。总的来说，这样的白板确实很适合“添加新点子”这个动作，加完以后看着满满当当的屏幕也会有一种奇妙的满足感。但是不要忘了，这块唯一的白板，承载着所有剧情、系统、程序、音乐等等等等的设计，等到要真正参考它上面的内容进行游戏制作时，我会浪费时间在找东西上、会被视野里的其它内容分心、甚至会需要抑制“想把一些文字排得更整齐”的欲望。
Miro 其实自带“看板”这个模块，官网的介绍图：

我也试过在我的这块大白板上直接添加一块看板，用来追踪任务的状态。但我相信术业有专攻，随着任务越来越多，在 2022 年，我开始寻找一款天生更适合项目管理的工具。
一番调研之后，我选择了 Fibery。简单来说，它是类似 Notion、类似飞书多维表格那样支持用不同的视图来查看结构化的数据库、但同时又支持白板的一款应用。我仍然看重支持白板，是因为我需要白板来可视化故事结尾处的剧情分叉，比如这样：

而利用它的数据库功能，我可以集中管理剧情中的所有“话题”（游戏中两个人的短信聊天会围绕某个”话题“展开）。
用“未完成、进行中、已完成”的看板视图来查看所有话题：

用“未指定年份、2006年、2010年、2014年、当下”（注意顶部分栏）的看板视图来查看所有话题：

类似地，我也可以按照优先级、按照角色来查看所有话题。
对于游戏系统需要实现的功能，我采用了“待办、进行中、已完成、已放弃”的看板视图，并且用任务所属的范畴（和载入有关、和选择有关、和声音有关，等等）来进一步对视图做横向分类：

除此以外，我还能用一个视图专门查看某个范畴里所有未完成的任务（在之前那个视图里由于空间不够需要点一下才能完整显示的任务，在这里直接就能完整显示）：

而对于“想起什么新的点子想要加到游戏里去”，我可以利用 Fibery 的 API，发送 HTTP 请求来添加一个待办任务到我称之为“快速待办”的集合里去。电脑上使用 Quicker，安卓手机上使用 HTTP Request Shortcuts，都能做到在很短的交互步骤内添加一个任务。
Fibery 也支持记录不那么结构化的内容，比如设计文档，开发日志、辅助编程使用的 AI Prompt 等等。比如这篇日志的草稿就是在 Fibery 里撰写的。
总之，迁移到 Fibery 之后，开发游戏的流程脉络清晰了不少。Miro 能做到“有什么都能记录下来”，但 Fibery 在一番初始规划之后，还能做到“记录在合适的地方，方便日后阅览和做出行动”，逐渐成为关于这款游戏的百科全书。
不过回过头看，我一开始选择 Miro 就注定了后来会发生这样的迁移。毕竟 Miro 首页的介绍就写得很明白，它是注重团队协作的一款白板应用，它从未自诩它的项目管理功能，只是我自己一开始需要一块头脑风暴用的白板，发展到后来才变成需要系统性地规划所有的剧情和任务。
程序设计：分离词句输入模块与渲染模块
游戏里用手机输入一句话时，会伴随一些删删改改的动作。我设计了一套简单的语法来控制这些动作：
`X`：下一个动作之前停顿  X 秒，打字时这个停顿的默认值是 0.2 秒
|X|：删 X 个字，删除之前默认停顿 0.1 秒
$一个词$：一个词一起出现，出现前的停顿默认是 {0.2 + 0.15 * 词长} 秒
<<X：光标前移 X 次（若 X 未出现，则 X = 1）
>>X：光标后移 X 次（若 X 未出现，则 X = 1）
 举例来说，如果原始输入是：
`1`$这是$一个`1.2`$例子$，我`2`$满满地$<<`1`|2|慢慢`1`>>`2`$打出$`.5`了a`2`bc
 那么到游戏里看到的打字效果便是：

我的第一版方案是在快速做出游戏原型时写的，所以把分析这套语法的逻辑和在屏幕上渲染的逻辑混到了一起，换言之，我拿到一句原始输入，就一边拆分语法，一边往屏幕上输出字符以及删删改改的效果。
那套方案一直持续到 2025 年初，并不是它不能用了，而是我看着那段庞大的代码觉得它太不优雅了。于是我咬了咬牙，决定重写这块逻辑，这次分成两个模块：
语法分析模块：输入仍然是一句完整的话，输出则是一个“动作序列”。每个动作可能是“输入一个中文字符”、“输入一个英文字符”、“替换刚才输入的英文字符”、“删除一个字符”、“输入一个词”、“移动光标”。每个动作都可以有自己的延迟、是否清空下划线等属性。
渲染模块：输入是一个动作序列，这个模块只需要按照每个动作的指示，往屏幕上输出内容就可以，它无需在意每个动作序列是经过了多少周折、从怎样复杂的原始输入里演变而来。
这样做的好处：
出错时易于排查
如果改变主意了，很容易做功能上的修改
语法分析模块变得容易测试了很多，毕竟这个模块完全不依赖 Unity
两边的代码都变得整洁
剧本创作：编剧和程序的身份切换
虽说剧本创作本身和程序设计无关，编剧也没有义务知晓程序中的细节，但这里我要提到的改进，恰恰是因为我一人分饰了编剧和程序两个角色才决定要去做的。
我使用 articy:draft 来编写游戏中的对话。由于逐句选择回复内容时，只要短信还没有发送，就可以后悔上一次输入，所以我需要一个办法来回到上一次做选择的那个时机。
原先我的做法是这样的，用一个黄颜色、专门用来负责”后悔“的节点，在做完选择后立刻提供一条路线，导向做选择前的那个分岔点：

这个方案在我刚开始做这款游戏时就确定了，也一直沿用到了 2025 年。它确实简单有效，但它并不简洁——回看上面那张图，黄颜色节点和灰色分岔点都没有任何实质意义，起到的作用仅仅是引导程序找回刚才的分岔点。换言之，如果以编剧的视角来查看这次分岔，只有粉色和蓝色节点里的内容是让人感兴趣的。进一步地，如果要让编剧以这个格式来在 articy:draft 里编写剧本，那么每编写一处选择，就需要额外添加一组这样的节点。这无疑会加大认知负荷，破坏创作心流。
其实我心里一直知道，最理想的情况，每处选择应该是这样的：

没有任何多余的打扰视线的内容，在屏幕上的就是实打实的文字剧本。至于“回到上一处做选择的地方”，程序里一定能有办法直接实现，而不依赖 articy:draft 中的引导线。
那么为什么我没有这么做呢？我最早实现这里的逻辑时，只想快速做出一个游戏原型。当时我扮演的角色可能有 90% 都是程序，所以我想着在 articy:draft 里需要多搞一点就多搞一点吧，至少程序上能简单一些。
做完初版方案以后，本着“又不是不能用，还有许多其它东西要实现，没时间顾这个”的心态，就一直忍受着它给 articy:draft 中的创作带来的不便利性。直到 2025 年，需要在 70% 以上的时间扮演剧本创作者时，我才下定决心，大改程序中处理 articy:draft 流程图的逻辑，彻底删掉了对那些“无意义节点”的依赖。
稍微复杂一点的例子，在优化前（注意一些弯弯绕绕的曲线——那些就是因为负责后悔的黄颜色节点总是需要往回连接到左侧节点）：

优化后：

 一个中等规模的话题，优化前：

优化后：

 一个复杂的话题，优化前：

优化后（看着并没有比上一张图简洁多少，是因为两张图的下方其实都有溢出后没有进入截图的内容，而这张图的溢出少了许多）：

经过统计，这次改动让 Ariticy:Draft 的导出文件行数下降了25%左右——这也合理，因为之前几乎是每二到三个有内容的节点，就需要伴随一个用来后悔的节点。
其实这并不是我对 articy:draft 中的设计做的唯一一处改进，其余零零总总的变化也在发生着，而所有这些改进都是为了一个目标：减小剧本创作时的认知负荷。我发现在用 articy:draft（或者是任何其它创作工具）创作剧本时，认知负荷越小，越利于流畅高效的创作。我会问自己有什么是创作剧本时需要关心的，有什么是其实应该丢给程序去处理的。扮演程序的我是会怕麻烦、想将就的，但一想到编剧同样是我自己来扮演，就会又有动力去扫清路上的障碍，想着“未来的自己会感谢现在的自己的”。

以上便是我的创作流程中几处有代表性的“再设计”，希望能给各位带来启发。最后，借此机会再给我的游戏打个广告：如果对《语默行间》（Steam 链接）感兴趣，请添加愿望单（试玩版已经在着手准备了，添加愿望单后便能在试玩版推出时第一时间收到通知），这会对我很有帮助，谢谢。