简介

    当你在为一款游戏写对话，或者故事材料时，你都努力的把内容写的更好，更具娱乐性。而你最后做的事情，却是用一些拙劣的演示来使你的听众觉得乏味。

    尽管如此，当你在为游戏书写故事内容时，却常常事与愿违。当然，你并不想让你的听众（你的游戏开发伙伴们）觉得无聊。那么，使你的文章远离单调乏味的最好办法，就是压抑你的创造欲望，而用接近于一种接近于技术文档形式的故事文档。

 技术文档

    在出于兴趣的讨论中，我们将技术作品定义为一种解释、描述的非小说性的文档。技术文章的书写者们将复杂的观念分解，并且用率直简单的语言表述出来，并且附带有用来表述意图的数据。技术文章不具备娱乐性，也不会扣人心弦或是引人入胜；它仅仅是表述一些信息。另外，它是为一些需要详细信息的听众而书写的。

    技术文章是精确的。它将内容简要而准确的表述出来。它是非个人的，因为作者在不断的交流数据，它并不是观测报告或是注释一类的。技术文章十分清晰，它们通常使用合适的，有组织的风格以及用词。由于听众可能不熟悉文章的内容，其内容的术语和格式，在表述上必须是一致的。另外，为了使文章更加可信，作者通常也是可靠的，而表述的信息也必须是经过透彻的研究。这些理念，在下面的情况下会有更深的扩展。

    书写技术文章的必要条件有很多。比如书写软件包技术文章作者，在书写用户手册、帮助文档或是维修指引时，他们要和程序员共同工作，学习工具和术语。

    游戏设计文档符合上述所有的标准。游戏作者需要分解复杂的观念，比如情节、角色设计、场景以及游戏世界，并且用简单率直的语言表述出来。而听众是游戏的开发者们，他们就是有详细信息需求的人群。

    让我们探索一下技术文章的特征，同时考虑一下如何将这样的文档应用于游戏的故事及描述。

 精确

在开发团队中，任何误解都会导致额外的工作，因此确保所有内容的准确性十分重要。

    比如说，一个游戏片断中将要展示一个角色爬梯子的场面，一名动作美工将为这个场面制作一个爬梯子的动作序列。然后，我们可能会发现这个制作出来场面动作序列实际上开始于这名角色匍匐在下水道的出入口。而我们可能事实上并不需要展示这些开端，因为我们没有多余的时间去制作这些场景。介于这个原因，我们应该略微多投入一点时间来准确的描述这些场景，这样可以节约大量的人力和时间。

    游戏设计文档同样应该是简短的，尽量剔除那些无关的内容。有时候，我们会很难拒绝在书写文档时添加一些幽默的或戏剧性的元素来增强文档的可读性。这种观点例如：如果游戏开发者想创造一个令人毛骨悚然的游戏，或者是一个有趣的游戏，那你的文档应该符合这个情感。其实这是错误的。当你的游戏需要一些有趣的笑话，或是感人的剧情时，这个游戏的文档并不需要使读者兴奋或觉得戏剧化。事实上，这些无关的元素减缓了阅读者的阅读速度，并且会产生挫折感。同样的，文档也不要写的很“好”。技术文档是直接而易懂的，而不是华丽的或像诗歌一样的。我们的读者不是为了娱乐、解闷或是陶冶情操而阅读，他们需求的是详尽的信息。

    关于书写“有趣的文档”的一点建议：我听说在文档中书写更幽默一点，会使文档更容易阅读。这是有经验的游戏开发者提出的，而我一向不置可否。即使是最优秀的喜剧，你能保证在看第三次，第四次的时候还觉得十分有趣吗？并且，这些喜剧的创造人从制作中获得了报酬。但即使是专家，也不能每次都写出让读者一见就捧腹大笑的对话。而你的设计文档有什么不同吗？通常设计文档将被阅读不止一次，尤其是直接按照文档内容工作的伙伴，他们可能要阅读数十遍，再有趣的文档一样会变得使他们恶心。因为游戏文档不是小说或剧本。

 客观

    技术文档强调事实和数据。游戏文档也应该是一样的。当你在书写一个角色的简历，或是一个故事的大纲，或是分解游戏中的一个任务，作者都应该站在阅读者的角度上来表述内容。这意味着在文档中不应该有意见，疑问或是不合实际的内容。

    举个例子，你可能会遇到这样一个作者，他/她经常提醒你他/她的存在：“作为一个谦逊的作者，我建议主要角色应该…”多使用被动的声音（第三者的思维，译者按）来取代这些第一人称代词（主观思维），从而避免使阅读者/听众感到困惑。另外，技术文档的作者还应该十分仔细的检查文档，以避免任何细微的，因疏忽导致的错误。

 清晰

    用简单而准确的表述来达到清晰的目的。通过对内容的直接表述，良好的语句结构，以及适当的遣词，游戏文档写作者可以创造出让人一看就明白的优秀文档。

    词汇十分重要。一些词汇，比如“ecdysis”，“meretricious”，“ophidian”，除非是有一些特殊的游戏体验，否则通常是不会在游戏中出现的。阅读者没有时间和耐心去拓展他们的词汇量。（现实意义在于，不要在文档中使用奇异的词汇，如果一定要使用，请务必在使用对其进行注释。译者按）。

    我认识一个工作室，他们的设计文档总是充满了深奥、冷僻的词汇，比如“promulgate”和“crepuscular”。阅读这样的文档，显然对于扩展词汇量有好处，但大多数的开发者更愿意直接去询问设计者本人，因为阅读这样的文档实在是浪费时间和精力。

    有组织的结构同样使文档变的清晰。你团队中的开发者们更喜欢看到有结构、清晰易读的文档。我曾经参加一款游戏的开发，它的设计文档是在网络上的HTML文件展示的。文档的本质就是一行行的文本，并且我们看到的是满屏幕的文本，它没有边距，甚至连格式也没有。在电脑上阅读这样的文本通常会使人感到十分头疼，因此大多数开发者宁愿把它复制下来，并粘贴在Word上，重新排版，打印出来，再来阅读。我们的团队有12名开发者，增加了这样一个额外的工作，浪费了我们大量的时间。

    有效的组织你草稿的内容，会使开发者更愿意去阅读。考虑如何去安排使文档清晰十分重要：有效的使用空白，段落分割，以及重点部分的标记。

 一致性

    当你在书写大量的故事文档时，你可能要花费数月开发时间，你会很难保证文档的一致性。但是这种一致性是技术文档的一个特点，使文档更容易阅读及传递要表述的信息。

    你整个文档中，字体，标题，边距都应该保持一致。MS Word提供了很多便捷的工具，来帮助你规范你的文档。

    当然，你也不能在检查过拼写（错别字？）和校对过之前，将所有的文档都交给你的开发团队。很多名词的拼写是Word检测工具不能检验出来的，比如角色的名字，魔法技能的名称等等，你要尤其注意检查这些名词的正确性。（老外真罗嗦…）

 可信性

    当你在书写你的文档时，请记住你的读者是将你的内容作为权威的基准。每一个错误或是疏漏都会导致同伴对你的信任降低，同时也会为团队的信心蒙上阴影。

    最好能为所有的主张都加以实际的数据支持，尤其是那些有争议的主张。比如说，我看到“这会使玩家觉得…”这样的话比我看过的故事文档更多。作者或设计者在这里要指出某一个部分会带给玩家什么样的感受。但这毫无依据，没有解释它为什么会是这样，它只指出了这个声明，却没有对其进行论证。当一个玩家的同伴死亡了，玩家会觉得伤心。你怎么知道的？你真的确信这名玩家喜欢他/她的同伴吗？

    可信性同样要依赖于对内容本身的了解，包括游戏性，物质的实质，游戏的主题，类型，以及系列的历史和版权。因此游戏设计者要对相关的内容做十分相近的了解及分析。

 为读者而写作

    作为一个游戏文档作者，你可能不会仅仅要求书写故事情节或对话，还要写一些任务，市场分析或是技术文档。

    无论如何，要记住的最重要的是，你在对读者表述你的核心信息。和市场部门一起分享你角色设计的细节部分，这不重要（除非他们有特别需求，或是对核心信息有所帮助的关键部分）。

 市场

    当想游戏市场人员表述内容时，确定转达给他们的只是他们需要的信息。他们可能会对故事的大概轮廓和主要角色感兴趣。一份长达20页的剧情及角色的细节描述文档，会为他们的工作带来额外的负担。

    为我带来很大帮助的，是新闻行业的一种倒金字塔型模式。如果你阅读报纸上的一篇文章的前两段，你就可以了解这篇文章的基本内容，后面的段落添加了更多的细节描述，但第一行将告诉你想知道的内容。用这种格式来想市场部门表述内容很有效果。一个简洁、描述事实的大纲，后面接着长篇幅的细节描述文档，可以将适当的内容传递给市场部门，并使他们容易阅读及理解。

    对文档的信息进行分类归纳也很重要。

 产品

    当你想制作人表述你的故事内容前，首先要确定制作人的需求。你是在写一份文档来鼓舞你的团队，并且向他们灌输游戏的内容？还是罗列了所有的角色和场景，以用来确定需要多少美工来制作游戏并计算资产？

    一份故事文档用来告诉团队的每个伙伴你的游戏的故事情节，但必须每人都阅读了这份文档。在两年前一款游戏的开发过程中，我在每个阶段都打印了一系列的任务摘要。这些摘要包含了在任务中角色的特征，场景，主要事件，以及故事情节中动作规范的重要性。角色美工，关卡设计师，以及其他开发者参考摘要进行开发，他们甚至不知道这个游戏究竟是关于什么的。这被证明了对鼓舞团队很有效。（？）

    但是如果你的任务是向那些关注于必要的预算和人力的部门提供内容时，你会想将你的故事做成一系列表示场景，任务等的电子表格。引用需要创造角色的类似模型的文档也十分有用。

 结束语