《奧日與精靈意志》是如何完成近乎不可能的Switch移植任務的？

作者：託比亞，會音樂和遊戲設計的TA裡最帥的那位
本文首發知乎：https://zhuanlan.zhihu.com/p/260116904

一直很好奇Moons studios究竟是如何在遠端合作的狀態下保持高度的生產力並完成如此優秀的遊戲的，他們甚至在近期完成了近乎不可能的任務：讓Ori在Switch上在對畫面質量不怎麼做出妥協的情況下讓遊戲穩定60fps，真的好想一窺他們的Workflow是怎麼搭建的。


終於Digital Foundary回應了我的期待！他們在前幾天釋出了個視訊，就是關於Moons Studios在針對Switch上面的開發優化上做了哪些努力，並多少分享了他們的Workflow！於是興奮的我反覆看了視訊數遍後草草記錄下了重點。

遊戲引擎採用的是自定義的Unity遊戲引擎，並取名Moonity，是個完全圍繞Ori遊戲型別和渲染方式特別定製工作流及渲染管線的自定義引擎。

他們完全採用了Painter Algorithm的方案（由後往前繪製），結合Early-z pre pass規避Overdraw，並根據結果渲染成6張layers的RT，再與3D角色的RT layer blend在一起（不過由於層級的深度排序幾乎是固定的，似乎做了些離線操作減少了early-z的gpu壓力，至今沒搞明白具體做了什麼）。除了角色層以外，每個RT代表的layers都可以單獨設定解析度，不僅可以做出景深（Depth of field）的效果，還能降低GPU的負擔。




由於玩家在進行操作精度高且快節奏的遊戲時，視角基本只會集中在角色身上，因此遊戲就能通過視覺焦點的位置去切不同頻率(Frequency)的貼圖資源。大體操縱方法是：視覺焦點的周遭選高頻率的貼圖，其他地方就能替換成低頻率壓縮（Low Frequency Compressions）的貼圖從從而減少視訊記憶體的負擔。


他們還進一步在每個場景設定了上百個攝像機的位置節點，來預計算並儲存每個場景物件對該鏡頭位置的貢獻度，這樣在遊戲中就能動態隱藏對鏡頭貢獻不足的物體了。


接下來我們聊聊對Ori畫面質量提升最大的自定義光照，其中分為了靜態光照及動態光照，先從相對簡單的靜態光照開始。

靜態光照是手動畫上去的，美術可以直接在Unity中將光照畫在一個低頻率獨立的GI Layer上面，並且可以依據情況在遊戲中切換成低解析度的版本。


而動態光照就比較Charming了，大體使用了兩個方法。首先美術會繪製角色6個不同面的受光資訊（前後上下左右），並把其烘焙到rgb裡（應該會是個atlas），根據光的位置與距離去進行插值，這也不算什麼新技術了，不過最終呈現的效果還是很讚的。



而光照的著色則是借鑑於Doom 2016中的Particle Lighting的技巧，Moons studio稱之為Tile light calling，大體是將不同深度及優先順序的光照資訊寫入一張Tile Atlas，再生成對應的Tile indices來索引和混合光照的顏色。相比於Xbox通過Compute Buffer計算並儲存Indices的方案，Switch則採用了一張低解析度的2D貼圖來記錄indices，結果上來說對畫質並沒有造成多大的損傷。



可能是團隊借鑑的技術，擷取自Doom 2016的分享。id software發現由於畫面中各別的粒子效果對畫面的貢獻程度是不同的，想到了根據距離及重要度等資訊將個別生成的光照資訊輸出成Atlas，並在繪製完粒子特效後重新疊加光照效果的方法，從而實現了高效優質的渲染效果，並且其渲染質量與螢幕解析度無關

有趣的是，所有的layers都是做的前向渲染，只有3d的角色layer採用的是延遲渲染。按照原視訊的說法，沒有統一使用延遲渲染的主要原因是延遲渲染會丟失真實的深度資訊，在逐Fragment計算Tile light calling時可能造成潛在的artifact。雖然沒有詳細說明，不過由於延遲渲染中，位置資訊會儲存在Fragment階段後所產生的MRT中的32位Float位置貼圖裡，是有資訊丟失的可能。


遊戲中的Soft Physics是直接在Unity中繪製的，省去了從其他DCC軟體頻繁匯出的煩惱，並且整個過程是Undestructive的


God rays則採用了對多個幀做Stochastic Sampling + Blur，Stochastic Sampling是一種結合Poisson Disc（均勻取樣） + 抖動的隨機取樣方法，從最終的畫面效果來說也是可圈可點的。


Ori的發光拖影其實就是一堆從頂點拖拽出的發光片，這裡借鑑了Keijiro大神的vertex based skinner方案，具體可以看https://github.com/keijiro/Skinner


Profiling 就更好玩了，他們首先定製了完整的In-Game Profiler工具，並且可以記錄足夠長時間的偵測結果，以客觀地量化當前的優化進度。


接下來，他們還製作了可以記錄每個場景當玩家處於不同位置的渲染時間，並分別記錄了各別場景的渲染峰值。由於Switch上的目標幀數是60fps，所以當渲染峰值高於15ms的時候，就會在場景上標記出來，這對開發人員偵測渲染效率的幫助是不言而喻的。


綠色表示的是玩家經過的路徑，除了記錄了QA Test的資訊外，他們還搞了個快速跑關的測試工具來重複並快速地檢測問題點。


為了方便對比XBox和PC平臺的畫面效果，他們順手拍下了各別平臺針對該峰值區域的截圖，並根據日期排序，以方便橫向對比優化前後及不同版本之間各平臺的顯示差異。



最後的最後，來聊聊Ori的場景無縫銜接解決方案吧。首先遊戲會快取相鄰場景間相關資訊，以便於在遊戲中實時計算玩家與相鄰場景的距離，並預測玩家即將到達和遠離的場景來動態讀取或釋放遊戲場景。


由於Ori是個快節奏高難度的動作遊戲，為了保證死亡能夠快速重啟，Ori的每個Checkpoint也會預快取周遭區域的資源，並在達到下個Checkpoint以前始終儲存在記憶體裡，也就造成了能夠記錄關卡資訊的記憶體就更少了，所以遊戲開始時候就需要做一些預快取來小心處理資源讀取可能存在的問題，不過這也就造成了開始遊戲的讀取時間會特別的長。結果上來說的確保證了遊戲的順暢性及場景無縫銜接的體驗，所以這種妥協肯定是值得的。


經常覺得周遭的開發者朋友們都在用苦癟的方式來開發遊戲，近期一直在尋找著能愉快地開發遊戲並方便自動化地檢測問題的workflow，Moons Studios的遠端合作方案的確給我帶來了很多的啟發，真心希望哪天我也能在家裡使用如此暢快淋漓的workflow來遠端開發我熱愛的遊戲吶！

原視訊地址：https：//www.youtube.com/watch%3Fv%3DkH6wTpIObxE%26t%3D650s