作者：Tim Huntsman

对于每一款设定了较高的设计或游戏玩法标准的游戏来说，有许多游戏并未达到这样的标准。为什么会这样？我发现许多可能的原因。许多游戏是由那些信口开河而 非真正将成功 作为一大目标的人所创造的，许多设计师还是新手，并不清楚别人对他们的期待，并且只有少数开发公司为创造和执行游戏创造了正式的设计过程。

如今的书籍和杂志只关注与游戏设计的技巧。因为这是一项具有创造性的任务，每个人都认为自己能够做到这点。如果这是事实，那便会出现更多带有更棒的控制，更棒的AI，更 多用户友好型前端，即使是12岁少年也能够快速掌握的游戏机制，以及在软件中拥有较少的游戏阻塞物等情况。但是我的一个朋友却跟我讲述了一个严酷的事实，即一家大型开发 商/发行商的开发VP问他，为何自己要投资140万美元于他的项目中而不只是将钱投资于股票市场中。答案是什么。如果游戏拥有有效，即时的设计并且非常有趣，那么他的投资便 有可能得到巨大的回报。

这一关于设计过程的引用可以分解为三大部分：执行，思考和需要。第一篇文章将解释你在准备创造一款游戏时需要做什么。第二篇则是着眼于你在制作一款游戏时需要思考什么 ，最后一篇文章将明确你在执行这项任务时需要什么。

做什么：

设计师的主要任务便是设计游戏。这听起来很简单；但却是必须做好的事。比起编写一些关于你所想出的理念有多酷的段落，写下无数没人愿意看而只有作者会逼迫自己看的细节 内容，设计一款游戏需要做的更多。

优秀的设计是关于执行理念和细节。为了明确你的游戏需要什么，你需要清楚你身边有什么。你需要知道市场可能会支持什么，市场所厌倦的是什么。你需要了解你的公司可能或 不想要看到什么。总之，你需要在开始前先问自己一些问题。

1.提问题

这与听起来一样简单，你需要在开始写下设计文件前问一些问题。在你炮制你的下一款畅销游戏前你需要考虑许多事。不管怎样这一列表还是很详尽的。有些问题可能与你们各自 的情况相关——并不是所有的游戏都需要考虑同样的情况，同时有些项目可能需要额外的问题。决定要问怎样的问题是你的工作最重要的一部分。

现在的趋势是什么？

当前的设计趋势是什么？浏览贸易地图并明确什么或谁创造了巨大的反响。技术提供给我们能力去拓展更多领域，创建并审视更大的世界，实时照亮它们，维持一种可被接受的帧 率，我们发现玩家对于娱乐拥有更多的期待。维持玩家兴趣的创造性公司所采取的一种方法便是模糊已确定的类型之间的界限。这能帮助我们挑战那些“已被接受”的内容并揭去 创造性设计的面纱。

趋势同样也存在于像旋转和实用性中—-竞争如何通过提高给玩家对于游戏环境的更多控制权而赋予他们能力。现在摔跤游戏的一大标准便是需要从从头开始创造定制的摔跤手。这 成为《WWF Warzone》在美国最受关注的功能，现在THQ和艺电也整合了更多“赋予玩家能力”的理念到游戏中。

市场营销的寻求是什么？

这可以被重申为“游戏玩家的寻求是什么？”着眼于市场营销专家，他们应该拥有关于人们想要什么的理念。他们会进行焦点小组测试，他们应该通过反馈去编制数据。同样地， 他们还会考虑市场能够忍受什么。“仿照“产品的销量总是不及它们所仿照的对象。

现在我们可以使用怎样的工具？

例如，着眼于动画需要怎样的动作捕捉。不要误会，我并不是在提倡一个“无时无刻捕捉所有动作”的游戏世界，但这样的数据也是创建待遇优厚和备受尊重的动作编辑器的基础 的一种有效方式，能够调整动作去匹配设计。

3D程序编写和世界建造工具仍然是帮助或隐藏设计过程的最受欢迎的例子。如果你需要匆忙创建一个概念原型或者如果你需要在失去游戏授权前赶上圣诞购买季前完成创造，那么 现有的工具便能够帮助你做到这点。

工具将帮助你创建一个设计原型而了解某个理念。它们同样也会帮助你更轻松地完成工作。循环技术并不是一个糟糕的理念，除非你的公司唯一能够宣传的技术与游戏玩法无关。

有些类型适合某种特定的音乐，通常是一些专业且有名的乐队或个体。听听什么是好的，会发生什么，然后整合其风格到你的游戏中。有些市场营销人士将支付你的大笔开发预算 与一些乐队或个人签约让他们为你的游戏制作音乐，但据我了解，人们很少会愿意购买一款拥有自己曾经在广播中听到的音乐的游戏。在特定情况下让较有名的人制作音乐将能够 让游戏变得更酷并在网上或杂志中创造一些噱头，但这却不能从根本上动摇消费者，这也不能保证游戏的宣传能够即时且有效地呈现出来。如果存在任何问题，一种可靠的解决方 法便是尝试着获得你想在自己的游戏中使用的某首歌曲的同步授权（你将获得使用某首歌的权利，但却不能使用最初创造者所创造的音源）。

有些公司已经浪费了许多钱去尝试获得一些音乐人才在自己的游戏中做出贡献，并将其当成是游戏的主要市场营销元素。Rob Schnider作为《A Fork in the Tail》的主唱或 Christopher Lloyd作为《Toon Struck》的主唱是否重要？如上，通常情况下大多数玩家不会因为一些名人声音的出现而去购买游戏。

获得一些能够匹配游戏态度的内容（或人），这将能够提高玩家的游戏体验。这也才是你们真正需要担心的事。

完成了什么以及是如何完成的？

我会在之后关于临界评定的“思考”部分谈论到这点，但当你最初开始进行设计时，这真的是一个非常重要的问题。我们并不需要你谈论一个众所周知的故事，或者创造一款已经 存在的游戏，再或者重新演绎已经上道的类型。你应该进行研究并通过研究获得学习。你应该玩游戏。你需要知道存在什么，那些内容已经有人做了，并且现在的标准有多高，如 此你才能够更好地明确自己该怎么做。

与其它娱乐业务一样，这里也存在一些如何呈现理念的基本规则和格式，以及一些人们不愿再看到的内容。自Smith/Corona（游戏邦注：40年代的美国打字机）时代以来，电影和 电视关于电视或银幕都有了标准的脚本格式。这些格式不只是人们所期待的，同时也是人们所需求的。

而我们的业务有点不同。它的“年龄”还不足以拥有标准和指南，但我们正在朝着产业标准和实践的“广谱规范化”前进。简单地来说，传统拥有繁殖的期待。我们需要在制作某 些内容前回答一些特定的问题。这是你的工作。你需要回答这些问题，如此项目中的所有人将为了获得信息并清楚需要做些什么以及该如何做等问题前来咨询你或你的搭档。

设计文件倾向于分为两种格式：它们可能会简单地描述一个游戏理念从而让上层管理者能够赞同该理念，然后将其丢进某人的文件柜并永远被忽视，或者它们如你们当地黄页般大 小，拥有只有编写之人在乎或愿意去阅读的任何可想而知的细节内容。

在尝试着维持设计员工与制作团队间的工作交流时，我想出了一个关于“功能导向型”文件理念，即能够确保团队中的所有人都即时获得相关信息，不管是设计发生改变或重新进 行设计。

如果你着眼于一份制作电影脚本，你将会在整个脚本的任何特定点上看到不同颜色的页面。这些页面代表的是从电影开始后脚本所做出的改变。这些颜色让演员和工作人员能够遵 循改变，从而保持连续性，并确保在做出更新时所有人都能处于同一页面。

与脚本一样，设计文件中的内容也会因为环境，人才或基于管理某些部分的创造性问题的解决或制作团队而发生改变。这些改变不仅需要标注出来，同时也应该发送给那些可能受 到影响的人手中。

功能导向型设计文件

我们的功能导向型设计文件始于一个基本格式，即能够保持参与文件设计的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游戏公司而非主机游戏公司。主机游戏公司有自己坚 持的标准。总之要允许玩家易于调整一些你所允许调整的东西。另外我还要补充一句，开发者完全应该让玩家知道自己该摁菜单屏幕上的哪个按钮。

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

这个特殊问题可以是“我们该如何向玩家授权？”越来越多玩家希望能够“组建”自己的游戏。在《雷神之锤》的玩家特制关卡、皮肤以及音效中可以看出这一点，我所参与开发 的《WWWF Warzone》和《WWF Attitude》也可以看到这种现象。给予玩家一些对环境的控制权可以增加你作品的重玩价值。Konami的《International Superstar Soccer ’98》就 采用了相同的理念，允许玩家创造真正或幻想的团队，并将其用于长期的竞赛中。赋予玩家很酷的功能、选项和游戏模式还可以让你创造一个忠实的粉丝基础，他们有可能源源不 断地购买你的游戏续作。

向你的作品添加选项和模式的简单方法就是询问你的测试部门（或者发行商），或者找一些焦点小组来进行测试。人人都有自己的看法，你最好听听大家的意见。

游戏节奏如何？

很简单的问题。整个游戏是否过于冗长？通常情况下，你会发现游戏太短。玩家掏出20至70美元不等的钞票来购买一款游戏，就是希望得到物有所值的回报。关于整个游戏体验究 竟应该有多长并没有明确的规定（街机游戏除外），但玩家自己会感觉到花出去的钱是否值当。

第二个考虑就是，以你评价一本书或一部电影的方式来考虑游戏节奏设置。你的产品是否过于拖拉，让玩家不耐烦？它是否会因为速度太快而崩溃，从来不给予玩家喘气或者思考 自己该怎么做的时间？节奏有变化是好事，但要记住如何管理这些变化。

究竟多困难才算困难？

考虑难度的时候要倾听QA的反馈。玩家能够以数分钟，数小时还是数天时间完成游戏？要记住那些购买游戏的玩家需求，而不是一味地迎合那些已经有6到9个月时间一直在玩这款 游戏的QA测试者。无论如何都要考虑到，你的测试者所能接受的难度也许会令那些可能购买游戏的用户退却，导致他们因为无关闯过第一关而拒绝游戏。不幸的是，调整关卡难度 （游戏邦注：如调整AI以及平衡游戏玩法）是一项艰难而耗时的任务，它需要所有参与项目的人共同解决。

我们该如何整合过场动画，FMV？

第一个问题很简单：你是否真的需要这种东西，或者说你的游戏没有它是否也能存活下来？如果真的有必要，可以试试“游戏内置”影片而不是预渲染的电影式恶作剧。这不但有 助于保持玩家渲染感，也可以让你的转场对玩家来说更为流畅。《合金装备》、《半条命》以及《Soul Reaver》就是游戏内置影片的杰出典型。

我们该如何从中获得重玩价值？

有些游戏结束就是结束了。游戏中的一切惊喜也戛然而止。而有些游戏却可以让人反复体验，要不就是因为其中还有更多可探索的内容，要不就是因为它可以让玩家做一些个性化 行为（如打败一个高分）。

我们的载入/保存时间如何？

没有人会想长久地坐等游戏完成载入。索尼在游戏加载方面有自己的标准，对于N64平台来说这并不是个问题。而PC游戏开发者就必须要求程序员优化这一点，因为这也是整个游戏 体验的一部分。

顺便提醒一句，要允许玩家在自己所需的地方进行保存，除非游戏真的有必要阻止他们保存。PC平台的《Reflection’s Driver》就是一个强迫玩家先通过三四个场景才能保存游 戏的例子。你应该知道这种做法有多令人讨厌，千万不可对玩家做这种事，除非只有这样做才能维持你游戏的基本设计功能。

2.良好的习惯，敏锐的观察力，以及趣味因素

合并设计文档，日程安排和预算。

在预制作设计阶段之中，或者之后必须马上安排项目的真正相关数据，时间和日期。上述词语的通常问题在于，对于每个概念，你必须有不同的人来处理相关数据。他们彼此之间 可能联系并不紧密。许多公司喜欢说，“我们必须填补这里的空白！你们要在8个月内做完这款游戏！”你的回答就是，“别做梦了，如果真是这样，那我们就需要更多资金和资源 ！”当然，他们并不想给你更多资金和资源来执行计划。这正是将所有相关团体引进开发过程的好处所在，让大家齐聚一堂来处理相关数据。这也正是它有助于将你的设计分解成 需求、任务和功能的原因。

在你提炼设计细节的时候，正是检查资源和预算考虑因素的最佳时机，当然除非你此时根本无需考虑日程安排或预算安排。但如果你是负责引导产品设计方向的人，你就很应该处 理好里程安排和预算考虑因素。一次性将所有相关人员召集到一起并列出具体数据。这个过程很痛苦，但从长期来看完成是值得的。记住，当设计文档变化，或者功能重新回炉时 ，你就要观察一下其中的影响并想想这是否会拖延你的开发进程。

更新设计文档

这听起来很简单，但在漫长的开发时间和压力之下，这可能会让大家忽略一些细节。你可能会在一个深夜的临时会议中提到一个功能，并打算在明天早上执行这个调整。你就应该 将这个调整记录在档，尤其是在你打算一年制作一个续集的时候，这样你就会记得自己最初做的事情了。

当团队中的任何人决定完成一个功能，调整一个功能，或者添加一个功能时，就必须注明这种变化，将其记录在案，并且告知所有人。如果你已经创造了一个在线风格的设计文档 ，你最好让团队获知其运行机制和相关职责。

记录设计日志

这听起来很直观，即坚持记录项目开发过程中的正确经验和失败教训。你可以保持每周记录一次的习惯，除非你正处于赶工时期。这样做有诸多好处。首先，它可以让你在数月后 想起你在项目早期所学到或没有掌握的情况，以免你在超时工作的压力下淡忘了经验教训。其次，它可以让你在事后分析项目开发过程中人们所遇到的关键问题。最后，它有助于 你在相关媒体上发表一篇事后分析文章，这样就可以让同行设计师学习你的经验，何乐而不为呢？

批判性地评估

当你查看执行功能时，你所能做的最好的事情之一就是严肃评估竞争对手的情况。不要吤因为它们先于你的作品面市而抨击竞争对手，而要对其进行评估。每款游戏，无论它有多 可恶，都有一些值得别人学的经验。这里的主要教训就在于避免犯下会扼杀一款竞争产品的相同错误。

要全面地查看一款游戏，看看它们的前端是否容易理解，检查其控制器设置，查看屏幕的实际使用率，并测试游戏内的计时问题和控制器取样。这样可以让你的开发工作更加省时 省力。如果其他游戏在某些方面表现良好，可以借鉴该理念或想法。你只需确保自己并没有照搬照抄该理念。记住：优秀的设计并不仅仅表现在理念上，它还涉及到这些理念的执 行。

当然，在某些时候你也得用这些批判性的目光来看待自己的作品。测试反馈可以派上一些用场，在看待你自己的产品时，一定要把那点可怜的自尊心收起来。有些作品之所以失败 就是因为开发者个人自尊与大众意见相抗，采用了扼杀了玩法的功能。

趣味因素

有些公司想让你制作出“趣味因素”。休闲玩家和一般用户都无法明确什么是真正的趣味。他们会告诉你某些东西很有趣，但他们无法告诉你游戏发生了什么情况，以及他们做出 了什么回应。趣味一般是与特定游戏的节奏、时机和兴奋感等概念有关。这些是你可以理念论的内容，告诉人们“打这个人很好玩！”但除非你自己花时间去玩游戏去实践这一操 作，否则就永远无法知道究竟有多好玩。作为设计师，你必须有能力批判性地评估竞争对手的情况。查看它们如何处理特定问题并对其进行记录。

趣味因素来自鉴别玩家在游戏中所做的事情，如何做事，持续在不会生厌的情况下做该事情的能力。这是执行游戏设计的一个棘手环节。许多人对细节存在诸多争议。解决这个问 题的一个方法就是通过你的QA部门过滤合理的信息和反馈。

3.“禁忌”列表

这个“禁忌”列表对我来说已经发展成为十大诫律。它们已经发展了多年，通常会在玩游戏过程中标注和扩展。它们是我注意到，意识到以及与同行讨论的东西。我还注意到其中 有些规则反复在游戏审查和评价中出现。

与所有优秀规则一样，它们也是可以被打破的。当然，你可以打破规则，但你最好确信自己有足够的底气打破这些规则。

1）永远不要让游戏过度复杂化。也就是之前所说的“保持简单性原则”。像我们这类已经上了一定年纪，知道何为“经典”电子游戏时代的人，都知道那时候大家很可能在屏幕前 坐上数小时玩游戏。游戏包括一个简单的前提或者控制输入方法。这些游戏并不会受限于技术，而是牢靠的试验概念。保持简单性原则在今天仍然适用。《吃豆人》有一个摇杆和 一个迷宫。《俄罗斯方块》有一些简单的形状从空中缓缓落下。即使是《雷神之锤III竞技场》也遵从了保持简单性原则不复杂化主要目标的理念，也就是不断轰炸你的竞争对手直 到你的手酸为止。游戏情境可能会因玩家期待或技术而变化，但其原则却仍然管用。

从前的街机游戏设计师清楚自己在做什么。这里的理念就在于他们有30秒时间将用户引进游戏并维持其兴趣。人们也愿意投掷20美分来玩游戏。如果他们无法立即看到投币产生的 效果，他们就不会再继续投入20美分。你必须快速抓住玩家，这要靠保持简单性来实现。下回你去E3或类似展会时，就要花点时间观察人们玩游戏的行为而不只是游戏本身。看看 究竟是什么吸引了玩家的注意力。找到人们爱不释手的游戏，然后带着批判性的眼光自己试试这款游戏。

2）永远不要重复犯相同的错误。批判性地评估竞争对手意味着你得看看游戏中的得与失。这意味着如果你在制作一款类似题材的游戏，你应该借鉴它们做得好的方面，避开它们失 败的方面。除非你真的很有时间，或者有更好的方法，不然就不要另起炉灶重头制作自己的游戏。

3）永远不要剥夺玩家的控制权。不要让玩家干坐着观看不必要的动画、过场动画或者音乐插曲。《合金装备》在使用运行时间转场吸引玩家注意力方面表现出色。Valve的《半条 命》则是另一个利用转场拿走玩家控制权，但却不会让人察觉的杰出例子。Cinimatix游戏《Revenant》则是一个糟糕的例子，因为其开发者的脚本引擎总是让玩家在抓狂中摁压 ESC键时，在屏幕上出现一些无所事事的角色。这个原则也适用于“游戏内部”事件。许多战斗、动作或者其他游戏中的一个普通问题就在于，当玩家正好是在与竞争对手“战斗” 时被“卡”在一个点击反应循环中。玩家此时就会连续三四次挨打，却毫无还手之力。这真是个令人抓狂的缺陷。

4）永远不要忘了用来玩游戏的控制器或I/O设备。PC游戏移植到主机平台时会出现一些显而易见的问题。你很难用Playstation控制器输入16个不同热键的动作。你得知道角色在游 戏中会有什么举动，同时你还要知道玩家如何在游戏世界中驾驭角色。这适用于导航库存屏幕以及复杂的选择机制。一般情况下，你应该总是服从保持简单性原则。

5）永远不要假设玩家知道你的想法。玩家通常是聪明的群体，能够自己快速意会现存的谜题或情境。因此，设计师必须想方设法挑战玩家。有时候，我们会通过向他们呈现一些对 我们来说挺合理，对执行测试的QA来说颇合理，但却无法令对游戏很陌生的玩家理解的东西，毕竟他们不像我们一样在过去9个月中一直同这款游戏打交道。《Soul Reaver》是遵 从和打破这一原则的杰出典型。游戏的教程环节出色地将玩家引进游戏世界。但在某些节点上，游戏却会在没有任何解释的情况下让你去做一些事情。例如，游戏会让你向北走， 但游戏中却并没有指南针，那我怎么知道哪条路是向北？光是理清这个问题就花了我4个小时的时间。

6）永远不要打破既定规则，除非你已告知玩家。有不少游戏是通过不允许玩家操纵其环境来向玩家传授游戏习惯。这并无不妥，但如果在之后你决定允许玩家使用一些不同于之前 的方法时，一定要告诉他们！《合金装备》就很擅长此道。该游戏信息让你知道自己必须完成特定目标。在这一切发生时它会有一些悬念，但也好过让你挣扎数小时忘却之前学到 的一些经验。对玩家隐瞒信息不应该划入谜题的范畴。这里还有个相应的说法就是，让你的谜题在一定程度上与现成的逻辑相关。《Return to Zork》就是一个逻辑与解决谜题毫 无关系的例子，玩家就是因为这个原因而对游戏失去兴趣。

7）永远不要认为技术可以弥补糟糕的设计。这是行业在过去数年反复打破的一个大规则，我们每年都可以看到不少游戏声称自己实现了特定的技术成就，例如拥有“最为真实感的 AI！”但如果要问游戏是否有趣，答案就不尽然相同了。如果游戏并不有趣，就没有人会想去玩。

有些时候技术的确可以缓解糟糕的设计。例如提升帧率和令图像更流畅。但有些技术却无法令普通的终端用户买帐。他们通常并不了解或关心技术标准，他们只想知道游戏是否好 玩。

这方面的例子包括Terminal Reality的PC游戏产品《Nocturne》。该游戏拥有出色的“即时照明和阴影”技术，可让游戏实现一些真正惊悚的效果，但每次屏幕上同时出现2个以上 的怪物时，画面帧率就开始大打折扣，在某些时候令玩家的战斗功能几乎失效，真是令人受挫的体验。

8）永远不要认为授权就是品牌保证。世界上没有哪一层关系可以助你热卖一款次品。这一规则也有些例外情况，但同第7）点一样，玩家只想知道游戏是否有趣。

9）永远不要欺骗玩家。这里的基本规则就是玩家如果做不到，CPU就不应该做得到。对程序员来说，设置完美的AI相当容易，但要让AI表现得像人类一样则更为困难。太过于聪明 的怪物AI会给人不真实的感觉，因为它们做了一些人类玩家式的行为。

10）永远不要操纵道德感。如果玩家发现利用保存功能，可以绕过你游戏的一个“功能”，那就随他们去吧。我们在《Baldur’s Gate》或《Jagged Alliance II》等RPG中可以看 到此类问题。我自己就曾经盲目地派出一些人去寻找坏人的来源，然后再重新载入游戏并据此制定计划。不要因为玩家重新载入某次失败的尝试而惩罚他们。这方面的特殊例子当 属《Baldur’s Gate-Tales of the Sword Coast》的扩展内容包。它们有一个功能，如果你重新载入之前保存的游戏，它们就会向你抛出更多怪物或者为你制造更多障碍。如果玩 家想保存自己的游戏，走进房间看有什么东西跳出来，然后再重新载入和重新配置自己的角色，那就允许他们这么做吧。这有什么关系呢？我们又不设计道德。如果玩家想“作弊 ”，那就随他们去吧，如果你能想出一个不惹恼玩家的方法那就更好了。

相关拓展阅读：篇目1，篇目2（本文由游戏邦编译，转载请注明来源，或咨询微信zhengjintiao）

A Primer for the Design Process, Part 1: Do

by Tim Huntsman

For every game that sets the high-water mark in design and/or game play, there are dozens of titles that don’t. Why is that? I’ve discovered a number of possible reasons. Many games are made by people who shoot from the hip instead of taking a good and proper aim at success, many designers are relatively new to their jobs and aren’t certain what’s expected of them, and few development companies have established a formal design processes for creating and
implementing a game.

Books and magazines are only now dedicating themselves to the craft of game design. Because it is an inherently creative task, everybody thinks they can do it. If that were true, there’d be more games out there with better control, better AI, more user-friendly front-ends, game mechanics that the average 12 year old can immediately pick up and play, and less games clogging the clearance bin at Software, Etc. A harsh reality story a friend of mine likes to tell regards a VP of development-type for a larger developer/publisher asking why he should invest 1.4 Million dollars in his project versus simply investing it in the stock market. The answer? The possibility of an astounding return on investment provided the game is well designed, on time, and fun to play.

This primer for the design process is broken into three separate sections: Do, Think, and Need. The first article explains what you need to do to get ready to make a game, the second looks at what you need to think about while you’re making the game, and the final piece examines what you’ll need to do the task.

What to Do:

The primary task of the Designer is to design the game. That sounds simple; it was meant to. More goes into designing a game than writing frilly paragraphs about just how cool you think your idea is, just more is required than writing a massive, hernia-inducing tome of endless and unnecessary detail that no one but the author can bring themselves to read.

Good design is about the implementation of ideas and details. To know what you need for your game, you need to know what’s going on around you. You need to know what the market might support and what the market is sick and tired of seeing. You need to know what your company (or those funding your company) may or may not want to see. In short, you need to start by asking some questions.

1. Asking questions

This is as simple as it sounds, you need to ask questions before you begin to write your design doc. There are a lot of things to consider while you’re cooking up ideas for your next platinum-selling title. By no means is this list all-inclusive. Some questions might be irrelevant to your respective situation -not all games need the same considerations- while some projects might require additional questioning. Determining which questions to ask is one of the most important parts of your job.

What are the current trends?

What are current trends in design? Scan the trade-mags and look at what and who are causing a buzz. As technology gives us the ability to push more polys, build and view larger worlds, light them in real-time, and maintain an acceptable frame-rate, we see that gamers are expecting more from their entertainment. One way that certain creative companies have kept the ongoing interest of gamers is to blur the lines between established genres. It helps us to challenge
what’s become “accepted” and push the veil of innovative design.

Trends can also exist in things like options and utilities-how the competition is empowering the player by giving them more control over their game play environment. One standard now being called for in the wrestling genera is the need/want to create custom wrestlers from the ground up. This became the most talked about feature on the US side with WWF Warzone, and now THQ and EA both incorporate more “player-empowering” concepts into their titles.

What is marketing looking for?

This could be restated as, “What are gamers looking for?” Look to the marketing experts, they should have a good idea about what people want. They do the focus-group testing, they should be compiling data from this feedback. Also, consider what the market can stand. “Me-too” products usually sell much less than the product they’re emulating.

What current tools do we have access to?

For example, look at what motion capture did for animation. Don’t get me wrong, I’m not advocating an “all motion capture, all the time” game world, but that kind of data is an excellent way to build a foundation that your well-paid and well-respected motion editors can start from, tweaking the motion to fit the design after the fact.

3D authoring and world-building tools are still probably the most prevalent example of things that can help or hinder the design process. Preexisting tools can also give you jump if you need to either prototype a concept in a hurry or if you need to race to make the Christmas buying season before you loose the license for your game.

Tools give you a way to either prototype a design to get an idea across. They also allow you to get a job done with less hassle. Recycling technology is not a bad thing, unless the only thing your company can hype is tech with no game play.

Some genre’s lend themselves to certain kinds of music, often from professional named bands or individuals. Take a listen to what’s good, what seems to be happening, then incorporate its style into your title. Some marketing folks will fork over a chunk of your development budget to sign bands or individuals to do the music for your title, but it’s been my understanding that very seldom, if ever, will a person’s decision to purchase a title be based on the fact that someone they may have heard on the radio once did the music for the game. In certain cases having a named talent do the music might add to the “cool” factor and help generate a little buzz on websites or the odd magazine, but it’s not going to sway the consumer and it can also be a huge licensing hassle with no real guarantee that what gets written for the game will be delivered on time or be any good. If there’s any question, a good solution is to try to get a synchronization license (Where you get the right to cover the song, but not to use the original recording by the original artist) for a piece of music you’d really like in your game.

Some companies have been known to waste a ton of cash trying to get a particular vocal talent or talents to act in their game as, unfortunately, a major marketing aspect of the title. Did it matter that Rob Schnider was the main vocal talent in A Fork in the Tail, or Christopher Lloyd was in Toon Struck? As above, more often than not most gamers won’t buy a title simply because there’s some celebrity voice actor that they button past in the first 2 seconds of hearing it in order to get back to the game play.

Get something (or someone) good that fits the attitude of the game, and it will increase the gaming experience for the player. That’s all you need to be worried about.

What’s been done and how was it done?

I talk about this later on in the “Think” section about Critical Evaluation, but this is a very important issue when you first start your design. There’s absolutely no need for you to tell a story that’s already been told, or develop a game that’s already been done, or rehash a genre that’s on the way out. Do your research and learn from that research. You should be playing games, plain and simple. You need to know what’s out there, what’s already been done, and how high the bar has been set so that you can clear it.

2. The Working Design Document

Once you’ve focused your ideas, its time to think about the design doc. The design doc acts as a script; it should be giving every other professional involved with the product a more than firm idea of what they need to know to implement their portion of the product.

Like other parts of the entertainment business, there are some basic rules and formats for how ideas are presented, as well as a few things that people no longer want to see. Publishing has its “double spaced 12-point Courier font” from the old Smith/Corona days, and film and TV have standard script formats for either television or the silver screen. These formats are not only expected, but also demanded.

Our business is a little different. It’s not quite old enough for standards and guidelines to exist, but we’re moving into the “broad spectrum formalization” for industry standards and practices. Simply stated, tradition has bred expectation. Certain questions should be answered before the thing is sent to production. This is your job, O Maintainer of the Creative Vision. You need to answer these questions and more, as everyone on the project will be coming to you or your people for information and the lo-down on what needs to happen and, more importantly, how it’s supposed to happen.

Design documents tend to fall into one of two formats: they either loosely describe a game concept so upper-management can sign off on the idea, then get dropped into someone’s filing cabinet never to be read again OR they are the size of your local Yellow Pages, filled with every imaginable detail that no- one but the person who wrote it cares about or is willing to read.

In an effort to maintain the working lines of communication between the design staff and the production team, we came up with the idea of a “feature- oriented” document that could keep everyone on the team up to date and informed whenever a design change was made or redesigned.

If you look a production movie script, you’ll see that there are different colored pages at any given point throughout the entire script. These pages represent changes that have been made to the script since the start of filming. The colors allow the cast and crew to follow the changes and thus maintain continuity and keep everybody -pardon the unintentional pun-on the same page when updates occur.

Like a script, things in a design document will change due to circumstance, talent, or innovative problem solving on the part of management or the production team. These changes should not only be noted, but also sent out to the people whom they affect.

The Feature-Oriented Design Document

Our feature-oriented design document began as a basic form that could help keep the 6 people involved with the design document up to date. It was designed not only as a fluid guide for everyone on the team, but also as a living document that could carry us through the ongoing design of 3 different games.

We put the design document on our LAN, with the design team continually adding to or updating the document at the same time. Version control is a simple matter of the software (in this case MS Word) not allowing more than one person to work on an individual sub-document at any given time.

The document itself incorporates a couple of features that help with keeping things organized, including major headings calling out important items like what the engine needs to do to, AI requirements, game modes, motion requirements, and on and on. Under these heading are the particular sub-documents explaining the features or functions that ndividuals on the team have been tasked with designing. Whenever a new design feature is nailed down we can send out updates to the relevant team member through E-mail with a hyperlink attached to the virtual document for easy access by team members. We can do this because the document is being written with the whole team in mind.

The sub-documents themselves take the form of a numerated template with the heading numbers tied to the table of contents. This allows us to sort these documents by feature or project when we work on layers of design for separate products. The template helps push for a more detailed design for each feature and also helps the designer answer questions up front, allowing for a more thorough design when the project hits production.

This template also allows us to design for more than one version of the game. Some design features have been layered to appear over a series of releases and as such, you’re always on the same page with whatever feature you’re thnking to forward.

The master plan for the design document is to have it linked with both a Technical Design Document that’s arranged in the same manner and some sort of scheduling software like MS Project. This has the added function of allowing us to asses any impact to milestones or budget new design features may have.

The Template:

The major reason most artists and programmers don’t read the design document is that, if there are any practical design features contained within, they are usually buried in page after page of ongoing paragraphs. Simply stated, no one wants to weed through it to get to what they need to know. The template, in this form, serves the major function of being digestible in small relevant chunks.

Remember, this is a FEATURE-ORIENTED design document, which means that it is put together with certain goals in mind, and these goals are broken down into doable bits.

0 TABLE OF CONTENTS – This needs to contain EVERY major heading that you’ll be dealing with. It should include sections like AI, collision, level design, front-end logic flow, controller input, and the like.

1 FEATURE HEADING – Describes and numerates the issue/feature in question. The numerical index, established in the TOC allows for easy finding and sorting once the project is underway.

1.1 Contact and “See Also” Information – Straightforward: Point of contact for who designed the feature and what other documents it relates to outside of this one.

1.2 Goals – A bullet list of associated goals including problems you may encounter implementing this feature and possible solutions to said problems.

1.3 Implementation – How you’re going to affect the feature. This is where you’d include formula, diagrams, or flowcharts that layout the design feature in question that all relative parties may need to know/follow to get the feature up and rolling.

1.4 Impact – How this feature will impact the current status quo. You can’t always crystal ball this, but in our case we’re making changes to an existing engine/game, so some changes do affect the way we’re currently implementing some features. An example of this would be having a new action for a wrestler to do, and needing a button-press to pull it off when we’re already overloaded here. Another use for this heading is to help you identify extra resources you
may need, and schedule relevant needs to bring the feature into line.

1.5 to 1.8 Tasks & Questions for:

Designers

Programmers

Artists

2D

Modelers

Motion

Sounds

There must be “Tasks & Questions” sections for each arm of the development team. This allows the Designer, Artist, Programmer or Sound Designer in question to skip straight to the task relevant to them without having to filter through all the other text. This also lets the design team ask any questions they may have at a time when they might not have access to the person that could immediately answer it.

You’ll also want some way to tag features that have been dropped or held back for whatever reason. You don’t necessarily want to delete those features, as they may make their way back into the current design or appear in the sequel if you’re doing one.

In our particular case, we’re working on the design for several titles at one time. Each heading is further expanded into 3 sub headings-one for each version-and color coded to make reading and separating them on-screen a little easier.

E-mail and the Hyperlink:

With the design doc online, we’re able to send intranet e-mail to all concerned parties when a feature is designed, changed, or dropped. In addition to the email saying, “This feature has been designed, changed, or dropped,” we can also add a hyperlink which, when clicked upon, will take the concerned party directly to the page(s) they should be reading.

The e-mail has a secondary consideration in that the Project Manager will know when and if the Email is being read. This helps in maintaining team accountability for what each person’s job should be, and how they need to implement it when the time comes. This kind of organization lends itself to a HTML-type document as well. We’re currently setting up just this kind of accessible, online document using MS Frontpage. You could also use Dreamweaver if you were so inclined. This allows anyone with a web browser to access the design doc and very easily navigate their way to whatever piece of info they need. Even better, you can do things like create art bible’s, complete with linked thumbnails and actual photo reference on the network, making sure all or your resource is available and protected.

The next section (THINK) will go deeper into asking questions about what you’re supposed to be doing as a designer. This also includes my list of “Nevers, ” garnered over the years both from friends in the industry and from simply doing things the hard way.

Tim Huntsman has been with Acclaim Studios, SLC for over 4 years and is the Lead Designer for Acclaim’s next-gen wrestling title. He has worked on the ECW wrestling franchise as well as the genre-defining WWF Attitude for PSX and N64, projects that taught him more about professional wrestling than he ever thought he’d know. When not working on games and their design, he’s playing guitar in experimental projects, writing various forms of fiction, painting in
the Sumi-E style, and fencing (with swords, not wooden planks.)

Previously, I talked about the “Do” process, about what you as a designer can do as you ramp-up in the early design process. The focus was on asking questions, finding out what people want, getting a focus for your project, and putting it into a format everyone could (and would) use. This next section should help in giving you some insight about the frame of mind you should be in during the early design and implementation phase.

Contents

Asking Even More Questions

Good Habits, A Critical Eye, and the Fun Factor

The list of “NEVER”

What to Think About:

The “Think” section contains info that you, as the Designer and maintainer of the overall vsion of the product, should be thinking about to improve the quality of your game. To be thinking is to be involved in the design process. You should be in constant contact with all the people working on your title. You should know what goes where, who’s supposed to put it there, and be able to answer just about any question anyone might have about the product.

1. Asking Even More Questions:

The following section can be employed through the development process. These are things you should be asking as you go Alpha, and they should be finalized before you go Beta. (Just so you know where I’m coming from, I’ve always understood the terms Alpha and Beta as they apply to game development in the following way: Alpha means that all of your “major” technology is in place, but not working 100%. This also applies to sound and art. Beta means that everything that’s supposed to be in the game IS in the game. It’s all down to tweaking and bug hunting from there to turnover.)

How is our front-end/fluff going to flow?

The “KISS” rule applies here (See “Never” rule #1.) Don’t force the player to filter through 6 or 7 screens to get to the game play unless it’s absolutely necessary to the game. Put things in their logical place, and don’t be afraid to give the player help or tell them what buttons do what within each screen. Another rule for you PC developers out there: If you’re going to make me type a new name for a game save, please allow me to hit the “return” key to save instead of forcing me to go back to the mouse and click on the “save” button. I won’t even talk about deleting an old save to free up some space.

This also includes thinking about what you’re going to let the player do to configure their individual gaming experience.

On a side-note-many companies have front ends that, to put it simply, suck. They have limited options, navigating these options is a task Uri Geller couldn’ t fake, and it’s usually a chore to try to configure something for your own liking. This comment holds true for the vast majority of PC game companies and not consoles. The console companies have standards that they are held to. Make it easy for players to modify things that you’re going to allow them to modify. And, I might add, there’s absolutely nothing wrong with giving players instructions on what button(s) they need to press to make something happen on a menu screen.

What options or modes should be included?

Creating a player in International Superstar Soccer ’98

This particular question could be restated as, “How can we empower the player?” More and more players want to “mod” their games. I’ve seen this with the popularity of Quake mods-special fan-made levels, skins, and sound FX-and in games I’ve worked on like WWF Warzone and WWF Attitude. Giving players some measure of control over their environment will do wonders to increase the replay value of your title. It pumps up the “cool” factor. Konami’s International Superstar Soccer ’98 had the same create a player idea allowing the player to make either real or fantasy teams and using them in long-term tournaments.

Empowering the player with cool features, options, and game modes also has a definite payback in the fact that you will build a loyal fan-base that will buy into the franchise you create. (Sequels, people, sequels.)

A simple way to find options and modes to add to your title is to ask your testing department (or your publishers) or get some focus group testing done. Everyone has an opinion, you might as well listen to them.

How’s the pacing?

Simple question. Is the overall game too long? Usually, you’ll find that the game’s too short. Players fork out anywhere from $20 to $70+ bucks for a game and it better be worth it. There are no rules on just how long the total gaming experience should be (with the exception of arcade titles) but players should feel like they got their money’s worth.

A secondary consideration is to consider in-game pacing in the same way you’d critique a book or a film. Does your product drag its heels for an ungodly long time, boring the player to tears from one scene to the next? Does it go crashing through it’s paces at breakneck speed, never giving the player time to catch a breath or reflect on what he’s supposed to actually be doing other than surviving? ‘Balance the flow’ are the words to remember. Changes in tempo are a good thing but remember to take care how you manage those changes.

How hard is hard?

Get QA’s feedback when considering the difficulty. Can players breeze through your game in minutes, in hours, or days? Remember the players who are buying your game, and don’t always look to please the QA testers who have been playing the game solid for the last 6 to 9 months. Whatever is going to be considered difficult for your testers will probably cream the average player who might purchase your game, and force them to return it because they can’t get past the first level. More than three levels of difficulty are usually better if you can swing it. Sad to say, tweaking levels of difficulty – adjusting AI to match and balancing game play to accommodate – is a tough and time-consuming thing that needs to be addressed by everyone involved on the project.

How can we integrate cut scenes, FMV or Run-time movies?

The first question is simple: Do you really need something like this, or can your game survive (quite nicely) without this? If absolutely necessary, try for the “in-game” movie rather than the pre-rendered cinematic escapade. It not only helps to keep the player immersed, but your transitions will be less jarring to the player. Metal Gear Solid, Half-Life, and Soul Reaver were good examples of the In-game movie.

How can we get replay value out of this?

Some games are over when they’re over. The surprise is done and there’s really nothing left to look for. Others can be played again and again, either because there’s more to discover, or you’re trying to do something personal like beating a high score. (Score? Games keep score? What’s that? I’m sorry, but I’m a throwback to halcyon arcade days of the early 80′s where score was EVERYTHING!)

How are our load/save times?

No one wants to sit around looking at 2-tone bar fill while waiting for the game to load. Sony has standards for it and it’s not really an issue for the N64. PC guys, you’re on your own. Push the programmers to optimize this. It’s ALL part of the total game experience.

On a related note here-allow the player to save where they want to unless it’s fundamentally necessary to not let them save. Reflection’s Driver for the PC is a glaring example of forcing the player to get through 3 or 4 scenarios before they can save. You should know just how annoying this is and furthermore, you shouldn’t be doing this to the gamer unless it’s absolutely necessary to maintain the fundamental design features of your game.

2. Good Habits, A Critical Eye, and the Fun Factor

Merging Design Documents, Schedules, and Budgets.

Time will need to be taken during, or immediately after, the pre-production design phase to come-up with real numbers, times, and dates for the project. The usual problem with those above-mentioned words is that, for each concept mentioned, you have a different group of people crunching the numbers. They also don ’t tend to be in very close contact with each other. Many companies are fond of saying, “Hey, we need to fill a gap in the quarter here! You guys, do this game in 8 months!” Your response is, “Not on your life, but if we must, we’ll need more money and resource to do it.” Of course, they don’t want to give you more money and resources to do it. That’s why it helps to gather all relevant parties to this portion of the development process, bring them together, and hash out the numbers. That’s why it helps to have your design broken down into needs, tasks, and features at the start.

There is no better time to examine resource and budget considerations then while you’re hammering out design detail, unless of course you have nothing to do with making the schedule or planning the budget. If you’re leading the design vision of the product, however, you should very well have a hand in the schedule and budgetary considerations. Get all the relevant people into the room at one time and hammer out the numbers. It’s a big pain in the backside, but it’s definitely worth doing in the long run. Remember, when the design doc is changed, or features are re-worked, you’re going to have to take a look at the impact and figure out if this is going to push you back in the development process.

Updating the design document.

This sounds easy, but in the throes of development long hours and crushing stress from all sides can cause details to slip through the cracks. You might talk about a feature in a late-night impromptu gathering and then implement the change the next morning. You should document that change, especially if you end up doing a sequel a year or so later, so that you remember what you did in the first place.

When anybody on the team decides to round out a feature, change a feature, or add a feature this change should be noted, documented, and brought to everyone ’s attention. If you’ve created an on-line style design document not entirely unlike the one mentioned part one of this article, you’ll have the mechanism in place to keep the team informed and responsible.

Keeping a Design Journal

This is as straightforward as it sounds; keep a running dialogue of what’s gone right and wrong during the project. Week to week will probably do unless you ’re in the middle of one heck of a crunch time. This will serve a number of purposes. First, it lets you recall, months and months after the fact, lessons you may have learned or not learned early in the project before the press of 15 hour days began to blur one day into the next. Secondly, it allows you to bring up key issues of good or bad work done by people throughout the project during the post-mortem (your company has post-mortems, right?) And lastly, it will help you in publishing a post-mortem article for a relevant publication so your fellow designers out there can learn from your experience, right?

Critical Evaluation

One of the best things you can do for your game when you’re looking to implement features is to critically evaluate the competition and I mean look at them. There is a saying, “It’s amazing how much you can see if you just look.” Don’t knock on the competition simply because their title is out before yours hits the shelves, evaluate it. Every title, no matter how heinous, has some lesson to be learned tucked within its folds. The primary lesson here is to avoid making the same mistakes that killed a rival product.

This goes for the whole game, look at things like their front end to see how easy it is to get into the game, check the controller set-ups, examine screen real estate and test in-game timing issues and controller sampling. You don’t want to be reinventing the wheel if you don’t have to. If some other game is doing something well, borrow that idea or concept. You just have to make sure that you don’t outright steal the concept. That would be a no-no. Remember: Good design not only about ideas, but it’s also about the implementation of those ideas.

Of course, at some point you are going to need to turn that cruel, cold eye of unswerving criticism on your own title. Testing feedback will help here but ultimately someone’s toes are going to get stepped on. When looking at your own product, put your ego in your back pocket. Many a title has crashed-and- burned because someone’s ego fought against the tide of popular opinion and washed-out (or in) a feature (or features) that killed game play.

The ‘Fun Factor’

Some companies want you to work on the “fun factor.” Everyone’s looking for that elusive concept that you read so much about in fluffy design treatments and marketing blurbs. The causal gamer and average consumer can’t nail down what is really fun. They’ll tell you something’s fun, but they can’t tell you what’s happening inside the game and what they’re responding to. Fun tends to be a relative concept that revolves around things like pacing, timing, and excitement as specific to that particular title. These are things you can theorize about; tell people “punching this guy is fun!” but you’ll never really know until you spend time with the game and work it out. As a designer, you need the ability to critically evaluate the competitions efforts. Look at how they handle certain issues and make note of them.

The fun factor comes from being able to identify exactly what’s being done, how it’s being done, and you can continue to do it without the game getting boring. This is a touchy part of the implementation of the design. Lots of people are going to have arguments one-way or the other about the details. One thing that will help you with this is filtering proper information and feedback from your QA department, but I’ll go into that later.

3. The list of “Never”:

The list of “Never” has evolved into a kind of Ten Commandments for me. They’ve evolved over the years, usually noted and expanded upon while playing games. They are things I’ve noticed, come to realize, and things that are brought up in conversations with my peers. I’ve also noted that some of these rules get repeated in game previews and reviews.

Like all good rules, however, they are ALWAYS made to be broken. And, of course, you are allowed to break them. You just better make darn sure you know what you’re doing when you do break them.

1. Never overcomplicate a game if you can help it. Stated in the obvious way it reads, “Keep It Simple, Stupid.” Those of us old enough to look back on what is considered the “classic” era of video gaming remember it as being a time of very straight forward gaming that could keep you glued to a monitor for hours. Games evolved around a simple premise or method of controller input. Those games were not limited by technology or the lack thereof, but were instead solid concepts of experimentation. The KISS principle still holds true today. Pac-Man had one joystick and one maze. Tetris had a few simple shapes falling gently from the sky. Even Quake III Arena follows the KISS ideal of not over-complicating the main goal, which in this case happens to be blasting your opponent as many times as you can till your hands fall off.

The context may change with player expectation or technology, but the principle will always remain sound.

The arcade game designers from the good old days knew what they were doing. The philosophy there was that they had 30 seconds to introduce someone to a game and maintain that interest. People are willing to drop 25 cents into a cabinet to see what it does. If they don’t see it immediately, they won’t drop another 25 cents into the machine. You have to grab them quickly. You do that by keeping it simple. The next time you go to E3 or some such event, spend some time watching not the game, but the people playing the game. See what’s grabbing their attention. Find the games that people won’t put down then try them yourself with an eye towards critical evaluation.

2. Never make the same mistake twice. Critical evaluation of your competition means looking at what’s been done and what’s out there. It means if you’re doing a game in a similar genre, you should be borrowing fro the things that they do well, and avoiding the things they don’t do well. Don’t re-invent the wheel unless you sincerely have the time and wherewithal to come up with a better way.

3. Never take control from the player if you can help it. Don’t make the player sit through some animation, cut-scene, or musical interlude if they don’t have to. Metal Gear Solid did a great job of using run-time transitions to keep you there and interested. Valve’s Half-Life was another excellent example of transitioning-taking control from the player-but it didn’t really feel like it. Revenant by Cinimatix, on the other hand, is a frustrating example of waiting for the developer’s scripting engine to putter characters around the screen while you mash the ESC key in frustration.

This rule also works for “in-game” events. A constant and common failing of many fighting, action, or other titles where the player is physically “fighting” an opponent happens when the player gets “stuck” in a hit reaction loop. The animation may have looked cool on the animator’s screen, but while the hero is writhing in pair from a vicious blow on the part of the attacker, this same attacker has finished his animation and has initiated another attack. (while the hero is still writhing) See where I’m going here? The player ends up getting hit 3 or 4 times with no chance to defend themselves. This is a very frustrating flaw.

4.Never forget the controller or I/O device you will be using to play the game. Obvious problems are when PC games are converted to consoles. It’s hard to type from 16 different hot-keyed actions with a Playstation controller. You’ve figured out what your character will be doing in the game, at the same time you should have figured out how the player is going to maneuver the character through your world. This applies to navigating inventory screens and complex selection schemes as well. You should always defer to the KISS philosophy here unless you absolutely can’t help it.

5. Never assume the player knows what you’re thinking. Players are usually bright people who can intuit a pre-existing puzzle or situation rather quickly. Because of this, designers must think of ways to challenge the player. Sometimes, we will challenge the player by presenting to them something that makes sense to us while we were working on it, and make sense to QA while they were testing it, but doesn’t translate for a player who hasn’t spent the last 9 months of their life working on the game.

Soul Reaver is a good example of maintaining this rule AND breaking it at the same time. The tutorial portion of the game was an excellent introduction to the game’s world. At several points, however, the game would tell you do something without any explanation. Case in point: Directions were given in the form of a compass point (go North, young man. . .) yet there is no compass in the game so, just how am I supposed to know which way is North? Sound’s easy, but I
lost 4 hours backtracking to figure this one out.

6. Never break the established rules unless you TELL the player. There are a number of games out there that will teach the player certain habits by NOT letting them manipulate their environment. That’s OK, but if at a later date you decide to allow the player to use these objects in a way that’s different from previous lessons, TELL THEM! Metal Gear Solid was good about this. The game gives you the information you need to accomplish your goal. It begs a little suspension of belief when this happens, but it’s far better that fumbling around for several hours trying to unlearn something you’ve been doing the entire game to this point. Withholding information from the player should not be the extent of the puzzle. There’s also the parallel argument here about making your puzzles somewhat dependent on existing logic. Return to Zork was a prime example of logic having nothing to do with solving the puzzle and the players lost interest for that very reason.

7. Never assume technology can fix bad design. This is a BIG rule that this industry is guilty of breaking repeatedly in the last few years. We see a number of titles every year that claim to make certain technological feats, usually in terms of pushing poly’s or having “the most realistic AI ever encountered! ” You’re answer to marketing ploy’s like this should be, “So, is it fun?” Real-Time Lighting! If the game’s not fun, no one is going to want to play it.

There are cases where technology can ease bad design. Pushing more poly’s, thus raising the frame rate and smoothing out your visuals, is a good thing. Some technologies, however, don’t or won’t filter through to the average end-user. They generally don’t know about or care about technical specs, they just want to know if the game is fun.

An example here is the PC product Nocturne by Terminal Reality. The game has great “real-time lighting and shadows” FX that lead to some truly creepy moments in the game, but anytime more than two creaturejumped on screen, the frame rate would bog to amazingly bad rates, making combat near unplayable at certain points. Very frustrating.

8. Never assume the license is all you need. No association in the world will help you sell an inferior product. There are some exceptions to the rule but as above, players want to know if the game is fun.

9. Never cheat the player. The basic rule here is that if the player can’t do it, the CPU shouldn’t be able to do it. It’s AMAZINGLY easy for a programmer to set up the AI to be perfect but it’s a lot harder to get that AI to act like a human would. The hand’s-down winner of cool creature AI would be Unreal because they do human player-type things to get on you.

10. Never design morality. If players find a way to circumvent a “feature” of your game by utilizing the save feature, let them. You see this kind of problem in RPG’s like Baldur’s Gate or Jagged Alliance II. I myself was guilty about sending guys blindly into the fray just to see where the bad guys were coming from, then re-loading the game and planning accordingly. Don’t penalize the player for re-loading a failed attempt at a room or hurdle. A specific example of creaming the player in this manner would be the expansion pack to Baldur’s Gate-Tales of the Sword Coast. They had a feature that, if you re- loaded a previously saved game, they would throw MORE monsters at you or make some sprung trap hit you even harder. This, quite simply, sucks. It’s also a poor excuse for problem solving. If the player wants to save his game, walk into a room to see what jumps out, the re-load and re-configure his characters, let him. So what? We don’t design morality. If the player wants to “cheat” let them but if you can come up with a solution that DOESN’T screw the player,
even better.