游戏设计文档之功能规格书Word下载.docx

游戏设计文档之功能规格书Word下载.docx

《游戏设计文档之功能规格书Word下载.docx》由会员分享，可在线阅读，更多相关《游戏设计文档之功能规格书Word下载.docx（12页珍藏版）》请在冰豆网上搜索。

因此，技术人员需等到功能说明文件通过审核并签收之后，才开始制作技术规格书。

他们无需理会功能文件签收之后的任何设计变化，除非该文件更新并制定出新规划。

这样就可以节省程序员的时间，让他们更好把握自己的工作安排，专注于解决执行过程中的开发方法和技术问题。

不过也有许多公司至今仍将功能规范书称为“设计文件”，但同时也会制作技术说明文件。

游戏中包含哪些内容及其用途都是功能规范书所涵盖的内容。

其中包含内容通常取决于撰写者的立场和想法。

而如何执行及其运行这些功能则是技术规格书的内容（游戏邦注：

其撰写原则主要取决于系统角度）。

这两者都是游戏开发过程中设计阶段的重要环节。

功能规范书撰写原则

功能规范书（以下简称规范书）是产品功能及特色的概括。

其瞄准的读者则是执行这些工作的团队，以及负责审核游戏设计的人员。

规范书是游戏理念、评论及讨论的顶点，它是游戏理念大纲及项目提案所描述愿景的具体化版本，它是技术规格书、项目进程安排和执行的起点。

必须从用户角度撰写其中所有内容。

换句话说，这个文件中要描述的重点就是用户所看到、所经验或接触的内容。

人们总是易于将其制作成以系统为导向的文件（尤其是程序员），但这些抽象内容非常不利于目标读者阅读和理解。

读者只希望通过这份文件想象游戏中发生的情况，而不是其运行原理。

这种规范书可能短至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渲染背景的镜头。

声音和音乐

强调声音和音乐的美学和技术目标。

描述你所追求的主题或基调，可以列出原有游戏或电影作为参照。

要指出技术要求和剪辑目标，例如采样率，磁盘空间，音乐格式和转换方法。

音效：

列出游戏所需要的所有音效及其使用位置。

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

不要忘了所有可能需要使用音效的地方。

所以要浏览一遍游戏元素及美术列表，看看还有哪些地方需要添加声音元素，以下就是一些值得考虑的地方：

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

武器开火、爆炸、xx鸣响

*单位/角色：

对话录音、跺脚、碰撞等

拾取物品、警报、环境声效

*地形（环境）：

鸟声、xx声、虫鸣声

*移动：

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

音乐：

*事件：

成功/失败/死亡/胜利/发现等。

*屏幕：

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

*关卡主题：

针对特定关卡的音乐（由其设计师选择音乐主题）。

*情境：

设置不同情境的基调（游戏邦注：

例如危险逼近、战斗和探索的时候）。

*电影音轨

故事（视情况而定）

写下游戏所讲述的故事概要，包括背景故事和角色细节描述。

要指时游戏文本和对话需求，以便将其添加到项目进程安排中。

但也不可过份纠缠于这些细节以至于忽视其他内容，毕竟讲述故事并非多数游戏的重点。

当然，如果你开发的是一款冒险游戏，那就很有必要在此多下一番功夫。

关卡需求

关卡图表：

不论这是一个线性活动，拥有分枝的任务树，还是一个自由开放世界，这个图表都应该是所有关卡创建的基础。

如果关卡结构仅需一个简单的列表就能表述清楚，就不需要创建图表了。

下图是一个典型的成功/失败分枝任务树图表。

当然每款游戏特点不同，其图表结构也会有所差异，重要的是要让它成为有助于关卡设计师和读者理解内容的线路图。

内容揭露计划表：

它应该是一个玩家首次接触游戏时所会看到的游戏内容表格或电子表格。

它可以是以关卡为行，以每种内容为列。

其中的内容包括升级道具、武器、敌人类型、诀窍、陷阱、目标类型、挑战、建筑以及其他所有游戏玩法元素。

这个表格可确保游戏中的内容，即促使玩家进入下个关卡的元素妥当分配，不会出现超量或没有充分使用的情况。

如果有些内容已经停用，那就最好将这个计划表绘制为Gannt图，用线条指出可用的内容和资产。

这样才好让关卡设计师知道自己该在何处下功夫，这样就不会搞砸自己或其他人的关卡。

关卡设计核心：

在写出详细的设计文件之前，要先点出设计核心。

设计师用工具试验并开发了首个可玩关卡之后再推出的设计，更有可能获得成功。

所以此时最好先列出每个关卡的核心，描述关卡目标，玩法以及它如何与故事（如果游戏有故事内容）相结合。

可以选择先勾勒一个草图，如果设计师对此已经拥有明确想法那就再好不过了。

要确保文件列出了地形、目标、新揭露的内容，以及目标难度等级等特定的关卡需求。

普遍误区

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

*细节不足：

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

*越俎代庖：

正如你不应该告诉厨师如何使用沙司调味，你也不可告诉美工如何管理自己的256调色盘，不能教程序员如何定义一个特定的数据结构。

只要列出重要的目标愿景即可，否则只会浪费彼此的时间，毕竟这种细节更适合出现在程序员所撰写的技术规格书中。

*模糊不清或自相矛盾的内容：

要警惕这种情况，因为它会使项目愿景偏离方向，产生一些误解，导致功能规范书失效。

*内容繁冗：

这份文件可能没有什么明显错误，没有模糊不清的地方，也没有任何缺乏，但就是内容太多了。

在充实这份文件时要把握好执行设计的时长，删减非必要的冗余功能，可以将其保存起来运用到游戏继作中，或者为保留这些功能而争取推迟项目交付日期。

*过于个人化的设计：

我曾经强调过游戏设计是一个协作的过程，虽然大家是各司其职地完成自己的工作，但功能规范书应该是集体智慧的结晶，因此它不可以是一项个人产物。

否则会让人觉得自己与设计过程没多大关系，同时也会让这份文件更像是一份命令和计划。

团队成员更乐意阅读大家合力完成的设计文件，这样人们提出批评意见时也主要是针对文件本身而非作者，这样可以让大家更自在地对文件提出改进意见。

*偏离项目愿景：

即使拥有一个良好的理念大纲和项目提案，功能规范书也仍有可能出现一些不同解释内容。

创意人员通常都有人马行空的想象力，并且很可能在撰写这一文件时受到自己当时所玩游戏的影响。