Unite 2019大會今天在上海開始了第一天的日程，除了Unity官方的技術乾貨，也有一些分享來自獨立遊戲，比如Switch平臺上廣受好評的《胡鬧廚房》（Overcooked）系列。
《胡鬧廚房》系列背後的故事堪稱傳奇。遊戲初代開發者只有兩人，一度連辦公室都租不起。而遊戲發售後由於其獨特的玩法和社交性大獲成功，Switch版本售出50多萬套。
續作《胡鬧廚房2》也延續了前代的成功，成為NS平臺實體銷量Top 30的遊戲。不過遊戲的升級換代並不容易，為了實現玩家呼聲已久的“多人在線合作”等玩法，遊戲開發期期間經歷了不同的技術難題。今天的Unite 2019大會上，《胡鬧廚房》系列的發行商Team 17總監David Smethurst分享了這一獨立遊戲爆款背後的技術思考。
以下為David演講實錄：
我叫David Smethurst，是Team17的總監，負責編程內部的工作，與我們的合作伙伴合作。我的演講是有關於《胡鬧廚房2》（Overcooked 2）的內容。
先講一下游戲的歷史，《胡鬧廚房》最早由Ghost Town Games開發，一款多人合作、烹飪益智類遊戲，可以讓4位玩家同時在一個遊戲中，通過多個步驟準備烹飪。遊戲的玩法很有趣，也獲得了很多的獎項。遊戲本身非常成功，但玩家對它有更多期待，Ghost Town發了兩個DLC，仍然覺得不夠。
所以接下來在續集中我們想要做什麼呢？
這是續集中Team17所做的工作，我們對續集很感興趣，希望和Ghost合作，提供一些功能集，讓更多的人蔘與，在保持本地遊戲的基礎上，支持全球聯網遊戲。多人在線互動是遊戲核心的功能。
當然，我們也希望在關卡中設置更多內容，有一些人已經在不同地區和分節關卡中有不同的進度，但是我們還想要做得多一些，所以我們在關底設置了動態“英雄”的關卡。
這是一個氣球的關卡，遊戲設計的第一個原型關卡。在飛行的過程中，玩家就是這些廚師，被放置在氣球裡，隨著時間推移，暴風雨進來，繩子被卡住，籃子落到地面，場地佈局和食譜也改變了。這就是《胡鬧廚房》中，Team17所做的工作——我們做了更多的設計，將玩家分隔開，你需要在這些環境之中來找到切分的可能。
比如我們在場地中加入了一些障礙，準備區和烹飪區的人必須在分離前進行食材傳遞。這裡面我們還設置了時間限制，以及新的廚具和可投擲的道具，也更新了一些物品。我們通過設置各種挑戰來達成目標。
比如這裡玩家還需要跨越邊界，運送食品到另一部分，或者是讓玩家來規劃一個方案。穿過兩個部分之間的間隔，回到自己的區域。當然，我們還需要設置更多食譜，所以我們加入了像壽司、漢堡、披薩這些，以及烤爐之類的新工具。這裡地圖也有變化，續集為什麼要這樣做呢？因為遊戲本身是受歡迎的，可能有很好的前景。
這些是Team17之前所做的工作，《百戰天蟲》我們開發了21個版本，還有其他的內容我們也做得非常成功。這是我們在《胡鬧廚房》中做的一些工作，首先要解決風險最高的部分是聯網。
我們先從原始代碼庫開始，希望能夠保持遊戲本身的玩法和風格，但是要增加多人在線，同時不損壞遊戲原有的風格。所以我們非常需要網絡插件的增強，我們可以使用Unity或者是完全重新編寫，但考慮維持到原有風格，這不太可行。
所以我們來看看第三方插件，這裡有幾個選擇：Photon、Ulink、Forge和Darkrift，這幾個插件要考慮到成本，有些是雲平臺的付費，我們是多平臺發佈，要保證兼容，所以插件使用要考慮到重要的因素，就是要對原有的代碼進行兼容。如果是有過多的設置或者是讓遊戲更加複雜，那我們的開發時間會受到更大的影響。另外大量的開發人員，在解決方案上可以幫助我們設置到最好。Unity有一個高級的API，就是HLAPI，通過它進行網絡連接同時也進行很多工作的同步，包括變量的協調。新的代碼庫也有大量的工作要做。
接下來就是傳輸層，而且還要考慮到像平臺的套接層，以及比較低層級平臺上的表現。這是在Unity中可用的傳輸層之上的網絡層，我們需要完全控制，並且決定每一個平臺上的具體細節。而我們內部的程序員也在開發這樣的項目，同時我們也會培訓其他的成員來提供內部的支持，共同達成我們的技術需求。
現在，我們來看看網絡拓撲。這部分在網絡構建中非常重要，我它決定了遊戲何時是需要去進行通訊和協作的，還有就是我們的數據以及帶寬方面的限制。我們採用的雲託管服務器需要非常大的帶寬，因為客戶包來回傳遞這會導致成本非常高，每一次都會因為新加入的玩家來遇到更大的帶寬要求。
另外也要保證所有的遊戲端都要可以充當服務端，每個端都有對象，在所有點都有所有權，然後在單點保證信息的傳遞，它是多向的，非常混亂。所以我們採用cs結構的網絡拓撲形式，然後對客戶包進行調整，它是直接適用於遊戲當中的物理對象，選擇拓撲結構是因為他們適合我們的需求。這也決定了我們使用原始的遊戲的代碼，就可以保持原有的風格，這對我們來說很重要，可以進行不同的模擬。另外是代碼在不同服務器上的相互移動，也可以更加高效。
最後是更高層級的網絡上，通過Unity在傳輸層上傳輸自己的解決方案，我們有一種辦法讓原本的腳本在網絡環境下工具，而不需要對這些腳本進行破壞性的修改。我們使用額外的組件來擴展。這也意味著每一個原始的組件我們都要做出三個版本，一個是服務端，第二個是客戶端，第三個是原始功能。我們的服務器使用全部三個版本，其他的端是使用兩個版本。當我們使用Unity時，我們為遊戲當中的每一個對象添加網絡組件，以便提供唯一的網絡標識。
我們還提供了客戶端版本，如果將現有組件加入當中，這些遊戲已經預先應用到了廚房設計的預製件，無論遊戲對象如何使用遊戲的腳本，我們都希望網絡代碼在所有的層級當中順利移動，這也意味著說，我們會通過在加載關卡時對場景進行掃描的方式，來增加網絡組件。我們迭代場景中的所有對象，對於每一個對象，我們都會添加server組件或是client組件。這就是無論我們如何捕獲這些實例，都無須檢查每一個資源，也不用告訴設計師和美工，如何在我們的GameObject上做出修改才能聯網。
做《胡鬧廚房》續集時，從第一天我們希望遊戲保持這一狀態。現在這一遊戲仍然可以單機運行，同時也支持多人在線遊戲，同時我們的功能在開發時進行網絡測試，在完整的pipeline中能夠足夠地去完成它的工作，避免在實際的平臺上運行不了的情況。
這是我們新的網絡層，現在通過掃描和設置場景中預先存在的對象添加多人支持，同時也需要在關卡中生成新的對象，因此創建新對象的級別中是可以生成一些預製的遊戲對象，列表來完成目標，同時通過網絡生成新對象引用列表。聽起來很簡單，但是需要確保所有的客戶端，在所有的衍生對象上都能保持同樣的ID。這樣就意味著我們的網絡、數據的路線非常重要。
當遊戲開始運行時，接下來就要進行網絡的驗證，我們必須重新編寫所有的代碼，首先是要支持移動玩家的平臺，同時我們還需要支持各種不同的物理對象。比如物品的掉落，比如移動，還有玩家在廚房當中扔食材等。我們建立了一個系統，客戶將他們的輸入發送到服務器，並且進行整個模擬，向周圍傳輸結果。這樣的話，我們就有可能面對一個滯後的問題，在等待服務器物理結果傳輸回來，我們還允許他們在服務器上直接移動，以響應本地的輸入。唯一的問題是，物體放在遊戲環境中會移動或者是旋轉，因為它們沒辦法平滑地在平臺上相互移動。
為了解決這一問題，我們在所有的物體上都是通過統一平臺，來防止物體旋轉滑過的時候發生誤差，而且廚師也會在他們的平臺上移動食材，如果不能讓廚師和食材移動的時候，就會出現情況。我們可以檢測廚師和空間的定位，將廚師角色和物體同時移動，在這當中進行了大量的迭代和測試，特別是低帶寬情況下，遊戲的玩家也沒有發現誤差，但是仍然有一個問題：兩個玩家相聚比較晚就會出現一些解決不了的延時的問題。
接下來看看網絡的功能，我們希望性能保持穩定，尤其是幀率，玩家也希望玩遊戲有流暢的體驗，而網絡的速度是比較穩定的。我們帶寬足夠，但是要保證數據傳輸量不要太大。原始的遊戲是將各個預製件水平拼湊在一起，所有的站點都是單獨的對象。那麼在這裡，我們需要大量的繪製調用，因此，運行的性能是比較差的，為了能夠幫助美工建立了一個地板編輯器，就是說可以在場景的視圖中編輯地板的位置，這樣我們可以做計算，進行可視化的處理。
那麼我們也確實是傳遞給美術，我們必須在Maya中創建整個對象的FBX的文件，然後導入到Unity中。而不是在編輯器中編輯，並且將對象簡單地組合在一起。但是為了解決我們在繪製耗時，我們依然需要做效率上的提升。比如說我們的美工他們需要更多的紋理和共享材料，我們會由渲染器進行合批，另外為了在滿足美術的要求的同時，達到能在最差的平臺運行的標準，我們選擇了配合Forward Rendering使用烘焙光照。為了輔助烘焙過程，我們會有專門的工具在專用的機器上運行。
另外我們還有一個編輯器工具，他們是強制在預製的物體上應用正確的設置。比如說它強制設置Motion Vectors選項為”Camera motion only”，以防止的TAA中的額外DrawCall開銷。我們要求所有的美工關閉靜態物體的Light probe功能以防止合批被破壞。我們還要求美術對所有不對場景產生明顯畫面影響的物體關閉陰影，這不會影響主要的操作區域的視覺質量。並且我們進行定期Profile分析，來確定瓶頸在什麼地方，我們也要確定未來一個開發更好的改善機會是怎樣的。
我們在使用Unity的Profiler的時候，也會去進行特定平臺的Profiler的研究，在進行遊戲的時候，我們還要去進行關卡和關卡性能的檢查，我們設計了簡單的性能、跟蹤的系統，這個系統在一個關卡中對FPS進行採樣，關卡結束向玩家（這裡指的是QA）彙報統計的數據，這是分不同的幀數範圍來進行彙報，還有幀數波動等等。
同時我們也會進行質量的檢查，另外我們還會收集標準差，幫助我們評估幀速率的檢查。有時候這些測試可以自動化地進行，而且可以非常快，容易規劃，另外就是在夜間可以完成，這樣的話，很容易去幫助我們提交數據。在這部分，目前一切進行很正常，但是實際上我們仍然遇到困難，比如說項目結束時發現特定關卡的CPU的性能出現在渲染問題上，對這些問題我們確認以後很明顯是DrawCall瓶頸，部分物體還是基於Prefab拼接，而不是在Maya中作為一個整體制作。在Unity批處理材料時，沒辦法在低端機上繪製足夠多的DrawCall。之後我們做了很多美工方面的工作，因為我們的內存資源是豐富的，我們選擇將相同的材質的對象合批，這樣我們就可以減少不需要資源的浪費。
在可能的情況下，我們還進行了網格的調整，儘可能合併和減少資源的調用，在平臺的低端平臺上運行時依然還是會面對很大的挑戰。因為我們內容的創作者它想要實現更多的東西、更多的內容和更多的光照效果和細節。所以我們必須在統一的渲染管線中實現操作。所以在這裡很重要的一點就是渲染功能，因為我們低端控制沒有大量的內存，幀速率降低，而且我們考慮效果的時候是需要壓縮的，一開始進行的測試它是採用Forward渲染的，通知渲染了除太陽以外的所有燈光，最初在照明方面我們取得了很大的進步，包括深度緩衝區等。
另外我們還必須在後期效果上進行驗證，就是使用Depth+Normal，最初使用這些工具降低了成本，但是仍然是有效率和時間的問題。然後我們最後的結果就是包括大量的綁定陰影，雖然說屏幕空間的陰影對於我們的陰影效果非常有用，但是它是比較花時間的。尤其是在這一過程中，我們是進行了一些常規的陰影貼圖。那麼我們所選擇的是在這個工具箱中的陰影，陰影的分辨率非常高，我們採樣一次shadowmap，通過雙線性插值時陰影變得柔和，來保證視覺效果相同。
最後一個問題是後處理，最初花費了10毫秒，降低Quality設置，在每一個像素上做更少的讀入和其他的優化，會讓整個的速度都會更好一點，但是很明顯，我們需要一個新的解決方案。同時你可以看到SSAO是唯一的一個後處理管線當中需要法線的部分，所以如果我們可以去掉這個步驟，我們就可以簡化pre-pass。我看評估了volumetric obscurance方案，一種極端簡化的SSAO技術，是非常方便而且容易實現的SSAO技術，它由CryTek針對XBOX360和PS3開發，這樣的一種方法解決了我們高樣本的需求，同時使得定製的發生器的輸出，只需要4個樣本就可以獲得非常好的結果。
TiltShift也是經常使用的，經常5毫秒以上，最低質量的設置中也是如此，也是要優化它，不然我們的美工也是無法控制和使用的。他們只需要在底部和頂部使用這一技術，在我們的攝像機下，也就是最近和最遠的區域，我們採用最新穎的方法，因為我們選擇不將它全部變成全屏後處理效果，相反地我們渲染了兩個四邊形，一個在底部一個在頂部，其效果的覆蓋40%屏幕的區域。
進一步的優化是，其實我們並沒有實現一個正確的景深效果，我們研究了一些2000年初的技術，你只要在模糊紋理和清晰紋理之間進行雙線性插值，就可以得到一個從模糊到清晰的景深過度。最後一個改進是把post processing stack中的FXAA的文件拿出來修改，強制它使用主機的code path。默認的是使用最高質量的實現。這個修改必須在源代碼中進行，因為這些接口沒有暴露出來，也不會受任何Quality設置的影響。
剛才講到了美工的原則，就是減少網格的複雜度以及合併DrawCall。另外我們區分了渲染用的網格以及碰撞網格，主要是為了減少碰撞耗時。我們在網絡層其中的增加的一部分關鍵就是更新管理，這個概念在開發後期添加到遊戲中，當我們通過系統向遊戲中添加大量的邏輯和修飾組件時，我們自然會增加場景當中實現了MonoBehaviour的Update方法的組件數量，這會導致引擎從C++跳到C#的回調增多，性能不是特別好。所以我們每一個網絡組件實現了UpdateSynchroniser接口，而不是通過MonoBehaviour的Update方法。
通過這樣的修改，組件所花費CPU的時間大大減少。我們還在加載界面增加了一個額外的步驟，就是掃描場景當中某些關鍵組件當中的某些關鍵實例，並且保存它們的引用，這對玩家交互代碼很重要，因為每一幀，我們都必須掃描所有的可以跟玩家交互的GameObject。對於遊戲當中的對象，預先存儲的引用數組大大減少了分配。還有一個非常重要的改進，就是把委託放在一個List中，而不是使用+=,-=的方式來進行註冊，功能是相同的，你可以看到加等和減等是相當大的垃圾源，所以我們還是要考慮儘量避免他們的發生。
還有一點是我們有時候沒怎麼講到，是用戶界面的一些具體元素的性能，特別是玩家的HUD，因為玩家用它們來理解遊戲世界遊戲中心的一些核心數值。最開始的時候，屏幕頂部的一些小部件都是帶有Animator組件的用戶界面元素，這個問題在於，UI組件的移動，會導致我們的Canvas被標記為需要重新佈局。這對性能是有影響的，尤其是進行多處組件都在這樣做的時候。
怎麼辦呢？我們乾脆移除了Animator，將UI元素實例化設置成靜態的狀態，並且使用著色器進行渲染，這樣相當於我們得到了動畫，但是我們的畫板還是非常乾淨的。如果在畫板上任何內容發生了變化，整個畫板都被標記使用過的或者是非乾淨的，並重新計算所需要的內容。所以將所有的靜態元素放到一個畫布上是最好的方法，將動態元素放到單獨的一個Canvas上也有用。對於單個元素的影響我們可以控制，我們重新組織了層級結構，因為大大提高了時間的效率。另外一個就是性能優化就是一個定時器UI，一開始我們用一個整形計時，然後把整型轉換成字符串，字符串的創建會造成垃圾的產生和廢物的產生，我們通過預先分配的字符串來，避免垃圾的產生。
其他的內容或者是更加具體的是，我們的輸入是否有延遲。你可以看到Switch的版本最終實現的目標是每秒30幀，PC、XBox的目標是60，與其他版本相比，Switch的版本即使是在穩定情況下也是響應很慢的。
通過調查我們發現兩個問題，遊戲移動系統以和遊戲相同的幀數進行，它是30幀或者是60幀，當玩家施加一個力，只是增加DeltaTime並不會實現同樣的結果，因為加速度和DeltaTime成正比，而速度不是，就意味著有一個物體在30的速度下加速變慢，我們必須把角色的刷新頻率鎖定，使其以60FPS的速度運行，哪怕是在較低的幀速率下也是如此。
即使做了這樣的調整還是很慢。我們使用高速的攝像機錄製200FPS的視頻來進行測試。從我們輸入到它出現到屏幕上的時間，我們拍攝屏幕和控制器，並且檢測到輸入後出現大白框的顯示，可以測量遊戲的輸入延時，這個測試我們做了5次，同時計算了平均值。我們發現在遊戲中有一個與幀速率的延時，60PFS當中延遲的是一半，PS4是5幀，XboxOne是3幀，Switch是3幀，直接讀取本機的輸入，測試時間為PS4節省一些時間。最後我們將這些時間安排在一起，他們都來自於Unity，我們和Unity進行交談，看看我們有沒有方法來解決這樣一些問題。所以當你有機會做出這樣的變化時，儘早測試，特別是由於遊戲當中所產生的。
還有一個Split—Pad，其中有手柄問題，半個手柄操作譯名廚師的控制方法。如果想讓兩個用戶交互，或者做表情的話，這種新功能是對整個環境是非常敏感的。玩家不能同時切菜和投擲，因為相同的按鈕不能用於兩個操作。
由於兼容性問題，我們無法在聯機模式下使用Split-Pad，Split會創建一個新的遊客玩家，在聯網環境下，這個新玩家無法通過認證。但是我們確保了在線環境下可以用半邊手柄來操作廚師的能力，它有一定的支持能力。
往後看，並不是所有的這些主機都有相同的功能，我必須要考慮到主機的一些差別。而且UI必須滿足這些不同主機的差異性。比如說這種系統集成到主菜單當中，選擇玩哪種模型之前，主人邀請朋友參與到他們的廚房活動中，這是非常好的系統，尤其是對於PS4和Xbox1和Steam來說。
但是在Switch上我們遇到了一個問題，這樣的功能並不是所有平臺都支持的。我們需要在平臺上保持相同的體檢，就需要不同的用戶界面，這樣主機就可以進入在線的狀態，他們的朋友通過自定義菜單來加入遊戲，我們需要另外一個自定義的代碼路徑來支持瀏覽列表的概念，以支持附近的玩家加入進去。這樣的類型我們在下載的時候，有的時候都是在爭奪這一焦點，常見的例子是由於某些錯誤的狀態，如手柄斷開鏈接而出現的對話框，這些對話框的焦點，就是你要將它關掉焦點將丟失，所以我們要考慮到它的邏輯層。
由於我們是在主機上開發，我們還需要計劃一些不定和DLC作為其中的部分，在開發NS版本時有時候需要AssetBundles的支持。同時平臺也要求你將Asset收集到Bundle當中，而不是將資源添加到場景當中。所以在遊戲當中，我們創建了自動化的系統，將資源添加到一個固定大小的Bundles裡面，我們儘量調大這個閾值，創建小的資源包，然後減少不定的範圍，或者是限定補丁的大小。我們使用了Asset Bundles，當你從裡面加載數據時，你的加載時間也會受到影響。
基本上講完了，大家有問題可以提問。這是非常好的遊戲，也有很多人非常喜歡《胡鬧廚房》的遊戲，我們會不斷地優化我們的管線，希望能夠讓我們覺得這個工作還是有沒有完成的地方。尤其是關於它的細節，其中的一個挑戰就是我們希望能夠有更多的設置。
一開始的版本當中，遊戲使用了大量的半透明面片，讓美工可以控制，性能非常差。當遊戲發佈以後，我們發佈了特別建模的葉子，這提高了性能，也是讓遊戲有了風格。這樣一種單獨建立的樹上的葉子，也是比較好的改進，因為它更加適合我們的風格。
此外，在最初的遊戲版本當中，幾乎每個遊戲對象都有自己的素材，還有一個簡單的著色器，完全滿足了對象在遊戲開發當中的需求，雖然這讓這個遊戲的開發變得更加簡單，這讓我們開始為每一個不同主題開始繪製它的紋理圖，並且貼合實際情況的著色器，每一層僅對所有的藝術資源使用很小的這樣一種素材，這隻用了1/4，所以提高了整體的幀速度，這是我們發佈以後最大的單性能提升，因此，我們的遊戲基本上都是以60秒/幀來運行。
目前我們已經發布了DLC，每個DLC都有一個小型的活動，自從遊戲發佈以來，我們還添加了練習和生存模式，玩家可以很放鬆地學習，並且知道每關怎樣玩。通過精心設計的組件系統，運行時可以切換網絡組件和本地組件，無需對場景進行更改即可切換本地模式和聯機模式。這可以讓補丁非常小。
我的演講完了，謝謝！
推薦閱讀
明日方舟｜隱形守護者｜自走棋手遊｜疑案追聲
遊戲人眾生相｜版號｜遊戲公司招聘｜王牌戰士
如果你認為寫得好，不妨點個“在看”唄
最新的遊戲專業書上架啦！點擊下方小程序即可獲取
關注微信公眾號“遊戲葡萄”，每天獲取最前瞻的遊戲資訊
相關推薦
