游戏任务设计(2)：MoveTo与Farm任务

游戏任务设计(1)：概念与简史 点击进入

照例，我知道你们都不爱看的枯燥无聊的理论文章……第二部分。说真的我没想到这个命题竟然能扯出这么多，写起来收不住了……所以这篇只是设计方法的（上）。

工具箱

任务设计的方法说简单很简单，就是对各种设计手法的灵活使用。说复杂也复杂，因为任务的种类实在是多种多样。一个像魔兽世界这样庞大的游戏起码能分类出几十种不同的任务形式，如果细化到设计师们交给程序的需求列表这种程度，这个数字肯定会增加到三位数或者四位数。

要把多种多样的设计目的、游戏内容和故事情节分解成任务的形式，你必须先对任务这个工具箱本身了若指掌。那些大号的电钻和锤子要放在最下面，钳子和螺丝刀在中层，螺母和螺钉装在顶层的塑料袋里。

所以，在正式进入主题之前，我先说一下这个工具箱的各层结构。

要解决的第一个问题是“这是个什么样的任务”，由设计目的决定的是任务的执行方式。我这个任务是要用来指引用户呢，满足用户的收集欲望呢，提供一种全新的游戏内容呢，还是方便关卡制作呢？从这个角度去思考任务的执行方式，就能把纷繁复杂的任务形式梳理清楚。

接下来的问题是“用户怎么获得这个任务”，由展示方法决定的是任务的逻辑结构。怎么把一个任务呈现给用户？把怎样的任务呈现给什么类型的用户？怎么给用户提供对一个任务的期待？在逻辑结构层来解决。

最后的一个问题是“各种各样的任务怎么管理”，由管理方法决定的是任务的分层模型；对玩家来说，这个分层模型也同时决定了他所看到的界面组织形式。

从这里再前进一步就是“任务相关的制作资源怎么管理”，这个说起来就太枯燥乏味了，我这篇文章可能不会提到。

最后一步是“预先告知用户任务回报”，这是个博大精深的话题，就算谈到我也只会是泛泛而谈。如果真要深入论述，恐怕得等到这架战略航空军的旗舰上出现一篇叫“游戏数值设计”的理论性文章以后了。

这些设计工具出现的时间有早有晚，有些仍然在发展中，有些工具已经产生了各种各样的变体。但是无论出现早晚，每种工具都有其优势和劣势。考虑到这是个进步非常迅速变化也非常快的领域，如果读者有什么意见也请自由发表。

执行方式：从设计目的出发

任务的执行方式设计是现代游戏设计中最多变，也是最需要创造力的范畴。

在执行方式这节中，我不打算像那些典型的“游戏教学书籍”那样用庞大枯燥的列表淹没你们——看那些“玩法教学书籍”是绝对学不会怎么设计的。同样，我也不需要重复一遍各种流行游戏中的任务设计，鹦鹉学舌的文章没有任何意义可言。与其有空看这种无意义的文章，还不如随便装个游戏抓紧时间打一打。

我会从“任务的设计目的”入手，从设计者和玩家两方面的动机出发把任务分成六个大类以及一个灵活的附加类。

MoveTo型任务（移动）

Farm型任务（重复）

Collect型任务（收集）

Hunt型任务（狩猎）

Puzzle型任务（解谜）

Challenge型任务（挑战）

附加类：Storytelling型任务（叙事）

由于我国是游戏设计后发国家，有些设计概念用中文表述可能不是太清晰，所有的类型都带个英文命名……总之你们知道Farm任务指代的是“重复作业”而不是“种田”就好了。

MoveTo型任务（移动任务）

人类是这样一种生物：他们声称自己喜欢自由。但对大多数人来说，如果真的把自由的选择权给了他们，他们就会不知所措。

所以，1990年的每个游戏中，都有庞大的地下城和分支对话。2010年的绝大多数游戏中，你只需要跟着任务黄点的指示，从一个黄点跑到下一个黄点。这是一个有点冷酷的事实，多数人并不是真的喜欢自由，或者喜欢选择——他们只是装作喜欢而已。

所以我们必须要给这些人设计MoveTo型任务。别给他们选择权，直接告诉他们现在应该去哪里吧。

MoveTo型任务是所有任务形式中最原始的一个，它的目的就是让玩家移动，或者说“跑路”。不管是魔戒的“到魔多去销毁戒指”还是西游记的“到西天去取经”，都是典型的Moveto任务。超级玛莉要从左到右突破所有关卡，雪人兄弟不往上冲就会被拖死，几乎所有FPS都要奔向一个又一个Checkpoint，这些也都是Moveto任务。从广义上来讲，甚至那些指示玩家如何按键移动人物、如何使用鼠标/手柄的教学目标都是Moveto类别的一种。

它的设计目的也非常显而易见：指引玩家行动，展示游戏内容。这个目的类型几乎和整个游戏史一样久远：既然你设计了游戏，当然要告诉玩家里面有些什么吧！

对玩家来说，完成MoveTo任务的目的是看到更多的没有看过的新内容；对设计者来说，MoveTo任务的目的除了展示玩家没有看过的新鲜设计内容之外，还要起到控制任务复杂度、关卡和脚本位置、Debug等等设计各种规范化的重要作用。在完成一个MoveTo任务之后，我们几乎可以笃定玩家必定在某个位置——这实在是太适合作为一段脚本的开头了。同样，对测试和Debug人员来说，移动任务也起到了重要的降低工作复杂度的作用——几乎是各种类沙盘游戏中唯一一个能起到该作用的设计手段。你不知道玩家什么时候去打哪里的怪，你也不知道玩家会怎么理解一个谜题，但是一个移动任务的结束地点肯定是个固定点。

“这不都是废话吗！”

肯定有好多读者要这么说了吧……且慢，且慢。从这个简单的事实陈述里面，能够导出一个很重要的问题，我把这个事实陈述换种说法看看。

“如果玩家跟着这种任务移动到了新地点，却没有新的游戏内容呢？”

现在你看到问题所在了。设计师设计Moveto任务除了指引之外，还有一个规范任务行动区间的作用；而玩家则不能理解这种作用，他们会觉得一段看不到任何内容的纯跑路是非常无聊枯燥的。

事实也是如此。偶尔做一两个还好，如果连续几个任务都是纯跑路，路上没有任何游戏内容，哪怕报酬再好，玩家也是很烦躁的。从根本的设计目的上来说，跑路任务就不应该是用来消耗玩家时间的。成天让他在毫无内容变化的地方跑来跑去，不枯燥才怪呢！你能怪玩家想要自动跑路吗？你能怪他想要传送系统吗？显然不能。这甚至不能用回报来加以平衡；毕竟跑路的过程中，玩家什么也没干。你可以偶尔给玩家大笔的横财，但你不能老给他横财，长此以往必将吊起玩家的口味，让你想给他真正的回报的时候也没得可给。

从这个简单的陈述中，我们可以推论出现代MoveTo任务设计的指导思想：“如果玩家不能看到任何新内容，就不要让他去做一个MoveTo任务”。

用设计目的这个标准来看，许多传统的任务设计方式都是有问题的。比如说，一个任务做完了以后，为什么一定要跑路回去交？如果没有任何新内容或者下阶段展开的话，有必要吗？一个关系到多个相关NPC的连续任务，需要让玩家跑来跑去吗？有没有什么代替方法？如果还不行，那么你就需要给玩家提供方便的移动方式：载具、出租车、自动跑路、瞬间移动，什么都行。这不是“现代浮躁的玩家不懂得游戏性”，而是“你根本没有给玩家提供任何游戏性”，这两者之间的区别是显而易见的。

而这条规则当然也可以反过来用：“在有重要的新游戏内容的情况下，你必须用Moveto任务来保证这些内容不被玩家错过”。

在这类情况下，MoveTo类型的任务则是绝对必要的，不能完全被方便移动方式所代替。最典型的用法，就如同介绍一个大型新场景给玩家的时候，最好能用MoveTo任务把你这个场景的各个设计要点交待清楚。一座主城需要让玩家了解各个功能区；一个副本需要让玩家了解各个关键设计所在；哪怕是一段大型的即时电影演出，玩家也需要观摩电影的指引。在这些情况下，不要用快速移动方式代替你的MoveTo任务；在可能的情况下，甚至可以限制玩家移动来保证BUG数量能够得到控制。回去交任务也并不是都是没有用的操作，有些时候交任务本身可能也是一个设计要点，这个例子就比如荒野大镖客RDR里面回家那一段的杰出演出。我们不应该对“快速移动”或者“自动跑路”这样的设计要素一棍子打死，而应该区分对待。

那如果设计师一定要插入一段内容不太丰富的MoveTo任务呢？倒也不是不能设计，只要你改换一下任务的类型。

我可以提供这么几个任务设计的例子。在通常的设计方法中，这些都被归类于不同的任务类别，甚至不同的游戏性；但如果从设计目的考虑，你会发现他们本质上都是MovTo类的任务。跑到某个地方采集一组药草，安装一个炸弹，拉动一个开关什么的，本质上有区别吗？其实没有。

设计师有一段路必需要求玩家跑两遍->在这两遍路上产生不同的、无法跳过的敌人。用不同的敌人来制造差异性。

设计师有一个大关卡必须要求玩家先到最里面然后再出来->在进去的时候是一个MoveTo任务，在脱出的时候是一个强制推进的MoveTo型任务，可能是有时间限制、炸弹、毒气、洪水，总之你自己去想吧。

设计师希望控制玩家特定的移动路径，或者交待重要的NPC剧情/性格->把MoveTo任务改写成一个护送任务，这是MoveTo任务的一个子类型。让NPC沿着事先设好的固定点移动，同时控制玩家不能离开NPC过远。

设计师不在乎玩家怎么移动，但希望玩家看到这个区域内所有的重要点->把MoveTo任务改写成一个多段的物品收集/地点到达任务。设定几个操作点，让玩家去完成特定的操作，同时完成区域的交待工作。这种任务虽然以收集、解谜甚至Farm的形式出现，但本质上还是MoveTo型任务。

设计师有一个复杂的关卡，但他希望玩家能按顺序完成这个关卡->把一个单一目标的MoveTo任务改写成一个连续而拥有多段目标的MoveTo任务。拆开路点，让用户每时每刻都有个短路点等在前面。

你可以从这个基础上发挥你的设计能力和创造力，继续改善你的设计。关键仍然是设计目的，只要不是拖延游戏时间，玩家就不会讨厌MoveTo任务。难道有人会讨厌看激烈的大场面？那还玩什么游戏啊。

实际上，不管是出于叙事考虑、设计考虑还是测试考虑，几乎每个任务的第一步都会是一个MoveTo型任务，这也是我把这个类别放在第一位的原因。