顺带一提，本周六 (5/28) 晚间就是分享会的时间搂 ~~ :D http://registrano.com/events/1aa2aa 图文版：http://blog.igdshare.org/?p=172 (文字转载 only，图说连同图片一起省略了) == LIMBO 大概这两年继 Braid 之後，评价最高的一款 Puzzle/Platformer， 不仅谜题设计精彩，在视觉呈现与音乐/音效表现上也令人刮目相看。GDC 2011 中一共有两场关於 LIMBO 的演讲，除了我所纪录的这场以外，还有 一场专门在讲的 LIMBO 音效呈现。我只有去听 Puzzle Design 这场，不 过很可惜 GDC Vault 至今并未把相关的影音档和简报档上线，这样蛮多细 节我也无从回头查证了…只是话又说回来，那我刚好有做这场的笔记，也 算幸运？日後有机会再将音效解说那场也去听完 : ) ※ 其实我发现关於 LIMBO 的资料在 wikipedia 上意外地完整，大家不妨先 至 wikipedia 上把游戏的相关背景略作阅览，我会尽量描述 wikipedia 上比较少提到的部份，自己的演译也会比较多；重复的部份我就只简略带 过，因此本篇篇幅也会短很多 :p 本场 Talk 重点分两大部份。第一部份为谜题设计，又分为原则说明与过 程范例的介绍两段落；第二部份为关卡编辑器Demo，现场示范谜题原型设 计，并说明此工具的优劣。 这场的主讲人是 Jeppe Carlsen，原本是在 Playdead 担任游戏引擎开发 的工作，先前并无任何的设计与企画相关背景；但後来在开发过程中，团 队其他人发现他其实很擅长设计谜题，於是渐渐地将主设计的工作交到他 手上。就我在会场上听到的，他说 LIMBO 的主要开发期超过 3 年，以及 11 名主要制作者（和 wikipedia 上的数字略有不同），来制作这个游戏 总时数仅仅 4 小时（不算隐藏成就且顺利过关的话）的作品。整个作品的 设计目标是极简风格（Minimalist），但要具有挑战性。 ※ Jeppe 在如何达成「看似简单，但又极富挑战性」这点下了相当多功夫， 他认为好的谜题设计应该要遵循几个原则： 1.构成元素能少则少，将复杂的问题建构在单纯的环境里。 2.避免谜题产生重复感。 3.不要使得玩家看到题目後只想 Trial & Error，这会导致花了时间和力 气解谜却没有满足感。 他在一开始就先举出了一些「反面例证」，第一个是《Uncharted 2》。虽 然普遍认为 Uncharted 系列这类 3D 动作过关游戏，里面也是充满谜题， 不过 Jeppe 却说，该游戏的重点其实是在刺激的动作场面，故事、角色与 场景的呈现等等，里面并没有真的谜题，大多数时间你只是在跟着游戏场 景给你的各种提示与暗示走，这中间并没有太多需要「思考」的地方。有 些谜题，譬如说要拿镜子反射光束是很常见的梗，但是老实说整个谜题的 步骤虽然多，不过却同样没有什麽要花到脑筋的地方。 外部连结：镜子反光谜题 in《Uncharted 2》 https://www.youtube.com/watch?v=ckArLWBxIkQ 外部连结：水池谜题 in《Prince of Persia》2008 https://www.youtube.com/watch?v=1xv4KSUGSS8 他提出的第二个例子便是 2008 年的《Prince of Persia》中间某段水池 谜题的设计，玩家必需要反复尝试各种不同的组合可能性。除非玩家本来 就是很熟悉这类谜题的解法，不然试没两步，玩家发现他根本抓不到解决 问题的窍门，却有一堆组合等着他的时候，唯一解决途径就是把每个结果 都试一次最快。 这很像魔术方块一样的状况，会解的人就是会，而且有方法有撇步；不会 解的人就只能一直错误尝试直到他放弃，或终於运气好解出来为止，其实 过程浪费很多时间但却得不到太多乐趣。这大概也是很少人会把魔术方块 类的谜题做到一般电子游戏里的原因，因为很明显太难了；但是那些「没 那麽难」的组合性谜题，却常常被用到游戏中。 ※ 一个玩家理想的解谜过程，Jeppe 认为有以下几个重点： 1.当然，一开始玩家必需要去尝试（并通常包含失败的尝试） 2.玩家从失败的尝试中能学到一些点子。 3.分析这些点子并找出更接近成功的路径。 4.解决问题，获得成就感（玩家本身要能确实学习）。 所以必需要把谜题设计得利於玩家产上如上述步骤的解谜过程，通常要做 到这点，Jeppe 认为设计者要能够预测玩这个游戏的玩家们，到底在解谜 时会如何思考、并进行一连串的动作。 这边再做一点个人的演译。其实光看上面这四点叙述，我们也会觉得，难 道组合性谜题就不是这样吗，玩家也是要一次一次试啊？试到後来可能他 看出窍门啊？ 我个人的看法是，分界点在於「玩家学习的比率」，也就是说，对於一道 谜题，到底有多少比率的玩家是透过一步一步想，有明确思考过程去解出 谜底，又是有多少玩家会被迫不管三七二十一就是一直踹踹踹踹，踹到过 为止？另一个验证法是，有多少玩家「真的记得、理解」这个谜题怎麽解 ？还是说过两天再给玩家试同样或类似的谜题，他就又不会玩了，又要踹 踹踹踹？依照 Jeppe 的逻辑，好的谜题设计应该要能让玩家确实「理解」 并「学习」。 说明完 LIMBO 的设计原则後，Jeppe 描述了设计的过程，也举出游戏中後 期某个实际范例。在谜题设计的时候，设计者必需要把玩家当成「敌人」 ，也就是前面提到的「预测玩家可能的作为」，然後挖洞给他跳；但是实 际上设计者也不能对玩家太坏，当谜题的草案出来後，也必须把玩家当成 「朋友」，给他一个易於操作与测试结果的环境。前面也提到了玩家的「 学习」，最好能让玩家觉得「那是他学到的」，不是「设计者教玩家的」。 这有点像 INCEPTION 的感觉 XD，游戏设计者要有办法在玩家脑中植入想 法，但是却不能被玩家发现有人在影响他。哇咧 … 越讲越玄，到此打住 XDDDD 最後 Jeppe 也提到，一道谜题对於「正确」与「错误」必需要十分明确。 玩家才有办法很明确地从中学习经验，并测试更进一步的做法。当玩家发 现「正确」的行动时，必需要让玩家觉得「哦，这真的是对的」，而且操 作简洁有力；当玩家做出「错误」的行动时，游戏环境必需用游戏机制让 玩家了解，这绝对是错的。譬如说不该跳得过去的地方，就不要故意设计 得好像硬跳有机会跳过去一样，玩家就懒得想其他解法，他会想反正一股 脑一直试「搞不好」有机会过。 ※ 外部连结：LIMBO 中後期的某个谜题 https://www.youtube.com/watch?v=OrnUT-bLaTM&t=1m35s 这道谜题的关键在玩家必需要观察出，如果不先让铁链来回摆动的话，就 不可能抓住铁链跳过带电区域。玩家拿到这道题目後，通常会先试铁链原 地摆荡过不过得去。玩家玩到这里应该是已经有办法判断，不需要真的跳 也知道荡不过去了，所以下一步玩家会知道能够让铁链移到另外一端的开 关是关键。 但这时通常第一次玩的玩家反应不会那麽快，在他思考的过程中铁链摆荡 已经小了，他会发现如果用开关把铁链移到另一端，这时他也不可能跳过 去抓住铁链。反应比较快的玩家这时应该就有办法联想到，如果铁链在另 一端时摆荡幅度还够大，就能从带电区前起跳，抓住铁链，然後荡过带电 区。 不过这道谜题并不是一开始就这麽精链的。 (略过的图片部份请参考图文版~) Jeppe 说他们快速 mock 出一个堪用的谜题後，很快就发觉这一段落太多 元素了，於是後来便渐渐把非本段他们想用的主角（摆荡的铁链）一一去 掉，譬如说多余的地型段差、多余的箱子、多余的开关等等，直到只留下 这段落想带给玩家最核心的那一项挑战为止。 ※ 接下来主讲人开始介绍 LIMBO 背後所使用的 in-house 视觉化关卡编辑器 ，这个编辑器也是游戏在一面开发的过程中一面慢慢完善化的，很多功能 都是半途才渐渐加入，到最後成了一套非常强大的 2D Physics Platformer 开发工具。 Jeppe 现场示范了如何快速开发一道简单的谜题，里面不外乎就是固定物 件、物理物件、Trigger、Timer 以及其他 pre-scripted building blocks 的混合运用。利用这套工具开发 LIMBO 可以让谜题设计者在最少的程式撰 写需求下，尽快做出一个可以试玩的场景，将全部的精神都灌注在内容的 设计与测试上面。 但是，这类的编辑器也有相当明显的缺点。简而言之，当互动的机制一复 杂起来之後，这样的编辑系统就会一发不可收拾地混乱，毕竟程式模组与 指令间互相牵连的这种关系，本来就是相当抽象的。用 UML 把 pattern 或 flowchart 描述出来有时候就已经会觉得图复杂到看不懂了，更别说像 这样每个变数、每个 Trigger 都要串起来，那更不得了。而且工具设计成 这样以後，能够开发的游戏种类局限性也就随之而来。 Jeppe 是认为这当然不是一体适用的解法，但刚好这个工具设计符合他们 的游戏开发需求，虽然局部的编辑内容看起来很混乱，但至少谜题与谜题 间是各自独立的问题，谜题A 复杂的线路图也不会影响到谜题B 的。讲者 是说，如果在场的人发现你有这类的工具需求，不妨回去请你们的程式员 参考一下。:p (本段落所提到的现场 demo 画面请看图文版~) == --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 203.72.57.78 ※ 编辑: linjack 来自: 203.72.57.78 (05/25 02:39)