在18日下午的2022N.GAME網易遊戲開發者線上峯會上，榮獲TGA年度最佳遊戲《雙人成行》的主策劃Filip Coulianos受邀就自己的開發經驗進行了分享。Filip Coulianos以《雙人成行》中一個關卡的設計為例，從效率工具的使用、團隊溝通、關卡創意的提出與落地以及遊戲測試等方面進行分享。
以下是演講正文（有刪減）：
大家好，我叫Filip Coulianos，Keepsake Games是我和幾位老朋友在斯德哥爾摩新創建的遊戲工作室，目前正在開發一款全新的科幻合作冒險遊戲，這款新作令人期待，但這不是我們今天要談論的內容。
今天要談的是我製作《雙人成行》的經歷，我將從策劃的角度，介紹我和設計團隊是如何協作，製作出五花八門的玩法和機制。
首先，我會介紹一下《雙人成行》誕生的背景，然後再講一點製作背後的技術，而演講最後，我會以一個設計案例，詳細介紹我們遊戲其中一小塊的創作過程。
開發《雙人成行》的Hazelight工作室也在斯德哥爾摩，它大約成立於8年前，我們那時候做的第一款遊戲叫《逃出生天》，也是一款雙人合作遊戲。
《逃出生天》獨特賣點就是，必須要多個玩家配合才能通關。遊戲發售之後，玩家們也很喜歡這一點，正是由於玩家們的支持讓這款遊戲脱穎而出。所以《雙人成行》自然沿用了多人合作的遊戲模式。
《逃出生天》的開發過程其實有很多可以借鑑的點，《逃出生天》是款多人遊戲，必須要和朋友一起玩，同時還支持網絡合作模式，這在技術上是比較大的挑戰，《雙人成行》亦是如此。而且這兩款遊戲都是分屏顯示以及線性敍事，和電影一樣，從頭到尾講一個故事。
但是《雙人成行》在玩法方面有了更多花樣，你可能不覺得，但新玩法確實佔了遊戲開發很大一部分。
之所以單獨強調這點，是因為從技術角度來看，《逃出生天》和《雙人成行》在技術層面有不少相似點。在《逃出生天》開發收尾階段，程序團隊碰到了比較大的問題，他們速度跟不上開發需求了，因為《逃出生天》玩法類型特別多，有射擊戰鬥、有飆車追逐，很多獨特的玩法，做出來只用了一次。
而且設計團隊又在不斷修改需求，經常改變設計方向，這使得程序很難高速工作。所以他們着手開發一些新的東西，他們在虛幻引擎（UE4）裏面支持了AngelScript腳本語言，UE4也是《逃出生天》和《雙人成行》都在用的引擎。
我們的程序製作了一個插件，讓UE4裏面可以寫AngelScript，作為C++和藍圖編輯器之間的快速腳本層。這就非常有意思了，因為這樣就可以用腳本語言進行快速編程，遊戲運行的同時，修改腳本並保存，修改立刻就會出現在屏幕上。這個功能特別棒，而且非常可靠。
這件事情引起了我和設計團隊的注意，這種腳本語言看起來非常有用，就我個人而言，我之前做過Mod和獨立遊戲開發，自學過編程，我覺得AngelScript腳本不僅對程序員有用，對設計師也很有用，可以幫我們製作玩法原型。我感覺團隊裏應該有一半的人都很感興趣，至少我是感興趣打算用一下的。
所以在開發《雙人成行》的前期，程序同事會給我們科普腳本編程基礎，教授我們如何編程以及如何使用這個神奇的工具。
所以從前期開始，AngelScript就融入了我們原型階段的開發流程。開發《雙人成行》的早期，設計還沒成型、我們也不知道遊戲會長什麼樣子的時候，我們會坐下來，嘗試各種玩法，並且不會太在意這個玩法的可行性，而是專注於這個合作玩法是否有趣。
然後 我們會用AngelScript自己把想法寫出來，作為鍛鍊使用工具的實踐。通過塑造各種玩法、嘗試表達各種理念，我們開始理解遊戲的趣味點，遊戲的故事也這樣逐漸成型了。
這時候我們意識到，那些腳本系統原型讓我們設計師可以全程參與玩法的開發。
通常情況，設計師最多做個小原型，然後要交給程序開發剩下的部分，交接的過程必不可少。但現在我們可以不用這樣了，這是個巨大的轉折。因為這意味着想出這個創意的人，可以全程參與想法從提出到落地的全過程。
還有一個重要利好，就是負責玩法的程序同事，和負責關卡的設計同事，用上了同一套工具。這種變化也很不錯，我們原本是關卡設計團隊。但現在，我們可以一邊編程一邊設計，設計師、程序的職業界限變得模糊，大家都變成了負責創意的人，邊構思邊實現。
我認為這是一種很棒的變化。因為通常大家都有具體的頭銜，然後會圍繞某種邊界展開工作，比如我是動畫師，就不考慮非動畫的事情。當這種考慮範圍變得模糊之後，大家都會去思考用户體驗。所以我認為這種變化是非常有益的。
那我們的工作流程有什麼改變呢？我們可以用一個案例，從頭到尾走一遍我們的創作流程。
首先是從故事板開始，我們會做一個故事板，為整個遊戲提供背景信息。故事板聚焦於故事劇情，而不那麼關注具體玩法和關卡設計，主要講的是背景設定和故事。
我們會把故事分成幾個章節，我們來看其中一個案例「羅斯的房間 · 恐龍樂園」。根據遊戲進度，這個時候的玩家，或者説遊戲裏的角色，還沒和好如初，而且還沒適應這個身體被縮小的奇妙世界。
所以我們在遊戲前期的思路就是，保持關卡不變，但加入新玩法，讓玩家習慣操作，同時新增一些別的設定。
那參考故事板的設定，我們知道羅斯的房間是一個玩具屋，那玩具屋會有什麼好玩的？
我們就想了各種主題，然後想到了玩具恐龍。這是個很常見的玩具，大家都很喜歡。然後我們圍繞恐龍進行頭腦風暴，我記得提到特別多的就是長脖子雷龍。
從故事的角度，我們將其設定為一輛玩具火車穿過房間，玩家需要乘着火車完成關卡，然後火車軌道會被各種東西擋住，移除阻礙才能繼續前進。
我們就想，如果能用這頭長頸恐龍，讓它清理軌道、移除碎片應該會很有趣，於是就有了一些初步的想法。
這其中有一個關鍵點，多人合作遊戲非常重要的一件事就是，如果一個玩家擁有某個獨特能力，比如這裏一個玩家控制了長頸龍，另一個玩家也需要有事情做。
然後我就想到了，能不能再搞一隻小恐龍，讓它橫衝直撞，把東西頂起來、翻轉過來，這樣兩個玩家都有事情可以做。
當然這個階段還只是隨便構思，但接下來我們會立即開始製作原型。我會和一個程序員分工合作，我製作其中一隻恐龍，他做另一隻，就這樣，只需要兩個人。
像我們的遊戲，還有一個特點，幾乎每個關卡都有獨特的玩法。我們必須限制每個模塊所花費的時間，要嚴格排期。因為當你從零開始製作玩法的時候，很容易花上好幾周的時間，探索這個長頸恐龍到底能做什麼。但我們必須確保時間花在刀刃上，沒時間試錯。
所以每週都有排期，明確這周要完成些什麼。實際上製作這整個場景，也只花了我們幾周的時間，下一步就是開始落地。
而考慮到時間限制，我們意識到要大幅限制開發範圍，就必須讓功能足夠簡單。如果長頸恐龍可以隨意走動，隨意把東西挪到別處，那將是巨大的技術挑戰。所以我們決定説，行吧，物體只能2D平面移動，這樣開發量就變得可控了。而對玩家而言，畫面可讀性會更好，操作也更容易了。
確定這些簡化之後，我們開始評估另一隻頂翻物體的小恐龍。我們意識到，讓這隻恐龍到處走動同樣會造成各種問題，所以也進行了限制，這隻恐龍也只能在2D平面上移動。
這時候，我們已經有一些技術實現的想法了，下一個難點便是，開發時間真的太少了。
我們甚至沒時間給小恐龍加一個跳躍之類的技能，它只能在軌道上面來回移動，而且頭撞的動作也比較難做。所以我們決定替換成地面衝撞，砸地面的時候障礙物會被頂飛。開發進度終於開始有點進展了。
這時候一個星期過去了，我們通過編程把各種模塊組裝起來，得到了一個粗略的關卡，可以用來測試了。我們還意識到，需要一些錦上添花的元素為合作玩法做一些額外改進，讓兩頭恐龍感覺是互補的關係，大恐龍可以挪走物體，幫助小恐龍推進。
於是我們在設計中加入可一個新的機制，讓大恐龍可以抓住某些物體，防止它們被頂飛。這樣，我作為設計師就能加入一些有趣的解密元素，因為大恐龍可以控制障礙物狀態，就需要和小恐龍配合，也就需要玩家之間進行溝通。
完善這些設計之後，整個創意看起來就不錯了。我們就開始着手實現這一切，製作這個小型場景，把關卡和我們搞出來的玩法拼接起來。從設計師的角度來看，後續就是一些標準套路了。首先從教學開始，讓玩家操作第一隻恐龍，幫助另一個玩家獲得第二隻恐龍。第二個恐龍就負責撞擊地面的動作，玩家學會這些之後，再一步一步增加難度，當這些場景都做出來了，我們直覺上也覺得沒問題了，就會開始進行玩家測試。我們會請工作室以外的人來試玩，然後觀察他們對關卡的反應。
我們重點關注的是，他們是否理解我們設計的流程、玩法。通過試玩，我們會發現一些需要加強引導的地方，比如鏡頭要偏移一點兒、屏幕上要加點提示、顯示按鈕對應的操作之類的，但總的來説，關卡的感覺不錯。
我想強調的是，在測試的早期，我們主要看玩家是否理解玩法，但不太關注他們是否覺得有趣，然後我們會繼續思考故事設定：玩家怎麼到達這個關卡、過場動畫等等這些沿途會發生的事件，為這個玩法提供背景，讓它融入到整個故事當中。
縱觀整個過程，有幾件事我特別欣慰，覺得特別好。首先是：我和程序坐在一起工作，我們用着相同的工具，效率得到大幅提升。另一件事就是，我能全程保持掌控，從最初的想法到最後的成品，這也是巨大的利好。當然，一些具體的系統需要交給程序來做，因為邏輯比較複雜，但我覺得新的流程很棒，我們之前提到的工具允許設計師全程參與。
你可能會想：這算是冒了很大的風險吧？你一個關卡設計師，本來只負責關卡，然後突然給了你這麼多其他的職責，除了關卡設計，還有玩法、編程等等，這不是有風險嗎？我也承認確實有。但是像這種遊戲，本來就需要打破常規，才能成功製作出來。
對我來説 我有一個信條是：如果你每天去健身房都只練相同的重量，你就無法發揮全部潛力。所以我認為這個流程裏比較好的一點，就是讓每個人都稍微離開了舒適區，讓大家發揮更多潛力。
我作為一個領導者也是如此，看到團隊全身心投入工作，大家都在過程中獲得了成長。大家都把工作當成自己的事情，努力提升自己，也獲得了很多實際上手的經驗。
最後還有我剛才提到的簡化玩法的問題，通過限制範圍和簡化功能，這也有兩方面的好處——首先是開發時間，我們沒有很多時間給每個玩法。還有一個好處很少有人提到，就是玩法變簡單之後，溝通起來也更容易了。如果只需要按一個按鈕，教會玩家也變得容易了，所以這也是很好的副作用。
我就説到這裏，感謝你的聆聽。
Q&A環節
Q1：你如何評估一個關卡的難度？
Filip Coulianos：評估難度主要靠的就是收集玩家數據，可以是從統計學的角度，比如你是一個已經上線的遊戲，有成千上萬的玩家，或者只是請幾個試玩的人坐一下定性測試，這種時候你坐在測試對象後面，觀察他們做了些什麼，或者觀看錄屏。
有一點比較重要，你要清楚自己的遊戲到底是什麼，是困難還是容易？團隊裏每個人對這些詞的理解會不太一樣，那首先就要確保，大家都認同容易的標準，才更容易實現；而且，應該制定一些難度標準，比如（平台遊戲）玩家跌落就會死亡，如果我們想做難一點，那玩家每次挑戰中，最多隻能死兩次，我們可以設置一些參數，所以整個團隊商量好這些之後，在做評估就非常簡單了。你只需要觀察玩家的行為，如果摸個關卡里玩家不斷地失敗，那你就要分析了，這是不是説明，是關卡普遍太難，還是説只是這個玩家的問題，或者説這個玩家，是否代表了你遊戲的受眾。
而且，這裏有幾種不同的步驟，比如設計解謎關卡這種不是勝負爭奪的挑戰，它可能是一個謎題，需要玩家想辦法求解。如果你製作的是這種智力型遊戲的話，你需要考慮玩家被難倒的情況，遊戲最多允許玩家停頓思考多久，如果過了太久，那挑戰對玩家來説就是太難了。
所以總結一下，你需要制定一些框架，幫助你評估難度，同時確保整個團隊都認同這些規則。之後，作為一個開發者就可以放心地進行玩家試玩測試，檢驗難度是否符合預期，之後再通過調整挑戰難度或謎題的難度，使其符合預期目標。
Q2：你覺得多人合作遊戲的設計關鍵點是什麼？
Filip Coulianos：合作遊戲的設計關鍵，顧名思義就是“合作”“協作”，這對玩家體驗非常重要。需要給予玩家合作的能力和空間，或者説，提供給玩家的工具必須要搭配使用，比如你有一個釘子，我有一個錘子，那你需要扶着釘子，我把它敲進去，這是最簡單的形式。
但遊戲必須要鼓勵，有時甚至是迫使玩家一起完成一個目標，這就是關鍵點。更進階的設計就是，加入一些需要把握時機的操作，比如你不能把釘子放好然後走開，10分鐘後拿錘子的過來敲一下，而是要確保兩個玩家同時在場，讓他們溝通如何把釘子敲進去。