Tim Huntsman关于游戏设计进程的相关解读

　　功能导向型设计文件

　　我们的功能导向型设计文件始于一个基本格式，即能够保持参与文件设计的6个人即时获得相关信息。它的设计不仅是作为团队中所有人的向导，同时也是将我们带向3款同时进行 的不同游戏的活跃文件。

　　我们将设计文件置于我们的LAN上，并且设计团队可以不断往里面添加内容或同时更新文件。版本控制也是一个简单的软件问题，任何时间都不允许超过一个人致力于一份单独的子 文件。

　　文件本身整合了一些能够有助于组织内容的功能，包括传达像引擎需要做些什么，AI的要求，游戏模式，动作要求等等内容的主要标题。在这些标题下便是一些特定的子文件能够 解释团队中的个体需要在设计中处理的功能。不管何时一旦敲定了一个新设计功能，我们便能够通过电子邮件并附加关于虚拟文件的超链接给相关团队成员。我们之所以可以这么 做是因为文件是由我们整个团队进行编写的。

　　子文件本身是以带有与目录相联系的标题数字的数字模板形式呈现出来。这让我们能在致力于不同产品的设计层面时通过功能或项目去区分文件。模板能够为每个功能推动更加 详细的设计并帮助设计师事先回答一些问题，并在项目制作时估计到更加全面的设计。

　　这一模板同样也允许我们能够设计更多游戏版本。有些设计功能已经在一系列发行时进行了分层，你将总是处于你所思考的任何功能的同一页面上。

　　关于设计文件的总体规划便是将其与基于同样模式的技术设计文件和一些像MS Project等调度软件连接在一起。这拥有额外的能够让我们引导任何对于里程碑或新设计功能预算的 影响。

　　模板：

　　大多数美术师和程序员未阅读设计文件的理由是(如果其中包含了任何使用的设计功能)，它们经常是藏在一页又一页连续的段落中。简单地说，没有人想要艰难地穿越它去获得 自己想知道的内容。基于这种形式的模板将作为较小的相关组块中可被消化的主要功能。

　　我们需要记得，这是功能导向型设计文件，这意味着它将带有一些特定的目标，并且这些目标能被分解成一些可行的位体。

　　0目录—-这需要包含你正在处理的每个主要标题。这应该包含像AI，碰撞，关卡设计，前端逻辑流程，控制输入内容等等部分。

　　1功能标题—-描述并列举讨论中的问题/功能。存在于TOC中的数字索引让你能够在项目进行时轻松找到它并对其进行分类。

　　1.1接触并“参见”信息—-简单的：关于谁设计某一功能以及它在外部所相关的其它文件的接触点。

　　1.2目标——一列相关目标，包含你在执行这一功能以及所述问题的可能解决方法的问题。

　　1.3执行——你将如何影响功能。在此你包含了可能陈列出处于讨论中并且是所有参与者都需要知道并遵循的设计功能的公式，图标或流程图。

　　1.4影响—-这些功能将如何影响现状。你不能总是对其进行预测，但在我们的情况中，我们正在对现有引擎/游戏做出改变，所以一些改变可能会影响到我们现在正在执行某些功能 的方法。对此的一个例子便是为摔跤选手设定一个新的行动，并当我们已经超载时需要一次按键按压动作去做到这点。关于这一标题的另外一种使用方法便是帮你识别你可能需要 的额外资源，并计划相关需求以确保功能相一致。

　　1.5至1.8的任务和问题：

　　设计师

　　程序员

　　美术师

　　2D

　　建模人员

　　动作

　　声音

　　对于开发团队的每一部门都需要有“任务和问题”的部分。这让设计师，美术师，程序员或声音设计师能够直接跳到与他们相关的问题中而无需再过滤所有的其它内容。这也让设 计团队能够在不能接近可以直接回答问题的人的时候询问他们所具有的问题。

　　你同样也想要某种方式去标注出因为某些原因被丢弃或隐瞒的功能。你不想身处这些功能，因为它们可能会采取某种方法回到当前设计中或出现在续集里。

　　在我们的例子中，我们正同时进行多款游戏的设计。每个标题都将进一步扩展成3个子标题，即根据不同版本和颜色进行划分，让它们更清楚地呈现于屏幕上。

　　电子邮件和超链接：

　　基于在线设计文件，我们能够在设计，改变或丢弃功能时发送电子邮件给所有相关人员。除了在电子邮件中说“这一功能已经被设计，改变或丢弃”外，我们也能够添加超链接让 对方可以直接到达他们想要阅读的页面。

　　电子邮件拥有另外一个考虑因素，即项目管理者在阅读电子邮件时将会意识到这点。这能够帮助他维持团队的整体责任感，即关于每个人的工作是什么，在时间快到时他们该如何 执行它等等。这类型结构有助于HTML类型的文件。现在我们使用了MS Frontpage设置了这种简单的在线文件。当然了，你也可以使用Dreamweaver，如果你想这么做的话。这让任何 拥有网页浏览器的人可以访问设计文件并轻松导航到自己想要的信息。更棒的是，你还可以创造《圣经》般的艺术，连通相连接的缩略图和实际照片参考，确保你的所有资源都是 可行且受保护的。

　　考虑因素

　　这个“思考”章节包含了作为设计师和产品整体愿景把控者在提升游戏质量方面应该考虑的信息。思考是游戏设计过程的一部分。你应该与参与游戏项目的人保持联系，你应该知 道项目进展，相关负责人，并要能够回答他们任何人对产品可能提出的任何问题。

　　1.提出更多问题：

　　以下部分内容也可以运用于开发过程。这是你进入Alpha阶段应该提出的问题，并且必须在你进入Beta阶段时终结的问题。(这样你才会知道自己处于哪个阶段，我一般将Alpha理 解为你所有的“主要”技术已经到位，但还没有100%可行的阶段，这也适用于音频和美工；而Beta则意味着游戏中该有的一切都已到位，只需要进行一些调整和漏洞修复即可。)

　　我们的前端/失误如何运行？

　　这里适用的是“最简化原则”。永远不要强迫玩家经过六七个画面才能接触到真正的玩法，除非游戏的确有此必要。以合乎逻辑的方式设置游戏，不要害怕给予玩家提供帮助，或 者告诉他们每个屏幕中相应按钮的功能。另管委会原则就是：如果你要求玩家为保存游戏而输入一个名称，那就要允许他们点击“返回”键来保存，而不是强迫他们用鼠标点击“ 保存”按钮，更不要说是删除一个旧的保存项目来腾出更多空间了。

　　这还要考虑到你将如何令玩家配置自己的游戏体验。

　　许多公司在前端服务这方面做得很不尽如人意。他们提供的选择很有限，导致玩家难以导航这些选项。这一点适用于大多数PC游戏公司而非主机游戏公司。主机游戏公司有自己坚 持的标准。总之要允许玩家易于调整一些你所允许调整的东西。另外我还要补充一句，开发者完全应该让玩家知道自己该摁菜单屏幕上的哪个按钮。

　　应该包含什么选项或模式？

上一页 1 2 3 4 下一页