《不成思議之夢蝶》建造人：操縱Unity把遊戲從PC 移植到Switch

5月11日，由Unity主辦的行業開發者大會Unite Shanghai 2019在上海國際會議中心召開，作為推出過《鯉》、《不可思議之夢蝶》的天津隊友遊戲的製作人，李喆就分享了團隊把《不可思議之夢蝶》從 PC 版移植到 Nintendo Switch 的經驗和心得。

以下為遊戲陀螺整理的演講實錄：

手柄適應性、存檔、聲音格式、插件等方面，《不可思議之夢蝶》的處理方式

先說一下基本的開發，Switch需要大家提前知道一些知識，不能用標準的Unity Input來做，我們用了一個插件Rewired，這個可以適應任何的手柄，我們還用了HD振動，還運用了Joy-Con等5種輸入方式。玩過Switch平台都知道，Switch兩個手柄是可以拆出來變成兩個手柄，然後它的按鍵位置都會發生變化，你要知道所有方式並對遊戲設計做好很好的規劃，像《不可思議之夢蝶》是不支持Joy-Con Left和Joy-Con Rirght。

《夢蝶》有大量的動作解謎要素

接下來是存檔問題，存檔文件都是有讀取要求的，需要根據范例重寫I/O部分來做。在獎杯系統里面，做的PC版本是有獎杯系統的，大家會收集獎杯去玩遊戲，這些獎杯在任天堂平台都沒有，我們要自己製作彈窗和展示。

在聲音格式方面。像Switch平台支持Opus格式硬解壓，使用的Wwise可以支持OpusNX格式。它自帶功能有很多，這個很多平台的聲音都是可以的支持，也可以對Switch平台有一個格式，甚至可以調用硬件，這個有一個壓縮格式，是可以直接壓縮進入內存的，在運行時占用內存會更低一些，如果做的遊戲沒有考慮內存問題可能會爆掉。

還有使用插件，像Wwise和Rewird是需要考慮授權和版本問題，像Wwise根據不同平台有折扣，Rewird是免費的，是一次性支付可以使用的，在打包時並沒有針對平台代碼。這個代碼怎麼獲得的，你要通過任天堂開發後台提交申請，是由任天堂提供給Wwise的開發商，再通過Wwise開發商提供信息給到你，這個東西是沒有技術難度，是有時間考慮的，像Wwise是需要兩個工作日的。

如何選擇Unity版本？

上面說的是一些具體基礎上的經驗。再說一下遇到的問題，這些問題如果沒有動手做過，幾乎是想不到的。如何選擇Unity版本？這個版本隨著SDK版本變化，你提交遊戲的Unity版本要求很高，如果項目沒有達到要求的最低版本的話提交就會失敗，是會被拒絕的。我們遇到一個問題，可能有時候打包出來的遊戲在Switch出現一些崩潰問題，而且只有非常少的信息提供給你，你去開發者論壇搜尋根本就沒有任何線索，我們要嘗試切換一下更低版本，去測試這個打包是不是正常。我們的遭遇是，一開始是用2018.1.1去開發，開發時都是正常的。再切換到2018.1.9直接打出來的Rewird就是正常的，大家也可以分享一下經驗，也許有其他辦法可以直接解決。

如果用兩個版本，比如說我開發功能，可以去調試，像《不可思議之夢蝶》遊戲是56G，每次開發版本要重新導入其他資源，如果你在SSD硬盤導入一遍遍工程需要一個多小時，完全接受不了這個時間，所以就可以加入一個Cache Server，但是時間還是長一些，最後又想出了Git，這種方式是最快的。

通過修改聲音格式，從90秒的載入時間，減至30秒

關於載入時間，Switch平台存儲實際上是用的一種慢速的存儲方式，像《不可思議之夢蝶》這種的遊戲，第一關載入時間大概在90秒左右，你可以做一些載入動畫什麼的，這個時間還是太長了，沒有辦法忍受，我們只做一個東西就變成了30秒。這里我要提一個非常有名的遊戲——《ICEY》，這個在發布時我正好和他們在辦公室聊天，就發現工程師一直在調試，他發現遊戲啟動時太慢了，整個遊戲前60秒都是黑屏的，很難調試。

另一款獨立遊戲佳作《ICEY》

其實我就突發奇想，要不改一下聲音格式，他就切了一下，直接就從60秒變成了十幾秒的載入時間，瞬間可以接受了。因為《ICEY》是有很多的語音聲音文件，打包還是在文件夾底下的，所以要把所有都載入內存。這種方式對Switch有壓力的平台有更好的優化方式。

我們還遇到一個問題，第一次播放聲音時有一個卡頓延遲，但是反復播就沒有了。我們通過將《不可思議之夢蝶》這個遊戲聲音的加載改成流式加載就可以將加載時間從90秒減少到到30秒，用最小的事情產生最好的結果。還有一個Wwise可以把不同音效打在不同的SoundBank里面，還有一些共同的音效可以打在公共的Bank里面，可以通過這種方式再次減少遊戲運行時的這種聲音資源帶來的壓力。

烘焙工作，可以大幅度減少包體容量

在包體尺寸的優化方面，Switch並沒有太大的要求，我們也是順便優化一下包體，主要的優化方式是用Console和Open Editor Log來做的，你很難發現是不是打入包里了，有些資源覺得根本沒用，會通過材質球還會進入包的安裝部分。所以通過這個東西完全清楚看到哪些在包里，哪些是不在包的，肯定要把包里的東西進行重點優化。像Switch平台是支持ETC2和ASTC這種模式的，會很快速載入的，你在壓縮會產生非常大的壓縮率。找到紋理之後去覆蓋平台設置，可以切換不同壓縮格式，壓縮格式也不是越小越好，因為壓縮的紋理是有顯示效果的損失。

大家要平衡最終的顯示效果和包體體積的關係，如果烘焙了，你可以對平台單獨設置，這樣可以大幅度減少包體容量，這些東西也可以很明顯察覺到陰影的顯示變化，你需要考慮在體積跟質量之間獲得平衡。其實Switch的掌機平台是比較低的，下降一些不會有太大變化。

還有一個是比較容易忘掉的，Mip Maps，這個在後期迭代時會把貼圖做得比較大，會做1024*512這種模式，如果把Mip Maps勾掉的話會有很多能量，所以不會產生實際上的效果。

整體看下來打包之後是1.8G，這個不是實際打包的，你看Android打包出來容量是這個，在里面還會繼續壓縮。像Switch壓縮打包結果應該在1.2G左右，後續還會有一個打包壓縮，在機器上就會占到1.8G的容量。

排第一的是60Mb、40Mb、25Mb，我們並沒有進行太多處理。第二位是otf，支持多語言的，你要有特殊字體放進去，每個字體都有容量，針對中國，不支持多語言切換的話都可以刪掉。第三，Fbx文件，里面有很多動畫，都是比較大的。

最後說一下Levels，《不可思議之夢蝶》場景里有很多Mesh，它的存儲不會占用太多的地方。為什麼需要優化呢？你就算切換到靜態模式的話，靜態合批會被動態物體打斷，你在Framedebugger里面可以看到是被打成一段一段的。這個DrawCall數非常高，對CPU壓力非常大，這個東西在PC是幾乎沒有影響的，在Switch平台和移動平台壓力是非常大的。

我們做了一個合併工作，就是烘焙工作，我們通過第三方工具來做的，叫做MeshBaker，非常有效果。你可以把想合併的靜態的Mesh選入進去，在工具里去設定每個球的半徑大小，這個球半徑包含的都可以形成一個簇，可以通過MeshBaker自動合併。為什麼合併呢？因為在運行前就已經處理好了，再有一個就是說遮擋剔除功能，在錄影機渲染上是可以直接拿掉的，這個可以極大的提高渲染性能，這是合併Mesh的目的。合併Mesh之後有一個結果可以讓場景變得非常大。大家可以想像一個石頭大概有100面，我這個場景里面石頭塊有1000個，我分的時候板這一塊地方一共會有50個物體，會合成一個，合成一個之後原來Mesh的就不用了，就單獨形成了一個頂點數新的模型，存儲容量會大幅度提升，會變得非常大。為了提高渲染性能，為了整體的結果，你肯定是要丟失一些東西。在紋理壓縮上做了很大處理，讓出了很多空間。紋理從一開始，沒有優化之前，就包括所有的Levels加起來有2G多，這是非常大的減少包體的辦法。

渲染性能方面，不僅要考慮顯卡，還有CPU問題

提升渲染性能。大家玩的3D遊戲多了之後只認為顯卡對遊戲性能比較大，我問過很多開發者，其實項目一開始優化時，CPU跑不動帶來的結果幾乎都是百分之百的。一般都不會去考慮CPU問題。它有一個單獨的工具，叫做NxGraphicDebugger，這個使用起來和他們差不多。我們通過自己的努力優化，沒有針對遊戲有改動，可以從Switch平台優化起來，我可以跟大家分享一個經驗，Unity打包出來的程序，如果使用Standard Shader，在Switch平台到底能運行幾個Cube？就在動態物體，不是靜態物體，最後測下來只能運行6個，超過6個之後就不能穩定在60幀了。所以大家在Switch，在掌機模式下也不用求60幀，我覺得30幀就已經不錯了。

在使用第三方插件時，一定要先把插件關上，看看遊戲到底能不能運行，有沒有問題，我們一開始閃退花了3-4天，是發現插件的原因，而且第三方引擎庫輸出是非常少的，其實是完全一個瞎調試的狀態。後來通過項目經驗開始關東西，最後排除發現是第三方插件的問題，就可以折半查找，關掉之後看有沒有問題用快速查找來看有沒有問題。

這是在一個星期之後，還是這個場景，大家看到全功能已經跑起來了，已經可以穩定在30幀以上了，就是這麼一個狀態。這個過程之中經歷了太多太多的調試和處理，最後再經過大概一個月的時間，我後來後來安排了工程師做全職工作，後來整個《不可思議之夢蝶》每個場景都可以穩定在30幀以上，有一些東西其實再說一下經驗。比如說Switch可以歸為移動平台，經過我們調試，像後處理的螢幕AO等占用都是比較大的，最後一定要想替代方案。