LIMBO 大概這兩年繼 Braid 之後，評價最高的一款 Puzzle/Platformer，不僅謎題設計精彩，在視覺呈現與音樂/音效表現上也令人刮目相看。GDC 2011 中一共有兩場關於 LIMBO 的演講，除了我所紀錄的這場以外，還有一場專門在講的 LIMBO 音效呈現。我只有去聽 Puzzle Design 這場，不過很可惜 GDC Vault 至今並未把相關的影音檔和簡報檔上線，這樣蠻多細節我也無從回頭查證了…只是話又說回來，那我剛好有做這場的筆記，也算幸運？日後有機會再將音效解說那場也去聽完 : )
其實我發現關於 LIMBO 的資料在 wikipedia 上意外地完整（就是篇首的那個 link），大家不妨先至 wikipedia 上把遊戲的相關背景略作閱覽，我會盡量描述 wikipedia 上比較少提到的部份，自己的演譯也會比較多；重複的部份我就只簡略帶過，因此本篇篇幅也會短很多 :p
本場 Talk 重點分兩大部份。第一部份為謎題設計，又分為原則說明與過程範例的介紹兩段落；第二部份為關卡編輯器Demo，現場示範謎題原型設計，並說明此工具的優劣。
這場的主講人是 Jeppe Carlsen，原本是在 Playdead 擔任遊戲引擎開發的工作，先前並無任何的設計與企畫相關背景；但後來在開發過程中，團隊其他人發現他其實很擅長設計謎題，於是漸漸地將主設計的工作交到他手上。就我在會場上聽到的，他說 LIMBO 的主要開發期超過 3 年，以及 11 名主要製作者（和 wikipedia 上的數字略有不同），來製作這個遊戲總時數僅僅 4 小時（不算隱藏成就且順利過關的話）的作品。整個作品的設計目標是極簡風格（Minimalist），但要具有挑戰性。
Jeppe 在如何達成「看似簡單，但又極富挑戰性」這點下了相當多功夫，他認為好的謎題設計應該要遵循幾個原則：
- 構成元素能少則少，將複雜的問題建構在單純的環境裡。
- 避免謎題產生重複感。
- 不要使得玩家看到題目後只想 Trial & Error，這會導致花了時間和力氣解謎卻沒有滿足感。
他在一開始就先舉出了一些「反面例證」，第一個是《Uncharted 2》。雖然普遍認為 Uncharted 系列這類 3D 動作過關遊戲，裡面也是充滿謎題，不過 Jeppe 卻說，該遊戲的重點其實是在刺激的動作場面，故事、角色與場景的呈現等等，裡面並沒有真的謎題，大多數時間你只是在跟著遊戲場景給你的各種提示與暗示走，這中間並沒有太多需要「思考」的地方。有些謎題，譬如說要拿鏡子反射光束是很常見的梗，但是老實說整個謎題的步驟雖然多，不過卻同樣沒有什麼要花到腦筋的地方。
外部連結：水池謎題 in《Prince of Persia》2008
Jeppe 認為應該要盡量減少依賴用組合數來設計謎題
他提出的第二個例子便是 2008 年的《Prince of Persia》中間某段水池謎題的設計，玩家必需要反複嘗試各種不同的組合可能性。除非玩家本來就是很熟悉這類謎題的解法，不然試沒兩步，玩家發現他根本抓不到解決問題的竅門，卻有一堆組合等著他的時候，唯一解決途徑就是把每個結果都試一次最快。
這很像魔術方塊一樣的狀況，會解的人就是會，而且有方法有撇步；不會解的人就只能一直錯誤嘗試直到他放棄，或終於運氣好解出來為止，其實過程浪費很多時間但卻得不到太多樂趣。這大概也是很少人會把魔術方塊類的謎題做到一般電子遊戲裡的原因，因為很明顯太難了；但是那些「沒那麼難」的組合性謎題，卻常常被用到遊戲中。
一個玩家理想的解謎過程，Jeppe 認為有以下幾個重點：
- 當然，一開始玩家必需要去嘗試（並通常包含失敗的嘗試）
- 玩家從失敗的嘗試中能學到一些點子。
- 分析這些點子並找出更接近成功的路徑。
- 解決問題，獲得成就感（玩家本身要能確實學習）。
所以必需要把謎題設計得利於玩家產上如上述步驟的解謎過程，通常要做到這點，Jeppe 認為設計者要能夠預測玩這個遊戲的玩家們，到底在解謎時會如何思考、並進行一連串的動作。
這邊再做一點個人的演譯。其實光看上面這四點敘述，我們也會覺得，難道組合性謎題就不是這樣嗎，玩家也是要一次一次試啊？試到後來可能他看出竅門啊？
我個人的看法是，分界點在於「玩家學習的比率」，也就是說，對於一道謎題，到底有多少比率的玩家是透過一步一步想，有明確思考過程去解出謎底，又是有多少玩家會被迫不管三七二十一就是一直踹踹踹踹，踹到過為止？另一個驗證法是，有多少玩家「真的記得、理解」這個謎題怎麼解？還是說過兩天再給玩家試同樣或類似的謎題，他就又不會玩了，又要踹踹踹踹？依照 Jeppe 的邏輯，好的謎題設計應該要能讓玩家確實「理解」並「學習」。
說明完 LIMBO 的設計原則後，Jeppe 描述了設計的過程，也舉出遊戲中後期某個實際範例。在謎題設計的時候，設計者必需要把玩家當成「敵人」，也就是前面提到的「預測玩家可能的作為」，然後挖洞給他跳；但是實際上設計者也不能對玩家太壞，當謎題的草案出來後，也必須把玩家當成「朋友」，給他一個易於操作與測試結果的環境。前面也提到了玩家的「學習」，最好能讓玩家覺得「那是他學到的」，不是「設計者教玩家的」。
這有點像 INCEPTION 的感覺 XD，遊戲設計者要有辦法在玩家腦中植入想法，但是卻不能被玩家發現有人在影響他。哇咧 … 越講越玄，到此打住 XDDDD
最後 Jeppe 也提到，一道謎題對於「正確」與「錯誤」必需要十分明確。玩家才有辦法很明確地從中學習經驗，並測試更進一步的做法。當玩家發現「正確」的行動時，必需要讓玩家覺得「哦，這真的是對的」，而且操作簡潔有力；當玩家做出「錯誤」的行動時，遊戲環境必需用遊戲機制讓玩家瞭解，這絕對是錯的。譬如說不該跳得過去的地方，就不要故意設計得好像硬跳有機會跳過去一樣，玩家就懶得想其他解法，他會想反正一股腦一直試「搞不好」有機會過。
這道謎題的關鍵在玩家必需要觀察出，如果不先讓鐵鍊來回擺動的話，就不可能抓住鐵鍊跳過帶電區域。玩家拿到這道題目後，通常會先試鐵鍊原地擺盪過不過得去。玩家玩到這裡應該是已經有辦法判斷，不需要真的跳也知道盪不過去了，所以下一步玩家會知道能夠讓鐵鍊移到另外一端的開關是關鍵。
但這時通常第一次玩的玩家反應不會那麼快，在他思考的過程中鐵鍊擺盪已經小了，他會發現如果用開關把鐵鍊移到另一端，這時他也不可能跳過去抓住鐵鍊。反應比較快的玩家這時應該就有辦法聯想到，如果鐵鍊在另一端時擺盪幅度還夠大，就能從帶電區前起跳，抓住鐵鍊，然後盪過帶電區。
不過這道謎題並不是一開始就這麼精鍊的。
這是上述連結中的謎題原型
經過簡化之後的謎題，可以發現到還是比實際用上的版本「複雜」
Jeppe 說他們快速 mock 出一個堪用的謎題後，很快就發覺這一段落太多元素了，於是後來便漸漸把非本段他們想用的主角（擺蕩的鐵鍊）一一去掉，譬如說多餘的地型段差、多餘的箱子、多餘的開關等等，直到只留下這段落想帶給玩家最核心的那一項挑戰為止。
LIMBO 遊戲編輯器長的樣子
接下來主講人開始介紹 LIMBO 背後所使用的 in-house 視覺化關卡編輯器，這個編輯器也是遊戲在一面開發的過程中一面慢慢完善化的，很多功能都是半途才漸漸加入，到最後成了一套非常強大的 2D Physics Platformer 開發工具。
藍色代表是可操作的物理物件
Trigger 連接與觸發區域的樣子
加上了 Timer 與重力的變換
Jeppe 現場示範了如何快速開發一道簡單的謎題，裡面不外乎就是固定物件、物理物件、Trigger、Timer 以及其他 pre-scripted building blocks 的混合運用。利用這套工具開發 LIMBO 可以讓謎題設計者在最少的程式撰寫需求下，盡快做出一個可以試玩的場景，將全部的精神都灌注在內容的設計與測試上面。但是，這類的編輯器也有相當明顯的缺點。
著名場面的背後 ...
講者要大家看到這一幕的實際開發畫面時別嚇到。:p
原來是長這樣子啊啊啊啊
嘩哈哈，我是受過 Virtools 專業荼毒的，這點小 case 嚇不倒我滴 XDDDDDDD
簡而言之，當互動的機制一複雜起來之後，這樣的編輯系統就會一發不可收拾地混亂，畢竟程式模組與指令間互相牽連的這種關係，本來就是相當抽象的。用 UML 把 pattern 或 flowchart 描述出來有時候就已經會覺得圖複雜到看不懂了，更別說像這樣每個變數、每個 Trigger 都要串起來，那更不得了。而且工具設計成這樣以後，能夠開發的遊戲種類侷限性也就隨之而來。
Jeppe 是認為這當然不是一體適用的解法，但剛好這個工具設計符合他們的遊戲開發需求，雖然局部的編輯內容看起來很混亂，但至少謎題與謎題間是各自獨立的問題，謎題A複雜的線路圖也不會影響到謎題B的。講者現場是說，如果在場的人發現你有這類的工具需求，不妨回去請你們的程式員參考一下。:p
