授权声明

本文转载自 IGDShare，感谢授权！

最近 Inside 的热度从 indienova 首页之中所占据的篇幅也能看出一斑。借着这个时机，我们不妨回顾一下 Playdead 在 Limbo 的制作之中所彰显出的谜题设计理念。

Limbo Puzzle Design

Limbo 大概这两年继 Braid 之后，评价最高的一款 Puzzle/Platformer，不仅谜题设计精彩，在视觉呈现与音乐/音效表现上也令人刮目相看。GDC 2011 中一共有两场关于 Limbo 的演讲，除了我所纪录的这场以外，还有一场专门在讲的 Limbo 音效呈现。我只有去听 Puzzle Design 这场，不过很可惜 GDC Vault 至今并未把相关的影音档和简报档上线，这样蛮多细节我也无从回头查证了…只是话又说回来，那我刚好有做这场的笔记，也算幸运？日后有机会再将音效解说那场也去听完 : )

其实我发现关于 Limbo 的资料在 wikipedia 上意外地完整（就是篇首的那个 link），大家不妨先至 wikipedia 上把游戏的相关背景略作阅览，我会尽量描述 wikipedia 上比较少提到的部份，自己的演译也会比较多；重复的部份我就只简略带过，因此本篇篇幅也会短很多。

本场 Talk 重点分两大部份。第一部份为谜题设计，又分为原则说明与过程范例的介绍两段落；第二部份为关卡编辑器 Demo，现场示范谜题原型设计，并说明此工具的优劣。

这场的主讲人是 Jeppe Carlsen，原本是在 Playdead 担任游戏引擎开发的工作，先前并无任何的设计与企画相关背景；但后来在开发过程中，团队其他人发现他其实很擅长设计谜题，于是渐渐地将主设计的工作交到他手上。就我在会场上听到的，他说 Limbo 的主要开发期超过 3 年，以及 11 名主要制作者（和 wikipedia 上的数字略有不同），来制作这个游戏总时数仅仅 4 小时（不算隐藏成就且顺利过关的话）的作品。整个作品的设计目标是极简风格（Minimalist），但要具有挑战性。

Puzzle Design

Jeppe 在如何达成“看似简单，但又极富挑战性”这点下了相当多功夫，他认为好的谜题设计应该要遵循几个原则：

1. 构成元素能少则少，将复杂的问题建构在单纯的环境里。
2. 避免谜题产生重复感。
3. 不要使得玩家看到题目后只想 Trial & Error，这会导致花了时间和力气解谜却没有满足感。

他在一开始就先举出了一些“反面例证”，第一个是 Uncharted 2 。虽然普遍认为 Uncharted 系列这类 3D 动作过关游戏，里面也是充满谜题，不过 Jeppe 却说，该游戏的重点其实是在刺激的动作场面，故事、角色与场景的呈现等等，里面并没有真的谜题，大多数时间你只是在跟著游戏场景给你的各种提示与暗示走，这中间并没有太多需要“思考”的地方。有些谜题，譬如说要拿镜子反射光束是很常见的梗，但是老实说整个谜题的步骤虽然多，不过却同样没有什么要花到脑筋的地方。

他提出的第二个例子便是 2008 年的 Prince of Persia 中间某段水池谜题的设计，玩家必需要反复尝试各种不同的组合可能性。除非玩家本来就是很熟悉这类谜题的解法，不然试没两步，玩家发现他根本抓不到解决问题的窍门，却有一堆组合等著他的时候，唯一解决途径就是把每个结果都试一次最快。

这很像魔术方块一样的状况，会解的人就是会，而且有方法有进步；不会解的人就只能一直错误尝试直到他放弃，或终于运气好解出来为止，其实过程浪费很多时间但却得不到太多乐趣。这大概也是很少人会把魔术方块类的谜题做到一般电子游戏里的原因，因为很明显太难了；但是那些“没那么难”的组合性谜题，却常常被用到游戏中。

一个玩家理想的解谜过程，Jeppe 认为有以下几个重点：

1. 当然，一开始玩家必需要去尝试（并通常包含失败的尝试）
2. 玩家从失败的尝试中能学到一些点子。
3. 分析这些点子并找出更接近成功的路径。
4. 解决问题，获得成就感（玩家本身要能确实学习）。

所以必须要把谜题设计得利于玩家产上如上述步骤的解谜过程。通常要做到这点，Jeppe 认为设计者要能够预测玩这个游戏的玩家们，到底在解谜时会如何思考、并进行一连串的动作。

这边再做一点个人的演译。其实光看上面这四点叙述，我们也会觉得，难道组合性谜题就不是这样吗，玩家也是要一次一次试啊？试到后来可能他看出窍门啊？

我个人的看法是，分界点在于“玩家学习的比率”，也就是说，对于一道谜题，到底有多少比率的玩家是透过一步一步想，有明确思考过程去解出谜底，又是有多少玩家会被迫不管三七二十一就是一直踹踹踹踹，踹到过为止？另一个验证法是，有多少玩家“真的记得并理解”这个谜题怎么解？还是说过两天再给玩家试同样或类似的谜题，他就又不会玩了，又要踹踹踹踹？依照 Jeppe 的逻辑，好的谜题设计应该要能让玩家确实“理解”并“学习”。

说明完 Limbo 的设计原则后，Jeppe 描述了设计的过程，也举出游戏中后期某个实际范例。在谜题设计的时候，设计者必须要把玩家当成“敌人”，也就是前面提到的“预测玩家可能的作为”，然后挖洞给他跳；但是实际上设计者也不能对玩家太坏，当谜题的草案出来后，也必须把玩家当成“朋友”，给他一个易于操作与测试结果的环境。前面也提到了玩家的“学习”，最好能让玩家觉得“那是他学到的”，不是“设计者教玩家的”。

这有点像 INCEPTION 的感觉，游戏设计者要有办法在玩家脑中植入想法，但是却不能被玩家发现有人在影响他。

最后 Jeppe 也提到，一道谜题对于“正确”与“错误”必须要十分明确。玩家才有办法很明确地从中学习经验，并测试更进一步的做法。当玩家发现“正确”的行动时，必需要让玩家觉得“哦，这真的是对的”，而且操作简洁有力；当玩家做出“错误”的行动时，游戏环境必须用游戏机制让玩家了解，这绝对是错的。譬如说不该跳得过去的地方，就不要故意设计得好像硬跳有机会跳过去一样，玩家就懒得想其他解法，他会想反正一股脑一直试“搞不好”有机会过。

Limbo 有一处谜题的关键在玩家必须要观察出，如果不先让铁链来回摆动的话，就不可能抓住铁链跳过带电区域。玩家拿到这道题目后，通常会先试铁链原地摆动过不过得去。玩家玩到这里应该是已经有办法判断，不需要真的跳也知道荡不过去了，所以下一步玩家会知道能够让铁链移到另外一端的开关是关键。

但这时通常第一次玩的玩家反应不会那么快，在他思考的过程中铁链摆荡已经小了，他会发现如果用开关把铁链移到另一端，这时他也不可能跳过去抓住铁链。反应比较快的玩家这时应该就有办法联想到，如果铁链在另一端时摆荡幅度还够大，就能从带电区前起跳，抓住铁链，然后荡过带电区。

不过这道谜题并不是一开始就这么精炼的。

Jeppe 说他们快速 mock 出一个可用的谜题后，很快就发觉这一段落太多元素了，于是后来便渐渐把非本段他们想用的主角（摆荡的铁链）一一去掉，譬如说多余的地型段差、多余的箱子、多余的开关等等，直到只留下这段落想带给玩家最核心的那一项挑战为止。

Level Editor

接下来主讲人开始介绍 Limbo 背后所使用的 in-house 视觉化关卡编辑器，这个编辑器也是游戏在一面开发的过程中一面慢慢完善化的，很多功能都是半途才渐渐加入，到最后成了一套非常强大的 2D Physics Platformer 开发工具。

Jeppe 现场示范了如何快速开发一道简单的谜题，里面不外乎就是固定物件、物理物件、Trigger、Timer 以及其他 pre-scripted building blocks 的混合运用。利用这套工具开发 LIMBO 可以让谜题设计者在最少的程式撰写需求下，尽快做出一个可以试玩的场景，将全部的精神都灌注在内容的设计与测试上面。但是，这类的编辑器也有相当明显的缺点。

著名场面的背后 ...

讲者要大家看到这一幕的实际开发画面时别吓到。

原来是长这样子啊啊啊啊。

不过，我是受过 Virtools 专业荼毒的，这点小 case 吓不倒我。

简而言之，当互动的机制一复杂起来之后，这样的编辑系统就会一发不可收拾地混乱，毕竟程式模组与指令间互相牵连的这种关系，本来就是相当抽象的。用 UML 把 pattern 或 flowchart 描述出来有时候就已经会觉得图复杂到看不懂了，更别说像这样每个变数、每个 Trigger 都要串起来，那更不得了。而且工具设计成这样以后，能够开发的游戏种类局限性也就随之而来。

Jeppe 是认为这当然不是一体适用的解法，但刚好这个工具设计符合他们的游戏开发需求，虽然局部的编辑内容看起来很混乱，但至少谜题与谜题间是各自独立的问题，谜题 A 复杂的线路图也不会影响到谜题 B 的。讲者现场是说，如果在场的人发现你有这类的工具需求，不妨回去请你们的程式员参考一下。