分支剧情创作中的挑战和工具
发布时间：2021-07-27 15:15:39来源：indienova
在制作游戏时，我们常遇见一种四个字就能概括的问题：分支剧情。它构想起来并不困难，无论是脑海中、纸面上还是电子屏幕上，我们都能顺其自然地画出剧情流程图。然而待具体实现时，这简单的几个字下却隐藏着诸多挑战——要以何种方式创作分支剧情，才能把它转变成游戏引擎，或者说机器能够理解的媒介？
如果把刚才这个问题中的“分支”两个字去掉，它仿佛就变得不那么棘手了。最显而易见的办法，无非是把所有的“在某件事发生之后触发哪个新的事件”、“谁在何时说了一句什么话”等等直接写到游戏本身的逻辑里去。虽然这个方法到头来会让剧情变得较难维护、对本地化不友好，但起码它直白、可行。
那么现在我们把“分支”两个字加回来。最直接的办法其实仍然存在——条件语句嘛。在现有的代码里，加上一个“取决于主角是否已完成某个任务，走向A剧情或者B剧情”不难吧？毕竟“完成过某个任务”是应该很容易拿到的一个、本身就会因为其它理由而存在的数据——等一下，如果是没那么唾手可得的信息呢？
如果剧情的分支需要取决于“主角是否与某名NPC有过交流”呢？这个信息听起来并不像是本来就会被记录的那种。办法还是有——记录下来嘛。每次主角与任何NPC交流，都在Gameplay逻辑中，额外地在游戏的数据库里标记一下。现在，可想而知，由于剧情走向难免会取决于各种信息，我们经常需要在Gameplay逻辑中记录和管理杂七杂八的、可能只服务于剧情的状态。
然而，当蜿蜒曲折的剧情发展到后期，即便我们做到了管理各种状态，条件语句也会变得越来越臃肿。这么做同时带来了更严重、也是刚才一直被逃避的问题：Gameplay逻辑和叙事逻辑被混在一起，使得调试、排查和维护任何一边都变得愈发困难。某一段剧情没有按照预想的方式被触发，可能是因为此刻鼠标的点击没有被监听到，也可能是因为剧情上的触发条件没有写完备——到了这一步，开发只会越来越低效。
所以我们的问题变成了：如何既在叙事中安插分支，又将Gameplay逻辑与叙事逻辑尽量解耦，保证两边的思路各自清晰。
况且，刚才的分析都建立在了一个隐形的条件上——（对于作家和程序分开的团队来说）为游戏创作剧本的作家也得花时间和精力学习游戏引擎和代码，不然就得让程序员特地将剧情逻辑“复制”进游戏代码当中去。怎么选都不是什么优雅的方案，所以我们更加需要设法解耦，让写故事的人和写程序的人互不干扰，各自最大效率地产出内容。
其实有些读者读到这儿，在脑海中应该能预想出一个解决方案了。说白了，我们需要的是一个独立于游戏引擎，但又比日常的文本编辑器强大的剧情编辑工具。它起码得对作家友好、能设计分支剧情、跟踪状态，以Gameplay逻辑为辅而不是为主，并生成能被游戏引擎识别的内容。
幸运的是，这个问题早已被许多游戏开发者意识到了，也因此涌现出不少插件、工具和叙事引擎。我在这里介绍几款较为主流的，它们的使用场景有重叠，但也有不同。需要额外指出的是，针对Galgame以及类型相似的文字冒险游戏，已有较为成熟的游戏引擎，本文探讨的诸如分支流程等问题已经被那些引擎自然而然地解决了。所以，接下来要介绍的这些工具，是应用于非文字冒险、但又涉及到分支剧情/对话的那些游戏的。《极乐迪斯科（DiscoElysium）》？《霓虹出租（NeoCab）》？《林中之夜（NightintheWoods）》？是，就是那些风格。事实上，这几个游戏全都使用了这些工具中的某一个。
限于篇幅，我不能对这些工具深入展开，希望简短的介绍起码能讲清楚它们各自是什么。至于具体怎么用，我会在小标题链接到官网，那里通常配有技术文档帮助上手。
Twine链接地址：https://twinery.org/
Twine是一个开源的基于网页的分支剧情创作器。
每个剧情节点内都包含了一段文字剧情，节点之间的箭头使流向变得直观，分叉处也显而易见
从未写过代码的人可以迅速上手，而对于有编程经验的人来说，Twine也提供了语法来实现赋值变量、条件控制（某些选项只有满足特定条件才会可选）等。
Twine可以在线使用也可以下载客户端。撰写剧本的过程中可以随时从指定节点起“试玩”接下来的剧情，游玩的过程即用鼠标在网页上点击选项，剧情会按照设计好的路线来推进。这听起来很简陋，但这可能是迅速创建一个可玩的互动电子剧本的最快方法了，所以适合迅速搭建原型。
在itch.io上有近6000个使用Twine制作的游戏，这庞大的数量也得益于itch.io对网页游戏的支持——Twine可以直接生成网页游戏，但不能生成被其他游戏引擎读取的数据文件。有一个叫做Cradle的插件可将Twine生成的故事导入Unity，但该插件已不再维护，随着Twine自身的更新迭代，我并不推荐去研究Cradle。如果对Twine的操作模式和功能感到满意，但又不满足于只在网页上游玩、想要和游戏引擎深度集成，那么接下来的Yarn是更好的选择。
Yarn链接地址：https://github.com/YarnSpinnerTool/YarnEditor
Yarn开源，基于Twine，正如它们两个词的意思本身也很像。
Yarn的编辑器，但是也可以选择不借助流程图，使用文本编辑器
Yarn的设计者之一JonManning曾在一个讲座上提到过他们的理念：让作家不需要学写代码，但允许作家通过Yarn来实现代码能够实现的事。所以，和Twine类似地，Yarn定义了一套非常简洁的脚本语言，来实现条件判断、变量追踪等。不同的是Yarn可以配合YarnSpinner使用，将整个剧情逻辑导入Unity（所以在Unity的Gameplay逻辑里可以一键“进行到下一段剧情”），甚至可以在Unity中定义函数，在使用Yarn编写剧情的过程中调用它们。
但Yarn自身不支持预览剧情，我的理解是，这意味着只有在导入Unity并完成相关的读取逻辑以后，才能在Unity中试玩到使用Yarn创作的剧情。这是Yarn目前比较大的一个短板。
从官网可知Yarn对本地化的支持不错。著名的借助Yarn完成的游戏有《林中之夜（NightintheWoods）》（正是该制作组带来了Yarn）、《短途旅行（AShortHike）》。
ink链接地址：https://www.inklestudios.com/ink/
如果说Yarn兼顾了视觉上流程图的直观性和逻辑上脚本语言的灵活性，那么ink可以说是在灵活性上走向了极致——这个工具不提供流程图，因为剧本片段之间的关系太过千变万化。
ink的编辑器inky，左边进行剧情编写，右边则是实时试玩
ink是带来了《80天（80Days）》《天堂之穹（Heaven'sVault）》等作品的inkle工作室开发并开源的一个脚本语言。主创之一JonIngold曾不止一次说过他并不喜欢所谓“流程图”的概念，因为流程图本身的存在，就意味着节点有固定的先后顺序：
Aflowchartsaysthisblobexistswithinastructure,wherethiscomesbeforeandthiscomesafter.InHeaven’sVault,whenSixandAliyawalkaround,there’sabucketofabout3,000to4,000thingstheycansay.
AndInkjustrunsthroughallofthemandsays,‘givemealltheconversationsthatwouldmakesenseatthismoment’.Andthenitsays,‘whichoneisthemostrelevanttowhatyouweretalkingaboutlast’,anditputsthatinfrontoftheplayer.Andthat’sallitdoes,thereisnostructure,noflowchart.
通过Jon的这段描述，我们不难理解inkle从不依赖流程图。如果某个角色接下来要说的话有三千种可能性，而这三千个备选项也能存在于不同流程里更早或更晚的对话中，那么我们需要的显然不是流程图，而是一个筛选器，挑选出最符合当下语境的那一句，然后推进剧情。而被选出来的那一句话，在下一次相似语境中就不会再被选中。
不仅对话，在inkle的设计理念中，剧情片段也是一样的道理。接下来要发生哪段剧情，与上一段发生的是哪段剧情并非强相关，更多地，系统会考量自游戏开始后的各种状态、玩家的历史选择——ink默认会记住玩家作过的每一个选择，包括很久以前的，而不需要我们手动使用变量去跟踪——从整个剧情池中挑出一个来推进剧情。
当然，ink仍然支持之前Twine和Yarn支持的那种传统分支结构，只是在这里一切都需要靠脚本语言去编写，不再有流程图了。
摆脱了流程图的束缚，ink可以实现相当细腻的“响应式（responsive）文字”。
GDC幻灯片截图（文末有链接）——上为ink中的一段，下为编译后众多可能结果中的两个
在这个例子里，短短的一段文字，经过随机短语间的排列组合，取决于玩家是否穿着潮湿的衣服、当前地形是否为树林，便能有好几十种最终的呈现方式，底下的两段只是其中的两种。若这样精细的内容调整贯穿整个剧本，那流程图当然难以体现密密麻麻的走向可能性。
也正是因为没有流程图，一旦学习了ink的语法，写剧本的效率要高于其他工具——毕竟不必每次想添加一段剧情，都先用鼠标在流程图上新建一个节点了。在这里，就像传统写作那样，手指不必离开键盘，一直打字就行。
ink官方提供了Unity插件，民间则有虚幻、Godot、GameMakerStudio2的插件。可惜ink对本地化的支持不好，用一种语言写完的剧本，若想要翻译，那么剧本里的可变部分（也就是那些响应式的部分）越多，翻译过程就越艰难，如果跨语系就更加如此。
ink也不只适用于文字为主的游戏。作为一个免费的开源工具，怎么用完全看需求。像《霓虹出租（NeoCab）》、Sable这类音画占比也很大的游戏，也都使用了ink。
articy:draft链接地址：https://www.articy.com/
方才的ink在写作过程中可以说是面向过程的，而接下来的articy:draft则能满足面向对象的设计——等一下，写互动剧本也能面向对象吗？这不是计算机领域的词汇吗？
游戏开发的本质仍然是程序开发，当然可以面向对象。就拿主角的一句台词来说，一句台词包含什么？
倘若我们能想到的只有人物和台词这两个属性，那还是没有跳出传统写作的框架。试想，在各种需求下，显示这句话的文字颜色、人物表情的不同立绘、语音播放这句台词所需的时间长度、这句台词在选项菜单里显示的缩略文字（因为可能显示不下完整的台词）等等等等，都是游戏里可以被绑定在“台词”身上的属性。
而人物的属性就不言自明了，等级、职业、血量……从这个角度出发，我们的确可以面向对象地先定义每句台词、每个人物的属性，设置默认值，进而在创作剧本时系统性地照顾到它作为“游戏剧本”的方方面面。
而articy:draft天然地支持往对话和人物上添加自定义属性、设置类型和默认值。一旦属性设置完毕，就能在流程图的各个地方去引用和修改。用户也可以自己定义新的Entity，例如“武器”，设置武器的各个属性，并在articy:draft而不是游戏引擎内新建多把武器。接着就可以往人物里新增一个“武器”栏位，代表人物目前持有的武器，而这一切信息都将在游戏引擎内被读取——这进一步说明articy:draft适合面向对象的创作思路。
articy:draft的分支对话流程图
在articy:draft的流程图中，每个节点可以是一段剧情或是一句台词，通过条件、指令等串联。articy:draft支持节点的无限嵌套，这对管理具有从属关系的剧情片段非常有帮助；合理安排层级关系，那么剧情流程图从外到内就能井井有条。articy:draft自带一个数据库管理的面板，可定义全局变量，在流程图中读取和赋值；在预览故事流程时，还能实时查看每个变量的值。
配合刚才提到过的“在流程图内引用和修改人物属性”、“在articy:draft里管理人物配备的武器”，不难发现articy:draft其实已经可以在剧情逻辑里实现相当一部分Gameplay逻辑了。如此一来，一个作家不需要掌握游戏引擎也能在撰写剧情的同时包揽一些Gameplay逻辑。当然，这是否可取就见仁见智了。
articy:draft支持本地化、配音、版本管理和多人协作，官方还提供了Unity和虚幻的插件。其实articy:draft能做的不仅仅是分支剧情的管理，它还能管理游戏设计文档、剧本大纲、游戏地图等，但这些方面我了解得不多，也不是本文讨论的重点，故不再展开。
有不少互动小说使用了articy:draft，如《极乐迪斯科（DiscoElysium）》《奥威尔（Orwell:KeepinganEyeOnYou）》《骇游侠探（Gamedec）》等。在官网可以找到相关游戏各自的访谈。
不同于之前的几个工具，articy:draft是收费的，好在Steam上打完折也不是很贵。一些大厂如CDProjektRED、Techland也是articy:draft的客户，这么想，或许能让这钱花得更心安理得些。
ChatMapper：类似articy:draft但是订阅制，我了解不多。https://www.chatmapper.com/
DialogueSystem：Unity素材商店的强大素材，自身可用于编写节点式分支对话（但要注意，这等于还是要在Unity里进行剧本创作），也支持ink、articy:draft、ChatMapper等的导入，将来也会支持Yarn。https://assetstore.unity.com/packages/tools/ai/dialogue-system-for-unity-11672
自己实现工具：我相信对于资源丰富的大厂来说，都有成熟的内部工具来辅佐各种类型剧本的创作了。黑曜石就曾分享过他们的分支对话工具使用心得，同样是基于流程图的。而对于有闲功夫的独立游戏人，想自己造一个这样的工具出来玩，也值得鼓励——何况上边介绍到的许多开源产品都可以用作参考。
让我们回顾一遍开头的问题：如何既在叙事中安插分支，又将Gameplay逻辑与叙事逻辑尽量解耦，保证两边的思路各自清晰？
回想介绍过的那些工具，除了不支持和游戏引擎结合、但适合快速在网页上搭建原型的Twine以外，其余都能满足这个要求。当然，刚开始都需要花时间学习工具本身的使用，以及如何和游戏引擎结合。另外，可以看到这些工具或多或少都支持从叙事流程中调用游戏引擎里Gameplay相关的函数——如何划清叙事逻辑与Gameplay逻辑的界线也是我没能展开讨论的话题，但我认为这个问题没有标准答案，很大程度上取决于游戏本身的性质、甚至创作人员对两边工具的熟悉程度。总之，工欲善其事必先利其器，一旦上手，之后的剧本创作和游戏开发将齐头并进、不再混沌。
每个工具的设计理念不尽相同，这些简短的介绍只是一个引子；究竟哪个适合自己，还得留给读者自行考察与斟酌。即便没有迫切需求，也希望对这些工具的探讨能触发大家对分支叙事实现方式和应用场景的思考。
浅谈电子游戏中选择的设计（本文介绍的是技术上的实现，而那篇则是从游戏设计的角度去讨论选择本身）https://indienova.com/indie-game-development/choice-design-in-video-games/
《80days》：如何以软件工程的思路编写一部互动小说https://www.gcores.com/articles/110516
Twine，ink和Yarn实现简单分支的方法对比https://medium.com/@haikus_by_KN/authoring-interactive-narrative-in-twine-2-vs-ink-a-quick-and-dirty-comparison-using-examples-e695eb4dfc3e
AdvX2018-JonIngold-SparklingDialogue:AMasterclass（使用ink将银翼杀手中的经典对白改编成互动对话。不仅介绍ink的语法，更多的是讲互动对话设计时的要点，故强烈推荐）https://www.youtube.com/watch?v=_vRfNtvFVRo
ink语言的介绍https://www.youtube.com/watch?v=KYBf6Ko1I2k
