写#p#难。
last_monster_master(from gamasutra)
如果你擅于辞令的话自然是极好的。如此你便能够轻松地创造出由3个不同的角色在4种不同的情境下所说出的不同话。通常情况下，编写非线性文本游戏对话和叙述内容是在约束，创造性再利用以及确信等条件下的有效实践。
假设你为一款基于文本的游戏列出了提纲。你知道游戏主题，主角，每个章节所发生的的主要事件，玩家的能力等等。那么现在你便可以开始进行编写—-但是你却难以迈出这一步。你该如何编写一个任何事情都有可能发生的故事？你该如何设定玩家的选择？你该从哪里下手？
最近我面向Choice of Games发行了我的首款未删节文本游戏《The Last Monster Master》（共有25万个单词！），并且在这个过程中我想到了一个能够帮助人们一章一章编写游戏的基本框架。在将最后文本带到ChoiceScript（游戏邦注：Choice of Games自己的脚本语言）前，我使用了Chat Mapper（免费）去编写每个非线性章节。
我将这个过程分解为了6个部分去完成每个章节，这能帮助我保持注意力。此外，Chat Mapper还拥有一个能让你改变每个文本节点颜色的功能。这能够让你追踪每个文本，并且我还使用这一功能去改变每个节点颜色以标记完成的内容。
第一道—-存根文本（没有颜色）
第一道是关于为章节制定结构。比起编写实际的对话或描写，我们可以使用占位符作为存根对话去预示谁将说话，何时会说话以及玩家的选择会是什么。
如果基于统计值以及其它条件会出现不同分支，那就指出有问题的统计值并清楚地描述选择内容。这时候你还不用担心去编写任何游戏逻辑，这是之后要做的事。
避免在这一道中进行过多的修改—-主要目的是为了将高级的章节结构分解成可读格式。当你完成这一任务时，你便能够初步明确接下来所有内容的路标。
在以下来自《The Last Monster Master》的序列中，玩家的一个怪物在进攻的时候陷进一棵树中。玩家必须选择使用心灵感应或字体语言检测技能去帮助怪物抵御进攻或逃出去。
stub_text(from gamasutra)
第二道—-修改存根文本（黄色）
在下一道中你应该只专注于你刚刚创造的结构。你正在着眼于内容的设置—-不要担心拼写错误或任何与文本相关的内容，因为在修改过程中你所编写的所有内容都会被替换掉。
你主要是在寻找无意义或者与故事或边界情况不符，并且有可能在之后引出问题的选择或选择分支。
其次，你正在确保到目前为止所设置的结构是使用你计划在这一章节中使用的所有玩家统计或能力选择。如果最终证明你并未执行你想执行的内容，那么你便需要做出一个明智的决定去修改最初的计划，创造使用这些统计的全新序列或选择，或者通过标注在未来章节使用那些被遗漏的统计。
第三道—-第一道文本（橙色）
基于有组织且经过完善的结构，现在是时候编写玩家能够看到的真正文本了。这是非常直接的一道，但与之前一样，你应该保持注意力。
不要担心为变量，结构转换或任何单纯编写内容设定数值。与大多数单纯编写内容一样，这是最有趣也是最消耗时间的一部分。
first_text_pass(from gamasutra)
第四道—-修改文本（紫色）
你是否曾经编写过真正的章节？现在事情的发展变得更加迅速了。你将进入编辑模式。
在阅读第一道文本时你会发现自己在编写时并不带任何感情色彩。所有与文本相关的内容都是关于游戏—-拼写，语法，对于角色或地点的错误引用，更严格的词汇选择等等。再一次地，你应该专注于编写。创造出生动的文本内容。
第五道—-变量（蓝色）
结构已经明确文本也很紧凑。现在我们将再次检查章节并寻找任何可能出现变量的情况，特别为了决定结果而修改或引用玩家统计的地方。有可能对于特定玩家道具或一次性遭遇你将只能找到少量的例子。
你将在之后的修改，游戏玩法平衡以及测试中完善这里所使用的数值。而现在，你将在你认为数值需要出现的地方画一条线。
为每个章节所需要的特定统计创造一份外部引用文件。例如，如果玩家的力量统计至少达到45他们才能在章节4踢倒一扇木门，那么在章节6要求玩家拥有65个力量才能踢倒一扇金属门便是符合逻辑的。
在特定的道中执行这一做法将能够确保统计的内部一致性，这也将进一步调整之后的数值。
variable_pass(from gamasutra)
第六道—-输出和逻辑（绿色）
最后，你需要将已经完成的章节带到你创造游戏所使用的开发工具中。幸运的是，Chat Mapper能够输出XML，JSON，Excel，和Rich Text等格式，如此便为你提供了更多选择。对于《The Last Monster Master》，我只审查了每个文本节点并将其复制到我的ChoiceScript文件中，并为格式化以及部分转换进行调整。
如果你也是自己编写幕后的真正逻辑，你便需要在将文本带到游戏时开始编写脚本内容。幸运的是，因为你已经解决了何时以及在哪里发生的问题，所以每个脚本任务将从内容中轻松地脱离出来。
其它方法
这并不是编写非线性文本游戏的唯一方法，但却非常适合这一项目。根据你的开发类型以及所使用的工具，你可以选择将存根文本较早输入游戏中，如此你便可以尽快执行了。此外，因为Chat Mapper支持Lua，那么只要你不介意再次在开发环境中编写所有内容的脚本，你便可以直接在程序中设置所有需要的逻辑。
不管你选择怎样的过程，你都应该一次只专注于一项任务，庆祝每一次的成功并记下你需要完善的内容。争辩非线性叙述并非一个琐碎的任务—-所以你何不从中创造一款真正的游戏？
