From Evernote: |
游戏设计文件撰写原则之功能&技术说明文件 | GamerBoom.com 游戏邦Clipped from: http://gamerboom.com/archives/55505# |
游戏设计文件撰写原则之功能&技术说明文件
作者：Tim Ryan
你有没见过那些长篇累牍，厚达四英寸的设计文件？看它的厚度你可能会认为其中内容一定很强大。但读了几页之后，可能就会发现篇幅长短根本不能体现内容好坏。这种巨幅文件通常夹杂大量不甚至不明朗的内容，难以找到有用的信息。因为这些设计文件的作者并没有遵循一定的撰写原则。
本系列文章主要阐述如何将设计文件划分成适用于从理念、提案、设计到执行等不同开发阶段的内容。我已经在第一部分内容 中提供了有关和项目提案的一些建议，现在要讨论的是功能规范书和技术规格书的写作原则。
功能 vs 技术说明文件
游戏行业传统上只有一种说明文件，涉及多少技术内容主要取决于文件撰写人的意愿。而程序员之后所写的用于执行过程的文件，一般都是非正式内容，通常写在白板或记事本上。但为了确保项目执行顺畅，按期交付并且不超出预算，这种项目说明文件就应该包含更多技术内容。制作如此详细的技术说明文件需花费一些时间——而如果产品目标和功能发生变化，或者未通过批准，那么这些时间就白费了。
但随着更多富有经验的程序员和软件开发项目经理加入游戏行业，这个问题也得到了妥善解决。这些人才引进了新的文件设计标准，确保项目规划更明确，并减少了技术性问题。他们将设计文件按照目标、方法、功能和技术类别，将其划分为功能说明文件和技术说明文件。这样产品客户、用户或主设计师就可以浏览功能规范书，直接反馈是否赞同指定软件的目标和功能，而无需考虑将由程序员等人员来处理的技术性决策和文件。
因此，技术人员需等到功能说明文件通过审核并签收之后，才开始制作技术规格书。他们无需理会功能文件签收之后的任何设计变化，除非该文件更新并制定出新规划。这样就可以节省程序员的时间，让他们更好把握自己的工作安排，专注于解决执行过程中的开发方法和技术问题。
不过也有许多公司至今仍将功能规范书称为"设计文件"，但同时也会制作技术说明文件。
游戏中包含哪些内容及其用途都是功能规范书所涵盖的内容。其中包含内容通常取决于撰写者的立场和想法。而如何执行及其运行这些功能则是技术规格书的内容（游戏邦注：其撰写原则主要取决于系统角度）。这两者都是游戏开发过程中设计阶段的重要环节。
功能规范书撰写原则
功能规范书（以下简称规范书）是产品功能及特色的概括。其瞄准的读者则是执行这些工作的团队，以及负责审核游戏设计的人员。规范书是游戏理念、评论及讨论的顶点，它是游戏理念大纲及项目提案所描述愿景的具体化版本，它是技术规格书、项目进程安排和执行的起点。
必须从用户角度撰写其中所有内容。换句话说，这个文件中要描述的重点就是用户所看到、所经验或接触的内容。人们总是易于将其制作成以系统为导向的文件（尤其是程序员），但这些抽象内容非常不利于目标读者阅读和理解。读者只希望通过这份文件想象游戏中发生的情况，而不是其运行原理。
这种规范书可能短至10页，也可能长达数百页，其长短要取决于游戏系统的复杂性。但一定不能指望一页纸就了事。我曾见过不少非常出色的设计文件，有些不足50页而有些却更为冗长，重要的是内容明确而非篇幅长短。
这类文件的撰写时长也不尽相同，如果是益智游戏可能几天就足矣，射击游戏游戏是一个月，而RPG或策略游戏等更复杂的项目可能长达数月。需注意，文件撰写时长与其篇幅长短未必成正比。造成这种情况的原因包括考虑时间长短不同，当游戏拥有独一无二、原创的特性，或者玩法极具深度时更是如此。当然，主设计师制定决策的效率也会对文件撰写时长造成影响，尤其是当大家对这个游戏项目都很有想法和激情的时候。
对多数人来说，这个功能规范书就是设计文件的开端。他们可以直接跳过概念文件和项目提纳中的市场调研和评审阶段（游戏邦注：这方面内容旨在锁定项目愿景和目标市场）。
游戏首席设计师通常就是功能规范书的撰写人。这份文件可能是集体智慧的结晶，也可能只是落实到书面上的制作人项目愿意。有时候制作人也会自己动手完成这个文件，这就可以确保文件表达的正是其本人的想法。与打电话游戏一样，在撰写这种文件的时候，项目负责人所表达的想法可能与后来写在书面上的内容存在出入。无论是哪种撰写过程，或者由谁负责撰写文件，重要的是制作人和首席设计师对这个文件达成了一致意见。不可出现口头所说与纸上所写内容相左，或者完全无视文件内容的情况。
我还没见过不会在执行过程中发生变化的设计，重要的是针对文件内容进行沟通和交流，即使需要更改或添加内容也不例外。有些变动由于时间有限，需要立即处理，这样才能让文件清晰明了。即使这些变动只是写在电子备忘录或者纸张上，也要确保将其添加到未来的规范文件中。但如果游戏版本发生变化，最好从一个新理念大纲和项目提议重新开始入手。更新版文件的准确性有利于节省未来的大量时间。
另一方面，这个文件不能出现太多技术倾向，因为它的读者基本上不是程序员。如果你发现它出现技术倾向，那就要收手了，因为这是技术规格书所写的内容，否则就会让非技术读者像看天书一样不知所云。与此同理，你或者其他撰写者可能也未必是技术人员，所以无权通过这份文件指令程序员如何执行工作。这要让他们在书写技术规格书时自己决定。毕竟这个文件纯粹是用于交流和审核产品内容，而非指导如何完成任务。但你可以针对自己认为非常重要的地方进行一些简短描述。例如，你不能指令使用哪些变量，以及如何使用这些变量去模拟一个物理定律，但你可以指出与这个物理公式有关的因素。同理，你不应该告诉程序员如何定义他们的数据结构和对象，但可以针对数据输入界面和数据描述提出一些建议。
功能规范书可以划分为以下6个主要版块：
*游戏机制
*用户界面
*美术和视频
*声音和音乐
*故事（视情况而定）
*关卡需求
游戏机制
游戏机制要以详细术语描述游戏玩法，它始于核心玩法，其次是追随玩家游戏活动的游戏流程。剩下的都属于无限的细节内容。
核心玩法：要用数个段落描述游戏本质。这些文字好比是设计发芽的种子，将其植入一个已知市场的土壤，它们就会开始生根，牢牢把握目标愿景，以繁衍出成功的游戏。这与游戏理念大纲中的描述版块内容相似，但它属于非故事内容，并且其要点描述更明确，但这一点主要取决于不同游戏类型的要求。
游戏流程：对玩家活动进行详细描述，注意玩家在这一过程中的挑战性和娱乐性的发展。如果说核心玩法是大树的根，那么游戏流程就是树干和分枝，所有游戏活动都是从核心玩法扩展而来。要明确指出玩家所执行操作，尽量使用"射击"、"指挥"、"选择"和"移动"等准确的词语而非"点击"、"摁压"和"拖拽"等字眼来描述内容。因为这种描述差异可能会对GUI运行方式产生影响。如果你在此首次提到屏幕、窗口或指令条等GUI元素，那就要记得将读者引向"用户界面"版块的内容。
角色/单位（视情况而定）：它们是在游戏中受玩家或AI控制的演员。这里应包含一个简短描述和一些合适的数值。这些数值需划分成A到Z或者"高到低"等级，这样才能明确每个单位彼此间的地位。但此时不宜插入准确数据，因为程序员到时候自然会在技术规格书中提到这一点，并创建一个可让你试验这些数值的环境。除了数值之外，这里还要列出单位的特殊技能或能力，并进行简要描述，但如果这些内容很复杂，可以在"玩法元素"版块进行扩展。
玩法元素：这是针对玩家（或者角色/单位）所能接触或获取的所有元素的功能描述。其内容包括武器、建筑、转换器、升降机、陷阱、道具、咒语、升级能量和特殊技能等。在描述每个种类特点之前，要用一段话指明这些元素的引进或交互方式。
游戏物理和数值：要划分游戏中的物理元素，例如移动、爆炸、战斗等，将每个种类分成一个子集。根据分配给角色、单位和玩法元素的数值来描述这些物理内容的外观和感觉。要指出催生这些物理功能所需的数值。描写这部分内容时要征求程序员的看法，例如游戏如何处理这些物理内容，数量如何严重影响玩家表现等问题。
这里的内容可能有点枯燥，但切记不可过于技术化。不要使用确切的数字或编程术语。因为这些都是程序员之后撰写技术规格书所考虑的内容。只要告诉他们你希望获得什么效果即可。例如，"这些单位上坡时会减速，下坡时会加速，除非它们是滑翔或飞行工具。攀升和加速的数值，以及倾斜角度会影响它们的表现。"你不可告诉程序员应该使用哪种算法调整速度，因为你自己并非程序员，他们才是这方面的行家。
人工智能（视情况而定）：这里要描述游戏AI的理想行为和可用性。其中包括移动（寻径），反应、触发器、目标选择，其他作战决策（游戏邦注：例如射程、定位等），以及与玩法元素的互动。要描述关卡设计师控制AI的路径，例如使用.INI文件，包含游戏数值或C代码的文件，专用AI脚本等。
多人模式（视情况而定）：要指明多人玩法模式（例如：贴身肉博战、合作对付AI、团队等），以及在不同网络中这种模式所支持的玩家人数。要描述多人模式与单人模式在游戏流程、角色/单位、玩法元素和AI上的区别。
用户界面
因为界面变动很频繁，所以我们看似没必要将其列入文件。但是，我们将其组织到文件中，就可以最小化设计变动所造成的影响。这里的内容包括屏幕和窗口导航流程图，所有的屏幕和窗口功能需求。完成这一步后，GUI美工才可以根据需求自由发挥创意。而在美术动工之前，你得先提供模型。然后描述所有需要编程的CUI对象。
流程图：这是多个屏幕和窗口的导航图表。可以使用VISIO或类似的流程图工具将已标签和标数的方框连接起来，使其代表屏幕、窗口、菜单等元素。要记得在每个表格的角落列出所有项目的序号，以方便程序员理解和落实工作。
功能需求：这是每个屏幕、窗口以及菜单的功能分解，它应列出用户操作及预期结果，可能还会包含图表和模型。可以适当列出一些具体交互行为（例如按钮、点击、拖放和产生动画），但最好不要在此添加过多这种内容，因为这会涉及到执行方式。当然，如果点击按钮这种描述更易理解，或者真的很有必要指出某物的特定运行方式，那就要详细指出其交互方式。
模型：针对所有屏幕、窗口和菜单创建模型。这一点通常被人所忽视，但如果美工对其工作没有概念，就可以利用模型启发他们。不要费太多时间创建精美的模型，只要用一些文本标签画些简单的线条即可。没有必要上色，因为这可能弄巧成拙，除非颜色真的很重要。可以利用一些绘图软件提供的模板快速建模。
GUI对象：这是创建所有屏幕、窗口和菜单的基本模块。这里并不包括主视图入口的项目，因为它们会出现这后的美术列表中。罗列在此的GUI对象主要用于帮助程序员了解自己需要编辑的内容。你应该详细说明这些模块的交互方式。虽然这看似不值一提的内容，但结合技术规格书与项目安排来考虑事情，无疑更有助于了解项目整体需求。
有些游戏很容易整合GUI对象列表中的按钮、图标、指针、滑块、HUD元素等内容，但界面截然不同的游戏则未必如此。但无论如何，对象之间的交互方式不会有太大出入，毕竟按钮就是按钮，点击女妖的头部与点击灰色矩形并无区别。
美术和视频
这里就需要列出游戏中的所有美术和视频内容。可以添加一些占位符参照内容以便之后命名，例如特定任务的美术内容，用于营销材料、样本、网页、手册和包装的美术内容。
总体目标：在这里你要将图案、特点、风格、基调、色彩等与美术目标有关的内容描述清楚。要确保主要美术设计人员和美术总监与项目总监或制作人达成一致意见。这样就可以节省下日后的返功时间。
2D美术&动画：这真是一个足以纳入美术工作安排的大型内容列表，必要的话也可以加入描述内容。有些美术内容需要额外说明，而有些可能有特殊的设计要求，这些都要一一说明。可以将美术内容划分为多个版块。主设计人员可能有一些自己喜欢的安排方式。以下是我列出的这些典型版块内容：
*GUI：屏幕、窗口、指针、标记、图标、按钮、菜单、外形等。
*营销及包装美术设计：你在这里和美术工作安排中可能都要考虑到这一点，其中包括网页美术设计、销售传单设计、样本启动画面、杂志等平面媒体以及包装合、手册中的美术设计。
*地形：例如区块、纹理、地势目标和背景等场景美术。
*玩法元素：玩家和敌人动画（精灵或模型）、玩法结构和互动物体、武器、升级道具等。不要忘了还有受伤状态。
*特效：喝彩、爆炸、火花、足迹、血迹、碎片、残骸等。
3D美术&动画：这里的需求和用途与2D美术列表相同。其中差别可能就在于任务分工不同。美术团队通常会将3D美术任务并入建模、纹理、动画和特效工作，以便最大化利用成员的技术，并保持工作一致性。
电影艺术：这通常是指介于不同任务之间，以及出现在游戏尾声的2D或3D场景。这原本应该像电影脚本一样另外撰写一个文件，但这属于制作方面的工作。功能规范书一般也会将其纳入文件在，列出其一般用途、内容和目标长度。如果涉及相关视频内容，就会将其列入以下的子集。
视频：除非你是制作全动态影象（简称FMV）游戏，否则就没必要在这个子集中投入太多精力。如果你的GUI中有个用来阐述情节内容的视频，就可以将它纳入此列。所有的视频任务都需要编写脚本，但这属于制作工作。这里也要列出一般用途，预期长度，以及演员数量、场景设计等一般内容，即便它只是个由蓝屏切入3D渲染背景的镜头。
游戏邦注：原文发表于1999年10月19日，所涉事件及数据以当时为准。
没有评论:
发表评论