文本 冒险: 写作 和游戏 开发 在本科 课程
摘要
借鉴电子游戏研究领域的学术成果,本文主张:我们不应仅仅将游戏作为文本客体进行写作,或通过玩游戏来揭示 其对写作的启示,而应设计相应的课程,向学生介绍支撑一款成功游戏所需的所有写作工作。本文更广泛的论点是:优 秀的写作能够带来优秀的软件。在此情境下,所涉及的软件恰好是一款视频游戏。软件与信息技术产业重视具备技能的 编写人员,从事写作教学法的相关人员应持续探索为学生准备这些职业机会的新方法。建议以现有的叙事学方法教授游 戏作为起点。本文记录了一项通过软件与游戏开发来教授写作的具体实践。文章展示了学生在从零开始开发自己的文字 冒险游戏时,如何完整经历整个软件开发生命周期及其众多写作挑战。©2015ElsevierInc.全部 rights 已保留.
关键词
视频 游戏; 写作 教学法; 开发; 软件; 叙事; 专业 写作; 技术 写作 ng
对于研究视频游戏的研究人员而言,2008年是标志性的一年。《计算机与写作》和《计算机与写作在线》期刊均 出版了专刊,主题为“阅读游戏:写作、读写能力与视频游戏”。同样,《技术传播》期刊也发布了一期关于“三维虚 拟世界与技术传播”的专刊。这些文章的大多数作者都指出了游戏研究领域不断扩展的里程碑,包括将游戏与学习和读 写能力联系起来的研究(吉,2003),揭示游戏修辞层面及其如何构建论点的研究(博戈斯特,2007),探索游艺学及 游戏玩法研究的工作(朱尔,2005),以及将游戏置于跨媒体叙事更大体系中的研究(詹金斯,2006)。此外,人文学 科学者继续开展重要的学术研究,对视频游戏进行理论化探讨(佩龙与沃尔夫,2009),分析它们为何在文化上“重要” (比塞尔,2011),以及它们如何持续帮助我们学习(斯奎尔,2011)。人文学科的学者,在
特别是,深入挖掘了游戏和游戏玩法所揭示的种族、阶级、性别、身份和身体等问题(伯恩,2006;卡里, 2006;格雷格森和托本,2009)。诸如技术写作教师协会、大学写作与传播会议以及计算机与写作等会议 每年都有数量稳定的专题讨论会聚焦于游戏。事实上,有关游戏和博弈论的学术研究持续发表于与修辞与 写作以及专业与技术传播相关的论文集和主要期刊中。
至于游戏的未来发展趋势,道格拉斯·艾曼在2011年发表于《计算机与写作》的一篇文章中写道,该文 章题为“计算机与写作20/20:一场对话,或一些非常聪明的人对未来的看法”。
我认为,在写作教学法的发展过程中,有两个写作场所将变得越来越普遍和重要,即移动设备和虚拟 环境(包括数字游戏)。事实上,这两个场所很可能会相互交汇,因为游戏实践与素养会从游戏的虚 拟空间流畅地延伸到物理领域。(沃克等人,第329页) 我也认为,在写作课程的教学进步方面,游戏还有更多的潜力可挖掘。本文的其余部分将探讨一门专 注于视频游戏开发的本科写作课程的设计、实施及其成果。该课程旨在明确建立写作、视频游戏和广义软 件开发之间的联系。在本科阶段开设视频游戏开发课程,至少部分受到艾曼在2008年《技术传播》关于虚 拟世界的特刊中所提出观点的启发(并得到支持):
游戏都是构建系统,需要经历任何计算机应用程序所需的相同开发周期和业务流程;因此,它们为技术传 播人员提供了与参与任何系统开发项目时相同的机会,以发挥他们所具备的技能与专业知识。(第243页)
尽管艾曼的文章大部分内容致力于阐述一个“将多人游戏生态与技术传播人员的工作与关切联系起来 的理论模型”(2008年,第246页),而我的重点则是阐明一门课程,该课程充分利用了艾曼的系统性观 察,使学生接触到整个软件开发生命周期以及与该周期相关的所有写作活动。在此情况下,所涉及的软件 恰好是一款视频游戏。开发周期与写作之间的关联之所以重要,不仅因为软件行业雇佣了大量技术传播人 员(Lanier,2009),更因为我希望学生在完成课程时能够更深入地理解:优秀的写作促成优秀的软件。
也就是说,我并不太关注技术传播人员“能否通过写作进入游戏产业”,而是更感兴趣于利用游戏来广义 地模拟开发过程(艾曼,2008年,第246页)。
对软件开发生命周期加上“广义上定义的”这一限定语是必要的,因为并不存在唯一一种开发流程, 而且正如我向学生强调的那样,没有任何两个开发环境及其资源会完全相同。开发流程可能受特定工作场 所或企业文化驱动,但开发团队构建软件的方式在很大程度上受到团队项目经理及其开发理念的影响。借 鉴爱丽丝·罗比森(AliceRobison,2008年)的民族志学术研究及其发现——“视频游戏设计的原则与创 建任何成功课程的原则出人意料地相似”(第362页),本文展示了写作教师如何在一个专注于写作与游戏 开发的课程中,将自己定位为既是“教师又是管理者”(第364页)。本文接下来将概述该课程内容,讨论 开发周期,考察课程所选用的文本式冒险游戏开发软件,并详细说明学生写作和展示要求是如何与游戏开 发相结合的。文章最后总结了对该课程成果的观察。
1. 本科游戏课程
游戏课程的正式名称为“叙事与视频游戏设计”。该课程首次于2012年春季学期开设,隶属于我所在的英语 系专业写作与编辑项目。正如我在22人的课程中所讨论的那样,我并不认为通过探讨视频游戏中呈现的叙事特征, 这门课程在内容上具有任何新颖之处。关于视频游戏与叙事之间的关联及影响,学术界早已存在长期的讨论。
在叙事与视频游戏等新媒体之间(阿塞斯,1997;马诺维奇,2001;米多斯,2003;瑞安,2004)。正如 艾曼等人指出的那样,叙事如今被视为进入游戏的一种“起点”(2008年,第246页)。然而,对于一门 假设学生没有游戏或其开发经验的本科课程而言,亟需一个易于入手的切入点。
简而言之,叙事理论探讨的是特定媒介如何传达事件、角色、场景和视角,而我们课程所关注的特定 媒介是视频游戏。我曾在其他地方讨论过在编写软件需求和设计文档时运用叙事的潜在好处,我希望学生 能够熟悉叙事理论的一些基本原理(巴伦廷,2010)。我们在学期初的阅读材料包括了H·波特·艾博特( 2008年)广受引用的叙事学导论中的章节,因此学生们具备了一些共同的术语基础。尽管我们都乐于分享 自己最喜爱的游戏是如何传达我们认为引人入胜的故事的,或者说艾博特所称的“事件序列”(2008年, 第13页),但我将课程的重点放在更宏大的目标上,即开发他们自己的游戏。也就是说,我希望课程既能 聚焦于我们自己的创造性叙事如何融入游戏玩法之中,也能关注叙事在我们软件开发过程中的作用。这些 目标与对游戏进行批判性分析以揭示其叙事结构有很大不同。我们对叙事的应用更接近于为商业软件制定 规范,而不是例如试图理论化C.S.刘易斯的《镜中世界》中的元素如何出现在美国麦吉的爱丽丝中。这并 不是说此类讨论没有价值,然而,鉴于一个学期的时间有限,以及课程旨在让学生体验从开始到完成的完 整开发过程,因此课程仅用短暂时间涉及了关于叙事和叙事学的诸多争论(参见巴尔,1997;米切尔, 1980;普林斯,1982)。
2. 软件开发生命周期
不同的公司及其开发团队使用不同的方法,甚至使用不同的术语来讨论他们的软件开发方式,这些方 式通常被泛称为软件开发生命周期(SDLC)。敏捷开发、瀑布模型、螺旋模型和快速原型开发是开发过程 中广为人知的具体示例。有关软件开发的讨论可以在电气与电子工程师协会(IEEE)的附属期刊和会议论 文中找到。例如,Paetsch、Armin和Frank(2003)发表的论文《需求工程与敏捷软件开发》就是一篇 优秀的入门文章,有助于理解这两种开发方法的重叠之处以及它们可能存在的差异。游戏课程中的学生通 过两个来源了解了软件开发的框架。第一个来源是微软发布的一份白皮书,其中概述了该公司称之为“微 软解决方案框架”(MSF)的方法(微软,2003)。该方法认可了现有各种开发方法的优势,并提出了一 种整合这些优势的方式:
每个项目都会经历一个生命周期,即包含项目完成之前及过渡到运行状态期间所有活动的过程。生命 周期模型的主要功能是确定项目活动的执行顺序。MSF过程模型结合了传统瀑布模型和螺旋模型的概 念,以发挥两者的优势。该过程模型将瀑布模型中的基于里程碑的规划与螺旋模型中的渐进式迭代项 目交付物相结合。(2003,第18页)
从非常实际的意义上说,微软对其开发周期的呈现为游戏课程中的学生提供了一幅地图。尽管我可以 依靠自身的需求驱动开发经验,但设计和讲授一门关于写作与游戏的课程并非必须如此。拥有微软的模型 (见图1)将有助于学生和写作教师遵循课程的时间安排。
学生接触到的第二种模型来自课程的主要文本之一《游戏关卡设计:创造引人入胜的游戏体验》(Co, 2006)。作者菲尔·科是一位资深的游戏设计师,他将视频游戏开发周期划分为两个主要部分:前期制作和生产。
每个部分包含的阶段大致类似于MSF,且这些阶段又细分为子类别。例如,科的高概念阶段中的概念性工作大致 对应于MSF的构想阶段。科的框架和MSF都在这一阶段用于确定项目并建立愿景。由于科专门针对视频游戏开 发,因此他将确定美术方向作为项目愿景的一个关键组成部分(2006,p.3)。这些细节是
向学生指出这一点很重要,但微软白皮书与科的模型之间的主要区别在于,科将其过程描述为一个线性模型。此处以项目符号列表的 形式重现如下:
- 前期制作
- Hire 团队
- Brainstorm 想法
- High 概念
- 确定 项目
- 建立 美术 方向
- 设计 文档
- 开发 设计
- 创建 世界 地图
- 原型/演示
- 建立 技术
- 建立 工具
- 生产
- 创建 关卡
- 创建 美术 资源
- 添加 功能
- 修订 内容
- 阿尔法
- 改进 内容
- 替换 美术 资源
- 修复 问题
- 测试版
- 修复 问题
- 最终 候选人
- 修复 主要 问题
- 黄金 大师
- 拿取 假期
- Brainstorm Next Project (科, 2006)
科指出,根据项目不同(例如,拥有现有美术作品的游戏续作与全新的项目),各个阶段所需的时间 也不同。然而通常情况下,生产阶段最长,紧随其后的是Alpha阶段的质量控制和改进措施。
科的模型和MSF都是极为有用的工具,但它们均未直接涉及写作教师在准备教授游戏课程时的需求。
罗比森(2008)的研究从游戏行业项目经理的视角揭示了游戏开发的创作过程,进而为写作教师提供了引 导学生团队完成游戏生命周期的策略。写作教师会认同这种以受众为中心、即在此情境下为玩家导向的开 发讨论方式。作为互动文本,任何游戏的首要目标都应是“使玩家能够通过其游戏体验产生有意义的社会 叙事”(罗比森,2008,第361页)。也就是说,写作教师必须教会学生如何通过协作写作来创造出被受众 视为有价值或具有“趣味性”的游戏体验。尽管捕捉像“趣味性”这样主观的概念可能非常困难,但罗比 森强调,“努力尝试至关重要”(罗比森,2008,第363页)。
幸运的是,写作教师的培训包括了介入高度主观空间的能力,例如写作过程中的构思与发现阶段。但 是,正如没有单一理论能确保写作产生预期的修辞效果一样,也没有单一的开发策略能够保证游戏为玩家 提供适当的挑战程度,或更为抽象的成就感(Co,2006,p.67)。作为教师与管理者的写作教师,其职责 是引导学生度过开发过程中创造性与主观性的混乱。为此,了解成功的项目经理如何结合使用自上而下与 自下而上方法来完成软件开发生命周期并发布游戏将非常有帮助(罗宾森,2008年,第364页)。
罗比森采访的项目经理在开始他的1流程时,会先撰写一份“基于他希望玩家在体验其游戏后所描述的 感受而形成的论文或使命声明”,然后还需与团队合作制定大纲,作为游戏中每个部分的检查清单与计划 (2008年,第363页)。尽管这种高度脚本化或自上而下的开发方法确实为团队提供了明确的方向,但这 并不妨碍项目经理同时采用自下而上的策略。自下而上法是对小型游戏内事件的提炼,可能只需“将游戏 中一系列有趣的时刻描述出来,例如一连串令人愉快的谜题或活动,就足以帮助团队达成构想并清晰表达 游戏的核心设定及其趣味性”(罗宾逊,2008年,第364页)。当团队在项目初期无法清晰构想并表达游 戏愿景时,项目经理可指导团队在开发过程中的任何阶段切换方法,例如转为采用自下而上法。罗比森明 确指出,该项目经理认为其工作的一个关键方面是“帮助设计团队思考构建游戏的两种理论方法”(2008 年,第364页)。巧合的是,罗比森研究中的这位项目经理被确认就职于微软,尽管文中并未具体提及他所 遵循的上述MSF(微软解决方案框架)。然而可以确定的是,他的策略属于一种混合模型,其结合自上而 下与自下而上的方法,适用于专注于游戏设计的本科写作课堂。在我的课程中,每个团队在软件开发生命 周期的不同阶段都曾陷入困境与停滞,引导他们转变开发的理论方法,从而进入创作过程中的‘顿悟’时 刻(罗宾逊,2008年,第364页),绝非易事。我再次需要思考:如何将一个能够容纳创造性过程混乱性 的完整开发周期融入到为期一学期的课程中,以及在何处、以何种方式简化游戏的开发。
3. 游戏开发软件
实现这一简化的第一步是选择学生用于游戏开发的软件。该课程在由院系管理的计算机实验室中授课,因此 安装和配置新软件是可行的。此外,用于教授游戏开发的软件选择众多。科的书籍附带了EpicGames的关卡编 辑软件UnrealEd的简化版本。随书附赠的光盘可在基于Windows的个人电脑上安装和运行,其中还包含示例纹
理、游戏主题和概念美术。像GameSalad[http://gamesalad.com/] 这样的开发软件则提供了一个免费的拖放 式编辑器,无需编码或编程技能即可进行游戏开发。
有才华横溢且取得巨大成功的女性游戏设计师,如KimSwift(《Portal》和《量子困境》)、RobertaWilliams(SierraOnline联合创始人, 《国王密使》系列所有Quest游戏的设计师)以及JaneJenson(《GabrielKnight》),但目前在游戏行业中,“女性仍然是局外人”( Burrows,2013)。
适用于Mac和WindowsPC平台以及苹果和安卓设备的游戏(专业版售价为299美元)。YoYo游戏公司为其GameMaker软件[ http://yoyogames.com/studio] 提供了免费版本,同样支持Mac和WindowsPC平台,并可选择购买99.99美元的专业版。
在众多选择中,我选用了突出写作的软件。本课程开发的游戏有意弱化了美学方面的考虑,而是使用 名为Quest的免费开源软件构建经典的文字冒险游戏。Quest(www.textadventures.co.uk)及其开发环 境具有适中的学习曲线、完善的教程以及活跃的开发者论坛。Quest可安装并运行于基于Windows的个人 电脑,或使用其基于网络的版本。游戏文件可以导出,并在大多数网页浏览器中运行。游戏还可以导出为 苹果或安卓应用。总之,Quest对于本课程的目标而言是最佳选择,因为它功能足够强大,能够制作出有 意义的游戏,但又不至于过于复杂,以致学习软件本身成为课程的主要负担。
Quest确实具备将图像和声音导入游戏的能力,从而提供比传统文本冒险更丰富的审美体验。然而, 我向学生明确表示,他们在前期制作和生产阶段的写作应以故事情节为核心来驱动游戏设计,而非美术。
我不希望学生过于关注游戏的视觉或听觉方面。正因为Quest是基于文本的,我发现更容易让学生专注于 贯穿整个开发周期的写作,并让他们认识到作者在整个开发周期中的贡献是至关重要的。
4. 使用 Quest
在我向学生介绍支持其游戏开发的写作作业之前,学生需要先了解文字冒险游戏软件,并实际体验 Quest游戏。Quest的主页面(见图2)提供了可免费游玩的游戏链接,以及用户论坛和Quest维基中的教 程。Quest主页右侧的教育链接包含了已使用该软件的学校和教师的相关信息
Quest在课堂中的应用。(页面上有一个链接指向该游戏课程。)作为指定阅读材料的一部分,学生需要学习维 基教程,并熟悉论坛的使用。在学期开始时,我并不清楚学生最终会多么依赖Quest论坛的支持。到了学期末, 我(以及学生们)都意识到,论坛作为一个宝贵的资源,能够让文字冒险游戏爱好者这一小群但专注的群体发布 问题并获得帮助。因此,学生通过与论坛及其成员互动,获得了一些计划外的专业写作体验。
Quest的游戏界面(见图3)对于玩过《Zork》三部曲等经典文字冒险游戏的玩家来说可能看起来很熟悉。
Quest还对这一类型做了一些改进:界面右下角提供了可点击的罗盘导航,以及用于输入命令的标准文本输入框。
玩家还可以点击链接或带下划线的对象,并激活任意数量的预设动作。当然,真正的挑战与其说是让学生对玩文 字冒险游戏产生兴趣,不如说是教会一群学生(其中一些人的技术能力非常有限)如何开发他们自己的游戏。
本节的其余部分旨在展示Quest适中的学习曲线,并概述其基本功能。幸运的是,学生无需掌握 Quest的全部功能即可制作出可运行的游戏。新开发者主要需要学习如何添加带有出口和入口的房间、对象、 动词或动作以及脚本。向游戏中添加房间或对象只需单击一次,系统会提示开发者为新房间或对象命名并 进行描述。例如,开发者可以添加一个新房间并将其命名为“宿舍房间”。描述可以是:“你可以看到一 张书桌、一本手册和一个手电筒。这是一个光线昏暗的 14′乘 14′英尺的方形房间,墙壁涂有砖墙。”由于 描述中提到了具体物品(砖墙、书桌、手册和手电筒),如果玩家需要与这些物品互动,开发者可能会希 望将这些物品作为对象引入游戏中。因此,在点击对象选项卡并将新对象命名为“手电筒”后,开发者可 以添加类似“这个老旧而沉重的手电筒有一个开关”的描述。手册也可以作为一个对象添加,附上同样简 短的描述。随着游戏的开发,开发环境左侧的菜单(见图4)会持续跟踪开发者的房间及其内部的对象。
为了实现与对象的互动,开发者需要确定这些对象可能执行的相应动作,然后添加适当的动词。要添 加动词,开发者可以点击Quest的动词选项卡,并输入他认为玩家可能会尝试与特定对象关联使用的任何 词语。例如,对于手电筒对象,开发者可能希望添加一些动词短语,如“打开”、“关闭”或“摇晃”。
类似地,手册对象可能需要“使用”或“阅读”等动词。虽然可为特定对象附加无限数量的动词,但开发 者还需准备添加描述,以便在玩家执行某个动作后向其展示结果。因此,当玩家命令“阅读手册”时,系 统可能返回响应:“你认真地从头到尾阅读了手册的内容。”但如果开发者希望“阅读手册”的能力取决 于手电筒是否处于使用状态,这时就需要用到脚本的作用。
Quest作为一款开发软件,其真正的强大之处在于开发者能够轻松生成脚本。为了让这个示例正常运行,玩 家需要能够首先捡起或“拿取”手电筒,并将其添加到自己的物品栏中。为此,开发者首先要选择手电筒的“物 品栏标签”,然后勾选“对象可被拿取”旁边的复选框。接下来,开发者需返回手册对象的“动词选项卡”。当 玩家尝试阅读手册时,不再只是返回一条基本消息,而是可以从下拉菜单中选择“运行脚本”选项,然后点击按
钮“+ 添加新脚本”。脚本选项众多,无法在此一一详述,但开发者可以通过一个简单的“如果、则、否则脚本” 创造出引人入胜的游戏体验。通过选择现在可见的单选按钮“if”,开发者将看到更多脚本选项。在本例中,开 发者会从菜单中选择“玩家正在携带一个对象”,然后选择手电筒对象。倒数第二步是添加一段描述,说明当玩 家在持有手电筒的情况下尝试阅读手册时会发生什么。例如,“你打开了旧手电筒,现在可以清楚地看到手册上 的内容并进行阅读”就足够了。最后一步是“否则”部分,用于处理玩家未持有手电筒的情况。Quest的直观界 面为开发者提供了另一个文本框,可用于添加类似“你试图阅读手册,但在黑暗中无法看清文字”的描述。虽然 无需实际编写代码,学生却开始逐步理解编程逻辑是如何运作的。也就是说,如果玩家拥有手电筒,则可以阅读 手册;否则,返回一条提示信息说明环境太暗。
学生在课程结束时报告称,他们最初确实对Quest感到一些挫败,但随后表示,为了开发具有一定复 杂性的游戏,这种学习曲线是值得投入的。学生在尝试设计复杂的游戏中谜题时最容易遇到挫折,例如要 求玩家在特定顺序下收集一系列对象,同时还要满足时间限制。学生们还表示,他们能够看出技术写作任 务与游戏开发之间的联系。
5. 写作 作业 在 一个 视频 游戏 开发 课程
本课程的大部分写作作业直接源自Co的文本以及他在每章末尾提供的系列提示。还应注意的是,Co的 书名本身就暗示了游戏开发者通常会为单个游戏构建多个关卡。就本课程而言,学生们明白他们将致力于 创作一款单关卡文字冒险游戏。为了让学生能够完成所有必要的工作,他们被组织成三到四人小组。写作 教师应准备好像在任何写作课程中一样,在学生起草和修改作业时与小组合作。虽然Co的提示在开发的自 上而下和自下而上的方法之间提供了有用的结合,但写作教师的作用是指导小组利用写作来思考游戏的开 发过程。同样重要的是,教师需要帮助小组认识到某种方法何时未能产生效果。例如,如果一个小组在开 发初期无法制定出明确的任务声明,则教师需要将小组的重心转向自下而上法,以生成“串联起来的游戏 精彩片段”(罗宾逊,2008年,第364页)。然后,教师可以帮助学生基于这些片段阐明他们游戏的整体 愿景。如果没有
在教师担任项目经理的积极角色的情况下,学生团队可能在游戏的软件开发生命周期中的任何阶段停滞,并且无法在学期结束前完成他们的游 戏。
将学生从活动引导到独立制作自己的游戏是一个困难的过程。首先,时间问题令人担忧。正如科在文 中早期所提醒的那样:“一个项目从概念到完成可能需要六个月到六年的时间”(2006,第2页)。他确实 指出这些范围代表的是极端情况,但在此并无太大安慰作用。对于新手游戏开发者来说,只有一个学期的 时间来完成整个开发周期,学生们感受到了生产截止日期的压力。幸运的是,学生们在整个学期中一直在 使用Quest,并且已经制作了可添加到游戏中的脚本谜题原型。尽管如此,我的作业序列对软件开发生命周 期进行了部分简化,以便学生和我能够更高效地集中注意力。本课程的作业序列始于定义游戏,然后进入 概念规划、玩法规划、反馈、前期制作、生产,最后是试玩测试。
他们的第一个任务来自科第2章“定义游戏”的结尾部分,学生需要确定他们拟开发的游戏的类型、主 题、目标受众和平台(2006年,第63页)。他们还被要求为游戏撰写一段简短的“包装背面”描述。也就 是说,他们必须编写一段文本,让玩家在GameStop或百思买等商店拿起该游戏的实体包装时,或在线阅 读相关信息时能够看到。教师应将此作业介绍为一种自上而下的开发方法,旨在为学生的游戏提供焦点和 相当于任务声明的内容。当然,游戏类型已为他们确定:每个人都在开发一款文字冒险游戏。由于Quest 游戏可以导出并在网页浏览器、iPhone以及安卓设备上运行,因此关于平台的问题也已得到解答。流行的 主题包括科幻与奇幻、后末日场景以及中世纪。其中一个小组将其主题归类为水下冒险,后来命名为《尼 斯的大冒险》。他们的描述邀请玩家帮助被称为尼斯湖水怪的尼斯逃离湖泊,并与她在北海的家人团聚。 包装背面描述中承诺玩家将面对一系列涉及渔船和水坝的谜题需要解决。尽管该团队将他们的游戏评级为 “E”(适合所有人),但大多数其他团队则选择了青少年目标受众。
接下来进入微软框架中的“规划”阶段,学生们被要求识别并报告其游戏及游戏角色的边界或限制。正如伊恩·博 格斯特(2011年)所写:
视频游戏是一种媒介,它让我们能够在模型世界的约束内扮演角色。与操场游戏或棋盘游戏不同,视 频游戏具有计算性,因此它们所产生的模型世界和规则集可以更加复杂。(第4页)
在本学期的这个阶段,学生们刚刚开始熟悉Quest的脚本功能,但此时要求他们记录下希望在自己的 游戏中实现的限制条件并不过早。这项写作作业改编自科的“限制玩家可进行的操作”练习,分为两个部 分(2006年,第86页)。首先,学生需要确定他们希望融入游戏中的所有障碍,这意味着各小组必须思考 构成其游戏叙事(事件序列)的一系列事件。可以引导学生利用这一自下而上的练习,将这些事件序列串 联起来,以强化和优化游戏的主要任务。其次,科强调了对角色技能进行分类的重要性。但由于学生正在 开发的是文字冒险游戏,因此他们并不太关注角色的身体能力,例如攀爬、奔跑、蹲下和跳跃,这些能力 在第一人称或第三人称射击游戏中才更为重要。相反,第二部分要求学生列出玩家在游戏中可能遇到或需 要互动才能成功通关的所有对象。因此,学生创建了一个电子表格,列出其游戏中最可能出现的对象,以 及角色可用于与这些对象互动的动词或动作词汇。例如,在一款名为ZombieApocalypse的游戏中,团队 成员确定了燃烧的汽车、上锁的门以及成群的僵尸等障碍。他们还列出了灭火器、撬棍、手电筒、急救包 和电池等对象。然后将每个对象与其对应的动词(如使用、拿取、打开、打开、关闭、投掷和挥动)一一 对应。
仍处于开发周期的“规划”阶段,接下来要求学生小组基于他们已确定的主题以及将融入游戏的对象 进一步展开构思。科将这一练习称为“植入关卡构思”,但由于我们正在构建的是文字冒险游戏,因此需 要进行一些调整(2006,第113页)。该任务分为五个部分,首先要求学生扩展其选定的主题,并描述其 Quest冒险中包含的空间类型,即房间。也就是说,学生应基于其核心设定或“对游戏的整体陈述”及其 “整体用户目标”进行构建。
在开发的这一阶段(罗宾森,2008年,第362页),例如,学生游戏《主厨》设定在一个城堡中,玩家必须 在城堡的多个房间中寻找食材,为国王烹饪一道三道菜餐点。该小组提到他们将建造诸如厨房、大厅、面 包店、肉铺和地牢等房间。其次,为了帮助撰写这些房间的描述,学生们在线搜索了能够体现他们希望在 游戏中叙事所传达建筑风格的图片。尽管学生们确实达到了能够熟练使用Quest的程度,可以在游戏中展示 图像和声音,但加入图形并非强制要求。接下来,学生们确定了几个可作为游戏内地标对象的元素。科建 议使用诸如“喷泉、雕像、特色建筑和大型机械”等对象,供玩家在游戏中定位自己(2006年,第101页)。 《主厨》小组决定在城堡中央设置一口水井,而《僵尸末日》团队则使用一堵压扁汽车墙作为他们游戏的 北边界。第四,各小组详细阐述了至少一个希望融入游戏中的谜题。《尼斯湖水怪》小组在其包装背面描 述中承诺会有一个涉及渔船的谜题,而现在他们进一步提供了关于被困在渔网中以及尼斯湖水怪需要如何 自救的细节。最后,各小组被要求起草一段更长的游戏开场场景描述。由于学生无法编程实现复杂的电影 式过场动画,因此文字冒险游戏的文本写作对于玩家的游戏体验至关重要。
除了这项作业的写作和研究要求外,学生还需要将自己的作品改编成Prezi演示文稿,并向同学展示。 正如我在其他地方讨论过的那样,Prezi的非线性结构非常适合展现冒险游戏中的众多路径和可能性( Ballentine,2012)。演示者可以在无限延伸的画布上任意位置添加内容,并通过Prezi的平移和缩放功能 将这些内容相互连接。该演示的重要目的在于促使学生讨论彼此的游戏,并分享应对学习Quest过程中已 遇到挑战的想法。
科所称的前期制作阶段的最后一项作业源自他的“布局你的关卡”任务,该任务要求学生从头到尾绘 制其游戏空间的示意图。正如科所指导的:“创建示意图并没有固定标准。示意图可以是快速的铅笔草图, 也可以是使用AdobeIllustrator、AdobePhotoshop或MicrosoftVisio等计算机程序制作的精细演示” (2006年,第129页)。我向学生提供了Photoshop的基本操作指导,包括如何为示意图创建图层、形状 和文本。然而,我建议各小组先使用坐标纸、尺子和铅笔进行初步绘图。科的文本为学生提供了多个优秀 的参考模型,但他的建议强调要基于开发周期中先前的工作:“如果你已经为关卡创作了关卡叙事,并根 据每个区域的功能对关卡进行了分解⋯⋯那么你实际上已经接近完成关卡布局了”(2006年,第131页)。 也就是说,写作教师可能需要指导学生团队采用自下而上法来思考这项作业,将他们已经设计好的谜题、 叙事和角色串联起来。学生的示意图展示了游戏中所有的房间以及房间之间的出入口。这些房间被标注或 编号,且标签与各小组此前已起草的叙事文本相对应。示意图还标明了特定对象的位置以及玩家将遇到谜 题的位置。
当学生完成游戏的可运行版本后,各小组建立了测试合作伙伴关系。当然,在开发过程中,学生们一 直在试玩、测试并改进自己的游戏;然而,正如大多数开发者所证实的那样,让其他人使用你的作品是一 种完全不同的体验。科对测试阶段之间的一些细微差别提供了见解,例如阿尔法和测试版之间的区别,但 就我们课程的目的而言,我们试图一次性涵盖游戏的所有问题,包括一般的游戏玩法问题以及错误和漏洞。 例如,尽管Alpha阶段通常意味着大部分创意工作已经完成,但传统上仍提供了通过调整游戏中不同阶段 任务难度的平衡来优化游戏性能的机会。在一款名为《潘多拉魔盒》的学生游戏中,玩家必须在月球基地 爆炸前逃生。学生们已足够熟练地使用Quest为游戏添加计时器,但测试将验证所设定的逃生时间是否既 现实又具有挑战性。与此同时,测试人员也在针对游戏过程中遇到的具体错误撰写漏洞报告。根据科的说 法,“每位开发者都应知道如何正确编写漏洞报告”(2006,第319页)。鉴于各类测试在软件行业中的 重要作用(例如,甚至产品手册和在线帮助系统也要经过可用性测试),所有参与项目的人,尤其是编写 人员,都应掌握测试方法并报告结果。学生们被要求使用一个基本表格来跟踪漏洞,并将其反馈给相应的 游戏团队。以下是一份漏洞报告示例:
漏洞报告的类型因公司而异,但绝大多数都会要求测试员详细说明重现错误所需的步骤。测试人员通 常还被要求对漏洞进行评级和排序。例如,如果某个漏洞导致程序崩溃,或在本案例中使游戏无法继续且 无法获胜,则该漏洞会被评为严重级别,并被赋予最高修复优先级。学期末,学生提交所有的游戏开发文 档作为期末作品集。各小组对其经过调试后的“黄金大师”版本游戏进行简短演示,全班同学受邀共同分 享并体验彼此的文字冒险游戏。
6. 评估
学期结束时,学生小组将他们写作材料的最终修订版本汇编成期末作品集,并提交了其Quest游戏的 最终可玩版本。尽管团队的书面文档可以以其自身质量(组织结构、有效性、对类型的遵循)进行评估, 但学生们被告知,他们的写作将与其Quest游戏一并评估。评估“游戏创造性的产出”极具挑战性,但正 如许多写作教师所认同的那样,评估“(有时明显缺乏趣味的)写作产出”同样困难(罗宾森,2008,第 360页)。这一做法并非要让写作与游戏开发相互竞争,而是为了向学生强化两者之间的联系。他们在写作 中详细描述的功能、限制、谜题和地图必须在其游戏中得以实现。对于学生和教师而言,这种评估方式有 助于缓解围绕“趣味性”或“有趣的游戏”所存在的主观性所带来的压力。当然,本课程中产生的某些游 戏比其他游戏更受欢迎。然而,即使较不受欢迎的游戏,也因学生写作的有效性以及团队运用这些写作成 功创造出富有挑战性的交互式体验的能力,而达到了课程标准的要求。
7. 结论
在整个学期中,尽可能频繁地向学生开发者展示他们的工作与微软的框架等软件开发生发生命周期之间的关 联。艾曼最初提出的观点——游戏和“任何计算机应用程序”一样都是“构建系统”——被反复强调。建立这种 联系意味着学生能够更实际地认识到,他们在支持游戏开发过程中所撰写的文档对于任何构建系统的开发都是可 迁移且有用的。
当然,学生也面临着构思和管理自身系统开发的挑战。但他们并非独自应对这一挑战。写作教师作为 项目经理的角色,意味着学生在游戏创意开发过程中能够获得协助,并且可以借助一位领导者来指导他们 如何运用自上而下与自下而上方法相结合的方式。我认为,学生在课程中所获得的技能
致力于写作与游戏开发的学生对雇主具有重要价值,且软件行业早已认识到学生开始并完成一款游戏所面临任务的难度。 构建软件系统中最困难的部分是精确地确定要构建的内容。在概念性工作中,没有其他部分比确定详 细的技术需求更为困难,其中包括与人、机器及其他软件系统的所有接口。如果这一部分做错了,对 最终系统的损害将最为严重。也没有其他部分在事后更难修正。(布鲁克斯,1987,第17页) 尽管自布鲁克斯最初发表《没有银弹》以来,计算机技术已取得显著进步,但他关于软件应用概念性 工作所面临挑战的许多观点至今仍然成立。也就是说,即使学生可以免费使用Quest这类基于网络的开发软 件,也并不意味着他们的游戏会自动实现。相反,先进技术带来更高期望。斯科特·罗森伯格(2007)在 《编码梦想》的引言中更直白地指出:“软件是一堆麻烦”,从头到尾成功开发软件绝非易事(第10页)。
尽管系统开发充满挑战,但软件也为专业和技术编写人员提供了巨大的机会去产生影响。2008年,大卫·迈 克尔·谢里丹和威廉·哈特‐戴维森曾提出:“如果你能通过玩视频游戏来学习写作呢?”(第323页)。这是 一个很好的问题,但如果你能通过开发视频游戏来学习为软件和技术行业写作呢?学生越了解项目如何实 现以及如何依赖写作,他们在工作面试、工作场所或研究生项目中就会越有优势。核心信息是:优秀的软 件需要优秀的写作者。
游戏开发中的写作教学实践

被折叠的 条评论
为什么被折叠?



