Tim Ryan解构游戏设计文档的设定问题上篇
  声音和音乐

  总体目标:强调声音和音乐的美学和技术目标。描述你所追求的主题或基调,可以列出原有游戏或电影作为参照。要指出技术要求和剪辑目标,例如采样率,磁盘空间,音乐格式 和转换方法。

  音效:列出游戏所需要的所有音效及其使用位置。要列出预期的文件名称,但在文件命名规范上要与声音程序员和音效技术人员进行沟通,以便大家快速找到音效文件,并将其运 用到游戏中。

  不要忘了所有可能需要使用音效的地方。所以要浏览一遍游戏元素及美术列表,看看还有哪些地方需要添加声音元素,以下就是一些值得考虑的地方:

  *GUI:点击按钮、打开窗口、确认命令

  *特效:武器开火、爆炸、雷达鸣响

  *单位/角色:对话录音、跺脚、碰撞等

  *玩法元素:拾取物品、警报、环境声效

  *地形(环境):鸟声、丛林声、虫鸣声

  *移动:风声、脚步声、地板咯吱声、涉水声、踏入泥淖的声音

  音乐:列出游戏中的音乐需求及其使用位置。描述音乐基调和其他微妙特点。游戏通常会重复使用一个主题和旋律,要指出需要重用这些主题的地方,并且咨询作曲人的看法。

  *事件:成功/失败/死亡/胜利/发现等。

  *屏幕:针对开头、鸣谢和结尾屏幕设置的音乐基调。

  *关卡主题:针对特定关卡的音乐(由其设计师选择音乐主题)。

  *情境:设置不同情境的基调(注:例如危险逼近、战斗和探索的时候)。

  *电影音轨

  故事(视情况而定)

  写下游戏所讲述的故事概要,包括背景故事和角色细节描述。要指时游戏文本和对话需求,以便将其添加到项目进程安排中。但也不可过份纠缠于这些细节以至于忽视其他内容, 毕竟讲述故事并非多数游戏的重点。当然,如果你开发的是一款冒险游戏,那就很有必要在此多下一番功夫。

  关卡需求

  关卡图表:不论这是一个线性活动,拥有分枝的任务树,还是一个自由开放世界,这个图表都应该是所有关卡创建的基础。如果关卡结构仅需一个简单的列表就能表述清楚,就不 需要创建图表了。下图是一个典型的成功/失败分枝任务树图表。当然每款游戏特点不同,其图表结构也会有所差异,重要的是要让它成为有助于关卡设计师和读者理解内容的线路 图。

  内容揭露计划表:它应该是一个玩家首次接触游戏时所会看到的游戏内容表格或电子表格。它可以是以关卡为行,以每种内容为列。其中的内容包括升级道具、武器、敌人类型、 诀窍、陷阱、目标类型、挑战、建筑以及其他所有游戏玩法元素。这个表格可确保游戏中的内容,即促使玩家进入下个关卡的元素妥当分配,不会出现超量或没有充分使用的情况 。

  如果有些内容已经停用,那就最好将这个计划表绘制为Gannt图,用线条指出可用的内容和资产。这样才好让关卡设计师知道自己该在何处下功夫,这样就不会搞砸自己或其他人的 关卡。

  关卡设计核心:在写出详细的设计文件之前,要先点出设计核心。设计师用工具试验并开发了首个可玩关卡之后再推出的设计,更有可能获得成功。所以此时最好先列出每个关卡 的核心,描述关卡目标,玩法以及它如何与故事(如果游戏有故事内容)相结合。可以选择先勾勒一个草图,如果设计师对此已经拥有明确想法那就再好不过了。要确保文件列出 了地形、目标、新揭露的内容,以及目标难度等级等特定的关卡需求。

  普遍误区

  以下是设计师需要注意的一些普遍问题:

  *细节不足:要用充分的细节传达关卡目的和功能,避免使用一些含糊不清的字段,除非你补充了更多详情。

  *越俎代庖:正如你不应该告诉厨师如何使用沙司调味,你也不可告诉美工如何管理自己的256调色盘,不能教程序员如何定义一个特定的数据结构。只要列出重要的目标愿景即可 ,否则只会浪费彼此的时间,毕竟这种细节更适合出现在程序员所撰写的技术规格书中。

  *模糊不清或自相矛盾的内容:要警惕这种情况,因为它会使项目愿景偏离方向,产生一些误解,导致功能规范书失效。

  *内容繁冗:这份文件可能没有什么明显错误,没有模糊不清的地方,也没有任何缺乏,但就是内容太多了。在充实这份文件时要把握好执行设计的时长,删减非必要的冗余功能, 可以将其保存起来运用到游戏继作中,或者为保留这些功能而争取推迟项目交付日期。

  *过于个人化的设计:我曾经强调过游戏设计是一个协作的过程,虽然大家是各司其职地完成自己的工作,但功能规范书应该是集体智慧的结晶,因此它不可以是一项个人产物。否 则会让人觉得自己与设计过程没多大关系,同时也会让这份文件更像是一份命令和计划。团队成员更乐意阅读大家合力完成的设计文件,这样人们提出批评意见时也主要是针对文 件本身而非作者,这样可以让大家更自在地对文件提出改进意见。

  *偏离项目愿景:即使拥有一个良好的理念大纲和项目提案,功能规范书也仍有可能出现一些不同解释内容。创意人员通常都有人马行空的想象力,并且很可能在撰写这一文件时受 到自己当时所玩游戏的影响。

  技术规格书撰写原则

  如果说功能规范书描述的是产品应该包含哪些内容,那么技术规格书解释的就是如何添加内容。技术规格书是游戏的工作蓝图,其作用是促使程序员将设计师的设想转变为现实, 在这一过程中程序员需吃透游戏该执行哪些内容,如何减少执行/集成中的障碍,如何描述编程区以及任务安排。

  Game-Design-Document

  许多公司都会略过这个步骤,因为撰写这种文件极为耗时,而且只有程序员可以从中受益。但撰写这份文件总比因未撰写文件而对错误问题采取补救措施更省时省力。技术规格书 的主要作者是主程序员或技术总监,不过如果可以让负责不同编程区域的程序员分工完成内容,这会提高文件撰写效率。必须采用每个程序员都能理解和入手的编辑格式。

  该文件的目标读者是项目主程序员以及公司技术总监。因此它是以系统而非用户角度出发撰写内容,看起来会很枯燥,对制作人和其他非技术人员来说简直像是天书。但制作人要 求撰写这一文件的目的在于,确保技术人员考虑周全,即便制作人本身对此并不了解。对主程序员来说,这是一个组织思维和勾勒项目框架的方法。这种编写文件的过程有助于显 示编程环节中的不确定因素和漏洞,以及功能规范书中的模糊或荒谬之处。

  许多出色的技术规格书编写格式与本文描述并不相同。这里的格式主要与功能规范书相对应,以确保覆盖所有的功能规范内容。有时候开发团队也可以出于分工不同,或因为基础 系统组织方式而选择不同编写形式。如果这样的话,我建议他们细读功能规范书的每行文字,并以萤光笔标出相关内容,以免忽略某些内容。毕竟疏漏一个细节可能会令产品、项 目和团队动态产生令人不快的结果。

  这些原则不会教你如何执行游戏开发,其假设前提是你已经是一个技术能手,富有经验的游戏程序员,而生手则不应该参与这项任务。我认为优秀的技术规格书应该遵从这些原则 ,它们会要求你定义所有游戏中的最普遍元素。有些原则可能并不适用于你的项目,但每个原则都值得认真考虑,毕竟它可能对你有所启发,而这也正是撰写这份文件的意义之一 。

  游戏机制

  这当然也是这份文件的组成部分。但在这里你会发现将其与功能规范书中的游戏机制部份一一对应的做法有多荒唐了。因为这份文件应以系统为出发点,而不是以设计师或用户的 角度来写作。开篇要提到的是硬件平台和操作系统,外部供应码对象(例如DLL、EXE、驱动器等),并描述内部生成码对象。然后再区分起源于控制环路的特定游戏代码机制。

  平台及操作系统:要指出项目所需的硬件平台、操作系统以及支持版本。对PC/Mac游戏来说,要提到最小系统需求和目标运行设备。如果游戏并非以CD而是以卡盘等形式发售,那 就要提到相应的ROM要求。

  外部代码:要描述并非项目团队所开发的所有代码来源和用途。这包括操作系统代码和针对不同游戏平台的预处理工具,驱动器和DirectX等代码库,以及项目所需的3D API,或其 他现成解决方案。

  代码对象:分解多种代码对象编码、编译和创建到EXE的用途和范围。如果使用到非进程内或者同进程的代码库(例如DLL),那也要分别进行说明,要说清使用对象实例及其存在 目的。

  控制环路:每款游戏都有一个控制环路。要详细说明启动代码、主游戏代码的控制转换过程。说明核心循环的功能名称及其作用,例如碰撞、移动和渲染路径。要解释多线程、驱 动器、DLL和内存管理的使用原因。当然,多线程和内存管理的更多详情应该出现于它们使用最频繁的区域,例如渲染或精灵引擎,声音代码和AI。

  这部分内容概括的是支持核心玩法的系统和内在框架,以及功能规范书所描述的游戏流程内容。

  游戏对象数据:先仔细阅读功能规范书中关于所有角色/单位的描述,以及游戏玩法元素内容。然后规划并列出所有数据结构,以及能够支持这些描述特点、功能和行为的标识符。 从某种程度上说,只有游戏物理、统计数值和AI部分内容考虑周全并载入文件时才可能做到这一点。在为用户界面或任何包含单位/玩法对象特定数据(注:例如图票、HUD 元素、动画或特效参

Leave a Reply