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

阐述游戏设计文件撰写原则之技术规格书

发布时间:2012-07-02 17:46:34 Tags:,,,,

作者:Tim Ryan

技术规格书撰写原则

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

Game-Design-Document(from gamedesigndocument.org)

Game-Design-Document(from gamedesigndocument.org)

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

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

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

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

游戏机制

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

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

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

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

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

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

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

如果使用的是面向对象的编程方法,那就要提供类继承树和每个类的界面属性和功能。描述集合的使用方式。列出可能作为全程变量以增强性能的变量,例如可能在碰撞时、移动或渲染等重要游戏惯例中命被多次引用的对象变量。需要重申的是,我并非教你如何为游戏编程,只是想让你多考虑其中的普遍技术问题,尤其是与整洁性、多功能化或速度有关的数据结构优化问题。

数据流:要说明数据如何存储、加载、转换、处理、保存和修复。要为数据输入或处理工具提供参考内容,任何复杂或与用户集中型工具都要分别说明功能和技术规范。

游戏物理和统计数值:这里的内容多而繁杂(例如移动、碰撞和战斗等等),但可能也是最有趣的编写和执行内容。但它的代码可能也是编程中变动最为频繁的内容。设计师喜欢更改内容,并且通常是在游戏具有一定可玩性时才能决定采用哪个设计。因此你的执行计划应该具有模块化和灵活性。要将控制操作行为的所有元素导入可以在运行时间阅读的数据文件中,这样可以方便设计师在闲暇时间进行调整,无需介入编程调整过程。这个说明文件应该明确区分代码及其控制数据的组合性和分类。

要定义每个函数或程序,描述它的用途,确定由哪些数值来控制它的行为(如常量、变量等)及其修改方法。这包括列出所有参数的函数原型。如果使用到了函数指标和函数重载,则需详细说明要使用哪个版本的函数。例如,你可能有多个处理不同单位类型移动过程的函数——其中一个处理着陆移动方式,一个负责空中移动方式,一个负责水中移动等,可以简要描述函数运行方式。对于复杂的函数,可以使用伪代码去说明编码方式。这一点对于要经常进行数值运算的CPU密集型函数来说尤为重要。要考虑如何对其进行优化以增强运行性能。也许进行一点位移或者使用宏指令就可以提高运行速度。

人工智能(AI):这个环节通常易于延伸成主要内容,但如果根据项目进程表来安排,又总会削减其中篇幅,仅保留必要内容。这说明设计师对复杂AI的追求有增无减,但由于时间和资源有限,最后总会让AI变成模拟智能或脚本行为。设计AI方案的时候尤其要注意这个问题。尽量在无需添加大层次的情况下完成功能规范书所描述的行业和决策制定方法,以免让这一过程呈现不必要的现实主义色彩。在此要运用基本的制作法则,假如可以用更少的成本和时间完成一项工作,那就没有必要投入过多时间和资金把事情复杂化。

当然,这里也需要注意一些例外情况。有时候总有些内容需要更长的创建时间,但完成这些内容有利于节省设计师创建关卡的时间。此外,创建一些更有弹性或强大的内容,也可以为公司开发其他项目提供宝贵的现成素材,或者让项目更易处理设计变更的问题。所以在制定这种决策之前,要先跟制作人和开发主管讨论可行性。

要确保这里的内容包含功能规范书所提到的AI控制方法,例如它是由数据驱动,还是嵌入编译代码,以及它究竟是一个脚本语言还是一个固定的变量集合,抑或是这两者的合体。

AI内容还应该包括寻径、目标选择、测试和附带相应行为的事件,角色制定的其他决策,与游戏情境相关的单位/智能游戏元素以及单位统计数值。

不要在其中添加驱动AI的实际脚本或数据。因为这是制作团队的工作。只要解释清楚决策和行为起因即可。要区别说明控制行为的统计数值。

多人模式:从多人模式角度来评估执行方案,这一点也非常重要。这部分内容应该分别说明游戏机制中的所有多人模式考虑因素,以及功能规范书中所有与多人模式相关的特定需求。

在多台PC上的多人模式(不同于共享控制器或hotseat模式)有许多需要解决的独特需求。例如,要考虑游戏支持的是哪种连网方式和网络协议?它是基于客户端服务器还是对等网络?数据包大小是多少,发送频率又如何?数据包结构是什么?如何解决数据包丢失和延迟的问题?要向特定主机传送什么信息?共有多少不同信息,它们何时使用?

用户界面

外观和风格是开发过程中最常变化的设计内容。因此,针对GUI的编程很有必要保持灵活性,要将玩法用途与GUI功能相分离,这样用户交互方法的改变就不会影响到游戏的其他层面,或者产生重大的改编程序。要使用继承类创建多种GUI对象(控制方法)以保持代码界面在事件中的一致性和数值。这样就可以在无需重大改变调用函数的情况下,将滑动块变换为文本框或按钮。最好将任何GUI对象都设置为可更改状态。

为此,你的文件应该具有弹性和通用性。需要将GUI划分为屏幕、窗口和菜单分别说明,但不可以延伸至特定交互方法,只需写下不同GUI对象运行方式,使用位置即可。

可以引用之前章节所记录的游戏机制功能,但与界面有关的所有信息都要写在这部分内容中。有关图像引擎的绘图和剪辑路径的内容应该纳入美术和视频章节,但如果涉及视察窗口和HUD附件,以及玩家交互活动的信息就要引用这里的内容。

要列出所有的全程变量、常量、宏指令、函数名或界面属性,这样程序员就知道如何快速引用文件。这也可以避免重复和不一致性问题。

游戏外壳:列出所有组成游戏外观的屏幕——这包括主游戏屏幕之外的所有屏幕及窗口。它们是由功能规范书中的流程图衍生而来,但可能包括一些主设计师所疏忽的额外屏幕(例如安装或设置屏幕)。所列的每个项目都要纳入其应用的片段,并描述其用途和范围(例如是在特定关卡数据加载之前还是之后),它将访问和设置的相关数值,它将调用的函数等。

主游戏屏幕:游戏中可能会有一个或更多与核心游戏玩法有关的屏幕。虽然许多人习惯从GUI角度再到其中复杂性进行考虑,但撰写本文件时要从低级别机制着手,然后再延伸至GUI。这样即使GUI外观发生变化,也可以保持文件一致性。

美术和视频

功能规范书已经详细列出了美术和视频内容,技术规格书的作用则是解释这些美术和视频内容如何在游戏中进行存储、加载、处理和播放。其中包括动画系统(2D或3D),视频解压和串流系统。当然有些内容可以采用现成的解决方案,尤其是视频代码。但这里应该提到所有接口技术的问题。

图像引擎:无论你使用精灵、立体像素或3D多边形渲染还是两者兼用,都要在此分别进行说明。虽然只是两句话的描述,但它却可能是这份文件的重要组成部分。要描述视察窗口、剪辑、特效以及游戏机制中所描述的碰撞和移动函数的关系。

game document(from trac.wildfiregames.com)

game document(from trac.wildfiregames.com)

美工说明:要为美工指出其中的重要细节,例如解决方案、色彩深度、调色板、文件格式、压缩、配置文件定义以及美工所需要注意的任何数据。要考虑应创造哪种工具来优化美术通道,并在此指出其特定说明,或针对更复杂及用户密集型工具创建单独的说明文件。

声音及音乐

在此要描述音乐加载及播放方式。要详细说明混频、DMA、多频道、3D音效等情况。如果用到了第三方驱动器,就要描述它们的界面和用途。要确保能够解决功能规范书所提到的一切相关需求。

音频编程说明:要为音频工程师及作曲人指出重要细节,例如采样频率、多频道使用、3D音效定义、样本长度等。如果使用到MIDI,要指出其使用版本、数量、可以使用及保存的乐器类型。要注明数据路径,以及包含特定配置文件的文件需求。要考虑到创建何种工具来优化音频通道,并指出它们的规格,针对更复杂或用户密集型工具创建独立说明文件。

关卡特定码

根据功能规范书中的关卡设计基础,描述如何执行关卡特定码,以及它如何达到预期效果。同时也要描述如果出现更多需求时,其他关卡特定码如何与游戏代码对接。一般来说,你应该让关卡特定码具有通用性和灵活性,使其方便快捷地运用于其他关卡或新创意的相似需求。

普遍误区

以下是你需要警惕的一些常见错误:

*遗漏详情:不可只是列出功能而没有补充如何执行功能的所有详情。撰写这份文件的用意是让程序员事先把开发流程过滤一遍,否则他们无法正确预估执行任务所需时间。

*尽管让各个任务指定程序员完成相应文件内容是一种很有效率的方法,但这并不意味着它能给游戏项目带来最大好处,或者程序员就会在没有监督的情况下自觉完成撰写文件的任务。在这一过程中初级程序员可能需要一些指导,而在所有文件整合在一起时,所有相关程序员都应该对文件内容进行一番讨论和点评。一些公司设置了让程序员相互评论对方工作的常规代码复查制度,最好在设计阶段尽早展开这种审核工作。

纸质关卡设计原则

在使用编辑器创建关卡之前,设计师应首先制作纸质关卡设计版本。理想情况下,设计师在项目动工之前就已熟悉设计画板、关卡编辑器和游戏引擎功能。要在执行阶段就根据功能规范书中的关卡设计核心制作好纸质关卡。

这些核心是关卡或基本需求(会指明需要引进哪些新资产或者设计的限制条件)的核心理念。最好不要一次性做齐所有的纸质关卡设计,因为设计师挨个落实每个新关卡时可以学到更多。

而制作人通常都希望马车跑在马前面,所以在真正的关卡设计开始之前,要首先制作具有可玩性的原型关卡。这通常是确保工具和游戏引擎顺利运行以制作关卡的一个基础。它也可以作为编辑器和引擎可实现目标的指南,以及关卡设计愿景的缩影。

紧接着就可以开展真正的关卡设计,但即使到了这一步,说明文件在节省时间和确保产品质量方面仍会发挥重要作用。以下是关卡设计需遵从的重要步骤:

步骤1:小样和讨论

关卡设计师要设想一个符何功能规范书和内容揭露安排要求的关卡布局。然后他们就可以制作一个草图并与主设计师进行讨论。这个小样可以是画在白板上或笔记本上,它是促进讨论的视觉辅助工具。这里不需要表达整个关卡设计理念或所有关卡细节,因为这些通常是讨论过程中所涉及的内容。

sketched-level(from petermcclory.com)

sketched-level(from petermcclory.com)

制作草图和进行讨论的好处在于节省时间,无需迫使设计师事先规划好一切并将其编入文件中。高级或主设计师可以在数分钟内决定大家所提出的关卡设计是否可行,并提出富有价值的改进建议。一份内容详尽的纸质文件可能需要数天甚至一周时间才能完成。设计师的稿件是否会被退回重新修改,则要视其技能水平而定。这在项目动工初期表现尤为明显,因为此时设计师仍在揣摩主设计师想要的效果是什么,临近项目尾声时,要得到原创而富有吸引力的关卡设计就更困难了。

步骤2:详尽的纸质版本

在小样和关卡理念获得批准后,关卡设计师就可以开始制作详细的纸质关卡设计版本了。关卡布局应比草图更详细,并且要按比例绘制出来。最好使用彩色铅笔在大张方格纸中绘图,在地图中要标注对象、行为、建筑、敌人、事件、位置等信息,也可以将其列入另一份单独的索引文件中。还要列出任务特定美术或代码内容。完成这些细节可能需要花费数天甚至长达一周时间,但比起在真正的编辑器中“搜索”或“重新设计”,这种方法可以省下更多时间。

完成这一步后,主设计师、制作人和其他主要决策制定者就要对其进行一番审核。他们可能批准这一理念,也可能提出一些修改意见,或是直接否决了这个关卡设计。

另外也要让技术型人员,最好是高级程序员从编程角度审核这份书面关卡设计。这样程序员就会留意关卡设计师的理念所涉及的工具和图像引擎。他们可能向工具添加一些功能,或者对代码进行调整以让关卡设计更具可行性或更易于执行。他们也可能要求移除或修改任何可能破坏游戏或几乎不可行的关卡设计。

人们通常倾向于跳过这个步骤,直接使用编辑器制作关卡,因为创建一个关卡原型往往比制作纸质版本更快。在项目进度安排较为紧凑的时候尤其如此。但项目安排越是紧凑,就越有必要使用书面文件来规范设计工作,因为事先考虑周全有助于一次性把事情做完,减少意外情况发生次数,节省返功时间。制作纸上关卡设计版本的好处在于,它可能让设计师事先就考虑到所有事项,在落实设计之前就表达出关卡的趣味和挑战性所在。这份文件还可以确保在设计师开始工作之前,程序员、美工和音频技术人员就已掌握自己的任务安排。

步骤3:创造关卡核心

设计师需确定关卡核心游戏玩法,应该在纸上设计版本中就体现其想象的趣味性和挑战性。然后征求主设计师和制作人的反馈意见,让他们决定这个设计的好坏。最终的关卡设计可能未必有纸上设计版本那样可行,或者有预期那样好玩。但这一做法却有助于节省设计师时间,以免发生重大修改或导致整个关卡都被否决。

步骤4:补充更多细节

确定关卡核心玩法后,要确保其他内容都有助于优化和提升核心玩法。这包括确立设置、充实关卡,使游戏更富生气(例如提供更多选项、解决方案或惊喜)的所有内容。

新美术或代码资产通常看起来都不会很协调,所以要确保设计师在植入占位符前就找到所需内容。然后再更新纸上设计和任务列表。

步骤5:玩法测试

让设计师体验这些关卡,并尽量收集更多反馈。这一过程仍然离不开设计文件。要确保设计师至少要用笔记本记录下所有漏洞,反馈和任务。有时候人们很容易遗漏一些问题,所以最好是将其归档到含关卡特定问题和反馈内容的数据库中。

文件阶段和开发安排

以下是关于项目进度安排中的典型阶段列表,在每个阶段(或称标志性事件)都有一个评审过程。因为只有当文件大部分内容都完成才能制定项目开发安排,所以要确保重新撰写文件或创建大家都认同的说明书这一过程不会影响到项目开发时间。为了赶时间发售游戏而匆匆编撰设计文件,并草率投入制作是造成项目失败的一大原因。并且这并不能为你节省什么时间,事实上它只会浪费大家的精力,并且造成更重大的项目延期。

概念阶段:

*文件:游戏理念

*文件:游戏提案

设计阶段:

*文件:功能规范书

*文件:技术规格书

*文件:工具说明文件(视情况而定)

制作阶段(游戏邦注:有时也称执行阶段):

*制作安排

*技术和美术样本

*首个可玩关卡

*文件:纸上关卡设计(不一定是可交付成果)

*Alpha

测试阶段(QA):

*Beta——发布首个潜在码

*Gold Master——发布代码

我们还可以列出更多阶段,因为发行商有必要掌握一些决定和确保项目执行顺利进行的途径。有时候它们会针对特定美术、代码和设计制定每月固定标志性事件。这里所列举的只是一些最为常见并且更有影响力的情况。

应对变化

看到一个项目依从这些原则而顺利运转应该是一件美妙之事,但有时由于灵感或市场趋势的变化也会让项目愿景转向。人们习惯使用“即时设计”模式以应对新变化,并且不影响项目安排。有时候这种情况确实难以避免,但这种模式也存在弊端。在这种情况下,唯一可用的方法就是固守这些原则及其程序。如果在合同上提到这一点那就更好了。不要在未更新有关文件的情况下调整项目内容。要知道功能规范书中的一个变化,可能就会导致技术规格书中的有关内容失效,并影响后续的项目安排。主设计师在签收并交付功能规范书时必须清楚哪些人可能提出修改要求。如果他们确实需要进行一些更改,那就可以通过更新文件和重新制定项目安排而减少其影响。只要想想卡在项目开发过程中,或被迫延迟任务的痛苦,就足以成为促使你事先考虑周全,制作好这些文件的动力了。希望本系列文件对你的项目开发过程有所帮助。

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

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

by Tim Ryan

Guidelines for the Technical Specification

While the functional specification explains what is going into the product, the technical specification explains how. The technical specification (or tech spec) is a working blueprint for the game.

It turns conjecture into reality by forcing the programmers to think through how the game will be implemented, by reducing implementation/integration headaches, and by delineating the program areas and tasks for the schedule.

Many companies will skip this step, as it is time consuming and seemingly benefits only the programmers. However, time spent working on a tech spec is less than the time lost from pitfalls that come with not writing one. The primary author is the lead programmer or technical director, though it is often more timely and useful if the programmers responsible for implementing the various program areas be responsible for documenting them. In its compiled form, it should present a plan that any programmer can understand and work from.

The target audience is the lead programmer on the project and the technical director of the company. Therefore it will generally be written from the system perspective as opposed to the user perspective. It will be boring and Greek to the producer and any other non-technical readers. By asking for one, the producer is just making sure the technical staff thinks everything through, even if he or she doesn’t understand it. To the lead programmer, it’s a way of organizing his or her thoughts and creating an accurate picture of the work involved. The process of writing it will flag any of the uncertainties on the programming side and any of the holes, ambiguities or absurdities in the functional spec.

Many good technical specifications vary from the form described here. This form mirrors the functional specification to ensure that all areas of the functional specification are covered. Sometimes it’s easier for a team writing this spec to organize it differently, if only because they are splitting the work differently or because of the organization of the underlying system. If they do, I’d recommend going through every line of the functional specification and do a correlation with a highlighter to make sure nothing has been overlooked. An overlooked detail can lead to undesirable results in the product, project and team dynamic.

These guidelines will not tell you how to implement your game. It’s assumed that you are a technically competent, experienced game programmer. An inexperienced or untrained game programmer should not attempt this task. These guidelines are the result of what I’ve come to expect in a good technical specification, though I certainly couldn’t tell you how to program your game. These guidelines force you to define the most common elements one finds in all games. Some may not be applicable, but each should be considered carefully. It may spark a question you haven’t asked yourself yet; which is sort of the whole point of writing this spec.

Game Mechanics

This is certainly the bulk of the document. Right away you’ll see that any attempt to match up specific subsections with the game mechanics section of the functional spec is totally ludicrous. The perspective must be from the system out as opposed to the designers’ or users’ perspective. This starts with the hardware platform and the operating system, the use of externally provided code objects (DLLs, EXEs, drivers), and the delineation of internally generated code objects (if any). Then it breaks down the specific mechanics of game code stemming from the control loop.

Platform and OS: Indicate the hardware platform and the operating system and the versions supported. For PC/Mac games, mention the minimum system requirements and the target machine. If distributed on something other than a CD like a cartridge, indicate the target ROM.

External Code: Describe the source and purpose of all the code used but not developed by the project team. This includes OS code and preprocessing tools of the various game platforms, drivers and code libraries like DirectX, any acquired 3D API, or any other off-the-shelf solution.

Code Objects: Break down the purpose and scope of the various code objects coded, compiled and built into the EXE. If any out-of-process or in-process code libraries (DLLs) are used, break them down as well, but be sure to explain the use of object instancing and their persistence (like Direct Draw objects).

Control Loop: Every game has one. Be specific about how control is transferred from the start-up code to the shell and down into the main game code. Spell out the names of the functions in the core loop and what they will do, like the collision, movement and rendering routines. Explain the use of multi-threading, drivers, DLLs and memory management. Of course further details on the likes of multi-threading and memory management will be covered in the areas that they will be used most, like the rendering or sprite engine, sound code and AI.

This subsection summarizes the system and underlying framework that supports the core game play and game flow described in the functional specification.

Game Object Data: Read carefully over the functional spec at all the character/unit descriptions and game play elements. Then list and formulate all the data structures and their identifiers that are required to support the described attributes, functions and behaviors. To a certain extent, these will not be complete until the game physics and statistics and AI subsections are completely thought through and documented. Add statistics for user interface or any other area of the game that have unit or game play object specific data (i.e. icons, HUD displays, animation or special effect references, etc.).

If using object oriented programming methods, show the class inheritance tree and each class’ interface properties and functions. Describe the use of collections. Identify any variables that could possibly be made into global variables to increase performance, such as any objects variables that may be referenced multiple times during critical game routines such as collision, movement or rendering. Again, I’m not telling you how to program your game. I’m just trying to get you thinking about common technical issues, specifically in regard to optimizing data structures for neatness, versatility or speed.

Data Flow: Explain how data is stored, loaded, transferred, processed, saved and restored. While references should be made to data entry or processing tools, separate functional and technical specifications should be made for any complex or user intensive tools.

Game Physics and Statistics: This is the nitty gritty – movement, collision, combat – and probably the most fun to document and implement. However, it can also be the code that gets altered more than any other part of the program. Designers like to change things. It’s often only after they can play it for a while before they can really decide what is right. For this reason, you should plan to implement things as modular and flexible as possible. Put all the factors that control behavior into data files read at run-time, so the designers can change and balance things at their leisure without involving coding changes and new builds. The specification should clearly identify the modularity and divisions between code and the data that controls it.

Define each function or procedure. Describe its purpose. Define what statistics control its behavior (constants, variables etc.) and how they can be modified. Include the function prototype listing all the parameters. If using function pointers and function overloading, specify where the different versions of the function will be used. For example, you may have multiple functions that handle movement for the various unit types – one for land movement, one for air, one for water, etc. Briefly describe how the function will work. For complex functions, use pseudo code to specify exactly how you will code it. This is especially important for CPU intensive functions that do a lot of number crunching or are just called very often. Think about how they can be optimized to increase performance. Perhaps bit-shifting or macros could speed things up.

Artificial Intelligence: This often grows to a major section unto itself and is then scaled back when the schedule dictates the necessity to keep it simple. This shows a growing enthusiasm for complex AI, but a lack of time and resources to make AI anything more than simulated intelligence or scripted behaviors. Be mindful of this when you design the AI scheme. Try to accomplish the behaviors and decision making described in the functional specification without adding a huge layer of unnoticed and therefore unappreciated realism to the process. The basic rule of production applies here. If something that costs less and takes less time to build does the job, then don’t spend more time and money creating something else.

Of course, there are exceptions that should be mentioned. Sometimes something might take longer to build, but it saves the designers a lot of time working on their levels. Also, creating something more flexible or powerful may make it a valuable asset to the company for other projects or just make it more capable of handling design changes should they occur. Discuss these with your producer and director of development before making a decision.

Be sure to include the methods of manipulating the AI as dictated by the functional spec, i.e. whether it’s data driven or embedded into compiled code, and whether it’s a scripted language or a fixed set of variables or a combination of both.

AI should include path finding, target selection, tests and events to attach reactionary behaviors to, and other decisions made by characters, units or intelligent game elements involving game situations and unit statistics.

DO NOT include the actual scripts or data driving the AI. That’s production work. Merely be specific enough to explain how the decisions and behaviors will be derived. Break down the statistics used to control the behavior.

Multiplayer: It’s extremely important that the implementation plan is reviewed from a multiplayer perspective. This subsection should break down all the multiplayer considerations in game mechanics and all the multiplayer specific requirements specified in the functional spec.

Multiplayer over multiple PCs (as opposed to console sharing or hotseat) has a lot of unique requirements that should be addressed. What connection methods and protocols are supported? Is it client-server or peer-to-peer? What are the packet sizes and how often are they sent? What is the structure of the packet? How are missed packets and latency issues handled? What messages are broadcast and what are sent to specific hosts? How many different messages are there and when are they used?

User Interface

Look and feel is one area of the design that undergoes the most changes during development. Therefore, its necessary that the programming for the GUI be as flexible as possible, separating game purpose from GUI function, so that changes that occur to the user interaction methods will not affect other areas of the game or require significant reprogramming. Create a variety of GUI objects (controls) using inheritance to maintain a consistent code interface to the events and the values. This way a slider bar can be exchanged with a text box or radial buttons with little or no changes to the calling functions. Assume that any of the GUI objects can be exchanged at any point in the project.

To this end, your documentation should be flexible and generic. While it should break down the GUI into the screens, windows and menus, it should not go any further into the specific interaction.

Instead, document how the various GUI objects will work, wherever they are used.

Make references to functions in the game mechanics documented in the previous section, but anything that’s interface related should go here. Explanation of the drawing and clipping routines of the graphics engine should be left for the Art and Video section, but certainly they should be referenced here in terms of view ports and HUD attachments and anything the player can interact with.

Document the names for any of the global variables, constants, macros, function names or interface properties, so that other programmers can refer to the documentation without having to dig through code. This also avoids replication and inconsistency and increases clarity.

Game Shell: List all the screens that make up the game shell – all the screens and windows other than the main play screens. These are derived from the flowchart in the functional specification, but may include some additional screens that the lead designer may have overlooked or brushed over (like installation or setup screens). Each item listed should be its own subsection with a description of its purpose, its scope (i.e. before or after level specific data is loaded), the pertinent values it will be accessing and setting, and what functions it will call.

Main Play Screen(s): These are the one or more screens in which the core of the game is played. Though many people think from the GUI perspective down to the complexities of what’s under the hood, this should be written from the low-level mechanics perspective (the engine and rotors) out to the GUI (the hood and the dash). This keeps it consistent even if the outward appearance of the GUI should change.

Art and Video

While this section in the functional spec pretty much just listed the art and video, the technical spec has to explain how the art and video will be stored, loaded, processed and displayed in the game. This includes the animation system, whether it’s 2D or 3D, and the video decompression and streaming system. Of course some of these might be off the shelf solutions, especially the video code. But all the interfacing should be mentioned here.

Graphics Engine: Whether you are using sprites, voxels or 3D-polygon rendering or a combination, break down their functions in very specific detail. While it’s only 2 sentences of description here, it will likely prove to be a very meaty piece of the spec. Describe areas like view ports, clipping, special effects, and the connection to the collision and movement functions described in the game mechanics.

Artist Instructions: Break out the details important to the artists, like resolutions, bit depth, palettes, file formats, compression, configuration file definitions and any other data the artists need to define to fold in the art. Consider what tools can be created to streamline the art pipeline, and indicate their specifications here or create separate specifications for the more complex or user intensive tools.

Sound and Music

Describe how sound will be loaded and played. Be specific about the use of mixing, DMA, multiple channels, 3D sound, and methods of determining priority. If using third party drivers, describe their interface and purpose. Be sure to address all of the requirements specified in the functional spec.

Sound Engineering Instructions: Break out the details important to the sound engineers and composers, like sample rates, the use of multiple channels, 3D sound definitions, sample length etc. If using MIDI, indicate the version to use and the number and type of instruments that can be used and possibly stored. Indicate the data path and file requirements including any specific configuration files that need to be created. Consider what tools can be created to streamline the sound pipeline, and indicate their specifications here or create separate specifications for the more complex or user intensive tools.

Level Specific Code

Based on the level design seeds in the functional specification, describe how code specific to those levels will be implemented and how it will accomplish the desired effect. Also describe how any other level specific code can be interfaced to the game code should the need arise to add more. In general, you should try to make any of the level specific code as generic and as flexible as possible so that it may be freely used to accommodate similar needs for other levels or new ideas.

Common Mistakes

Here are some common mistakes to look out for:

•Hand waving: It’s very tempting to just list the functions and not fill in all the details that force you to really plan how you are going to implement them. Sometimes they are just glossed over, but really the hand waving should end with the functional spec. This spec is supposed to force the programmers to really think everything through ahead of time. How else are they going to estimate the task time correctly?

•While it can be very effective to assign portions of the technical spec to the individual programmers responsible for implementing it, it’s not always in the best interest of the game or indeed the programmer to do so without some supervision. An entry-level programmer should get some guidance, and all the programmers should discuss and critique their documentation before it gets all folded together. Some companies have regular code reviews where programmers critique each other’s work. That should start even sooner during the design phase.

Guidelines for Paper Level Designs

The designers should do paper versions of level designs before they begin creating the levels in the editor. Ideally, the designers will be familiar with the design palette, the level editor and game engine capabilities before they get started. Paper level designs are creating during the implementation phase, though they are based off of level design seeds expressed in the functional specification. These seeds are the core idea for the level and/or the basic requirements that may indicate what new assets are being introduced or what to limit the design to. It’s best not to do all of the paper designs at once, either, as the designers usually learn a lot while implementing each new level.

For some reason, producers often expect the cart to come before the horse, so before serious level design begins, push for a playable, prototype level to be created first. It’s often a milestone unto itself that ensures that the tools and game mechanics are working well enough to develop levels. It should also serve as a guide to what can be accomplished with the editor and engine and epitomize the vision for level design.

Following the first playable mission, level design can start in earnest. Yet even here, documentation plays an important role in saving time and ensuring quality through meticulous planning and the critical process. The process of level design that works:

Step 1: Thumbnail & Discussion

The level designer conceives of a level layout that meets the requirements laid out in the functional specification and asset revelation schedule. He or she then produces a thumbnail sketch and discusses the concept with the lead designer. The thumbnail could be on a white board or a note pad. It is a visual aid in the discussion. It does not need to convey the entire idea or all the details for the level, as these often evolve during the discussion or get tossed out altogether.

The benefit of doing a thumbnail sketch and discussion rather than forcing a designer to first think everything through and document it is that it saves time. A senior or lead designer can in a matter of minutes determine whether a proposed level design has merit and give valuable advice that can drastically alter the design. A fully detailed and documented paper version can take days or even a week to put together. Depending on the skill of the designer, a designer might get sent back to the drawing board many times. This is especially true near the beginning of the project, when the designer is still learning what the lead designer wants, and near the end of the project, when original, compelling level concepts are harder to come by.

Step 2: Detailed Paper Version

With an approved thumbnail and level concept, the level designer can work on a detailed paper version of the level design. The layout (or map) of the level should be much more detailed than the sketch and should be drawn to scale. This is best done on a large sheet of graph paper using colored pencils. Information about objectives, behaviors, buildings, enemies, events, locations etc. should either appear on the map or on a separate document with reference points on the map. Any mission specific art or code should also be listed. This amount of detail can take a few days or as long as a week to draw and document, but it saves a lot of time that would otherwise be spent “searching” or “redesigning” in the actual editor.

When completed, the lead designer, producer and any other principal decision-makers should subject the paper design to an approval process. They may approve it, throw in some changes, or kill the level right then and there.

It’s also important that someone technical, preferably a senior programmer, review the paper design from a technical standpoint. This gives the programmers a heads up on what the level designers are going to attempt to do with the tools and graphics engine. They might add some features to the tools or make some code adjustments to make the level possible or just easier to implement. They may also vote to eliminate or alter any level designs that may break the game or are similarly unfeasible.

It’s often very tempting to skip this step and jump right into the editor as it’s often faster to just build a prototype of the level than to write up the paper version. This is especially tempting in tight schedule situations. Yet, it’s these tight schedules that make documentation that much more important, because it means there’s even more reason to get it right the first time and reduce the number of surprises and time to redo the work. The benefit of a detailed paper version is that it forces a designer to think everything through and express the fun and challenges before he or she implements it. It also ensures that the details that may involve more tasks for programmers, artists and sound technicians get documented and scheduled for completion before the designer begins working on the level.

This article is focused on documentation, but for completeness to this section and to this process, here are the remaining steps to level design as I see them:

Step 3: Creating the Core of the Level

The designers should establish the core game play of the level using broad strokes. They should get it to the point that it gives them the fun and challenge they envisioned in the paper design. The designer should then get feedback from the lead designer and producer, who will determine whether the level has merit or not. It may indeed prove impossible to accomplish what the paper design suggested, or it may prove to not be as fun as was expected. This is simply a review point in the level design that saves the designer time should drastic changes need to be made or the level dropped entirely.

Step 4: Filling in the Finer Details

Once the core game play of the level is established, everything else should just make it better. These are all the things that establish the setting, flesh out the level, and liven up the fun by providing more options, solutions, or surprises.

Often new art or code assets may seem appropriate, so be sure the designers find out they can get them before putting placeholders in. Then update the paper design and task lists.

Step 5: Play Test

Have the designers play their levels and get as much feedback as possible. Again, documentation plays a role here. Be sure they keep track of all their bugs, feedback and tasks with at least a notebook and pencil. It’s very easy to lose track of issues at times (not to mention sheets of paper), so a centralized database with level specific issues and feedback is ideal.

For further guidelines for level design, I encourage you to read my articles on level design that present a background to level design and some rules to design by. The first part “Level Design Theory” can be found here. The second part “Rules to Design By and Parting Advice” is available here.

Documentation Milestones and the Development Schedule

Below is a list of the typical milestones in a schedule and where the documents described in this series serve as deliverable items. Following each milestone would be a review of that milestone, which would require approval to go on to the next. As the production schedule isn’t due until after the bulk of the documentation, then there shouldn’t be an impact on the schedule if time needs to be spent going back to the drawing board and creating specifications that everyone can agree with. It’s a recipe for disaster to race into production with iffy design documents just because of the urgency to meet an arbitrary ship date. In the end, it usually doesn’t save you any time, and in fact often leads to wasted efforts and significant delays.

Conceptual Phase

•Document: Game Concept

•Document: Game Proposal

Design Phase

•Document: Functional Specification

•Document: Technical Specification

•Documents: Tool Specifications (if applicable)

Production Phase (sometimes called Implementation Phase)

•Production Schedule

•Technology and Art Demo

•First Playable Level

•Documents: Paper Level Designs (not always a deliverable)

•Alpha – Functionally Complete

Testing Phase (Quality Assurance)

•Beta – First Potential Code Release

•Gold Master – Code Release

There could be more milestones, as it’s often necessary for publishers to have some means of determining and ensuring that progress is being made. Sometimes there are arbitrary monthly milestones for particular art, code, and design. The ones suggested here are the most common and have the greatest significance.

Dealing with Change

It can be a beautiful thing to witness a project run smoothly following these guidelines, but what typically happens is some change to the vision due to inspiration or market trends. It’s very easy to slip into design-on-the-fly mode to try to adapt to the new vision without impacting the schedule. Of course it inevitably does anyway, because design-on-the-fly has its dangers. In these cases, the only way to make sure this doesn’t happen is to be adamant about the guidelines and the procedures they promote. This is easier if it’s spelled out in the contract. Don’t make any changes to the game without it going through the documentation. A change to the functional specification potentially invalidates the technical specification and subsequent schedule. It’s certainly grounds for reassessing the schedule. It should be very clear to the principle designers who may want these changes that when they sign-off on the functional specification and deliver it, they do so with no expectations on being able to make changes. Then, if they really want the change, the impact can be lessened with a period of updating the documentation and a reassessment of the schedule. The threat of being stuck with what you got or being late is certainly compunction enough to put as much forethought as possible into the design and produce the best possible documentation. The guidelines presented in this series of articles should help you do just that.

For more details on how to deal with change, I encourage you to read my article “Controlling Chaos in the Development Process” published here.

This concludes part 2 of a 2 part series of articles on the anatomy of a design document. (source:gamasutra)


上一篇:

下一篇: