写在前面：叙事游戏失败时，常常不是因为故事不好
唐临做的是一款分支叙事游戏。
玩家扮演一个小城电台主持人，每晚接听听众电话。不同回答会影响来电者命运，也会改变城市新闻、同事关系和最终结局。
这个点子很好。
早期原型只有三个电话，却已经很有味道。玩家会纠结是否劝一个高中生离家，会犹豫要不要公开一名工厂工人的爆料。
唐临以为最难的是写作。
后来他才知道，真正难的是管理写作。
一、内容很快超过了手工维护能力
最初，他把剧情写在几个 JSON 文件里。
每段文本有 id、角色名、对白、选项和跳转目标。
这看起来足够简单。
但随着内容增加，问题开始出现：
- 某个选项跳到了不存在的段落
- 一个角色在第三晚已经离开，第五晚却又打来电话
- 玩家没听过的事件被新闻提到
- 同一个变量在两个文件里含义不同
- 结局条件互相覆盖
唐临每天修这些问题。
修完一个，又冒出两个。
他没有可视化编辑器，没有自动检查工具，也没有清晰的状态表。所有分支都靠脑子记。
当剧情超过 6 万字后，脑子已经不够用了。
二、写作和实现互相打断
叙事游戏需要连续写作状态。
但唐临很少能连续写两个小时。
他写到一半，发现需要一个新变量，就去改代码。
改完代码，发现存档结构要变。
存档改完，又发现旧剧情需要补条件。
这样反复切换后，他既不像作者，也不像程序员。
最糟糕的一次，他花三天写完一条支线，导入游戏后发现某个条件写反，导致玩家只有在没有接到前置电话时才会触发后续剧情。
这不是创作问题，而是流程问题。
三、测试成本被严重低估
分支叙事最难测的是组合。
如果一个玩家第一晚选择沉默，第二晚选择公开录音，第三晚又错过某个电话，那么第五晚的新闻是否合理？
唐临一开始靠自己通关测试。
但每条线都要几个小时，他根本测不过来。
后来他找朋友试玩。朋友发现很多问题，却很难复现。
他们只会说：
我记得之前选了一个比较强硬的回答，然后后面新闻好像不对。
这类反馈如果没有日志系统，很难定位。
唐临后来补了日志，但已经太晚。前面的内容结构并不支持清晰追踪，很多状态命名混乱，日志只能记录现象，不能解释原因。
四、好故事被坏管线消耗掉
项目暂停时，唐临已经写了 12 万字。
其中有不少段落质量很高。
但游戏版本不稳定。
玩家可能遇到断线分支、重复电话、错误新闻和无法达成的结局。
他试着删掉一半内容，做成线性短篇。
可故事原本依赖选择和后果，删完后味道也变了。
最后他把部分文本整理成小说式文章发布，游戏本体停止开发。
这不是完全浪费。
但作为游戏项目，它确实失败了。
复盘：内容型游戏要先做管线，而不是先堆内容
这个案例的教训很清楚：
- 分支叙事需要编辑、校验、日志和回放工具
- 变量命名和状态设计要早于大规模写作
- 每条剧情线都要能快速跳转测试
- 内容越多，越不能靠手工记忆维护
个人开发者常常以为工具是“大项目才需要的东西”。
但对叙事游戏来说，工具就是项目能否完成的前提。
故事写得好，只能让玩家愿意进入。
内容管线可靠，才能让玩家顺利走出来。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。