游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

阐述游戏设计文件撰写原则之功能规范书

作者:Tim Ryan

你有没见过那些长篇累牍,厚达四英寸的设计文件?看它的厚度你可能会认为其中内容一定很强大。但读了几页之后,可能就会发现篇幅长短根本不能体现内容好坏。这种巨幅文件通常夹杂大量不甚至不明朗的内容,难以找到有用的信息。因为这些设计文件的作者并没有遵循一定的撰写原则。

game design document(from quebarium.co)

game design document(from quebarium.co)

本系列文章主要阐述如何将设计文件划分成适用于从理念、提案、设计到执行等不同开发阶段的内容。我已经在第一部分内容中提供了有关和项目提案的一些建议,现在要讨论的是功能规范书和技术规格书的写作原则。

功能 vs 技术说明文件

游戏行业传统上只有一种说明文件,涉及多少技术内容主要取决于文件撰写人的意愿。而程序员之后所写的用于执行过程的文件,一般都是非正式内容,通常写在白板或记事本上。但为了确保项目执行顺畅,按期交付并且不超出预算,这种项目说明文件就应该包含更多技术内容。制作如此详细的技术说明文件需花费一些时间——而如果产品目标和功能发生变化,或者未通过批准,那么这些时间就白费了。

但随着更多富有经验的程序员和软件开发项目经理加入游戏行业,这个问题也得到了妥善解决。这些人才引进了新的文件设计标准,确保项目规划更明确,并减少了技术性问题。他们将设计文件按照目标、方法、功能和技术类别,将其划分为功能说明文件和技术说明文件。这样产品客户、用户或主设计师就可以浏览功能规范书,直接反馈是否赞同指定软件的目标和功能,而无需考虑将由程序员等人员来处理的技术性决策和文件。

因此,技术人员需等到功能说明文件通过审核并签收之后,才开始制作技术规格书。他们无需理会功能文件签收之后的任何设计变化,除非该文件更新并制定出新规划。这样就可以节省程序员的时间,让他们更好把握自己的工作安排,专注于解决执行过程中的开发方法和技术问题。

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

游戏中包含哪些内容及其用途都是功能规范书所涵盖的内容。其中包含内容通常取决于撰写者的立场和想法。而如何执行及其运行这些功能则是技术规格书的内容(游戏邦注:其撰写原则主要取决于系统角度)。这两者都是游戏开发过程中设计阶段的重要环节。

功能规范书撰写原则

功能规范书(以下简称规范书)是产品功能及特色的概括。其瞄准的读者则是执行这些工作的团队,以及负责审核游戏设计的人员。规范书是游戏理念、评论及讨论的顶点,它是游戏理念大纲及项目提案所描述愿景的具体化版本,它是技术规格书、项目进程安排和执行的起点。

必须从用户角度撰写其中所有内容。换句话说,这个文件中要描述的重点就是用户所看到、所经验或接触的内容。人们总是易于将其制作成以系统为导向的文件(尤其是程序员),但这些抽象内容非常不利于目标读者阅读和理解。读者只希望通过这份文件想象游戏中发生的情况,而不是其运行原理。

这种规范书可能短至10页,也可能长达数百页,其长短要取决于游戏系统的复杂性。但一定不能指望一页纸就了事。我曾见过不少非常出色的设计文件,有些不足50页而有些却更为冗长,重要的是内容明确而非篇幅长短。

这类文件的撰写时长也不尽相同,如果是益智游戏可能几天就足矣,射击游戏游戏是一个月,而RPG或策略游戏等更复杂的项目可能长达数月。需注意,文件撰写时长与其篇幅长短未必成正比。造成这种情况的原因包括考虑时间长短不同,当游戏拥有独一无二、原创的特性,或者玩法极具深度时更是如此。当然,主设计师制定决策的效率也会对文件撰写时长造成影响,尤其是当大家对这个游戏项目都很有想法和激情的时候。

对多数人来说,这个功能规范书就是设计文件的开端。他们可以直接跳过概念文件和项目提纳中的市场调研和评审阶段(游戏邦注:这方面内容旨在锁定项目愿景和目标市场)。

游戏首席设计师通常就是功能规范书的撰写人。这份文件可能是集体智慧的结晶,也可能只是落实到书面上的制作人项目愿意。有时候制作人也会自己动手完成这个文件,这就可以确保文件表达的正是其本人的想法。与打电话游戏一样,在撰写这种文件的时候,项目负责人所表达的想法可能与后来写在书面上的内容存在出入。无论是哪种撰写过程,或者由谁负责撰写文件,重要的是制作人和首席设计师对这个文件达成了一致意见。不可出现口头所说与纸上所写内容相左,或者完全无视文件内容的情况。

我还没见过不会在执行过程中发生变化的设计,重要的是针对文件内容进行沟通和交流,即使需要更改或添加内容也不例外。有些变动由于时间有限,需要立即处理,这样才能让文件清晰明了。即使这些变动只是写在电子备忘录或者纸张上,也要确保将其添加到未来的规范文件中。但如果游戏版本发生变化,最好从一个新理念大纲和项目提议重新开始入手。更新版文件的准确性有利于节省未来的大量时间。

另一方面,这个文件不能出现太多技术倾向,因为它的读者基本上不是程序员。如果你发现它出现技术倾向,那就要收手了,因为这是技术规格书所写的内容,否则就会让非技术读者像看天书一样不知所云。与此同理,你或者其他撰写者可能也未必是技术人员,所以无权通过这份文件指令程序员如何执行工作。这要让他们在书写技术规格书时自己决定。毕竟这个文件纯粹是用于交流和审核产品内容,而非指导如何完成任务。但你可以针对自己认为非常重要的地方进行一些简短描述。例如,你不能指令使用哪些变量,以及如何使用这些变量去模拟一个物理定律,但你可以指出与这个物理公式有关的因素。同理,你不应该告诉程序员如何定义他们的数据结构和对象,但可以针对数据输入界面和数据描述提出一些建议。

功能规范书可以划分为以下6个主要版块:

*游戏机制

*用户界面

*美术和视频

*声音和音乐

*故事(视情况而定)

*关卡需求

游戏机制

游戏机制要以详细术语描述游戏玩法,它始于核心玩法,其次是追随玩家游戏活动的游戏流程。剩下的都属于无限的细节内容。

核心玩法:要用数个段落描述游戏本质。这些文字好比是设计发芽的种子,将其植入一个已知市场的土壤,它们就会开始生根,牢牢把握目标愿景,以繁衍出成功的游戏。这与游戏理念大纲中的描述版块内容相似,但它属于非故事内容,并且其要点描述更明确,但这一点主要取决于不同游戏类型的要求。

游戏流程:对玩家活动进行详细描述,注意玩家在这一过程中的挑战性和娱乐性的发展。如果说核心玩法是大树的根,那么游戏流程就是树干和分枝,所有游戏活动都是从核心玩法扩展而来。要明确指出玩家所执行操作,尽量使用“射击”、“指挥”、“选择”和“移动”等准确的词语而非“点击”、“摁压”和“拖拽”等字眼来描述内容。因为这种描述差异可能会对GUI运行方式产生影响。如果你在此首次提到屏幕、窗口或指令条等GUI元素,那就要记得将读者引向“用户界面”版块的内容。

角色/单位(视情况而定):它们是在游戏中受玩家或AI控制的演员。这里应包含一个简短描述和一些合适的数值。这些数值需划分成A到Z或者“高到低”等级,这样才能明确每个单位彼此间的地位。但此时不宜插入准确数据,因为程序员到时候自然会在技术规格书中提到这一点,并创建一个可让你试验这些数值的环境。除了数值之外,这里还要列出单位的特殊技能或能力,并进行简要描述,但如果这些内容很复杂,可以在“玩法元素”版块进行扩展。

玩法元素:这是针对玩家(或者角色/单位)所能接触或获取的所有元素的功能描述。其内容包括武器、建筑、转换器、升降机、陷阱、道具、咒语、升级能量和特殊技能等。在描述每个种类特点之前,要用一段话指明这些元素的引进或交互方式。

游戏物理和数值:要划分游戏中的物理元素,例如移动、爆炸、战斗等,将每个种类分成一个子集。根据分配给角色、单位和玩法元素的数值来描述这些物理内容的外观和感觉。要指出催生这些物理功能所需的数值。描写这部分内容时要征求程序员的看法,例如游戏如何处理这些物理内容,数量如何严重影响玩家表现等问题。

这里的内容可能有点枯燥,但切记不可过于技术化。不要使用确切的数字或编程术语。因为这些都是程序员之后撰写技术规格书所考虑的内容。只要告诉他们你希望获得什么效果即可。例如,“这些单位上坡时会减速,下坡时会加速,除非它们是滑翔或飞行工具。攀升和加速的数值,以及倾斜角度会影响它们的表现。”你不可告诉程序员应该使用哪种算法调整速度,因为你自己并非程序员,他们才是这方面的行家。

人工智能(视情况而定):这里要描述游戏AI的理想行为和可用性。其中包括移动(寻径),反应、触发器、目标选择,其他作战决策(游戏邦注:例如射程、定位等),以及与玩法元素的互动。要描述关卡设计师控制AI的路径,例如使用.INI文件,包含游戏数值或C代码的文件,专用AI脚本等。

多人模式(视情况而定):要指明多人玩法模式(例如:贴身肉博战、合作对付AI、团队等),以及在不同网络中这种模式所支持的玩家人数。要描述多人模式与单人模式在游戏流程、角色/单位、玩法元素和AI上的区别。

用户界面

因为界面变动很频繁,所以我们看似没必要将其列入文件。但是,我们将其组织到文件中,就可以最小化设计变动所造成的影响。这里的内容包括屏幕和窗口导航流程图,所有的屏幕和窗口功能需求。完成这一步后,GUI美工才可以根据需求自由发挥创意。而在美术动工之前,你得先提供模型。然后描述所有需要编程的CUI对象。

game UI flowchart(from behance.net)

game UI flowchart(from behance.net)

流程图:这是多个屏幕和窗口的导航图表。可以使用VISIO或类似的流程图工具将已标签和标数的方框连接起来,使其代表屏幕、窗口、菜单等元素。要记得在每个表格的角落列出所有项目的序号,以方便程序员理解和落实工作。

功能需求:这是每个屏幕、窗口以及菜单的功能分解,它应列出用户操作及预期结果,可能还会包含图表和模型。可以适当列出一些具体交互行为(例如按钮、点击、拖放和产生动画),但最好不要在此添加过多这种内容,因为这会涉及到执行方式。当然,如果点击按钮这种描述更易理解,或者真的很有必要指出某物的特定运行方式,那就要详细指出其交互方式。

模型:针对所有屏幕、窗口和菜单创建模型。这一点通常被人所忽视,但如果美工对其工作没有概念,就可以利用模型启发他们。不要费太多时间创建精美的模型,只要用一些文本标签画些简单的线条即可。没有必要上色,因为这可能弄巧成拙,除非颜色真的很重要。可以利用一些绘图软件提供的模板快速建模。

GUI对象:这是创建所有屏幕、窗口和菜单的基本模块。这里并不包括主视图入口的项目,因为它们会出现这后的美术列表中。罗列在此的GUI对象主要用于帮助程序员了解自己需要编辑的内容。你应该详细说明这些模块的交互方式。虽然这看似不值一提的内容,但结合技术规格书与项目安排来考虑事情,无疑更有助于了解项目整体需求。

有些游戏很容易整合GUI对象列表中的按钮、图标、指针、滑块、HUD元素等内容,但界面截然不同的游戏则未必如此。但无论如何,对象之间的交互方式不会有太大出入,毕竟按钮就是按钮,点击女妖的头部与点击灰色矩形并无区别。

美术和视频

这里就需要列出游戏中的所有美术和视频内容。可以添加一些占位符参照内容以便之后命名,例如特定任务的美术内容,用于营销材料、样本、网页、手册和包装的美术内容。

总体目标:在这里你要将图案、特点、风格、基调、色彩等与美术目标有关的内容描述清楚。要确保主要美术设计人员和美术总监与项目总监或制作人达成一致意见。这样就可以节省下日后的返功时间。

2D美术&动画:这真是一个足以纳入美术工作安排的大型内容列表,必要的话也可以加入描述内容。有些美术内容需要额外说明,而有些可能有特殊的设计要求,这些都要一一说明。可以将美术内容划分为多个版块。主设计人员可能有一些自己喜欢的安排方式。以下是我列出的这些典型版块内容:

*GUI:屏幕、窗口、指针、标记、图标、按钮、菜单、外形等。

*营销及包装美术设计:你在这里和美术工作安排中可能都要考虑到这一点,其中包括网页美术设计、销售传单设计、样本启动画面、杂志等平面媒体以及包装合、手册中的美术设计。

*地形:例如区块、纹理、地势目标和背景等场景美术。

*玩法元素:玩家和敌人动画(精灵或模型)、玩法结构和互动物体、武器、升级道具等。不要忘了还有受伤状态。

*特效:喝彩、爆炸、火花、足迹、血迹、碎片、残骸等。

3D美术&动画:这里的需求和用途与2D美术列表相同。其中差别可能就在于任务分工不同。美术团队通常会将3D美术任务并入建模、纹理、动画和特效工作,以便最大化利用成员的技术,并保持工作一致性。

电影艺术:这通常是指介于不同任务之间,以及出现在游戏尾声的2D或3D场景。这原本应该像电影脚本一样另外撰写一个文件,但这属于制作方面的工作。功能规范书一般也会将其纳入文件在,列出其一般用途、内容和目标长度。如果涉及相关视频内容,就会将其列入以下的子集。

视频:除非你是制作全动态影象(简称FMV)游戏,否则就没必要在这个子集中投入太多精力。如果你的GUI中有个用来阐述情节内容的视频,就可以将它纳入此列。所有的视频任务都需要编写脚本,但这属于制作工作。这里也要列出一般用途,预期长度,以及演员数量、场景设计等一般内容,即便它只是个由蓝屏切入3D渲染背景的镜头。

声音和音乐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

*电影音轨

故事(视情况而定)

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

关卡需求

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

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

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

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

普遍误区

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

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

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

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

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

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

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

游戏邦注:原文发表于1999年10月19日,所涉事件及数据以当时为准。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

The Anatomy of a Design Document, Part 2: Documentation Guidelines for the Functional and Technical Specifications

by Tim Ryan

Editor’s note: Part 1 of this article was published on 10.19.99.

Did you ever look at one of those huge design documents that barely fit into a four-inch thick, three-ring binder? You assume that by its page count that it must be good. Well, having read some of those design volumes from cover to cover, I can tell you that size does not matter. They are often so full of ambiguous and vague fluff that it was difficult finding the pertinent information. So why does this happen? Because the authors didn’t follow guidelines.

This article is part two of a two part series that provides guidelines that when followed will ensure that your design documents will be pertinent and to the point.

Unlike the authors of those prodigious design volumes, I believe in breaking up the design document into the portions appropriate to the various steps in the development process – from concept and proposal to design and implementation. I covered the first two steps in part one of the article, providing guidelines for the game concept and game proposal. This part will provide guidelines for the two heaviest undertakings – the functional specification and technical specification, as well as some guidelines for the paper portion of level design.

Functional vs Technical Specifications

Traditionally in the game industry, there was only one spec. How technical it was depended on who wrote it. Any documentation the programmers wrote afterwards to really plan how they were going to implement it was informal and often remained on white-boards or notepads. Yet in order to ensure the project would proceed without hazard and on time and on budget, the documentation needed to be more technical. Such detailed technical specifications took time – time wasted if the goals and function of the product should change or fail to gain approval.

This problem was tackled as more and more seasoned programmers and managers of business software development moved into games. They brought with them new standards for documentation that helped ensure more accurate plans and less technical problems. They introduced a division in the design document between goals and method and between function and technique. They separated the design document into the functional specification and technical specification. This way, the clients, users or principal designers of the product could review the functional specification and approve the goals and functions of the proposed software – leaving the determination and documentation of the methods and technique up to the technical staff of programmers.

Therefore, the technical staff waited until the functional specification was approved and signed-off before starting on the technical specification. They worked from the functional specification alone, ignoring any design changes that occurred after sign-off unless the spec was updated and a new schedule agreed to. Thus the division saved time for the programmers and gave them more control of the schedule, while still ensuring they had a complete plan for the methods and technique for implementation.

Many companies still refer to the functional specification as the “design document” and yet also produce a technical specification. The term “functional” is a clearer term adapted by businesses and these guidelines to clarify what is expected in the document. Here is a link to a formal definition:

http://webopedia.internet.com/Software/functional_specification.html

In short, what goes into the game and what it does is documented in the functional specification. This is often written from the perspective of the user. How it is implemented and how it performs the function is documented in the technical specification. This is often written from the system perspective. Both form important deliverable milestones in the design stage of the game development process.

Guidelines for the Functional Specification

The functional specification (or spec for short) outlines the features and functions of the product. The target audience is the team doing the work and those responsible for approving the game design. The functional spec is a culmination of the ideas, criticisms and discussions to this point. It fleshes out the skeleton of the vision as expressed in the game concept and game proposal. It is a springboard from which the technical specification and schedule is derived and the implementation begins.

It’s important that it is all written from the user perspective. In other words, what is seen, experienced or interacted with should be the focus of the document. It’s often very tempting (especially to programmers) to create something that’s very system oriented. This often leads to distraction and hard-to-fathom documents.

Readers are really just looking to this document to visualize what’s in the game, not how it works.

The length can vary from ten pages to a few hundred, depending on the complexity of the game. You really should not aim for a page count. I’ve seen and written really GOOD design documents that were less than fifty pages and some that were much more. It is just important that each section under these guidelines be addressed.

This will eliminate the vagaries and guesswork that comes with insufficient documentation and the apparent need to ramble-on that comes with aiming for a high page count.

The time involved in writing the functional spec is anywhere from a few days for say a puzzle game, a month for a shooter, to a few months for a complex game such as an RPG or strategy game. The amount of time spent may not be congruent to the resulting length. The discrepancy comes with deliberation time, especially if the game has any unique, unexplored qualities or if the game play is particularly deep. Of course, how efficient the principal designers are in making their decisions is of enormous impact as well, especially if everyone is particularly imaginative and passionate about the game.

For many, this functional specification is where the documentation begins. They skip the important research and review phase of the concept document and game proposal, which would otherwise help it anchor the vision and target market firmly in place. By skipping the first steps, they also put off the inevitable criticism from marketing, finance and technical staff, which leads to wasted efforts.

The game’s lead designer usually produces the functional specification. It may be a compilation of other’s work and hence a cooperative effort or it could simply be a matter of putting the vision of the producer on paper. Sometimes the producer will produce the document him/herself; which is ideal for assuring that the vision expressed is indeed what the producer desires. Like the game of telephone, sometimes the message gets altered when it goes from the lead visionary to the author.

Whatever the process and whoever the author, it’s important that the producer and lead designer totally agree with everything expressed in this document. They cannot be preaching one thing and documenting another or the documents will be ignored and serve no purpose.

I’ve never seen a design that didn’t undergo some changes during implementation, but the process of communication has to be expressed through the specification, even if it requires updates or an addendum. Some changes need to be fast and furious due to time constraints so the documentation may be light. So, even if it’s an electronic memorandum or notes on a piece of paper, be sure to distribute these and attach them to all future copies of the specification. If the vision of the game changes, however, it’s best to start from the beginning with a new concept document and proposal. The clarity the updated documentation brings will save time in the long run.

Unlike the game concept and proposal, the functional specification is not a selling document. It merely breaks down and elaborates on the vision in very clear terms understandable by every reader. It can be a little boring or dry as the necessary details are filled in. I’d recommend putting in summary level paragraphs at the start of every section, so that readers can get the gist without skipping any sections or losing any confidence in the thoroughness of the specification. Why do I recommend this? Well, the question should really be “Why do some people never find the time to thoroughly read the project specifications?” While your company’s managers and team members might not fail in this regard, there’s always a third party, like the publisher or contractor.

On the other hand, this document cannot be technically explicit, as its readers are mostly non-programmers. If you find yourself getting technical, stop. That’s what the subsequent technical specification is for. Besides, getting technical with a bunch of non-technical readers can make their eyes glaze over or open up a can-of-worms. You don’t want to give them an invitation to stick their nose into something they don’t necessarily understand and really shouldn’t care about. Likewise, you or the other authors may be non-technical, and you shouldn’t be dictating to the programmers how they accomplish what you want them to do. Let them determine that when they write the technical specification. This document is purely for the communication and approval of what goes into the product as opposed to how to accomplish it. Limit descriptions of how something should be accomplished to those areas that are you believe are really important that it work a certain way. For example, you would not indicate what variables to use and how to use them to simulate a law of physics; however, you might want to indicate the factors involved in the physics equation. Similarly, telling a programmer how to define his data structures and objects is a bad idea, but proposing the interface for data entry and the delineation of data is certainly within the confines of function.

The functional specification can be broken down into a few major sections:

•Game Mechanics

•User Interface

•Art and Video

•Sound and Music

•Story (if applicable)

•Level Requirements

Game Mechanics

The game mechanics describe the game play in detailed terms, starting with the vision of the core game play, followed by the game flow, which traces the player activity in a typical game. The rest is all the infinite details.

Core Game Play: In a few paragraphs describe the essence of the game. These few words are the seeds from which the design should grow. Planted in the fertile soil of a known market, they should establish roots that anchor the vision firmly in place and help ensure a successful game. This is similar to the description section in the game concept, except that it’s non-narrative, and usually expressed clearest in bullet points, though this could vary depending on the type of game.

Game Flow: Trace the typical flow of game play with a detailed description of player activity, paying close attention to the progression of challenge and entertainment. If the core game play is the root of a tree, the game flow is the trunk and the branches. All activity should actualize and extend from the core game play. Be specific about what the player does, though try to use terms like “shoot”, “command”, “select” and “move” rather than “click”, “press” and “drag”. This keeps the description distinct from how the actual GUI will work, which is likely to change. Refer readers to specific pages in the User Interface section when you first mention a GUI element such as a screen or window or command bar.

Characters / Units (if applicable): These are the actors in the game controlled by the players or the AI. This should include a brief description and any applicable statistics. Statistics should be on a rating scale i.e. A to Z or Low to High, so that it’s clear where units stand in relation to each other in broad terms. It’s a waste of time plugging in the actual numbers until the programmers have written the technical specification and created an environment for you to experiment with the numbers. Special talents or abilities beyond the statistics should be listed and briefly described, but if they are complex, they should be expanded upon in the game play Elements section.

Game Play Elements: This is a functional description of all elements that the player (or characters/units) can engage, acquire or otherwise interactive with. These are such things as weapons, buildings, switches, elevators, traps, items, spells, power-ups, and special talents. Write a paragraph at the start of each category describing how these elements are introduced and interacted with.

Game Physics and Statistics: Break out how the physics of the game should function, i.e. movement, collision, combat etc., separating each into subsections. Describe the look and feel and how they might vary based on statistics assignable to the characters, units and game play elements. Indicate the statistics required to make them work. Get feedback from the programmers as you write this, as how the game handles the physics and the quantity of the statistics will severely impact performance issues.

This can get a little dry, but avoid getting too technical. Avoid using actual numbers or programming terms. These will come later in the technical specification, written by the programmers who will want to do things their way (usually the right way). Just tell them what you want to accomplish. For example: “The units should slow down when going up hill and speed up when going down, unless they are a hover or flying vehicle. How much they are affected should be a factor of their climbing and acceleration statistic as well as the angle of the incline.” You would not tell the programmers what math to use to adjust the speed. Assuming you are not a programmer yourself, they’re just better at that than you.

Artificial Intelligence (if applicable): Describe the desired behavior and accessibility of the AI in the game. This includes movement (path finding), reactions and triggers, target selection and other combat decisions such as range and positioning, and interaction with game play elements. Describe the avenue through which the AI should be controlled by the level designers, i.e. using .INI files, #include files of game stats or C-code, proprietary AI scripts, etc.

Multiplayer (if applicable): Indicate the methods of multi-player play (i.e. head-to-head, cooperative vs. AI, teams, every man for himself, hotseat) and how many players it will support on the various networking methods. Describe how multi-player differs from solo-play in game flow, characters/units, game play elements and AI.

User Interface

The interface changes so very often that it almost seems pointless to document it; however, it’s got to start somewhere. It’s structured here to minimize the impact of changes. It’s starts with a flowchart of the screen and window navigation, then breaks down the functional requirements of all the screens and windows. That done, the GUI artist is free to do what he or she feels is right as long as it meets the requirements. To get him or her started you should provide mock-ups. This often is to the designer’s benefit to think everything through. Then follow up with a description of all the GUI objects that need to be programmed to make all the screens work.

Flowchart: This charts the navigation through the various screens and windows. Use VISIO or similar flowcharting tool to connect labeled and numbered boxes together, representing screens, windows, menus, etc. On the corner of each sheet, put a numbered list of all the items for easy referencing and ease of defining tasks for the programmers.

Functional Requirements: This functional breakdown of every screen, window and menu lists the user actions and the desired results and may include diagrams and mock-ups. While the specific interaction (buttons, hotspots, clicks, drags and resulting animations) can be listed, it’s often best to keep this separate from the list of functional requirements as these can evolve during implementation. Of course if it’s just easier to think in terms of clicking a button or it’s really important that something work a certain way, then by all means get specific about the method of interaction.

Mockups: Create a mock-up for all the screens, windows and menus. This may end up getting ignored, but it’s a good starting point for the artists if they have no idea what else they may want to do. Don’t waste your time creating anything really pretty. Just create simple line drawings with text labels. Color can be very distracting if it’s bad, but if it’s important, go ahead. Some drawing programs have templates that make creating mock-ups very quick and easy.

GUI Objects: These are the basic building blocks used to create all the screens, windows and menus. This should not include the items seen in the main view portal, as these are covered in the art list in the next section. The GUI objects are primarily listed here for the programmers to know what pieces they’ll need to code and have for putting together the screens. You should explain in detail how each is interacted with and how they behave. It may seem a bit obvious and not worth documenting, but it really helps when drafting together the technical spec and schedule to know exactly everything the game will need.

For some games, this can be a very quick list to put together – buttons, icons, pointers, sliders, HUD displays etc. But it’s much more complicated in games where the interface is at all different. However, keep in mind that the methods of interaction are not all that different. A button is still a button, even if it’s clicking on a gorgon’s head instead of a gray rectangle.

Art and Video

This should be the definitive list for all the art and video in the game. We all know how things creep up, though, so add a couple of placeholder references for art to be named later, like mission specific art and art for marketing materials, demos, web pages, manual and packaging.

Overall Goals: This is where you should spell out the motifs, characteristics, style, mood, colors etc. that make up the goals for the art. Gather consensus with the lead artists and art director and make sure they see eye to eye with the project’s director or producer. Doing so now will save a lot of time later if they end up redoing everything because the goals were never clearly defined.

2D Art & Animation: This is really just a huge list that can be thrown into the art schedule. It can also include descriptions if needed. Some art isn’t self-explanatory, and other may involve specific needs from a design standpoint. Be sure to explain it all. Break your art down into sections. The lead artist may have some particular way he or she would like you to do that. I’ll list the typical section and their contents. Read them all to be sure you don’t forget anything.

GUI: Screens, windows, pointers, markers, icons, buttons, menus, shell etc.

Marketing and Packaging Art: You might as well list it here and the schedule, because they’ll ask for it. This includes web page art, sell sheet design, demo splash screens, magazine adds, press art, the box and manual.

Terrain: Environment art like tiles, textures, terrain objects, backgrounds

Game Play Elements: Player and enemy animations (sprites or models), game play structures and interactive objects, weapons, power-ups, etc. Don’t forget damage states.

Special Effects: Salvo, explosions, sparks, footprints, blood spots, debris, wreckage

3D Art & Animation: This serves the same purpose and has the same requirement of the 2D Art list above. The difference may be in how the work may be divided. Art teams like to divide 3D art task lists into models, textures, animations and special effects, as they usually divide the tasks this way to maximize talent and skill and maintain consistency.

Cinematics: These are the 2D or 3D scenes often shown as an intro, between missions, and at the end of the game. These should be scripted like a film script as separate documents. This, however, is production work. For the purposes of the functional spec, just list them here with the general purpose, content and target length. If any video is involved, list it in the following subsection.

Video: Unless you are doing an FMV (full motion video) game, this subsection is pretty light. If you have any video in your GUI for say pilot messages, break it down here. All video tasks will require scripting, but that is production work. List the general purpose, expected length, and general content like number of actors and set design, even if it ends up being blue-screened into a 3D rendered background.

Sound and Music

Overall Goals: Stress the aesthetic and technical goals for the sound and music. Describe the themes or moods you want. Name existing games or films as examples to aspire to. Issue technical edicts and editing objectives, such as sampling rates, disk space, music formats, and transition methods.

Sound FX: List all the sound FX required in the game and where they will be used. Include the intended filenames, but be sure to consult with the sound programmer and sound technician (or composer) on the file naming convention. This makes it easier for people to find the sound FX and fold them into the game.

Don’t forget about all the areas that sound FX may be used. You don’t want to overlook anything and throw off the schedule. Go through all the game elements and your art lists to see if there should be some sound associated with them. Here are some to consider:

•GUI: Button clicks, window opening, command acknowledgments

•Special Effects: Weapons fire, explosions, radar beeping

•Units/Characters: Voice recordings, radio chatter, stomping, collisions

•Game Play Elements: Pick-up jingle, alerts, ambient sounds

•Terrain (Environment): Birds, jungle sounds, crickets, creaks

•Motion: Wind, footfalls, creaking floors, wading, puddle stepping

Music: List all the music required in the game and where it will be used. Describe the mood and other subtleties. Music will often reuse the same themes and melodies. Mention where these themes

should be reused. Consult the composer on this.

•Event Jingles: Success/failure/death/victory/discovery etc.

•Shell Screen: Mood setting for title screens, credits, end game

•Level Theme: Level specific music (designers choose the theme)

•Situations: Sets the mood for situations (lurking danger, combat, discovery)

•Cinematic Soundtracks

Story (if applicable)

Write the synopsis of the story told by the game. Include the back-story and detailed character descriptions if it helps. Indicate the game text and dialogue requirements so they can be added to the schedule. Some game designs focus so much on this that they overlook everything else that should be in the spec. Telling a story is not the focus of most games. Of course, if you are doing an adventure game, it is extremely important. Expand and organize this section as is necessary to tell the story.

Level Requirements

Level Diagram: Whether this is a linear campaign, a branching mission tree, or a world-hopping free-for-all, this diagram should be the backbone upon which all the levels are built. A diagram isn’t necessary if the structure is so simple that a list would suffice. The following is an example of a typical success/fail branching mission tree. Of course this will vary greatly for each game.

The important thing is that it just presents a road map for the level designers and for the readers.

Asset Revelation Schedule: This should be a table or spreadsheet of what level the game’s assets are to be revealed to the player for the first time. There should be a row for each level and a column for each general type of asset. Assets include power-ups, weapons, enemy types, tricks, traps, objective types, challenges, buildings and all the other game play elements. The asset revelation schedule ensures that assets, the things that keep the players looking forward to the next level, are properly spaced and not over or under used.

If it’s important to the game that certain assets stop being used, then the schedule might be better drawn as a Gannt chart with lines indicating the availability of assets. This gives the level designers a guide to what assets they have to work with so they don’t ruin their level or anyone else’s.

Level Design Seeds: These are the seeds for the detailed paper designs to follow. Detailed paper designs at this point are less legitimate and unlikely to survive intact. Designs created after the designers have had time to experiment with the tools and develop the first playable level are much more likely to succeed. It’s best to just plant the seeds for each level with a description of the goals and game play and where it ties into the story (if applicable). A thumbnail sketch is optional, but very helpful if the designer already has a clear idea of what he or she wants. Be sure to list any specific requirements for the level, such as terrain, objectives, the revelation of new assets, and target difficulty level.

Common Mistakes

Here are some common mistakes to look out for:

•Insufficient details: The descriptions need to be specific enough to convey intent and function. Avoid using vague terms unless you follow up with specifics.

•Patronizing material: You wouldn’t give a chef a recipe that told him how to make a marinara sauce, so you don’t tell artists how to manage their 256 color palette or programmers how to define a particular data structure. Just list the facts important to the vision. Not only does it waste their time (and annoy them), but it wastes the writers’ time. Such details are more appropriate for the technical specification anyway, which is written by the programmers.

•Ambiguous or contradictory material: Watch for this. It clouds the vision, creates misunderstandings, and invalidates the functional specification.

•The Design Document from Hell: Nothing stupid, nothing ambiguous, nothing lacking – it just is too damn much. Try to keep a mental total of how long the design is going to take to implement when fleshing out the specification. Cut extraneous, non-essential features and save them for the sequel; or be prepared to argue the merits of keeping the features and extending the ship date.

•Getting too personal with the design: You are not your work. Your personal boundaries should not include the design. As I have stressed throughout this document, game design is a collaborative process. While you want people to take ownership and responsibility for their work, the functional specification should have joint ownership. This keeps people from feeling isolated and more a part of the process, and it makes the documents feel less like marching orders and more like a plan. The team members are also much more likely to read something that they helped put together. Criticism is then aimed at the design not the documentors who put is all together; thus making the team more comfortable and productive in offering their criticism.

•Wandering vision: This may happen as you write the functional spec. Even with a good concept document and proposal championing the vision, there’s still some room for interpretation. Creative folks have a wandering imagination and may be influenced strongly by whatever game they may be playing at the moment(source:gamasutra


上一篇:

下一篇: