順帶一提，本週六 (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)