【逆水寒三週年】大型MMO專案UI管理的價值與責任

《逆水寒》作為一款大型MMO端遊，UI工作的複雜和壓力相當巨大，雖然最艱難緊張的時間是17年到19年，但是如今想來還是心有餘悸。大型MMO端遊流程複雜、資源繁多。開發過程中，參與人員多、開發進度緊，特別在上線以後，常常需要根據實際情況緊急調整內容。在《逆水寒》上線三週年之際，我們將開發和運營中的UI管理工作經驗整理出來。

本文只討論UI管理工作，對於UI品質的全盤設計工作，以後另文總結。

一、工作背景

《逆水寒》開發初期也存在著各種大型遊戲開發中遇到的問題，開發率低下且設計質量不高。

從品質表現來說：

過於彈窗化的設計阻礙了玩家和遊戲世界的交流，且彈窗沒有深度，深層資訊全靠疊加彈窗，互動工作更像是排版工。

從開發效率來說：

整體效率太低，阻礙了整體遊戲的開發進度。雖然看起來是【品質】和【效率】兩個問題，但其實本質上還是UI工作管理的不合理造成的。UI工作關鍵點不過三者【流程】【工具】【人員】，將這三者調整到最優，是UI管理工作的核心。


從流程來說：

我們需要一個高效運轉的工作流程：流程中的每個環節都可以產生有效的價值；每個環節都有嚴格規範的標準進行要求；各個環節之間靈活銜接互相促進，而不是互相制約。

從工具來說：

工具包括製作工具、資源管理、協作溝通三者。逆水寒有著先進的自研引擎，在畫面渲染方面非常出色。使用起來非常適合專業的技術大佬，但對不懂程式碼的UI同學來說有一定難度。此外在研發前期設計UI框架時，缺乏專業設計師來探索未來的設計風格，導致基礎結構以平面彈窗為主。

從人員來說：

需要加強設計師對自己方案的責任感，對自己的方案要落實跟進到底，榮譽與付出掛鉤。要對自己的方案有一定專業追求，要對情緒體驗、操作流程、資訊結構等多方面進行思考，而非單純注重介面美觀程度。

好的UI管理體系是能夠【自主】【高效】的運轉起來，並且給專案組節省極大的開發成本的。

二、工作流程

優化UI工作管理，第一步是從全域性角度審視，讓整個UI流程合理且高效。之前《逆水寒》的UI流程存在兩個問題：第一，所有環節依次進行，每個環節和依賴上一環節的完成度，如果出現一個環節延遲，那麼後續所有工作都必須推遲，整個開發效率會變得十分緩慢且不可控；第二，互動設計師只輸出設計文件，不對自己方案的落實結果負責，經常導致遊戲中實際情況覆蓋補全，再反覆討論修改，必然消耗更多的時間。

因此對UI整體工作流程的優化至少要解決以上兩個問題，讓每個環節的人員可以機動利用時間完成要做的事情，同時加強互動設計的交付標準和責任意識。

1、刪減多餘環節

原有互動設計師只進行方案設計，輸出互動文件，並不參與實際開發工作。這樣存在幾個問題：一、單純的文件非常容易遺漏玩家各種操作和玩法極端情況，倘若開發中出現這樣的問題，不論策劃找互動反覆溝通，或是自己處理，更多溝通以後和之前的文件也大相徑庭了。二、互動文件交付下游工作後，接手程式和美術可能並不清楚遊戲中已有相似功能，於是出現重複開發，極大增加專案成本。


如此，必須對不產生實際價值的工作量進行刪減：

① 互動設計和動效美術都需要將自己的方案直接做進引擎中，特別是互動這樣自己更清楚實際的情況，對介面最終效果負責。在有重複功能時可以直接複用已有控制元件，節省下游工作量。

② 程式只負責功能開發，專業的人做專業的事情，保證功能穩定是程式更應該花精力做的事情。

2、串聯變為並聯

曾經UI的開發流程是典型的瀑布式開發：

溝通需求——互動設計——視覺設計——動效設計——介面製作——程式開發——驗收測試

於是存在著瀑布式開發的典型問題，1、每個環節過於依賴上一環節，但是任何一個環節如果出現問題（比如員工請假、工作太滿），後續環節都要相應延期，倘若後續再有什麼問題，那整個流程的進度完全不可控。2、到下游環節發現上游已完成的工作存在問題，如此返工會嚴重浪費開發時間。


這就需要我們的流程既能解開每個環節的互相依賴，也能在各個環節之間建起高效快捷的溝通方式。

調整之後的流程變成了：

策劃需求——互動設計/介面製作——視覺設計/程式開發——介面替換/動效製作——交付測試


我們從互動設計著手，要求互動在初期設計方案的同時，需要將遊戲介面的初級功能檔案製作出來，在所有資源都到齊並且程式開發完成後，對介面進行正式化調整。這樣一方面促使互動設計師在設計的過程中更清楚的瞭解具體的遊戲環境，另一方面也要求互動設計師必須對自己設計方案的最總結果進行負責。

程式工作和美術工作同時進行，互動設計跟進，這樣在開發環節發現任何問題都可以直接進行調整。

在任務管理平臺上，也會總任務和子任務的掛接關係，表現整個流程的責任關係。當每個環節的子任務完成後，互動驗收總需求，就可以將總任務關閉，交由負責策劃和QA再進行更多驗收（比如伺服器功能等）。


3、需求交替進行

理想情況下，每個環節的參與人員一個流程內只做一個需求，一個流程走完正好一個月左右。但是下一個需求不會等上一個完成才來，因此每個人員的工作也是交替進行，上一個需求的前幾步交付出去，下一個需求就開始了。如果安排合理，開發週期從之前的幾個月繼續縮短。如果開發壓力不是很急，在這裡為了保證設計質量，不太建議並行2個以上的需求，畢竟設計不是靠加班就能想出更好idea的工作。（但我們當時開發壓力真的很急，這裡也非常感激所有在逆水寒上線前奮力加班的UI同學們。）

理想的開發流程：

如果每個環節都需要參與，並且正常執行的話，一個完整的流程應該是這樣


實際的開發情況：

然而，實際並不是所有需求都要把全部流程走一遍，這就需要互動設計同學能夠在前期判斷出如何合理調配資源可以做到更好更快。並且有些開發設計和開發可能比較簡單，就不需要每個環節都佔用一週時間。


三、工具優化

工具包括【製作工具】【資源管理】【協作溝通】三部分，因為我們是自研引擎，對於實際製作工具的優化雖是個非常艱難的過程，但對於其他專案並沒有太大參考價值，所以這裡對資源管理進行一些總結。

1、【製作工具】重要的所見即所得

為了保障介面製作的效果，一個所見即所得的介面編輯工具尤為重要。介面工具往往包括幾個功能：資源管理、元件製作、介面拼接、遊戲內驗收。一些較為成熟的工具（Unity等）會同時包括這幾個功能，如果有需要優化的需求，就要求助於技術人員，優化工具帶來的效率提升對於專案成本的減少是非常可觀的。

2、【資源管理】多級資源管理

初期《逆水寒》將資源分為通用資源和專用資源。但在設計的過程中，我們希望，每個系統有自己的性格，有自己的定位，並不能都簡單粗暴的用同一套資源。因此存在一批在特定系統中較為通用的資源（比如結婚系統的紅色彈窗和相應資源），但既不全域性通用，也不只有單獨頁面使用。為了同時保證資源複用，又不過於增加包體大小，我們增加了中間層級資源管理。


一級資源為全域性通用資源

這部分資源會在遊戲啟動時載入，影響啟動速度，所以需要嚴格控制大小。這個檔案也會做檢測，當匯入太大資源時會有提示。（因為曾經有設計師把任何自己認為可複用的圖都往裡導，致使整個UI組開發效率變慢）。此外這個檔案需要方便所有人檢視，因此我們對其做了定時匯出，每天凌晨匯出最新一版到共享伺服器中，來上班時開啟資料夾可直接檢視最新版本，隨時查詢複用。

二級資源為系統通用資源

《逆水寒》存在著大量以系統為單位的介面，比如幫會系統、婚姻系統等，這些系統有自己獨立的設計元素，在系統內部大量複用。因此我們以系統為單位將資源進行聚合，形成部分二級通用資源。這部分資源只在某一系統內複用，既不會影響全域性，也不會在單獨介面中重複儲存。

三級資源為介面專用資源

每個介面會配有自己的資原始檔，彼此不通用。將每個介面專有資源放在這裡，也方便識別和管理。

3、【資源管理】通用機制製作

圖素資源一般是組合為控制元件在遊戲中被使用，那麼直接將通用圖素製作為通用控制元件，豈不是更方便？

① 通用控制元件製作

應該有許多專案也是這麼做的，將各種較為通用的控制元件進行統一製作，在開發中隨時呼叫。比如進度條，使用時可以調整控制元件引數以適用於所需要的環境。但當時《逆水寒》的通用控制元件數量不多，且存在重複開發。於是後來在新方案製作的過程中，將可以複用的控制元件進行製作，節省未來的開發量。

② 實時更新資源

為了保證遊戲的整體性，每個遊戲都會制定一套自己的設計規範，並有一套通用資源庫對其進行保證。但隨著遊戲的繼續開發，遊戲內容不斷擴充套件，遊戲的通用控制元件庫也會隨之更新。倘若控制元件庫是靜態的文件形式，必然產生維護成本。但貫徹通用規範又在很大程度上依靠大家自覺，這就又帶來了管理成本。所以我們構建了一個更為自動化的控制元件庫：

• 【自動更新】將通用控制元件庫整理之後，也做了每天定時匯出，如此對控制元件庫中出現的不符合統一性的問題可以及時調整，減少維護成本。
• 【直接呼叫】提高了複用的便捷性，允許設計和開發人員直接呼叫公共庫元件，減少了重複製作的工作量，也保證了玩家體驗的統一性。
• 【允許擴充】減低限制，過於限制創意人員的發揮也會帶來遊戲品質下降。因此部分控制元件是允許一定程度的自由發揮的。在約定好互動方式下，美術可以替換其中的資源和樣式或修改引數，以產生更多的可能性。
  

③ 更多表現效果

在專案過程中，我們發現已有需要有更多表現機制才能帶來更多的遊戲體驗，因此這裡和技術大佬們一起研究開發了一些新的表現方法。


如在強調氛圍時，優化了全屏粒子特效。與之前相比，可以通過引數調整粒子的漸變、線性、軌跡等，只要填入合適的引數，可以生成變化多樣的效果。

4、【資源管理】主題化製作介面

當遊戲上線運營後，經常要根據玩家反饋迅速調整遊戲內容，這對介面輸出的速度提出了更高的要求，甚至一週之內要完成互動、美術、開發等全部工作（比如《逆水寒》經脈系統）。在實際的開發過程中，我們發現在【戰場】【比賽】【裝備】三大模組的此類需求最多，於是將相似主題的控制元件進行歸類，形成專用庫。如果出現相關需求，設計者可以直接使用模組化的元件快速製作介面。同時也開放了部分可以替換資源的介面，防止連美術樣式也一樣，會讓玩家對不同玩法產生迷惑。


5、【協作溝通】打通崗位協作

常有策劃或美術在自己的工作中，需要呼叫UI資源的情況。

① 圖示、稱號、頭像等

遊戲策劃最經常呼叫的是圖示資源，如道具、頭像、頭像框、稱號等。如果需求方不瞭解已有資源的情況，就要麻煩互動來幫忙查詢，在一來一回的交流中，雙方都很耗費精力。所以將資源直接開放給所有需求方，會便捷很多。但又不能完全開放圖示資源的編輯許可權，防止過多編輯導致其他引用連結出現問題。這就需要將此類資源做僅可讀匯出，方便需求方可以檢視資源樣式和資源名，直接使用資源名稱。

② 檢視所有介面

對於全部遊戲介面也會進行定期匯出，方便所有人可以及時檢視全部遊戲介面的最新效果。也方便設計師的日常走查，如果哪個介面出現表現問題，可以在每天最新的匯出檔案中直接檢視。

③ 通用介面機制

有些較為通用的介面也可以像控制元件一樣做成通用機制，比如結算、二次確認等。當策劃做玩法設計需要結算介面時，可以直接呼叫該介面控制元件，填上要顯示的獎勵物品和數量即可。根據實際情況做了14中分類：


為了方便多層次需求，相同功能的介面也會製作不同規格介面，如小玩法結算：


四、人員管理

1、規範交付標準

越是大型遊戲，參與的人員越多，越需要大家更為緊密的配合。不僅自己的工作要做好，也要配合好相關職能的工作，整個團隊才能更高效的運轉，因此要對每個環節的工作要求和交付標準進行規範。

互動設計師將工作成果交付美術和程式之前，需要給出互動文件以及工程檔案，那麼這兩者就需要達到下游人員需要的標準。再正式介面交付QA前，也需要對最終效果有一定要求。

• 互動文件：作為互動設計師產出的產品，應該考慮使用者（相關的策劃、美術、程式和QA）的使用情景，如果以後轉交工作，那麼也要方便後面接手的設計師。
  

有些內容可以參考，根據實際需求來選用：

• 文件資訊：記錄需求及變更、設計師姓名、方案版本、修改記錄等。
• 現有問題分析：一般用於迭代設計，會對當前的設計方案進行走查和記錄。
• 競品分析：可以選用，對相關競品進行分析，方便自己思考也方便以後接手人員更快了解情況。
• 功能結構圖：一般用於系統設計，對整個系統的功能結構進行分析和設計。
• 任務流程圖：一般用於玩法設計，對玩家操作的各種情況進行分析和規範。
• 互動設計原型：必不可少的一部分，是對互動方案的系統化闡釋。並標記出初級介面各個介面及控制元件名稱，方便程式開發時快速查詢。
• 各類資源需求：單獨將需要的需求列出來，方便美術、音效等崗位人員可以快速瞭解需要做的工作。
• 驗收問題跟進：在最終介面做完以後進行自我驗收，並整理出來問題進行跟進。
  

2、確定責任歸屬

互動設計師需要跟進整個流程，並對最終結果負責。當然中間程式和美術的環節，不能過於限制相關同學的發揮，畢竟專業的事情交給專業的人來做，每個人都要對自己的工作負責。此外為了方便下游人員直接開始工作，每個環節結束後的提交會有一定的要求，比如需要填寫提交路徑，或者修改檔名稱，這樣其他人看到就可以開始自己的工作了。


只做效果圖不考慮設計細節也不對整個方案負責到底的互動設計師是非常不合格的，這樣會使得團隊中幫其處理實現細節和跟進落實的其他人非常受打擊。畢竟好看效果圖最好展示工作，但好不好用卻非常不好展示。

五、到底意難平

作為一個次世代端遊，《逆水寒》UI所呈現的效果遠遠不應該只有現在表現出的效果。我們的期望效果是，強沉浸感、臨場感的，是可以借鑑主機遊戲做場景化UI或者行為導向型UI。

實際總是和理想存在差距，現在也還有諸多問題，比如彈窗化的基礎框架沒辦法修改；沒有辦法將UI置於場景中，強調沉浸感；很難讓UI隨玩家行為進行變化等。面對各種前期問題和限制，又要平衡效率和質量。

好在努力提高效率後，設計師團隊有了更多的精力對品質進行思考。在遊戲上線以後，逐步開始對每個系統進行敘事化獨立包裝和，讓遊戲整體氛圍更加熱鬧，讓每個介面也更有故事性，把國風武俠的世界融入玩家操作中。


來源：GameTube
原文：https://mp.weixin.qq.com/s/jaSFDj3c2oDGdcMF0jlSOA