• 概述游戏脚本编写实用指南及注意事项


    转自:http://gamerboom.com/archives/32846

    游戏邦注:本文原作者是资深游戏编写人McDevitt (代表作《刺客信条:血统》和《野兽家园》),他在本文概述了游戏制作前及制作中的设计、制作和游戏写手之间的分工合作过程。

    电子游戏写手是很容易被误解的一类人。即使是在最理想的情况下,如果说游戏设计师的工作成果是砖块,游戏写手的至多也就是填补在砖块缝隙间的水泥沙浆——把游戏中那些有趣的片段用一些修饰性或评注性的对话连接起来。

    另外一个不可否认的事实是:一方面,游戏制作团队最希望的就是在游戏中充满夸张如戏剧、精美如《合金装备》的动画;与这样的一群人共事,游戏写手的地位就更加边缘化了。另一方面,想出华丽如飞花四溅的语句来组成一份450页的脚本,写手的负担并不见得轻。

    我觉得有必要澄清一下,否则认为编写工作只是把字码成句子这种明显错误的观念,恐怕难以颠覆了。

    虽然关于游戏编写的真相并非如此,但一定程度上,游戏行业的大量偶然事件已经把这种观念制度化了。过去几十年,为数惊人的游戏已经见证了这种观念的效应。

    当写手被请来写一个游戏时,一般是不允许在脚本中穿插游戏节奏、背景、人物的动机和情绪口吻,写手只能凭借唯一的武器——别扭的诮皮话和陈述性的通俗哲理来表达自己的想法。所以也难怪自己最喜欢的游戏角色往往只能说些让人不舒服的诮皮话和勉强的教条。

    分工协作精神的体现,似乎也不包括游戏写手。

    writing(from bellevuepublicschools)

    writing(from bellevuepublicschools)

    事实是,游戏写手并不想用毫无意义的独白来打断游戏,也不想捏造一些做作的好莱坞风格的史诗巨作。游戏写手只是想帮助设计师,一起精制一种吸引人的、有互动性的游戏剧情。无论有没有对话、有没有人物,写手只是想让游戏有一个有趣的开始,然后经历几个高潮,最后以更有趣的方式收场。当然,这也是游戏写手所擅长的。

    并非所有的游戏都需要剧情构成,当然,主流游戏机游戏普遍以剧情构成为特征。现在,如果一个真正的写手打算写一个主流游戏机游戏的脚本,游戏设计师或者制作人——这些重量级的人物就会对游戏剧情非常重视。

    但写游戏脚本不是你有想法就能写的。如果你看到某个游戏写手“赋闲”,你就知道自己算是幸运了。许多游戏制作人只瞄准利润,所以他们坚信不需要在让人捉摸不透的奢侈品(游戏脚本)上做过多的开销也能做出一款游戏。在许多情况下,我不得不惭愧地承认他们是对的。

    因为没有专人编写游戏脚本,游戏大众就会受到粗制滥造的游戏剧情的折磨。但一款游戏剧情上来了,玩法崩坏了,其命运要么是昙花一现,要么是搁在架子上蒙尘。我尊重也支持先玩法后剧情的排位顺序。游戏玩法第一——这是黄金定律。

    然而,如果某些叙述形式正好在游戏中扮演重要角色,那么就有必要赋予它与其他设计元素同等的待遇,而不是把它当成可分离的部分。如果制作团队已经大胆地迈出了打造剧情导向型游戏的步伐,那么,在此有不少措施可以帮助游戏写手摆脱边缘化的困境,防止剧情(和写手)被无尽的GDD(游戏开发者大会)修正案埋没。

    首先,做一个简单的概念转变:视游戏写手为合作设计者。从游戏设计的最初阶段就应把写手纳入其中直到项目结束。即使此人并非有经验设计师,一个好的写手也可能对游戏玩法产生各种奇思妙想,然后将其体现在脚本中。再者,编写工作不仅是堆砌高明的语句,还要创造剧情套路、动机和节奏等等,其实也就是做什么、为什么做和什么时候做。

    writing_ico(from gamasutra)

    writing_ico(from gamasutra)

    我喜欢的大多剧情导向型游戏,如《Ico》、《旺达与巨像》、《Flashback》和《Out of this World》等,里面虽然有明显的情绪、语气转变,并且在转变中确实反映了某些有意义的即时事件,但这些游戏都几乎不含对话。

    当写手和设计师双方一起探讨游戏机制、关卡、剧情、人物、场景和背景,不同学科在整个团队中的交叉合作,无疑会碰撞出更令人振奋的创意火花。

    不幸的是,这种协同作用真的很难实现,特别是与开发周期少于一年的第三方合作。因为日程紧张,大家又埋头于各自的工作,制作人、设计师与写手之间产生一点距离也是很经常的事。

    其实编写与制作从某种程度上说根本就是一回事,编写就是设计。毕竟写手和制作团队都在从无到有地创造一个新世界。所以如果能让一个写手也参与到游戏设计的过程中,写手就能对剧情叙述部分如何提升(或拖累)整体游戏,有一个更清晰的理解。

    编写前期工作

    为了更清楚地展示这个过程,我们应该带着几个制作前目标,精确定位游戏写手前期最重要的节点任务。在正式编写的前几周,作为写手,我们很容易陶醉于成千上百个转瞬即逝的灵感中,但无论如何,必须带着明确的目的来总结这些幻想。

    高级叙述总结。 在制作前期,设计团队应该直接与写手一起构思一个简要的剧情大纲。把这部分工作做成“电梯演讲“(游戏邦注:指用简短的、有说服力的描述来阐明个人或团体对某种产品的想法或理念等)——尽量做得简洁干脆。这份剧情大纲是唯一一份大部分团队成员都会读到的文案,所以清楚深刻是必要的。提前做好这部分工作,同时尽早让投资方签下它。编写的每一阶段都要即时跟进签核。如果不能让投资方尽早签下游戏脚本的协议,结果就是后患无穷。

    主要场景和关卡。 如果写手不曾参与概念设计的工作,绝对会对这部分编写工作感到纠结。这是因为设计师经常在没和写手商量、也没考虑背景在剧情进展中的巨大作用的情况下,就提前设计关卡概念。

    在电子游戏中,场景往往比角色重要,如果写手、设计师和美工能够合作,大致确定游戏场景的规模、数量等问题,那就皆大欢喜了。

    写手必须明确编写一出优秀的剧情需要什么场景;而美工和设计师则要确定写手写出的内容与游戏是否相关。

    一个项目组成员心目中所谓的“相关“概念显然是不尽相同的,但在开发周期较短的小项目中,能不能把这个概念统一起来,对工作时间的影响是很大的(不明白?统不统一所造成的差别就是,场景美工是当天傍晚六点回家还是第二天早上六点回家)。

    一旦制作工作启动,编写工作就进入下一个阶段了。这也是整个设计团队必须上下一心,拧成一股统一力量的时候。

    详尽的情节概述。剧情结构完成后,就是时候开始精细化剧情细节文件、完善场景描述和游戏任务。根据剧情对设计的影响程度,文件中的细节量也会有所不同,但应该尽可能详尽。无论如何,细节概述都将有助于更好地理解游戏类型及一段时间后的设计返工对脚本的依赖。

    在情节导向的游戏中,设计难题直接来源于剧情,例如解救犯人、暗杀守卫、递送包裹等。对于RPG类非线性游戏,这类文件必须集中详尽化处理。对于不是太有组织的游戏,写手对设计的直接作用可能较比小。请务必提前理清这种平衡关系。

    剧情展示计划。 游戏到底如何叙述及谁来叙述?有没有渲染场景或游戏动画?谁负责连接这些场景?可能游戏中没有任何动画,而你更愿意实时叙述剧情,那这可不可行?

    提前考虑这些问题吧。在某个项目的开发过程中,居然没人确切地理解剧情的叙述方式,这就是写手所目睹的最大的悲剧了,因为这会影响他的编写计划。

    估计影像的故障。 如果游戏中确实包含影像或其他任何形式的动态画面,那么请务必尽早估计其的数量。如果已做好详尽的剧情大纲,这部分工作应该不难。在工期比较紧的项目中,做好这部分工作有助于提前确定各个场景的复杂关系和质量要求,这样,整个团队就可以合理地分配各种资源。

    角色。 生成剧情细节后,还需要制作一份清楚的角色清单,什么角色,及其在叙述剧情和游戏中各起什么作用?NPC有哪些?谁是正面互动角色?BOSS?任务发放者?商店店员?导师?等等。

    美工会制作所有人物模型和动画,他们还需要知道具体数量。如果写手在项目的进程中又添加了15个NPC,信不信,美工一定会在休息室里说写手的闲话。因为这些漫不经心的语句在脚本的剧情对话中占了相当大的分量,所以尽早确定角色数量,才能更容易地确定游戏需要多少“触发事件对话”。这可不是无关紧要的东西,所以好好记录。

    整理文本数据库。 这可能是件乏味的任务,但尽早整理文本数据库、启动和运行工具却不是小事。把这部分工作拖拉得越久,你就会越对自己咬牙切齿(你会后悔的)。一些游戏的文本要求比较复杂难懂,比如非线性对话系统,所以理清数据就更是至关重要了。

    另外,花点时间决定传输脚本的方式吧。并不是所有的写手都清楚关于文本数据库有什么行业规范,所以如果写手以word或Final Draft(一款脚本编写软件)的格式传输脚本,还得想办法解决转换问题,

    编写进行时

    一旦游戏制作基础建立了,团队成员就要着手制作工作,而这时,真正的编写工作也开始了。这是个有趣的部分。写手喜欢写作,但并不与设计团队保持实时的联系,所以他们面临的风险就是:写太多了用不上,或者写了完全不相干的东西。当编写者写好了100节五行打油诗才被告之:“写得好是很好,不过在Chaz Dastard的 《Intergalactic Star Safari 2 : Misremembered Legacy》没地方放啊。”这样无疑是浪费大家的时间。也让写手不痛快。

    制定明确的编写界限,这样才能把写手的书写冲动扼杀在萌芽状态。如果编写者从一开始就参与设计,那还好办,因为所有人都明白游戏编写需要的范围,从编写开始到结束都要跟进所有工作。不明确界限或方向的游戏写手,特别是团队之外合同写手(外包写手),编写的内容对游戏来说,就像Andre Breton写的《soluble fish》那样太过感性或超现实,就是他们要冒的风险。

    脚本起草。 在第一阶段,写手应该忙得要死。在短期项目中,理想的情况下,写手已经完成了用于制作第一步的第一份脚本草稿。有了这份脚本草稿,关卡设计工作的进展会更顺利。

    在长期项目中,写手和关卡设计师应该一起反复协商以确定关卡细节尽量接近第一草稿。

    需求剧情与脚本再次签核。务必明确客户已经审阅脚本,且尽可能早地得到反馈要求。根据我本人的经验,客户方面的工作是让我最头疼的。

    许多客户都错误地认为脚本是游戏中最最重要的方面,所以应该花上数月时间来通盘考虑细节,虽然这些细节实际上对最终的游戏帮助并不大。愚昧地拖延只会阻碍关卡设计师和动画美工,浪费掉的时间也不可能那么简单地就得到弥补。

    请个有经验的写手的好处很少被提及,相对于编码员和美工,好的写手工作效率相当高。文本编辑和校订工作没什么技术含量,也用不着太多时间。但如果写手没有意识到所有材料都需要校订,那么这个优势就对谁也没用了。

    我忘了清点看似无伤大雅的关卡设计调整和地图布局的数目了,这些内容已经占据好一块不着边际的对话了。如果我再不意识到这种调整,我的头痛病怕是无药可救了吧。

    Darby:听听这宝石,伙伴们:“前往远方的黑森林吧,坚定的旅人,珍贵的水晶匕首在等着你。”

    制作人:“啊,Darby,抱歉,黑森林已经废弃,现在变成沃尔玛了。我们应该早点告诉你的。”

    Darby:呃,好吧。等等,我的笔在哪?

    只有演员把所有对话都录制完了,倒霉的团队才发现不协调的地方。所以我有必要重申一下,保持写手和设计的始终合作状态。

    制作进行时

    终于到制作阶段了,重头戏这才开始,如果所有早期工作都已经搞定了,那么制作过程应该是比较顺利的,当然,前提是投资方那方面不出问题。如果你太不小心了,这种问题还是很可能发生的。但不幸的事实并不是那么黑白分明。总有些强势的投资方,总有各种合理的理由认为剧情应该不断地修改,直到测试。你能做的就是记住:谨慎、冷静、坚持。

    在制作过程中,脚本完成后,写手就会觉得他差不多可以一边凉快,剩下的都是制作团队的事了。不要抱有这种空想,还是有点活是写手能帮上忙的。

    角色分配。 演员进行录音时,就是决定谁给谁(角色)“代言”的时候了。在一些没有正规导演的小项目中,写手就派上用场上了。务必在录音期前确定角色分配。演员的日程表总是很紧,你发现在录音环节那几周,最合适的演员总是特别忙。

    最终脚本。 虽然很困难,写手还是不得不开足马力调整对话和其他描述。当然,鼓励写手合理化内容是个不错的主意。脚本可能充满的适时的机智和智慧,但最重要的是,它是仍然是一个游戏脚本;如果它还考验写手的耐心,那就成问题了。更确切地说,脚本越长,影像制作小组就要花越多的时间来精细动画或脚本事件。所以当写手全力以赴,先知先觉地做好编写工作,那所有人都不必做多余的工作了。

    旁白录制。 有些写手也是不错的旁白录制导演。但所有优秀的写手都应该有能力重写实时对话,所以确保抄写人在录制环节能派上用场。当写手第一次听到自己写的对话,可能还想修改,所以留点修改余地,但不要让写手陷入重写“暴走”的状态。限制修改的程度,也就是只有太恶劣的错误才能调整。

    一旦漏洞被发现,写手的工作就容易多了。但仍然有必要让写手不脱离制作进程、参与讨论,但只是偶尔。

    校对。 写手从来不会重新编辑或是校对自己的作品,这倒不假,在游戏行业,编写量相当于一本小说,所以写手自己不校对也并不奇怪,另外,在QA部门也鲜有优秀的校对人员,所以尽可能让多点人过目文本,包括写手。

    非叙述文本修正。 要确定越积越多的指南、数据和菜单文本是费时的差事,但这部分工作在制作过程中是不会停止的,所幸的是,文本的执行和修正并不难,就算在最后一分钟还做出调整也没关系(如果此时你仍然在校对)。

    现在,写手的工作到尾声了,游戏也接近完工了。太好了,可以松一口气了。整个制作过程这才进入倒计时。

  • 相关阅读:
    Vue 事件修饰符 阻止默认事件
    vue created 生命周期
    续集---网络管理常用命令
    网络管理常用命令(6/14) -netstat命令详解
    系统OOM复位定位
    nohup- Shell后台运行
    一个linux命令(6/13):traceroute命令
    一个linux命令(6/12):cat 命令
    linux命令(6/11)--修改文件的用户组chgrp和文件所有者chown
    Linux终端快捷键
  • 原文地址:https://www.cnblogs.com/sevenyuan/p/3517062.html
Copyright © 2020-2023  润新知