葡萄君在此前的文章中，已經對《偶像大師MLTD》（後文簡稱MLTD）這款本身，以及它的運營技巧進行了非常詳盡的報導。MLTD的優秀之處在於，它依靠系列作品12年的內容、技術積累，在移動端表現出了精緻的舞臺演出效果。
只不過，早期MLTD能夠支持同臺演出的最大人數，只有5人。對於即時演算的舞臺效果而言，要保證足夠的表現力，必須融入足夠多的光效、動畫，以及大量渲染處理，最關鍵的，就是展現出足夠到位的舞臺細節，來烘託人物動作、服裝風格、詞曲表達，乃至整個的舞臺氛圍。
對於移動端的設備來說，要承載這樣的表現，已經比較吃力了。而MLTD在今年又實現了一次技術上的突破，僅用了不到三個月的時間，就將可同臺演出人數擴展到了13人，讓玩家體驗到了13位成員的完整組合，在手機的畫面中演出同一首歌曲的精彩場景。
在上個月，Unity在日本舉辦了「Unite Tokyo 2018」技術分享大會，期間《偶像大師MLTD》開發團隊，萬代南夢宮工作室的主程序池田早人、程式設計師加藤政樹分享了他們的製作經驗，以及遇到各種優化問題時的解決方案。
下文部分內容來源於日媒SGI的報導，由於缺少細節，遊戲葡萄根據原PPT添加補充說明，可能存在一定程度上不準確的描述。
項目組很幽默地將支撐整個遊戲內容的製作流程，用遊戲中的角色茜（AKANE）來命名
池田於1996年以硬體工程師的身份加入南夢宮，作為客戶端工程師的負責人，主要負責進度管理和版本管理等。
萬代南夢宮的主程序池田早人（右）、程式設計師加藤政樹（左）
MLTD這款遊戲與2017年6月上線，以偶像大師系列最早的舞臺765事務所為起點，來表現765 MILLION ALLSTARS的偶像們從事的偶像事業。遊戲主要玩法為音樂舞蹈，玩家需要指導這些偶像，通過演出、工作、劇場對話等方式，來推動遊戲的進展以及加深與偶像的交流，體驗角色、故事、世界觀背後的樂趣。
在遊戲中核心玩法演出的部分，在不同時期有不同程度的迭代。
剛上線的時候，遊戲可以支持5名偶像同臺演出；偶像角色的站位、服裝可以隨意調整；在特殊的曲目中，5名偶像還可以按照獨立的舞步進行演出；部分歌曲支持51名偶像獨立演唱；在演出中還會加入特殊的特效展示環節（繼承自主機的傳統）。
在運營的過程中，遊戲逐漸追加了支持4人、3人、2人演出的功能；支持了52名角色獨立演唱同首曲目的功能（角色琴葉回歸）；在演出中偶像可以變身了（瞬間換演出服）。
最近一次大型的功能迭代，就是支持了13名角色同臺演出。
MLTD中，每名角色建模都由10000個面構成，服裝材料是一張1024×1024的貼圖，表情則使用了BendShape功能來製作。
每個演出場景建模都由15000面構成，其中10000面是基礎的舞臺建築，剩下5000面則用來支撐特效演出相關的內容。舞臺材質使用了兩張1024x1024的貼圖，為了降低消耗，觀眾席上的投射燈只用了1個Mesh來表現。
後期處理採用了景深、Bloom、Blur等效果，在處理光暈（Flare）效果時，由於Unity的高畫質效果對手機的負載很高，所以項目組使用了自己編寫的優化Shader，靈活運用中間Buffer來節約內存。
遊戲整體的解析度以720為基準，在iPad等設備上，則調整到960x720。對於GPU性能比較低的設備，遊戲也設置了低解析度的模式，但這種情況下鋸齒會比較明顯，所以可以嘗試MSAA處理。儘管這種處理會稍微提高負載，但在繪製面積比較多的場景裡，低解析度帶來負面效果更多，所以這種做法還是可取的。
在製作演出部分的時候，項目組採用了Timing Sheet工具（舞臺事件工具），其實就是Timeline工具。
工具分為兩類，一種用來製作舞臺演出，另一種用來製作運鏡效果。這個工具是在家用機採用的工具基礎上，在Unity中重新製作的。這套工具，可以將鏡頭、角色位置、角色表情、舞臺演出、舞檯燈光動作等所有的數據整合起來，進行自主編排。這套工具也在隨著設計和畫師的需求不斷優化。
在分唱（對應角色聲優的個性化演唱）功能上，根據成員站位的不同，遊戲中準備了不同的演唱部分。這套功能在主機板偶像大師中就有了，要實現它，必須收錄每個偶像的聲優演唱音頻。在手遊版本中，因為有52名角色，所以按照不同的排列組合，5個人的演出隊伍，就可以組合出約3.1億種不同的演唱效果。按照1首曲子2分半的時長，把所有不同版本的歌聽完，差不多要花掉465億秒，也就是538194天，相當於1474年。
音頻使用了CRI的ADX2格式，通過採用多個通道，以及靜音功能，來實現分唱的效果。分唱的數據也由前文提到的舞臺演出工具來管理。
從開始開發，到2016年4月，團隊主要在嘗試製作通過程序和技術美術來表現3D演出的效果；隨後的兩個月，逐步完成了α1版本的製作，包含標題界面，到劇場場景，到故事功能，再到演出的整個主要流程。從6月到11月的期間，加入了遊戲需要的全套外圍系統。
這次演講最重點的優化環節，是從2016年11月到2017年7月的這段時間，也就是遊戲上架前的5個月。隨後就是資源打包，伺服器建立，以及整體評測等工作。在上架前的3天，升級了Unity的版本，在應用商店中提交了遊戲，緊接著就開服了。
在開發的時候，很容易遇到一些必須設法優化的問題。剛開始，MLTD只考慮了能不能在iPhone的最新機型上流暢運行，結果，在iPhone5s、安卓等機型上，遊戲卡得完全玩不了。於是項目組在開發團隊之外，建立了一個獨立運作的優化團隊，來保證遊戲能在安卓上流暢運行，他們將優化項目稱為「AKANE大作戰」。
順便一提，AKANE大作戰的命名，是來源於「安卓-高速化-與-自定義化」的日文讀音首字母。
圖中角色就是茜（日文讀作AKANE）
整個優化分為四個主要部分：1、重審項目設定；2、3D繪製的高速化，提高CPU和GPU的效率；3、2D繪製的高速化，從畫布（Canvas）轉向圖像拼合（Sprite），判斷是否存在無效的透明繪圖，集成圖片（Atlas）；4、防卡頓，不做垃圾數據回收（GC），更不能讓它出現。
所需要達成的目標也有四項：首先要減少SetPassCall（DrawCall）。其次要減少GPU負載，包括集成貼圖、整合Index Buffer、削減材質、調整繪製順序。接下來要減少CPU負載，提高擺動物件的計算速度，線程化，合理分配CPU運算量。最後是優化內存，尋找不用做垃圾數據回收的方法。
最終目的是讓遊戲FPS平均穩定在60左右，這意味著16.6666毫秒內要完成所有的運算處理。
在Profile方面，他們在保證不降低視覺品質的基礎上做了很多優化。首先，有關CPU的優化方案可以在UnityProfiler中看到。其次，針對GPU做優化的時候，項目組使用了Qualcomm提供的Sanpdragon Profiler。第三，很重要的一點是整合測試環境，提供數值化比較的方案。
因為盲目地採用一些優化方案，也沒法測出實際效果的好壞，所以就算是很麻煩，也要在有變動的地方做好配置，通過數值來比較效果。從實際情況來看，有些時候做了很大的變動效果其實並不好，相反，有些時候只做了很小的改動卻帶來非常大的影響，所以監控數據測試環境是非常重要的。
最後，理解不同設備的適配情況也很重要，除了設備本身的差異，尤其要注意的是一些日本手機在發熱後會啟動降頻保護。因此很多時候，一些優化方案並不能達到想要的效果。
項目組在實現方案和測試的時候，按照如下流程來進行：將優化方案按照優先度排序→實際添加功能→生成和測量→提供更好的方案。在開發界面，為了更方便測試，項目組設計了隨時可以開關優化項目的功能，這對於視覺美術人員來說，也更便於測試。另外他們用了對程序負載最大的五名角色來進行測試。
從引擎的角度來說，也存在很多可以優化和沒法優化的方面，比如項目組趁早放棄了多線程化。對於短期內沒辦法實現的方案，他們的選擇就是不做，一方面Unity遲早會推出新的應對功能，等待也是一種方法。另外，活用Unity本身的演講資料、培訓資料也很重要，還有Unity Forum、UnityIssue Tracker等等。需要注意的是，遊戲發布之後再進行程序版本升級，會遇到很多難點，必須非常慎重，所以開發的時候儘可能要用最新版的引擎。
在遊戲發布之後，MLTD的優化工作也沒有停下。比如持續改進演出效果、整合材質、舞臺演出輕量化、通過安裝獨立的動畫系統來削減處理負載和數據量、減少GC等。因為遊戲後續逐漸上線了新的功能，所以優化團隊定期都會執行Profile流程。
基於以上的一套優化流程，MLTD最重大的一個功能「13人LIVE」才得以迅速實現。在2017年底的時候，製作人提出了「能不能讓五名以上的角色同臺演出」的問題，於是項目組開始嘗試製作。
但實際上在壓力測試的時候，項目組已經採用了超過5人的功能模式，所以這塊的功能是驗證過可以實現的。在他們只做了15人演出的測試功能後，發現居然能順暢的運行，於是最終只花了3個月不到的時間，優化成了13人同臺演出的完成版。
其實在優化過程中，優化團隊並沒有針對13人模式去實行專用的內存優化、負載優化方案，這得益於他們在整個優化過程中，對系統平衡性進行持續調整的積累。
總結來看，有五個關鍵點。第一，優化是積累的過程，在優化之前要明確工程量。第二，Profile非常重要。第三，優化效果的可視化非常重要。第四，必須建立起可持續推出並實現優化方案的工作流程。第五，積少成多，不論多麼瑣碎的事，最終都會展現出極大的成果。
具體再看詳細的優化案例。
在角色DrawCall的優化方面，先決條件是保證不改變角色的外觀，同時不重新製作資源。
從優化的結果來看，經過對Sub Mesh的整合，一個角色建模的DrawCall數量從25降低到了17。通過Command Buffer這項功能，可以實現對模型繪製的細節調控。
MLTD中，角色的模型分為頭部和身體。製作中需要著重刻畫身形、服裝、夜光飾片、皮膚、色彩等方面，可以通過腕飾、項鍊等小飾品展現出角色的特徵。Shader方面，項目組用一條通道來展現角色的建模，用另一條來展現輪廓線。輪廓線的繪製需要注意幾點，一是繪製翻轉多邊形，二是讓頂點Shader擴大，三是採用與模型共通的Mesh。
製作中遇到了不小的困難，項目組希望把DrawCall都整合起來，但是這樣就很難一次囊括進所有獨立的Sub Mesh。
所以它們採用了分類處理的方式，按照模型、Mesh、Sub Mesh的三大類，對頭部、身體的建模進行了劃分。對於頭部而言，Mesh需要包含頭髮、頭顱、頭飾三個部分，然後省略Sub Mesh的內容。對於身體而言，Mesh即是整個軀體，Sub Mesh則包含了服裝、領口和裙擺、手、腕飾等。對於所有歸類到Mesh的資源，都要注意定點構造的區別，而對於Sub Mesh中的資源，則更需要注意材質的差異。
通常，在繪製建模的時候，最關鍵的幾個部分是頂點Buffer、Index Buffer、材質。
在製作時，Sub Mesh的部分需要用Index Buffer來處理，而不用在頂點Buffer上處理。
從這裡延伸出來一個點，如果遊戲後期需要加入新的Index Buffer用來處理輪廓線、材質等Sub Mesh，那麼加入後的內容依然能與整體的建模繪製並行使用。
他們在後續的嘗試中也驗證了這種做法的可行性，只不過，僅追加Sub Mesh是沒用的，還需要擴充材質的排序，加入只有輪廓線的材質。
下面是追加SubMesh的代碼：
下面是追加材質的代碼：
下面是項目組對Unity內置環境的理解：
整個優化的結果是DrawCall數從25降低到17，儘管看起來減少的並不多，但從遊戲變化來看，從5人演出到13人演出，實際上已經實現了非常大的突破。更重要的是，畫面品質沒有下降、資源也沒有重做、上線節點也趕上了。
包括UI在內，優化前後的DrawCall數則是從44降低到36，少了8個。
項目組還表示，儘管他們目前還沒有在正式版中實際運用材質LOD、COmmand Buffer的等功能，但實際上他們也找到了能夠更加細緻地整理角色建模繪製的方法。
在材質的LOD方面，他們選擇在鏡頭較遠的時候，將衣服和裙擺等資源優化成一個DrawCall，而在近距離的時候就展現出所有的細節。
LOD最重要的一點，是對Sub Mesh資源可見性的調控。比如反射效果會在衣領、裙擺這個材質上實現的，High LOD模式下，需要將全部特效顯示出來。而在Low LOD模式下，由於衣領裙擺和服裝被綁定成一個Sub Mesh，所以就失去了這個效果。不過對於遠距離的單位，反射的視覺效果並不明顯，因此進行LOD也是可行的。
另外，他們還研究了Command Buffer的使用。對於整合到一起的Sub Mesh材質，Command Buffer可以進行統一繪製。
需要注意的是，如果要單獨將SkinnedMesh渲染關掉，同時繼續維持Skinning的運行，則需要將Renderer.materials[ ]的值調為空值，這樣一來不僅Skinning會繼續運行，Frustum Culling也會繼續運行。
具體的代碼如下：
材質優化前後的對比：
總結來看，Command Buffer的有點在於，它能夠更容易地控制繪製順序，能夠以Sub Mesh為單位進行可視化處理，切換材質時也很方便。
開發組還公開了一組Scene View攝像頭與Command Buffer關聯運用的代碼：
在實際的運用中，一方面可以處理Sub Mesh的可視化效果，另一方面可以用來Debug。
Sub Mesh的可視化效果：
Debug視圖：
演講最後，項目組認為，能夠實現這些成果，得益於他們在引擎底層自定義改造的知識。在開發MLTD之前，項目組的很多成員也來自PS4版《偶像大師》的研發團隊，靈活運用此前積累的經驗，也是實現這些效果的關鍵。可見，使用遊戲引擎來提高遊戲品質和開發效率十分重要。
關注微信公眾號「遊戲葡萄」，每天獲取最前瞻的遊戲資訊