作者：Ian Fisch

如果你认真调查那些成功和失败的游戏，你就会注意到决定游戏成败的往往不是机制或想法，而是从始至终的开发设计过程。

《蜘蛛人2》、《Stranglehold》和《刺客信条》等众多游戏向玩家呈现了新奇的概念和设计，但是填充到游戏中供玩家体验10到15小时的内容成了游戏崩溃的因素。

另一方面，《使命召唤4》等游戏尽管没有任何创新，但是其节奏和关卡结构产生了很大的吸引力，使玩家在整个游戏体验过程中都能保持专注。如果没有绝妙的执行，即便连《传送门》或《粘粘世界》这样被视为极具创新性的游戏，同样无法获得成功。

我遇到过许多团队，项目开始时有绝妙的概念，但在将其转化成产生吸引力的电子游戏体验时遇到了各种问题。我注意到，游戏设计过程中会出现某些情况，阻碍开发者为设计团队做出贡献。

我将这些情况总结为“10大设计过程易犯的错误”，如下文所示：

1、没有安排玩游戏的时间

这个错误看似无关紧要，实际上会对设计过程的质量和效率产生很大的影响。理想情况下，在游戏的预制作阶段，设计团队的所有成员都需要花一定时间来体验与即将动工的游戏题材相同的其他游戏。

我从未见过有团队组织安排了这个时间。对有些制作人来说，安排“游戏时间”似乎很难进入他们的计划，安排5人团队花1周时间对现有游戏展开“调查”似乎是件很“奢侈”的事情。

反之，制作人总是期望设计师对目前的行业现状已经相当了解。不幸的是，并非所有的游戏设计师都有足够的空闲时间来体验已经发布的每款游戏。通常情况下，游戏设计师的年龄越大，他们拥有的空闲时间就越少。此外，设计师选择在空闲时间体验的游戏或许与出于开发目标应当体验的游戏并不相同。比如，许多并不出名的游戏中包含有趣的想法，可以作为很有价值的学习工具。

花时间来体验同题材其他游戏有助于提升最终产品的质量，还能够节省大量的开发时间。我曾经参与过一个项目，设计师刚好玩到一款同题材的游戏，他在那款游戏中发现了更好的玩家导航系统，而我们为此已经耗费了数个月的时间和精力。

在另一个项目上，有人在一款不甚流行的游戏中发现了与我们讨论的极为相似的第三人称机制。如果我们玩过这款游戏，就可以节省数周的讨论时间，也能够明白这项机制并不如想象的那样有趣。

当所有设计师都体验过同类游戏后，他们互相之间表达想法的能力也会获得显著的提升。比如，一个设计师可以对另一个设计师说：“我们可以使用《银河战士》中的锁定系统，这样玩家就无需一直按右侧的操纵杆。”

如果后者也玩过《银河战士》，他马上就能够理解前者的想法。前者也无需再向他深入解释锁定系统。不仅如此，后者还明白这种设计会让玩家使用控制器时手上产生何种感觉，这是用言语无法传达的内容。

我曾经用纸笔向项目主管解释《战争机器》中的手榴弹抛掷系统，他觉得这个系统过于复杂。在他亲自体验过游戏和系统后，他理解了我的想法，并采纳了我的建议。

重要的是，首席设计师自己也要参与到调查中，同设计团队成员一起体验游戏。如果首席设计师认为这是件无关紧要的事情，那么其他团队成员也会产生同样的想法。此外，因为首席设计师往往是团队的主要决策者，所以他必须拥有能够同其他设计师交流的背景知识。

执行组织化的游戏体验时间计划或许需要说服制作人。如果能够让制作人看到明确的学习结果，那么他会更有可能同意这项计划，比如每个设计师都需要在每天体验结束后向首席设计师提交报告。

2、过于看重纸上设计

数学系的学生或许都知道，混沌理论的基本理念之一是，有些系统（游戏邦注：比如天气）过于复杂，无法对其行为做出准确的预测。互动变量过多，任何一个都会导致系统发生很大的改变。我觉得，游戏也是如此。

设计师可以尝试在脑中想象游戏中关卡的体验过程，但上百种互动元素的任何一种都会对关卡的整体趣味性产生巨大的影响，比如环境、控制、游戏机制、物理和AI。这正是我不会过于注重纸上设计的原因之一。

第二个原因是，根据我的个人经验，最佳的想法是在不断实验中偶然发现的。我经常采用的做法是，当我注意到AI能够以某种方法与环境互动时，会以纸上设计为基础构建出关卡。

随后，我会修改关卡，将其制作成多数玩家在游戏中会遭遇到的情境。但是，只有当设计师有足够的自由来修改根据纸上设计而制作出的关卡时，这种通过与游戏系统互动来发现趣味性的方式才能够发挥作用。

不幸的是，设计师并不总是拥有这种自由。在我曾经工作过的某些团队中，设计师在纸上创建关卡和在3D环境中创建关卡的时间几乎相同。纸上设计完成后，团队就会开会讨论、分析和改善这个方案。

如果设计师想要在3D阶段做出重大修改，那么就会被视为改正他在纸上设计过程中犯下的错误。纸上设计也需要被重新修改，这又需要经过团队主管的审核和批复。

团队期望设计师能够在首次设计时就得出恰当的结果。如此设计过程的最终结果是，游戏中的环境可能会与游戏内容不符。比如，对于有些环境中的敌人，玩家很远便可以看到并将其击杀，而有些环境中的敌人直到逼近玩家才会被看到。

3、未重视其他人的作品和评价

peer_review(from dwrl.utexas.edu)

如果你曾经在游戏公司工作过，你偶尔可能在会议上听到“你们需要多玩游戏”这样的话语。

通常情况下，这类话语主要针对美工和程序员，但是我注意到设计师也存在不玩其他人作品的习惯。我自己也落入这样的陷阱中，过分专注于自己的作品，从而忽视了其他人的作品。

定期玩其他设计师制作的关卡能够激发想法，往往有助于游戏质量的提升。我经常会看到设计师在体验他人的关卡时，将发现的有趣元素添加到自己设计的关卡中。

设计团队中可以营造良性竞争的氛围，每个设计师尝试利用他人的想法并将其改善。在玩他人制作的关卡时，设计师们还能够更好地了解游戏制作完成后的整体可玩性。

同行评审往往会被人所忽略，除非这个评审得到首席设计师的认可。我认为，设计团队可以每周定期开展同职位成员讨论会，所有设计师都分享自己的作品，并对同时的作品发表评论。

同行评论活动不应当在游戏开发即将结束时才匆匆开展。比如，假设开发进程进一步深入的时间出现在每周五，那么可以将同行评论的时间安排在每周四下午。

4、首席设计师应涉足具体设计过程

设计团队都有许多不同的职位和许多不同类型的设计师。根据我的个人经验，能够晋升为首席设计师的人几乎全是侧重管理任务的设计师，比如制作电子表展示哪些关卡中将呈现何种类型的敌人。

那些侧重内容制作的设计师往往只能在团队中维持原样。精于制作关卡的设计师通常不会获得晋升，因而也就没有机会来做那些较大的游戏设计决策。这两种类型的设计师同等重要，但这样的不平衡状况会对项目造成伤害。

造成这种不平衡状况的原因是显而易见的。首席设计师需要对所有其他设计师的作品和成果负责，而不是只对你自己的结果负责。这需要良好的人事管理技能。如果你在每天8小时的工作时间里，头脑一直保持编辑内容的状态，那么便很难展示出你拥有足够的人事技能。

反之，当你处理的是涉及整个团队的任务时，就很容易展现出这种能力。比如，你负责的是确保设计要求能够定时定量地通过编程呈现出来。

不幸的是，如果做设计决定的人从未亲自制作过富有吸引力的内容，那会对项目造成很大的危害。在决定游戏应当采用或舍弃哪些想法时，他很可能无法做出明智的决定。

更糟糕的是，因为亲自投入设计过程的时间很少，他并不能及时了解何种决定有益于内容制作。比如，他可能就不会重视同职位讨论会，因为他从未在自己的工作中体验到这种方法的益处。

选择出优秀的首席设计师是件很困难的事情，如果首席设计师既能够完成自己的本职工作，又知道如何做有助于优秀内容的产生，那这样的团队无疑是幸运的。因为这需要两套不同的技能，而且能兼有这两套技能的人并不多。

首席设计师应当致力于维护设计进程和评论其他设计师的作品，最好能够利用些许时间亲自动手设计。同时，制作任务列表和每周报告等管理任务应当交给与设计部门密切配合的制作人处理。

5、不利用占位符

占位符资产和代码在这个行业中大量使用，然而在出现游戏制作人后，占位符的使用往往会大幅减少。这种情况的产生是可以理解的。如果开发商是为某发行商工作，那么展示游戏开发进程是很重要的环节。用拙劣的动画角色和背景来报告，这实在难以让发行商满意。

就内心想法而言，游戏设计团队成员（游戏邦注：尤其是艺术师和动画师）往往偏好先制作低质量的最终资产，随后再将其替换。然而，制作人通常不喜欢返工和重新制作。于是，放弃使用占位符影响到最终产品的质量，还让设计进程放缓。

以下情况经常在设计过程中出现：设计师想要看到游戏的资产，比如3D模型、动画和游戏玩法机制等。如果要看到完整的资产，他需要等待1周的时间，但是看到占位符只需要等待数个小时的时间。如果不使用占位符，万一他最终看到的东西不像自己想象的那样有趣，那么浪费的是1周的时间。

为避免上述情况的发生，团队往往会执行漫长的审核过程，意图找出最佳的想法。在实际操作中，审核的效果并不明显。

那么现在，因为不能用占位符来尝试想法以继续开发进程，设计师必须等待1周时间来获得最终资产，而这样获得的资产的趣味性往往比不上利用占位符试验找到的资产。

不利用占位符来开展设计工作，在许多方面都会浪费时间。与由简单BSP组成的关卡相比，由上百个复杂3D模型组成的关卡的加载和测试时间都会变长。开发者在修改时也需要更多的时间，因为组成模型的是数百块碎片而不是几个简单的形状。

最后，任务设计师新会常会浪费时间来完成内部装饰和光照，事实上他们应当专注于制作出有趣的游戏玩法。原本任务设计师制作有趣环境只需要些许简单的纹理和部分占位符3D对象即可。

侧重使用占位符的游戏设计过程需要许多人的配合。它需要工作室能够在设计团队制作“最终”关卡时组织美工完成其他工作。

它需要众人相信上级（游戏邦注：比如外部发行商或内部的工作室主管）不会过于肤浅，能够从布满占位符的丑陋界面中看到游戏的趣味性。如果你无法做到上述要求，那么可以通过外部人员的测试来证明游戏的“趣味性”。

6、让故事控制游戏设计

在电视和电影行业中，作家编写剧本后，将其提交给制作人。随后，团队便可以用此剧本作为纲领，向观众讲述其中的故事。如果游戏的主要目标是向玩家讲述故事，那么这个过程同样可以用于电子游戏制作中。

《最终幻想》等许多JRPG和冒险游戏仅凭借出众的故事便获得了成功。但是，如果游戏的主要目标是让玩家感受到高互动性体验，那么就不能使用上述方法。

如果你的游戏类似于《光晕》、《使命召唤》或《战争之神》，那就应当围绕游戏玩法来构建剧本。关卡设计、玩法机制和节奏是游戏中最重要的因素。如果这些内容不完善，再多的故事讲述也无法提升质量。这并不是说游戏故事不重要，而是说作者应当能够灵活根据游戏呈现给玩家的互动体验来改变故事。

让故事凌驾于游戏设计的其他元素之上会带来许多麻烦。2003年游戏《黑客帝国：进入矩阵》便是典型案例。

游戏的情节及其过场动画模仿了电影《黑客帝国2：重装上阵》，该电影的制作者在游戏设计过程中占据重要地位。

结果就是，游戏单纯从故事的角度来设计关卡，从而忽略了玩法。此外，开发团队不得不制作3种不同的游戏类型（游戏邦注：汽车驾驶、徒步行走和驾驶气垫船），仅仅因为故事的需要。

我曾经参与过一个第三人称动作游戏项目的制作，我们的剧本由某个好莱坞编剧撰写。尽管这是个有趣的故事，但它与许多已经设计完成的游戏玩法元素相冲突。剧本呈现的是角色在狭小的环境内与众多敌人作战，而我们已经设立的游戏机制是角色在空旷的地点与敌人展开大型枪战。

在完成的游戏设计中，玩家有个伙伴，可以向他下达命令，但是剧本要求玩家在游戏后半部分的大部分时间里需要独自作战，这严重破坏了游戏的学习曲线。项目的取消很大程度应该归咎于设计团队被迫遵循这个好莱坞剧本。

动作游戏故事的编写工作应当由专门的游戏文案负责。游戏文案必须是那些专门为游戏编撰故事的人，至少其本人就该是个游戏玩家。游戏文案应当是设计团队中的全职岗位，而且要理解自己的故事需要根据设计重新修改。

如果设计团队决定将飞机场关卡放在游戏开端会更有意义，而不是放在游戏末尾，那么文案就应当可以从容应对这种情况。为游戏编写故事与编写电影剧本并不相同。所以，让好莱坞编剧来编写游戏故事并非正确的选择。

7、未向设计师提供足够的工具

许多人辩解称，应当通过游戏工具来限制设计师。设计师接触到的功能和变量越多，就越可能犯错误。

程序员最讨厌的事情莫过于解除经验不足的设计师所编写代码中的漏洞。此外，通常情况下设计师并没有接受编程方面的训练，所以他们尝试去做本该由程序员完成的事情无异于浪费时间。

这种观点确实有一定的正确性，但还必须从设计师工作效率的角度来看待问题。如果设计师能够不间断地制作关卡，那么通常情况下他能够更加专注且效率更高。

如果设计师每次添加新功能都需要与程序员交流，那么他的节奏就会被破坏。他无法专注于设计一个关卡，只能先完成自己的工作，然后将碰到的问题交由程序员解决。

就个人担任关卡设计师的经验而言，我亲身体会了上述情况对效率的影响。当我无法在关卡设计中继续进展下去时，我就会频繁吃零食，花更多的时间与同事闲聊，等待着下班时间的到来。当我能够不间断地工作时，在下班时间到来前我几乎未曾离开自己的座位。

我觉得，在设计师能够做和不能做的事情间，团队应当找到平衡点。设计和编程团队制定严格的代码标准并强制执行，这样便能减少问题颇多的代码出现。

要为玩家制作出最好的系统，设计和编程间应当经常交流，而不是完全剥夺设计师编程的权利。

8、制作一开始就乏味的内容

在制作《马里奥64》中，开发者花了数个月的时间改善马里奥在简单花园环境下移动的感觉。他们想要确保当将该主题转变为3D游戏时，角色的基本动作依然足够有趣，能够对玩家产生吸引力。

与《马里奥64》类似，许多绝妙游戏的基本元素相当有趣。即便没有过场动画和剧情，《合金装备2》依然很有趣。

《暗黑破坏神》中鼠标点击式的基本战斗形式的趣味性便足以吸引新手玩家，即便他们刚进入游戏时还没有发现其中的深度RPG元素。

不幸的是，许多项目还未创造出趣味内容变匆忙进入游戏制作阶段。

制作出有趣的原型或矢量图能够让项目获得显著提升。它能够充当指引游戏制作的灯塔。当项目制作持续数个月后，团队可能已经对游戏甚为熟悉，似乎没有东西能够再让他们感受到乐趣，这是设计师便可以利用原型来回想起首次玩这款游戏时会产生的感觉。

另一方面，没有趣味内容便进入制作阶段会影响到团队的斗志。我曾经参与过一个带着无趣原型进入制作阶段的项目，团队希望在执行和平衡所有游戏内容后，最终的产品能够显得有趣。数个月过去后，尽管以此原型为基础萌生出许多想法，但并不显得有趣。

设计团队之外的多数人都不明白我们究竟在制作什么游戏，而设计团队中的成员也无法达成统一的愿景。因为制作开始时就没有有趣的内容，所以成员并不确信项目主管选择的方向是否正确。

有趣的是，许多预算不高的独立项目比某些庞大预算的项目拥有更多趣味性。这表明，趣味性并不一定需要大量的资金投入。

9.没有保持设计文件的更新

你曾经有多少次听别人说“不要阅读那些文件，它们都没有更新”呢？如果你从未听到过这句话，要么你并非身处游戏行业，要么你就是非常幸运。在开发团队中，存在过时设计文件是个很普遍的现象。

这种情况看似不可避免。游戏的功能并不会永远保持与设计文件上相同，它们在游戏开发过程中会有多次改变。保持设计文件的更新确实很麻烦。尽管这需要耗费大量的时间，但不这么做可能带来相当严重的问题。

如果设计文件未保持更新，人们就会失去对它的信任。他们会认为，原设计文件中的任何内容都是无效的。当他们遇到问题时，他们也不愿意将其作为参考对象。

反之，他们更偏好直接询问设计团队中的其他成员。如果设计师意识到他们的文件没有人阅读，他们就更没有动力维护和更新。最终，“设计文件毫无价值”就成了整个团队默认的想法。

通过言语表达来传输想法存在一定的内在问题。设计师向程序员描述功能时，可能无法与原先的想法完全保持一致。

随后，程序员会根据自己对设计师描述的记忆来执行功能。当首席设计师发现执行的功能与之前讨论的结果不同时，冲突便会产生。

另一个问题在于信息的分裂性，只有1到2个人知道所有设计内容。我曾经在某个项目已经制作4个月时进入设计团队，我需要游戏中所包含关卡及其顺序的列表。

获得这个信息的唯一方法是向首席设计师发邮件索取，随后他将自己桌面上的一个电子表回复给我，而这却是个完全没有更新过的文件。

保持设计文件更新并非易事，但是可以利用某些技术来让这个过程变得更加容易。我曾经就职的某个公司使用了一个系统，如果文件为修改时间超过两周，那么系统会自动为该文件添加“未更新”标签。未更新文件无法打开，直到设计师将其标记为已更新状态。这种系统确实有助于保持设计师更新文件的意识。

10、未将外部测试纳入开发过程

越来越多的公司意识到定期测试对设计进程的价值。比如，Valve在《半条命2》和《传送门》制作过程中融入了严格的游戏测试。育碧对游戏测试的重视也为行业所称道。

不幸的是，这种做法的普及度还不够。许多开发者将其视为无关紧要的事情，有些开发者甚至认为它对游戏开发有害。经验丰富的游戏设计师会将测试视为自己最有价值的工具。

如果游戏的目标玩家并非传统的“硬核”玩家，比如游戏主要针对休闲玩家或儿童，那么游戏测试便是必不可少的过程。设计师必须遗忘自己十多年积累下来的游戏经验，才能够以休闲玩家的眼光来看待游戏。这根本不可能做到。

即便你认为自己已经制作出了最直观的游戏界面，当你让40多岁的人来体验游戏时，仍然会为自己想当然的次数感到震惊。

如果你正在制作的是针对儿童的游戏，那么要做好进行更大调整的准备，6岁大的孩子只能理解那些最为直观的概念。他们的大脑还未被充分开发，可能无法理解我们认为很容易的内容。

即便游戏针对硬核用户设计，测试也相当重要。经历过整个游戏制作过程，每个游戏设计师都能够精通掌握他正在开发的游戏。

让新玩家觉得充满挑战的内容，设计师可能会觉得乏味无趣。他会逐渐开始制作那些自己感觉充满挑战的内容，而这些内容对玩家来说就显得过于困难。

如果开发团队直到测试版发布时才开始进行外部测试，那么这些困难的内容可能就会残留在游戏中。

反之，如果将测试纳入设计过程，那么设计团队就能够精心构建难度等级逐渐攀升直至游戏高潮的体验。

我曾经与不喜欢在开发阶段进行测试的设计师合作，他们认为开发阶段过分依赖测试无异于根据目标用户品位来制作电影，项目的艺术性会受到影响。这种观念只考虑到了游戏的趣味因素，忽略了用户的理解层面。

如果用户因为无法理解游戏而卡在首个关卡，那会带来很严重的问题。所以，最好能够尽早知道设计成果能否被玩家理解。

结论

如果你是个游戏设计师，我猜想你势必会遇到以上某些设计过程错误。我曾经遇到过资金和人才均充足但项目依然失败的情况，主要原因就在于设计过程不佳。

最重要的是，这篇文章中提到的许多重要错误会很自然的产生，比如同行评论和保持文件更新的问题，这就需要团队严格的自律和强制性规范。

当游戏开发由能够认识和实践优秀设计过程的领导来管理时，才能够制作出真正令人惊叹的内容。

游戏邦注：本文发稿于2009年5月7日，所涉时间、事件和数据均以此为准。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

10 Game Design Process Pitfalls

Ian Fisch

If you look at which games succeed and fail critically, you will notice the outcome is generally not due to a great mechanic or a new idea, but from competent execution from the moment of boot-up to the end credits.

Countless games such as Spider-Man 2, Stranglehold, and Assassin’s Creed present the player with innovative concepts but fall apart when it comes to filling up the 10-15 hours of gameplay.

On the other hand, you have games such as Call of Duty 4, which brings almost nothing new to the table, but excels greatly when it comes to pacing and level structure — keeping the player hooked throughout the entire experience. Even games considered to be innovative — Portal or World of Goo — would not have had their success were it not for superb execution.

I’ve worked with a number of teams that start with a very nice concept but run into problems when it comes to translating it into a compelling video game experience. I’ve noticed that certain practices tend to crop up that hamper a developer’s ability to get the most from its design team.

I’ve organized these into the 10 “design process pitfalls” below.

1. Not Structuring Time For Game Playing

This first pitfall seems trivial, but can actually have a large impact on the quality and efficiency of the design process. Ideally pre-production would include a set amount of time for everyone on the design team to play games in the genre they are about to take a shot at.

I’ve never seen this happen in a structured way. “Play time” can be hard for some producers to wrap their heads around, and the idea of scheduling a week or more of “research” for a five-person team can seem like a rather expensive play session.

Instead, designers are expected to already have a strong knowledge of what’s out there. Unfortunately not all game designers have enough free time to play every game out there. Generally, the older the game designer is, the less free time he’ll have. Furthermore, the games a designer chooses to play in his free time may not line up with the games he should play for development purposes. Many mediocre games, for example, contain interesting ideas and are valuable as learning tools.

Devoting time to playing other games in your genre can lead to a better product and save a tremendous amount of time. I worked on a project where a designer happened to play a game in the genre we were working in and “discovered” a better player navigation system than the one we had already spent months on.

On another project, someone “discovered” a third-person cover mechanic implemented in an unpopular game that was exactly like the one we argued about including. Weeks of debate could have been saved had we played this game and had known that the mechanic wasn’t as fun as it seemed on paper.

When the designers all have experience playing the relevant games, their ability to express ideas to one another is greatly enhanced. One designer can say to another “We could have the lock-on system from Metroid Prime, except toggleable by pushing in the right thumb stick”.

If the other designer has played Metroid Prime, he immediately understands what the one designer is thinking. The lock-on system does not need to be explained to him. Not only that, but he knows how it feels in his hands – something that cannot be conveyed with words.

I once worked with a lead who deemed the Gears of War grenade throwing system too complex when explained to him on paper. Once he finally sat down and tried it himself, he saw that it clicked and approved its inclusion.

It’s important that the lead designer himself takes part in the research along side the rest of the design team. If the lead designer deems it “lesser important” the rest of the team is likely to follow suit. Furthermore since the lead is usually the main decision-maker, it’s important that he is able to speak from the same lexicon as the other designers.

Implementing a period of structured game playing may require some persuasion. A producer will be more likely to get on board if there are tangible results — for example, each designer could be required to present notes to the lead at the end of every day.

2. Placing Too Much Importance On Paper Designs

Students of mathematics may know that one of the fundamental ideas of Chaos Theory is that some systems, such as the weather, are so complex that it is impossible to make accurate predictions of their behavior. There are too many interacting variables, any one of which could lead to a major change. I feel that games are the same way.

A designer can try to imagine how a level is going to play in his head, but any of the hundreds of interacting elements — the environment, the controls, the game mechanics, the physics, or the AI can each make a huge impact on the overall fun. This is one reason that I don’t put too much weight on paper designs.

The second reason is that, in my experience, the best ideas are discovered through experiments and happy accidents. I’ll often be building a level based on a paper design when I notice that when the AI interacts with the environment in a certain way, I get a really cool little experience.

I will then modify the level to make this something that most players will encounter. This form of discovering fun through interacting with the game’s systems only works when the designer has the freedom to modify his level from the original paper design.

Unfortunately, designers don’t always have this freedom. I’ve worked on teams where designers were given equal time to create a level on paper as to create it in 3D. Once a paper design was finished, it was presented at a big meeting, analyzed and approved.

If a designer wanted to make a large change during the 3D phase, this was treated as correcting an error he had made in the paper process. The paper design had to be reedited and another approval was needed from the department leads.

Designers were expected to get it right the first time. The end result of this process was environments that didn’t fit with the game. For example, some environments featured enemies that the player could see and pick off from a mile away. Others featured enemies that the player couldn’t see until they were two feet from his face.

3. Peer Review Not Taken Seriously

If you’ve worked at a game company you’ve probably heard the phrase “more people need to play the game” tossed about at a meeting or two.

These calls are generally made to the artists and programmers, yet I notice that designers have a habit of not playing each other’s work. I’ve definitely fallen into the trap of being so focused on my own work that I neglect to play the work of others.

Regularly playing other designers’ levels leads to cross-pollination of ideas and generally makes a better game. Often I’ve seen one designer play another’s level, think an element is cool and then include it in his own level with improvements.

A healthy sense of competition is created in the team where each tries to take another’s idea and one-up them. By playing levels other than their own, designers also gain a better feel for how the game will play as a whole rather than just seeing it through the perspective of his personal chunk.

Peer review is something that will fall apart unless it is strictly enforced by a lead. I recommend that a team have weekly scheduled peer review sessions where all designers are told to put down their own work and spend the afternoon reviewing the work of his teammates.

The peer review day shouldn’t be too close to a deadline. For instance if milestones are usually on Fridays, schedule your peer reviews for Tuesday afternoon.

4. Decision-Maker Picked For His Producer Skills

There are many different roles on a design team and many different types of designers. It’s been my experience that the designers promoted to the role of lead have been almost exclusively the types that gravitate toward the administrative tasks — such as creating the spreadsheet that dictates which enemy type will be included in which levels.

Those that gravitate toward content creation usually stay there. A designer who excels at making levels will not be rewarded with a promotion — and thus will not have the opportunity to make the big game design decisions. While both types of designers are equally important, this imbalance can be harmful to a project.

The reasons for this imbalance are obvious. Being a lead requires a sense of responsibility for people’s work other than your own. It requires good people skills. It is difficult to demonstrate either when your head is in an editor eight hours a day.

It is easy to demonstrate these, on the other hand, when you are handling tasks that involve the entire team — for example if you are responsible for making sure design requests find their way to programming in a timely and organized manner.

Unfortunately, it can be bad for a project if the person making the design decisions has never made compelling content himself. He is less likely to choose wisely when it comes time to deciding what ideas get included in the game and what get left on the floor.

Worse, having spent little time in the trenches, he will not have first-hand knowledge of what processes lead to good content creation. For instance he may not place importance on peer review since he’s never benefited from it in his own work.

Picking a good lead is difficult, and a team is lucky if it has a lead who is a responsible leader and has a good sense of what makes good content. Since these are two different skill sets, I recommend that they not necessarily fall on the same person.

The lead designer could devote his time to maintaining design processes, reviewing the other designers’ work, and hopefully getting some hands-on time with the tool set. Meanwhile the administrative tasks, such as creating task lists and weekly reports, would be handled by a producer that works closely with the design department.

5. Not Taking Advantage Of Placeholders

Placeholder assets and code are used a lot in this industry, yet placeholder use often greatly diminishes once production starts. It is understandable. If a developer is working for a publisher, it’s very important to show progress. Going from a nice shiny vertical slice to builds filled with jerky animations and flat-shaded backgrounds can look like a step backward.

Internally, team members, particularly artists and animators, generally prefer working on final assets than low-quality ones that will have to be replaced later. Producers generally prefer something done once rather than twice. Unfortunately under-use of placeholders reduces final game quality and slows down the design process.

The basic scenario goes like this: a designer wants to see an asset in game — be it a 3D model, an animation, a gameplay mechanic, etc. Rather than wait a few hours for a placeholder, he must wait a week for the finished asset. If what he receives isn’t as fun as he had imagined, that will be a week of work wasted.

To avoid this from happening, long approval processes are often implemented with the intention of weeding out all but the best ideas. In practice the approval process can shear off all but the least risky elements of the idea until it’s lost its originality.

So now instead of trying out an idea with a placeholder and moving on, the designer must wait a week to receive a final asset that is often far less interesting than what he would have discovered through experimentation with placeholders.

Working without placeholders wastes time in many ways. Levels made up of hundreds of 3D meshes take longer to load and test than those that are made of simple BSPs. They take much longer to modify because they’re made of 100′s of pieces instead of a few simple shapes.

Finally less experienced mission designers will waste time showing off their interior decoration and lighting skills when they should be focusing on making fun gameplay. Some flat-shaded textures, a pool of placeholder 3D objects, and a watchful eye of an artist to make sure things are architecturally sound should be all a mission designer needs to make fun environments.

A placeholder-heavy game design process requires a lot from a lot of people. It requires a studio that can shuffle artists to other duties while the design team settles on what they want for the “final” level.

It requires faith that the higher-ups (be they an external publisher or an internal studio head) are not as superficial and can appreciate the value of a fun, if ugly, level filled with placeholders. If you don’t have this faith, outside playtesting can be used to quantify the “fun” in lieu of showing polished graphics.

6. Allowing The Story To Control The Game Design

In television and film a writer writes a script and hands it off to a producer. The crew then uses the script as a map for telling a story to the viewer. This process can work for video games so long as the main purpose of the game is to tell a story to the player.

Games such as those in the Final Fantasy series as well as many JRPGs and adventure games can succeed on a great story alone. If the main purpose of your game is put your player into the middle of a highly interactive experience, than this method is inappropriate.

If your game is Halo, Call of Duty, or God of War, the script should be shaped around the gameplay and not the other way around. Things such as level design, play mechanics, and pacing are the most important factors. If these things aren’t solid, no amount of storytelling can pick up the slack. This is not to say story isn’t important, but rather the writer should be flexible enough to change the story based on what presents the player with the most compelling interactive experience.

Giving the story priority over other elements of game design can lead to trouble. A classic example is the 2003 title Enter the Matrix.

The plot of the game and its live-action cutscenes were made to weave in and out of the movie The Matrix Reloaded; the movie’s creators were heavily involved.

The result was levels that made sense from a story perspective but had no purpose from a gameplay one. Furthermore the dev team was stretched thin creating three different game types — in car, on foot, and in hovercraft — because the story demanded it.

I once worked on a third-person action project with a script that was handed down to us by a Hollywood writer. While an interesting story, it conflicted with a lot of the gameplay elements that had been designed. The script called for levels in intimate locations with a handful of enemies when the game mechanics were set up for huge firefights large cover-filled locations.

The game had been designed with a partner in mind that the player could give orders to, but the script demanded that the player should be alone for a large part of the game’s second half — destroying the learning curve. The cancellation of the project was largely due to the design team being forced to follow the Hollywood script.

The story of an action game should be the responsibility of a game writer. A game writer is someone who’s written for games before or at least is a gamer himself. A game writer will be with the team full time and understand why his story needs to be reworked continually.

He won’t get flustered if the design team decides the airport level makes more sense in the beginning of the game rather than in the end. Writing for games is not the same as writing for films. Simply cutting a Hollywood man a check to deliver a script is not the way to go.

7. Not Giving Designers Enough Tools

There are many sound arguments for limiting what a designer is capable of doing with a game’s tool set. The more functions and variables a designer has access to, the more he can do wrong.

There’s nothing that a programmer dislikes more than having to debug poorly organized designer code. Furthermore, designers aren’t trained to program so, the logic goes, they’ll waste time trying to do what a programmer was trained to do.

These arguments make sense, but the problem must also be looked at from the designer productivity side. If a designer can work on a level uninterrupted, he is generally more focused and more productive.

If a designer has to petition a programmer every time he needs a new functionality, his rhythm is destroyed. Instead of being able to focus on a single level, he has to slowly pick away at all the levels on his plate until he runs into walls that only programmers can overcome.

I can speak from personal experience about the difference in my own productivity when I was a level designer. On days when I wasn’t able to make much progress in my levels, I took more frequent trips to the snack machine, spent more time chatting with coworkers and generally had one eye on the clock. On days when I could work uninterrupted, I wouldn’t leave my chair until well past quitting time.

I think a healthy balance should be struck between what a designer can and can’t do. Messy designer code can be alleviated by having strict coding standards that are created by the design and programming team and enforced.

There needs to be a dialogue between programming in design in order to create the best system for everyone, rather than just assuming that every designer is a bull in a china shop.

8. Entering Production Without Something Fun

In creating Mario 64, the creators spent months working on the feel of moving Mario around a simple garden environment. They wanted to make sure that this basic act was fun enough to keep a player engaged as he adjusted to the concept of 3D gaming.

Like Mario 64, many great games are still enjoyable when stripped to their base elements. Metal Gear Solid 2 is fun even without the cinematics and set pieces, as Metal Gear Solid 2: Substance proves with its VR Missions.

Even the basic one-mouse-button combat of Diablo is fun enough to engage new players before they discover the deeper RPG elements to the game.

Unfortunately, many projects go into full-steam-ahead production mode without having created anything that’s actually fun.

Having a prototype or vertical slice that’s fun can be a great boon for a project. It can act as a guiding light. When the project is months into production and the team is so accustomed to the game that nothing seems fun anymore, the designers can boot up that prototype and remember the feelings they had when first playing it.

On the other hand, going into production without something fun can be horrible for morale. I worked on a project that entered production with a vertical slice that was not fun — but with the hope that the actual game would be fun once everything was implemented and balanced. As the months dragged on, ideas were piled on top of that vertical slice without ever achieving anything fun.

Most people outside of the design team did not have a clear idea of what game we were making, and people inside the design team were unable to form a unified vision. Since there had never been anything fun to begin with, there was no faith that the course chosen by the game’s director was the correct one.

It’s interesting how many indie projects created on a shoestring budget have more raw fun than some of the hulking multimillion-dollar projects out there. This proves that fun doesn’t have to be expensive. Starting without something fun can be.

9. Not Keeping Design Documentation Up-To-Date

How many times have you heard someone say, “Don’t read those. They’re not up-to-date”? If the answer is zero, you’re either not in the games industry or you’re very lucky. Out-of-date design documents are a common fixture in development teams.

It may seem like an unavoidable failing. Features almost never ship exactly as they were designed on paper. Rather they change many times after their original implementation. Keeping the documentation in step with the changes can be a real chore. Time-consuming as it may be, the consequences for not doing so are fairly serious.

When documentation is not kept up-to-date, people lose faith in it. They assume that whatever is in the source control isn’t valid. They don’t bother using it as a reference when they have a question.

Rather they will prefer to ask a member of the design team directly. Once the designers realize that their documentation isn’t being read, they will put even less energy into maintaining it. Eventually the team will come to the clichéd conclusion that “design documents are worthless”.

There are inherent problems with transmitting ideas through word of mouth. A designer may give a programmer a description of the feature that isn’t exactly what was originally agreed upon.

The programmer will then implement that feature based on what he remembers of the designer’s description. This will cause conflicts when the lead designer looks at an implemented feature that’s different from what was discussed.

Another issue is that information becomes fragmented — with only one or two people knowing how everything is supposed to work. I was four months into the production phase of a project when I needed a list of which levels were to be included in the game and their order.

The only method of getting this info was to email the design lead who then emailed me a spreadsheet from his desktop. The two level sequence documents in the source control were out of date.

Keeping design documents up to date isn’t easy, but technology can help. I worked for a company that had a system for automatically giving a document an “out-of-date” tag if two weeks had passed since the document had last been modified. Out-of-date documents couldn’t be opened until a designer marked them as current. It was a success, for the most part.

10. Not Making Outside Playtests Part Of The Process

More and more companies are realizing the value of making regular playtesting part of the design process. Valve, for example, is well known for the rigorous playtesting it used in the creation of Half-Life 2 and Portal. Ubisoft is also well known for placing a high priority on playtests.

Unfortunately this practice is not as widespread as it should be. A lot of developers see it as unimportant, and some as downright harmful. An experienced game designer should see playtests as one of the most valuable tools in his tool belt.

If the intended player is not within the traditional “hardcore” demographic — casual gamers or children, for example — then playtesting is indispensable. Attempting to see a game through the eyes of a casual player requires the designer to block out 15+ years of accumulated game-playing knowledge. In other words, it’s impossible.

Even if you think you’ve made the most straightforward interface possible, you’ll be amazed how much you take for granted the first time you hand the controller over to a 40 year old mother.

If you’re making a children’s game, then prepare for an even bigger adjustment — a six year old will have trouble with anything more than the most straightforward concepts. Their brains just aren’t developed enough to comprehend things we understand naturally.

Even if designing for a hardcore audience, playtesting is still incredibly important. Over the course of production every game designer will become a master of the game he’s developing.

Things that would challenge a new player will become boring to the designer. He’ll start to create setups that he can complete with a little bit of finesse but are way too hard to be included in the shipped game.

If the team doesn’t start outside playtesting until beta, these bits will have to be smoothed over hastily. Often the result is a game whose changes in difficulty level doesn’t seem to follow any plan.

If playtesting is part of the design process throughout, on the other hand, the design team can carefully craft an experience with a difficulty level that steadily climbs until the game’s climax.

I’ve worked with designers that prefer not to do playtests during development because, they claim, relying too much on playtests during development is akin to making a movie through focus groups — it will water down the artistic vision. This argument only considers a game’s fun factor and ignores the comprehension side.

If the designer doesn’t care if Billy thought the game was fun or not, don’t ask him. If he can’t get past the first level because he can’t get his head around the dual analog stick aiming system, then we have a problem. And it’s better to know that sooner than later.

Conclusion

If you work as a game designer, I imagine you’ve come across some, if not all, of these design process pitfalls. I’ve been in situations where the money was there and the talent was there, but the project still failed to come together because of bad design processes.

The most important thing to take away is that a lot of the important elements mentioned in this article, such as peer review and keeping documents up to date, do happen come naturally — they require discipline and enforcement.

When the game development is being managed by individuals with the experience necessary to recognize and practice good design processes, there is the potential for truly amazing content to be created. (Source: Gamasutra)