《语默行间》（Steam 链接）是一款操作老款手机收发短信的文字冒险游戏。它由我独自开发，所以需要一人扮演多职，包括但不限于项目管理、程序设计、剧本创作等。由于已经陆陆续续开发了六年多，一些过去作出的决定，到后来会显得不够成熟。这篇日志记录了我在扮演以上提到的这几种身份时，做出的几处创作流程上的改进。

最开始设计这个游戏时，我使用的是 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 首页的介绍就写得很明白，它是注重团队协作的一款白板应用，它从未自诩它的项目管理功能，只是我自己一开始需要一块头脑风暴用的白板，发展到后来才变成需要系统性地规划所有的剧情和任务。

游戏里用手机输入一句话时，会伴随一些删删改改的动作。我设计了一套简单的语法来控制这些动作：

举例来说，如果原始输入是：

那么到游戏里看到的打字效果便是：

我的第一版方案是在快速做出游戏原型时写的，所以把分析这套语法的逻辑和在屏幕上渲染的逻辑混到了一起，换言之，我拿到一句原始输入，就一边拆分语法，一边往屏幕上输出字符以及删删改改的效果。

那套方案一直持续到 2025 年初，并不是它不能用了，而是我看着那段庞大的代码觉得它太不优雅了。于是我咬了咬牙，决定重写这块逻辑，这次分成两个模块：

这样做的好处：

虽说剧本创作本身和程序设计无关，编剧也没有义务知晓程序中的细节，但这里我要提到的改进，恰恰是因为我一人分饰了编剧和程序两个角色才决定要去做的。

我使用 articy:draft 来编写游戏中的对话。由于逐句选择回复内容时，只要短信还没有发送，就可以后悔上一次输入，所以我需要一个办法来回到上一次做选择的那个时机。

原先我的做法是这样的，用一个黄颜色、专门用来负责”后悔“的节点，在做完选择后立刻提供一条路线，导向做选择前的那个分岔点：

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

其实我心里一直知道，最理想的情况，每处选择应该是这样的：

没有任何多余的打扰视线的内容，在屏幕上的就是实打实的文字剧本。至于“回到上一处做选择的地方”，程序里一定能有办法直接实现，而不依赖 articy:draft 中的引导线。

那么为什么我没有这么做呢？我最早实现这里的逻辑时，只想快速做出一个游戏原型。当时我扮演的角色可能有 90% 都是程序，所以我想着在 articy:draft 里需要多搞一点就多搞一点吧，至少程序上能简单一些。

做完初版方案以后，本着“又不是不能用，还有许多其它东西要实现，没时间顾这个”的心态，就一直忍受着它给 articy:draft 中的创作带来的不便利性。直到 2025 年，需要在 70% 以上的时间扮演剧本创作者时，我才下定决心，大改程序中处理 articy:draft 流程图的逻辑，彻底删掉了对那些“无意义节点”的依赖。

稍微复杂一点的例子，在优化前（注意一些弯弯绕绕的曲线——那些就是因为负责后悔的黄颜色节点总是需要往回连接到左侧节点）：

优化后：

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

优化后：

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

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

经过统计，这次改动让 Ariticy:Draft 的导出文件行数下降了25%左右——这也合理，因为之前几乎是每二到三个有内容的节点，就需要伴随一个用来后悔的节点。

其实这并不是我对 articy:draft 中的设计做的唯一一处改进，其余零零总总的变化也在发生着，而所有这些改进都是为了一个目标：减小剧本创作时的认知负荷。我发现在用 articy:draft（或者是任何其它创作工具）创作剧本时，认知负荷越小，越利于流畅高效的创作。我会问自己有什么是创作剧本时需要关心的，有什么是其实应该丢给程序去处理的。扮演程序的我是会怕麻烦、想将就的，但一想到编剧同样是我自己来扮演，就会又有动力去扫清路上的障碍，想着“未来的自己会感谢现在的自己的”。

顺便提一句，我把 articy:draft 3 内建 Query 的用法、以及 Unity 插件的使用方法喂给了 NotebookLM（链接，输出语言可以在设置里调），这样想不起来 Query 怎么写或者想查 API 的时候就可以直接问这个 AI，而不是手动查了——这也是一种节省未来的时间的方法吧。而且由于 articy:draft X 的出现，现在在 Google 上搜相关问题，会出现很多 articy:draft X 的结果，这个 AI 能保证回答适用于 3 代。同理可以做一个仅适用于 articy:draft X 版的，不过我暂时没去做，因为自己还在用 3 代。

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