作者：Mike Stout

在游戏开发中，我们常常发现一些在纸上看起来很不错的设计而在实际开发中却往往不如所愿。反而多显“肤浅”或“平淡无奇”。游戏测试者，发行商或者其他与之相关人员都认为它们应该“更多样化”或者“更具有层次感”。

每一位游戏设计者或许都曾经听到过这样的抱怨。在我开发每一款游戏时都遇到过这些问题，而我也想出了三个方法能够帮助我解决这些问题。

如果玩家抱怨游戏缺乏多样性，那么你便可以添加更多游戏机制，看看这么做是否能让游戏更加“丰富”。

*需要警惕的关键词：这款游戏的“玩法过于单一”，具有“反复性”，“需要更多的创造性”。

*这类反馈信息通常是描述游戏的总体情况。玩家认为他们看到的内容缺乏变化。

如果玩家认为单一的游戏机制太过平淡无奇且没有价值性，那么你便可以通过提供给他们更多的反馈，奖励，更好的游戏效果，音效，更有特性且更酷的画面或者其它附加修饰物等而进一步完善游戏机制。在未改变游戏机制的前提下完善游戏效果，将能够更合理地解决玩家所抱怨的问题。

*需要警惕的关键词：现存的游戏机制很“无聊”，具有“反复性”，“没有任何乐趣”。

*反馈信息与完善效果一起用于描述一个单一的游戏机制，但是这一描述通常太过模糊且过于感情化。

如果玩家认为单一的游戏机制“不能给予足够的挑战空间”，或者他们感觉“这一机制刚开始很有趣但是很快就乏味了”。那么你便需要想办法让这个机制更有深度。

*需要警惕的关键词：：这款游戏“太肤浅”，“太简单”或者“太平淡无奇”。玩家经常会说一款游戏在一开始很有趣，但是很快就开始无止尽地重复变得无聊了。

*在接收到如此反馈后，你可以完善游戏效果以帮助玩家更好地忍受这一机制，但是这么做的话你的机制也就只能停留在此了。而如果你的完善效果失灵了，那么你就必须卷起袖子，投入更多的精力去让你的游戏机制更具有深度。

我在不同文章里都详细分析了这些内容，而在本文中我们将着重分析这三个中最棘手的：深度问题。我想通过这篇文章向你们介绍我使用过的一些方法，并帮你们找出游戏机制缺少深度的原因。除此之外，我还希望借此传授一些有用的技巧，帮助你们更好地解决“肤浅的”游戏机制问题。

相关定义

在研究深度问题之前，我想要解释几个我将在文中用到的术语：

游戏机制：我所说的“游戏机制”是指电子游戏中一些主要的游戏设置。以经典游戏《塞尔达传说:与往昔世界的连接》中的一些游戏机制为例：刀剑搏斗，推动砖块，投掷回飞棒，游泳，基于按钮的益智关卡，躲避危险，使用特殊武器等等。

挑战：挑战是任何游戏脚本中都会出现的一环，能够以此考验玩家在特定游戏机制下的技术。如《塞尔达》地牢中的单人房，《拉捷特与克拉克》的钢索路段以及《光晕》中的战斗等。

“深度”意味着什么？

Dictionary.com将“深度”定义为：“一些产品所涵括的知识，情报，学识，洞察力，感情等而被当成一种科技论文，论据或者艺术品等等。”这么看来深度算是一种针对于个人而言的术语了，而且不同人之间也存在着差异性。

对我而言，深度则是一个有效点，当玩家能够重复展现精湛技术以应对游戏机制时，深度便展露出来了。挑战不能总是一层不变而让玩家感到厌烦，同时它也不能频繁改变使得玩家不能很好地发挥自己的技术。

显然，在我们的很多机制中都能发现“深度”的存在，但是我们却经常不知道怎么获取它。

根据我的经验，为了让游戏机制更具有深度，我们需要做到两点：

首先应该设定明确的目标，这样玩家才知道自己怎么做才能取得成功。如果玩家感到困惑，那么他们将认为这一游戏机制缺乏深度。

其次，作为游戏设计者你需要拥有各种有意义的技能，以此为玩家创作出更棒的挑战，并帮助玩家精通你的游戏。

目标

当玩家进入一个游戏时，他必须清楚游戏目标是什么。换句话说，他必须能够清楚地勾勒出目标完成时的状态。

如果你想要创造一个具有深度的游戏机制，那么你就必须明确游戏目标。就像我之前提到的，如果玩家不清楚目标完成时的状态是怎样的，那么他将沦落至漫无目的盲目前行的状态而不能完美地展现自己的技能。

如上图所示，在《塞尔达传说：时空之链》中，玩家看到这种门时，就会知道应该去找一把特殊的过关钥匙“Boss Key”。这种门虽然很简单，但确是一个很好的目标。玩家一看到门就知道要先去找钥匙，然后再回到这里。

深度技能

深度技能指的是玩家在游戏开始到结束这期间所有的行为。换句话说，一旦玩家意识到了挑战目标，那么这种技能便开始发挥作用。

我所说的有深度技能并没有特别强调某些东西。“深度”显然是这个定义的重要组成部分，就像如果玩家的技能太过平凡，将不会帮助你创造出具有深度的游戏机制。而这时候玩家就必须完成一个最简单的任务，如查看任务列表等。

关于太过平凡的技能的一个经典例子便是“从A点移动到B点。”这种基本的移动方法就像“按住控制器按钮而获胜”一样。这很基础，但是却太简单，没有任何深度。

进一步来看，当你真正去思考这个问题，当你说“从A点移动到B点”，你其实是在表达一种挑战目标而非叙述获得这一目标所需的游戏技能。

这听起来确实存在差异性，但是事实上这种差异却非常重要。当你在思考如何设计游戏机制时你可以将这种差异融合进去，从而帮助你看到一些更深层次的问题。

关于深度技能的经验和教训

当我参与《拉捷特与克拉克》的制作时，我还是个没有太多经验的设计者，而我需要将“牵引波束”引入游戏中的2个关卡。牵引波束是一种游戏机制，它能让拉捷特快速移动一个标有特殊牵引波束标志的大型砖块。这种做法就像是对《塞尔达传说》中推动砖块挑战的夸张诠释。

想出教程设置并不难。玩家只需要从A点移动砖块到B点便能够跳上去而逃走了。但是我所面临的问题就在于，当我尝试着去想出更多有趣的挑战时，我却绕进了一个死角。在我看起来，从一个地方将东西带到另一个地方是一个非常基本的技能。而我除了提供教程，便无法提供更多不一样且更有趣的挑战给玩家了。

那时候我并未真正理解深度技能与基本技能之间的重要差别。我也不知道明确的目标有何重要性。因为缺少经验，我决定通过添加更多功能而让游戏机制更加有深度。如果你在为此哀怨，那么恭喜你，因为我在写这篇文章的时候也正在哀怨。

除了移动砖块，我认为让玩家区域夺取并控制一个乖巧的机器人将会很有趣。玩家便可以通过按钮去控制机器人开门。但是这并不是我想要的效果，所以这种机制看来还是很肤浅。

所以我决定继续探索并添加更多功能。

我在游戏中加入了一些炸弹，你可以用来炸毁通道，同时你还可以使用一些低能弹弓在目标周围抛射弹药。

我决定赋予砖块阻挡镭射光束的能力，你可以利用它们挡住那些光束扫射。

我在一些特别的砖块里添加了爆炸式火箭，以此能够炸毁一些特定的关口。

最后我设置让一些砖块滑进地上的凹槽里。这时玩家就需要去思考如何做才能按照特定顺序去整顿这些砖块，虽然这些砖块将被安置在同一个凹槽里，但是它们却拥有不同的进入方法。

落到最后，我不但被众多程序员所讨厌，而且牵引波束游戏机制也遭到了牵连，因为玩家认为这种机制太困难，他们掌控不了。从游戏测试中我们知道玩家对此感到疑惑，所以我们便不得不从牵引波束机制的工作中抽出一般时间用于教程设置，让玩家能够更好地理解自己需要做些什么。

回头想想，我顿时豁然开朗了，为何这些游戏机制缺少足够的深度：因为我总是添加新的目标，但是却遗漏了那些有深度的技能。

我将在下文探究这一话题，而我之所以会在这里提及它是因为比起目标，深度技能更能够帮助创造一种深度感。

牵引波束机制着实给我上了一堂意义深刻的课：很多游戏机制之所以缺少足够的深度，是因为它们都拥有太多目标，但是却缺少足够的深度技能。

声明

如果我能回到过去，我是否能够制作出更有深度的牵引波束机制？好吧，首先我将会在没一个挑战环境中设定一个“活动声明”。

活动声明只有简短的几句话，通过陈述挑战目标和玩家必须使用的特殊任务以描述游戏挑战。

举个例子来说，活动声明中的一个简单平台挑战可以被描述为：“我希望玩家能够跳到平台上。”在这里“跳”便是一个深度技能，而“平台”则是一个目标。

而较为复杂的活动声明则是：“我希望玩家能够双直跳并滑翔到平台上”或者“我希望玩家能够调节跳跃速度以躲避喷射的火球并安全着陆在平台上”。

上述的活动声明都同时包含了目标和深度技能。如果你漏掉了其中一个因素将会怎样？我们已经证明了如果游戏挑战中没有明确的目标，那么将缺少深度，同时如果游戏机制包含太多目标但是却缺少深度技能，那么也会显得肤浅。

*以下的活动声明与我之前设计的牵引波束挑战类似：

“我希望玩家能够从起点将听话的机器人移送到地上的按钮那里。”

“我希望玩家能够将炸弹从起点移至关口前。”

“我希望玩家能够从起点开始移动砖块，以此阻挡镭射光束的袭击。”

“我希望玩家能够将装有爆炸火箭的砖块移至地面按钮处。”

你会发现，上述的声明都有明确的目标，但是却缺少深度技能。事实上，当你仔细去观察这些声明时，你将会发现这些目标都很类似，而且也并无多大乐趣。

每一个声明都只是在说“从A点移动到B点”，就像在描述一种最基础的游戏技能，而这永远不可能让我们的游戏机制带有深度。

以下是我之前设计的其它两个游戏挑战，显然我对于游戏深度的诠释有所提升了：

“我希望玩家能够将炸弹移到能量弹弓上，并使用它炸毁目标。”

“我希望玩家能够把这些砖块移动到凹槽里，并按照一定的顺序将其摆放整齐。”

这两个活动声明中“使用能量弹弓摧毁目标”以及“按照一定顺序将砖块摆放整齐”都是对于技能的描述，并且较之前的基本技能来说更有深度。

*掌握了这些内容，我将会建议过去的自己：

1.删掉上述中大部分基本技能或目标内容。因为它们归根结底只是一种摆在眼前的事实，玩家可以轻易地按照指示使用炸弹或火箭砖块完成任务。减少繁琐复杂的武器，简化你的游戏任务，让玩家能够思路清晰地进行游戏吧！

2.观察两个更深层次的游戏机制，并尝试着为它们创造更多挑战。过去的我应该开始在活动声明中编写新的游戏挑战了。

3.让新的挑战更具标准化。

4.测试新的挑战。

5.如果整体效果看起来还是太肤浅，那么你可以继续添加其它深度技能（并确保它们不是目标），并重复开始执行步骤1。

注意：目前我所列举的所有例子都是关于益智类游戏机制，但是这篇文章并不是全部关于益智类游戏。而是我认为所有类型的游戏都可以从中受益。

例如，让我们假设你的枪战游戏机制很肤浅。这也许是因为“用枪杀死敌人”却并未涉及任何深度技能。这只是在陈述一种目标。在《拉捷特与克拉克》中，我们的枪战活动声明是“选择适合的武器或武器组合尽快地杀死一群敌人。”

在设计阶段转变你的活动声明，让其涵括更多深度技能（而因此转变基本的游戏机制），你的整体游戏设计将会变得更有深度，且让玩家更加满意。

避免模糊的活动声明

活动声明很有效，但是有时候也会让你陷入不必要的麻烦中。如果你的活动声明太过模糊，那么你将会很容易陷入这些麻烦中。

举个例子来说，以下是《传送门》（游戏邦注：Valve开发的第一人称射击游戏）中使用的简单活动声明：

“我希望玩家能够使用portal gun去获得按钮上的砖块。”

如果在这个简单的活动声明中所提到的技能（游戏邦注：即使用portal gun）碰巧是深度技能，那么这种模糊的声明形式将会让你不小心陷入困境中。

《拉捷特和克拉克》中的“克拉克”游戏设置便是一个典例。

“克拉克”挑战总是会困扰许多游戏设计者，甚至会导致他们失眠，其中也包括我。当我们在设计这种挑战时，它们看起来应该是一些富有深度的活动，但是事实常常让我们感到失望。

我们可以添加一些特性或者尽可能地简化它们以做出弥补，但是却仍需要添加一些更深层次的东西才能让我们感动满意。即使玩家喜欢这些机制，但是我们还是认为自己能够做的更好。

前两款系列游戏《拉捷特和克拉克》中，克拉克需要命令Gadgebots（总是跟随着他的可爱机器人）去通过一些障碍。虽然在游戏中有许多不同类型的障碍，但是它们的结局都是一样的。虽然我们利用一些特效以及可爱的动画形象进行弥补，但是事实上还是显得很肤浅。

活动声明：“我希望玩家能够命令他的Gadgebots帮助他度过阻碍。”这么描述太模糊了，并未提供太多信息以证实这一机制是否具有深度。

而在后来的《拉捷特和克拉克未来：时空裂缝》中，克拉克能够在某些关卡的特定位置记录自己的行动，并由一个全息图记录下这些行动。

这种挑战拥有一些较复杂的活动声明，像“我希望玩家能够记录下自己走向按钮并打开关卡的行动。然后我希望玩家能够重播这个记录，一旦全息图碰触到按钮，关卡的大门便能够打开，而我希望玩家能通过这扇门。”在这里你将会看到一些清晰的目标“走向按钮并打开门”以及“通过折扇门”，还有一些有效的深度技能“记录自己”以及“重播记录。”

这便是更有深度的游戏机制，没有太多让人混淆的活动声明。

完善深度

你现在完成了游戏设计，而且也制定了适当的活动声明，但是虽然你已经按照标准去进行修补了，为何你的游戏机制仍然看起来那般平淡无奇？你还能做些什么？

首先评估状况：

1.确定并列出你的目标。

a.在确定每个目标之前扪心自问：“是否这个目标的功能与列表中的其它目标相似？”如果答案是肯定你就必须考虑是否可以放弃它。你是否真的需要花些时间去教玩家如何达到这些目标？如果答案是否定的，那就跳过它。

2.确定并列出你的深度技能。

a.在确定每个深度技能之前扪心自问：“这是否真的是深度技能？而非基本技能或目标？”

b.扪心自问：“这些技能的功能是否与列表中的其它深度技能类似？”如果答案是肯定的，你便可以抛弃它。你总是在自我欺骗，认为自己拥有比现实中更多的游戏技能。

如此评估，你是否发现自己的游戏机制中存在着太多的目标而缺少足够的深度技能？我敢打赌你肯定发现了。这时候你便可以按照我在前面提到的做法，摆脱过去被牵引波束牵制着的所有问题：

1.添加1个或多个新的深度技能。

a.当你添加新的深度技能后自问上述的问题，即“这个技能是否是深度技能？而非基本技能或目标？”

2.仔细检查你的所有挑战，并完善你的活动声明。

3.让你的新内容标准化。

4.游戏测试。你的问题是否解决了？如果解决了，你便可以进行标准测试了。

5.如果你的问题并未解决，那么重新回到步骤1再试一次。

需要考虑的一些问题

就像我在文章开头提到的，制作有深度的游戏机制往往不像你想象中的那么简单，在你着手制作具有深度的机制之前，你需要回答这些问题：

如果你制作出富有深度的机制，是否仍然适合你的用户？

游戏的目标通常是一些年轻玩家，而他们多喜欢各类肤浅的游戏机制。《乐高星球大战》便很好地解决了这一问题。

你的玩家是否真的喜欢深度机制？对于一些休闲游戏来说，更多的活动比起深度内容更加有益。

吸引人的游戏机制

如果你的机制是想表达不一样的特性，那么深度或者丰富的挑战将会阻碍你的玩家更好地体验游戏挑战。

我之前提到的《拉捷特和克拉克未来：时空裂缝》中的克拉克挑战便是一个很好的例子。

行动记录机制收到各种各样的反馈。

进一步来说，它需要很多教程或帮助信息以教会玩家如何执行新活动。而游戏机制只是作为整体游戏中的一个小部分，所以看起来并不理想。

玩家也许会只是把克拉克挑战部分当成一个有趣的部分。而如果要求他们学习更多深层次的新技能将有可能疏远他们。

叙述性游戏机制

有时候游戏机制的目的只是想让玩家体验游戏，或者只是单纯地出于叙述目的。如此看来，提高游戏深度和复杂性将可能阻碍玩家的游戏感受。

《全面失控》和《暴雨》都合理地应用了叙述机制。

所以，当你认定了深度机制后，你需要确保每个游戏机制中都拥有明确的目标和足够的深度技能。只要你能按照我上述说到的方法，并牢记基本技能和深度技能的区别，你将能够更好地对你的游戏机制做出评估，并相应解决一些问题而创造出富有深度的游戏机制。

结语

在本篇文章中我倡导用一种特殊的方法去分解游戏机制。我指出了深度技能的重要性，甚至超越于目标和基本技能。

尽管我认为这是一种很好的分析方法，但是却不等同于没有比它更好的方法了。这只是我用来解决游戏问题的其中一个好对策。

法国数学家Henri Poincaré在他的著作《科学与方法》中说道：“几何学并非真理，它只是一种有益的方法。”

这个道理同样适用于游戏设计。没有哪一种游戏设计是真理，它们都只是为了更好地辅助游戏开发。而我上述屡次提到的深度问题，便是能够帮助我更好地评估，预测并解决各种问题的好方法。带着这种想法去使用深度机制，你将能够有所收获。

游戏邦注：原文发表于2010年7月21日，所涉事件和数据均以当时为准。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Evaluating Game Mechanics For Depth

by Mike Stout

The Problem

Often, in game development, a design that looks great on paper doesn’t turn out as well in practice as you’d hoped. It comes across as “shallow” or “flat.” Perhaps play-testers, publishers, or peers describe it as “needing more variety” or as “feeling repetitive.”

Every game designer has heard these complaints at one time or another. I’ve bumped up against problems like this on every game I’ve ever worked on and there are three ways I like to approach solving them.

If the players felt the game overall didn’t have enough variety you can add more game mechanics to the game. Think of this as increasing the game’s “breadth.”

Buzzwords to watch for: The game is “a one-trick pony,” “repetitive,” “or needs more variety.”

Feedback that can be fixed with these kind of content expansions tends to describe the game as a whole. Players feel they don’t have enough different things to do on a global level.

If players feel that an individual game mechanic is flat and unrewarding you can refine that mechanic’s “theatrics” by giving the player better feedback, more rewards, better effects, cooler sounds, more personality, a cooler camera, or other bells and whistles. After theatrics refinements, players will often — with no changes to the underlying gameplay — tell you the problem is fixed.

Buzzwords to watch for: A given game mechanic is “boring,” “repetitive,” or “just not fun.”

Feedback that can be fixed with theatrics improvements usually describes a single game mechanic, but is vague and “touchy-feely.”

If players feel that an individual game mechanic “isn’t giving them a good enough challenge,” or feel that “the mechanic is fun at first but gets old quickly,” you need to add depth to your mechanics.

Buzzwords to watch for: A given game mechanic is “too shallow,” “too easy,” or “flat.” Often players will say the mechanic started out fun, but that it quickly got repetitive or boring.

It’s a good idea to pump up the theatrics when you get feedback like this, but while it might help players tolerate a mechanic for longer, it will only go so far. When theatrics fail, it’s time to knuckle down, roll up your sleeves, and get to work on making your game mechanic deeper.

While each of these could be the focus of its own article, this article will focus on perhaps the trickiest of the three: depth. By the time you’re done reading this article, I hope to describe for you the tools I use to find out why a game mechanic doesn’t feel deep enough. Even better, I hope to impart a few techniques that I’ve found help a lot when it comes time to fix a shallow game mechanic.

First: A Few Definitions

Before diving into a discussion on depth, I wanted to define a couple of terms that I’ll be using a lot in this article:

Game Mechanic: When I say “game mechanic” I’m referring to any major chunk of gameplay in a video game. Using the classic The Legend of Zelda: A Link to the Past as an example, here are a batch of game mechanics: sword combat, block pushing, boomerang throwing, swimming, button-based puzzles, hazard-avoidance, use of specific weapons, etc…

Challenge: A challenge is any in-game scenario that tests the player’s skill at a specific game mechanic. An example of this would be an individual room in a Zelda dungeon, a grindrail segment in Ratchet & Clank, or a combat encounter in Halo.

So What Does “Deep” Mean, Anyway?

Dictionary.com defines depth as: “The amount of knowledge, intelligence, wisdom, insight, feeling… evident either in some product of the mind, as a learned paper, argument, work of art, etc.” As is evident from the scope of this definition, depth can be an incredibly personal term, and can mean a lot of different things to a lot of different people.

To me, it describes a sweet spot — that point during a game where the player can repeatedly display his mastery of a game mechanic. Challenges never stay the same long enough to be boring and yet they also don’t change so fast that the player can’t enjoy his mastery over the game.

Clearly this “depth” is something we want to achieve in many of our mechanics, but it’s often less clear how to obtain it.

In my experience, in order for a game mechanic to be deep it needs two very important things:

It needs clear objectives, so the player knows what he has to do to succeed. Confusion and obfuscation tend to make players feel like a mechanic is LESS deep once they find themselves needing to experiment randomly to win.

It needs a variety of Meaningful Skills that you, as a game designer, can use to create good challenges for the player and that the player in turn can use to achieve mastery over the game.

Objectives

When a player enters a challenge, he must have a good idea of what his objectives are. Another good way to put this is to say that he must be able to clearly visualize the completion state of the challenge.

Clear objectives are a must if you want to create depth in your game mechanic. As I mentioned before, if the player doesn’t know what the completion state of the challenge should be, he’s reduced to floundering about and trying things randomly instead of demonstrating his mastery of the game’s mechanics.

Meaningful Skills?

Meaningful Skills are all the “things” the player must do to take a challenge from its beginning state to its completion state. In other words, once the player has recognized a challenge’s objective, the work has only begun.

It can’t be stressed enough that I’m referring to meaningful skills. “Meaningful” is an incredibly important part of this equation. If a skill is too basic, it will not help make your mechanic feel deeper. At that point, it becomes a simple task the player must complete, like checking items off a shopping list.

A classic example of a too-basic skill can be found in the statement “move from point A to point B.” That kind of fundamental movement challenge is essentially the same as saying “hold a button on the controller to win.” It’s foundational, but it’s too simple. It’s not deep.

Further, when you really think about it, when you say “move from point A to point B,” you’re actually talking more about the objective of a challenge and not the skill required to achieve the objective.

This sounds like a small distinction, but is in fact very important. Making this shift in how you think about designing game mechanics allows you to see depth-related problems that you otherwise would not.

Meaningful Skills: A Morality Tale

When I was a junior designer on Ratchet & Clank 2, I was given the task of coming up with all the “Tractor Beam” puzzles for the two levels of the game that used them. The tractor beam was a game mechanic that allowed Ratchet to freely move large objects marked with a special tractor beam symbol. Essentially this is a theatrical “paint-over” of classic block-pushing challenges from games like The Legend of Zelda.

Coming up with the training setups was easy. The player simply had to move blocks from point A to point B so that he could jump up on them and get out of a pit. My problems began, however, when I tried to come up with more advanced challenges. I quickly came to an impasse. Moving blocks from one place to another, I saw, was too basic a skill. Beyond the training example, there wasn’t much more I could do to “ramp it up” and provide varied, escalating challenges.

At this time in my career, I didn’t yet understand the important distinction between meaningful skills and too-basic skills. I didn’t know how important clearly identifiable objectives were. And so, lacking experience, I decided to just start adding features until the mechanic was deep enough. If you’re groaning at this, then I congratulate you. I’m groaning, myself, as I write this.

Besides moving blocks around, I decided it would be great if the player could grab and drag around a wacky robot (if you’re reading this and thinking “oh, you improved the theatrics,” you get a cookie). The player could then drop the robot on buttons to open doors. This didn’t help as much as I wanted it to — it just still seemed way to shallow.

So I forged ahead and kept adding features (groan).

I added bombs that you could drag around to blow up doors and little energy slingshots you could use to fling the bombs around at targets.

I decided blocks would be able to get in the way of laser beams so you could get past them.

I added special blocks with explosive rockets inside that would blow up certain doors.

Finally, I made it so that some of the blocks slid around inside a groove on the floor. The player had to figure out how to arrange the blocks into a specific order, but the blocks all got into each others way, since they shared a groove.

By the end of all that adding, not only was I permanently on several programmers’ hate lists, but the tractor beam game mechanic was quickly getting too bloated. It was way too complicated for players to handle. Playtests were generating feedback that players were routinely confused. We had to devote about half the time spent with the tractor beam purely to training, so that our players could understand the basic gist of what they needed to do.

Looking back, it’s clear to me why the mechanic never felt deep enough: I kept adding new objectives, but failed to add many meaningful skills.

I’ll go into this a little more below, but I bring it up now because it illustrates how meaningful skills contribute much more to a feeling of depth than objectives do.

Experiences like the one I had with the tractor beam taught me a valuable lesson: most game mechanics that don’t feel deep enough feel that way because they have too many objectives and not enough meaningful skills.

Making a Statement

So if I could go back in time, how would I help myself make the tractor beam challenge deeper? Well the first thing I’d suggest is that my past-self come up with an “Activity Statement” for each challenge in the segment.

An Activity Statement is a simple sentence that describes a challenge by stating both the objective of a challenge and the meaningful skills that the player must use to obtain his objective.

For example, a simple platforming challenge could be described in an Activity Statement as: “I want the player to jump up to that platform.” In this case “jump up” is the meaningful skill and “that platform” is the objective.

A more complex platforming Activity Statement might be “I want the player to double jump straight up and then glide down to that platform” or “I want the player to time his jump to avoid the fire spouts and land on that platform.”

The Activity Statements listed above all contain a mixture of objectives and meaningful skills. But what happens if you exclude one of those ingredients? We’ve established that challenges without a clear objective are not deep, but it’s also true that game mechanics that feel shallow tend to include many objectives, but few meaningful skills.

Here is what Activity Statements would have looked like for some of the tractor beam challenges past-me designed:

“I want the player to move a wacky robot from his starting spot to a button on the floor.”

“I want the player to move a bomb from its starting spot to a spot in front of that door.”

“I want the player to move a block from its starting space so that it blocks that laser beam.”

“I want the player to move an explosive rocket block to that button on the floor.”

You’ll notice that the above statements all clearly outline objectives, but no meaningful skills. In fact, when you examine them closely, all of them outline the same objective, and it’s not even a particularly interesting objective!

Each statement is basically saying “Move from point A to point B,” which we already know describes a skill so basic that it doesn’t make our game mechanic any deeper.

With the other two challenges past-me designed, it looks like I was onto something a little deeper:

“I want the player to move a bomb its starting spot into that energy slingshot and use it to blow up a target.”

“I want the player to slide these blocks around inside a groove and arrange them in a specific order.”

Both of these Activity Statements, “use the energy slingshot to blow up a target” and “arrange the blocks in a specific order” describe skills that are much more meaningful than the others.

Knowing this, I would advise my past-self to:

Cut most of the too-basic skills / objectives described above. They all boil down to “take an object near a door to open the door” and could be accomplished with either the bomb or the rocket-block. Nuke redundancy and simplify things for your players, past-me! Do it now!

Examine the two deeper mechanics and try to create more challenges for each of them. Past-me would begin designing these new challenges by writing an Activity Statement for each one.

Prototype the new challenges in-game.

Play-test the new challenges.

If the whole thing is still too shallow, add another Meaningful Skill to the list (make sure it’s not an objective!) and repeat from step 1.

Note: All of my examples thus far have been about puzzle-like gameplay, but this article isn’t just about puzzles. All types game mechanics can benefit from this way of thinking.

For example, lets say you have a gun combat mechanic that is feeling shallow. Perhaps this is because “use your gun to kill an enemy” doesn’t say anything about the meaningful skill. It is purely a statement of objective. In Ratchet & Clank, our gun combat’s Activity Statement was more like “Choose the correct weapon or combination of weapons to kill a group of enemies as efficiently as possible.”

By altering the Activity Statement during the design phase to more explicitly encompass the meaningful skill (and thereby altering the underlying mechanic), your whole design will get deeper and more satisfying.

Avoid Vague Activity Statements

Activity Statements are an immensely useful tool, but it’s possible for them to get you into trouble. The easiest way to get in this kind of trouble is to create a vague Activity Statement.

For example, here is a simple Activity Statement that could apply to most of the challenges in Portal:

“I want the player to use the portal gun to get this block on top of that button.”

While the indicated skill (use the portal gun) in this simple Activity Statement happens to be a Meaningful Skill, this kind of vague statement can get you into trouble if you’re not lucky.

The Clank gameplay in the Ratchet & Clank games is a good example of this.

The Clank challenges always bugged many of the designers I knew at Insomniac, myself included. When we designed them, they seemed like they should be deep activities, but they never turned out that way.

We were able to patch them up by giving them a lot of personality and by keeping them fairly simple (theatrics, baby!) but it took many sequels to add enough depth to them to satisfy us.

Players seemed to like them, but we thought we could do better.

In the first two Ratchet & Clank games, Clank needed to give commands to his Gadgebots (cute little robots that followed him around) to get past blockades. There were a few different types of blockades, but in the end they all ended up feeling the same. We patched it up with effects and cute animations, but in general they were quite shallow.

The Activity Statement: “I want the player to command his array of Gadgebots to get him past blockades,” in the end, is too vague. It doesn’t give enough information to tell whether or not the mechanic will deep enough.

Flash forward to Ratchet & Clank Future: A Crack in Time. Clank now has the ability to record his actions at certain points in the level and then have a hologram play those actions back.

This gave way to challenges with very complex Activity Statements like “I want the player to record himself going to that button, which opens a door. Then I want him to play back the recording and, once the hologram hits the button and the door opens, I want him to go through the door.” You’ll notice clear objectives “go to the button to open the door” and “go through the door” as well as good meaningful skills “record himself” and “play back the recording.”

This is a much deeper mechanic, with a much less vague set of Activity Statements.

Exercise to Improve Depth?

So you’ve got your design and it had what seems like a killer Activity Statement. But now you’ve prototyped it (or gone even further) and somehow the mechanic still ends up feeling flat.

What can you do now?

First take stock:

1. Identify and list your objectives.

a. For each, ask yourself: “Is this objective functionally a duplicate of any of the other objectives in my list?” If it is, ask yourself if you really need it. Do you really want to spend the time on teaching your players how to interact with it? If the answer is no, cross it out.

2. Identify and list all your meaningful skills.

a. For each ask yourself: “Is this really a meaningful skill? Not too basic? Not an objective?”

b. Ask yourself: “Is this skill functionally a duplicate of any of the other meaningful skills in my list?” If it is, cross it out. You’re tricking yourself into thinking you have more skills than you actually do.

Having taken stock, do you now find you have too many objectives? Not enough meaningful skills? At this point, I’ll bet you’ve discovered that, yes, somehow that’s happened. At this point, just do the same exercise I suggested above to help my past-self get over his tractor beam problems:

1. Add one or more new meaningful skills to the list.

a. As you add them, ask yourself the same questions as above. “Is this skill really meaningful? Is it too basic? Is it really an objective?”

2. Go through all your challenges and improve your Activity Statements

3. Prototype the new content.

4. Play-test. Is your problem solved? If so, then you’re done!

5. If your problem isn’t solved, go back to step 1 and try again.

Something to Consider?

As I mentioned at the beginning of this article, making a mechanic deeper might not always be something you want to do. Before you go ahead and do a ton of work making a mechanic deeper, ask yourself these questions.

If you make this deeper, will it still be appropriate for your audience?

Games intended for very young players tend to have a wide variety of fairly shallow game mechanics. The Lego Star Wars games have done this incredibly well.

Does your audience really want depth? Some more casual games might benefit from more activities rather than deeper ones (a fitness game, for example, or something like WarioWare).

“Charming” game mechanics

If the main purpose of your mechanic is to express charm or personality, depth and increased challenge might actually get in the way of your players experiencing the quirkiness of your challenge.

A good example of this might be the deeper Clank gameplay I mentioned from Ratchet & Clank Future: A Crack in Time.

The action-recording gameplay received very mixed reviews.

Further, it required a ton of training and many help messages to teach players how to execute the new moves. For a mechanic that was a very small part of the whole game, this may not be ideal.

Players might look at the Clank sections as more of an amusing diversion. Needing to learn much deeper new skills might have alienated some.

Narrative game mechanics

Sometimes the purpose of a game mechanic is to make the player “feel” something, or to serve some similar narrative purpose. In this case, depth and increased difficulty might actually get in the way of the player feeling what you want him to feel.

Indigo Prophecy and Heavy Rain are two games that made very good use of these kinds of Narrative Mechanics overall.

So once you’ve thought it through and decided that depth is what you want, you need to make sure your game mechanics each have clear objectives and a good set of meaningful skills. By using the exercises described above, and remembering the distinction between too-basic skills and meaningful skills, you’ll have a better chance of evaluating, troubleshooting, and adding depth to your game mechanics.

A Final Note?

In this article I advocate a specific way of breaking down game mechanics. I pointed out the importance of focusing on Meaningful Skills over objectives and “too-basic” skills.

Though I believe this is a very useful way to break things down, I don’t mean to imply that this way of breaking things down is somehow “more correct” than any other way. This is one of many very valid ways a game can be broken down.

In his book Science and Method the French Mathemetician Henri Poincaré said “Geometry is not true, it is advantageous.”

The same is true with models for thinking about game design. None of them are true — they are only convenient. The model I suggest above has, time and again, proven quite convenient for me to use evaluating, predicting, and troubleshooting depth in game mechanics. Use it for that purpose, and it’ll be your best friend. （source:gamasutra）