文 / 王楠 (夢加網路遊戲製作人 The Line關卡設計師) 授權搜狐IT發布
前段時間關於Unity是否適合國內手遊/網遊創業團隊的討論非常火爆，本文從《蒸汽之城》的開發歷程談起，對於國內網遊團隊是否應該選擇Unity引擎，以及如何解決使用Unity開發網遊時遇到的各種主要問題進行討論。
廈門夢加的蒸汽之城
《蒸汽之城》是廈門夢加網絡的第一款作品，使用Unity引擎製作的蒸汽朋克風3D實時戰鬥MMORPG頁遊。遊戲擁有幻想工業時代恢弘蒼涼的場景；豐富的種族、職業和技能系統；和端遊比也毫不遜色的優質畫面和特效；各式各樣的副本挑戰和PvP活動；最後，所有這一切用戶都能直接在瀏覽器中以極短的下載時間享受到。《蒸汽之城》被包括福布斯、Massively、ZAM等知名媒體列為2013年最值得期待的MMORPG遊戲之一，目前已經籤約了多家海外發行商，範圍覆蓋所有英語國家、東歐、土耳其和中東。土耳其版本已經於3月1日（北京時間）正式開始公開測試。
中文官網已經正式開放：www.mengjiagames.com
夢加團隊當初選擇Unity引擎的原因和大部分團隊類似，快速出原型、大量現成的內置功能和中間件、支持在瀏覽器裡展示高素質的3D遊戲畫面。在幾年的開發過程中團隊才慢慢認識到用Unity開發MMO頁遊需要克服太多問題和陷阱。幸運的是我們最終克服了絕大部分問題，《蒸汽之城》也即將開始海外公測。下面我們會深入探討要完成一個高素質的Unity頁遊MMO，應該解決哪些技術問題和怎樣建設團隊。
請注意，這裡我們不會討論使用Unity製作單機遊戲，因為Unity單機或者有社交功能的手遊都有太多成功的巨無霸例子，很多開發者也通過自身經驗表明小團隊使用Unity製作輕量級的單機或社交遊戲並無太大障礙（遊戲列表可以查看官網：http://unity3d.com/gallery/made-with-unity/game-list），下面我們還是以多人在線，需要後臺和大量數據處理的MMORPG為例來討論。雖然夢加到目前為止都一直在開發瀏覽器版本的遊戲，但其中很多技術話題對於多人手遊項目也同樣適用。
從傳統頁遊到次世代技術
雖然Unity已經有了7年多的歷史，這款引擎從誕生之初就一直保持了比較先進的設計理念，包括其一直以來的首要賣點：為開發者提供基於瀏覽器的高素質3D遊戲解決方案。Unity的特色既包括面向獨立開發者的快速原型、低成本跨平臺發布，也在近年來整合了更多高端商用的中間件和次世代的渲染技術。使用Unity現在已經可以開發素質幾乎達到用Unreal Engine、CryEngine這些次世代引擎開發的遊戲，Unity也被越來越多的AAA工作室選用來開發跨平臺的主機遊戲。
這意味著Unity很好很強大，沒錯，但不代表團隊選擇Unity就是理所當然的。商用引擎的一大特點是兼容並包，要適合各種不同的項目和團隊需要，而作為次世代引擎，其中又包括了大量圖像、動畫和資源管理的先進技術。對於初創團隊來說，選擇Unity雖然得到了一大堆可以快速見效的功能，但面對這些功能時如何取捨，以及對引擎技術的理解和挖掘程度，都會對項目的命運造成決定性的影響。
Unity雖然一直以易上手、原型快速、中間件豐富整合快速著稱，但隨著項目規模和複雜程度的上升，很快開發團隊就會進入一塊網上各種單機遊戲教程無法涵蓋的真空地帶，而國內網遊技術分享的環境又相對比較薄弱，這時在一些關鍵的技術難題上，初創團隊就會遇到很大的麻煩。從快速原型到攻克大規模項目的技術難題之間，通常是讓很多團隊無法正確估計成本的危險過渡地帶。這也是很多使用Unity的項目結果反而不如使用自主開發的引擎或相對老舊引擎的原因。自主引擎任何功能都要自己開發，相對老舊的引擎功能較為局限，所以在內容和功能規模方面的計劃一般不會太過狂放；而Unity這樣的引擎包括從官方和社區的宣傳上都給人一種到處都是隨手可得的免費午餐的感覺，反而會讓團隊的計劃更加激進，對困難認識不足。
下文中我們會對這些危險和解決方案進行逐一的分析，希望能給經驗不足的團隊提供警示和提前準備好解決問題的思路。
內容規模和版本控制
開發者在不同類型和規模項目的經驗，很大程度上造成了對」Unity是否適合手遊/頁遊創業團隊「這一討論兩極分化的看法。對於以Temple Run、亡靈殺手等遊戲為榜樣的單機遊戲開發者，以及CSR Racing這樣有多人對戰模式的單機遊戲，即使團隊很小使用Unity開發都不會遇到什麼太大的問題。這些單機遊戲非常適合發揮Unity遊戲性成型快的優勢，而內購、社交等功能都可以用現成的中間件來快速實現。
當使用Unity製作有海量內容的網遊時，團隊遇到的第一個問題，就是無法把遊戲的全部內容放進一個Unity項目中。一方面資源文件數量達到一定程度後，每次開啟項目的導入過程就夠你泡壺茶；另外幾十人的團隊共用一個項目，在版本控制和數據安全性方面也會有很大的危險，任何人的操作失誤都可能導致整個項目癱瘓；最後不同分工的開發者需要面對的項目數據和工作流程差別很大，共用同一個項目會在很大程度上降低生產效率。
《蒸汽之城》使用了很多個Unity項目來為各個不同的部門和小組提供定製的數據範圍，工具和流程。3D角色美術的項目裡只使用角色數據（FBX->Prefab）和相關的預覽和打包工具；場景美術使用不同的項目來管理不同的場景；客戶端程式設計師使用的是主要的客戶端項目，他們的代碼運行後可以讀取其他開發者上傳到伺服器上的數據，從而讓遊戲跑起來。而大部分開發者可以使用編譯成可執行文件的客戶端來測試自己隨時向測試伺服器上上傳的資源和設計數據，從而既保證了每個人能最高效在自己的領域裡工作，又保證了自己生產的內容能夠隨時在遊戲版本中測試。
如此多的項目要怎樣實現版本控制呢？我們的解決方案是用Gitlab作為統一的管理平臺，每個項目作為一個單獨的Git Repository（倉庫）。使用Git的最大優勢在於客戶端項目的版本管理，客戶端項目隨時都有多名程式設計師在提交代碼，使用Git就能讓他們把測試代碼和穩定代碼通過不同分支（Branch）來管理。我們使用master分支作為穩定的版本，來合併每個程式設計師提交並測試通過的個人測試分支；整個團隊使用的可執行客戶端用master分支來編譯創建，就保證了新功能開發的速度和主版本的穩定性。
另一個優勢在於Submodule的使用，通過Git的submodule功能我們可以在不同項目中共享一份核心的底層代碼和部分工具代碼，這樣就不用為每個項目分別進行遊戲引擎和工具更新。Git作為目前最先進的分布式版本控制系統，在掌握難度上是非常高的。國內網遊團隊即使是程序部門使用Git作為版本控制系統的情況也不是太多，而夢加做到整個團隊都用Git作為日常的版本控制系統，付出的努力雖高，但回報絕對物有所值。
數據處理和工具開發
近期的討論中很多人認為Unity的短板之一在於偏重代碼驅動的引擎沒有辦法處理大批量的數據，這種印象可能跟官方和社區對於那個運行超級方便、什麼工作都能往裡放的MonoBehavior類的大力宣傳和依賴有關。實際上Unity裡除了MonoBehavior還有使用.NET標準的自定義類，有用法非常靈活的統一數據類型ScriptableObject，還有各種各樣只有你想不到沒有你做不到的編輯器腳本和數據處理接口。只不過除了MonoBehavior，其他一切數據處理手段都需要開發者去Unity的官方論壇和StackOverflow這樣的泛編程問答站點深入挖據。官方論壇上通過搜索，其實是能找到很多使用Unity做大數據量網遊的同行討論的，只不過這樣的引擎在國內還沒有形成很大規模的知識分享社區，一些做的比較久的中文Unity論壇也缺乏網遊項目的討論，所以給人的印象就是Unity不擅長做這個。
事實上，Unity處理各種數據類型（XML，Json，SQL）都有現成的接口（用戶提供和分享的開原始碼），而《蒸汽之城》策劃團隊日常使用Excel格式的數據配置，也可以很容易的轉化成XML後通過編輯器腳本導入Unity。最後客戶端只要讀取和處理導入後的ScriptableObject就可以了，一些改動頻繁的數據還可以直接使用XML格式在運行時讀取，減少客戶端需要更新的頻率。
說到數據處理使用的編輯器腳本，這裡就必須要探討工具鏈開發的問題。對於任何大型項目，開發配套工具都是至關重要的，Unity的特色在於編輯器本身有著非常優秀的可擴展性，所以我們使用的工具鏈包括編輯器腳本和外部工具兩部分，分別用來處理客戶端和伺服器端需要的數據。比如任務邏輯和對話的編輯器是直接編輯資料庫的，所以我們使用VC製作的外部編輯工具。而包括關卡、資源導入、貼圖合併、NPC角色打包等等要處理Unity使用的資源數據的工具，都是使用Unity腳本製作，開發者通過菜單命令就可以快速完成資源管線操作和編輯。
一款數據量很大的網遊在工具開發和維護方面需要投入的力量是很大的，《蒸汽之城》在增加了工具開發的人手後，其他開發和資源生產部門的工作效率都得到了顯著的提升。此外通過不斷改善工具的可用性，加入大量對用戶操作的預先檢定，可以有效的減少操作失誤造成的數據錯誤，提高了遊戲版本的穩定性。
原型碎片和整合測試環境
上面提到Unity裡能驅動一切的MonoBehavior類為原型開發提供了很大的方便，但作為網遊項目，任何功能和資源都需要在遊戲實際聯網運行環境下進行測試。如何在Unity網遊項目中平衡原型開發和實際聯網測試呢？項目早期基礎功能的原型，包括動畫系統、圖像渲染、角色換裝等等，都是可以直接建立單機原型的。用腳本實現基本功能後再加上編輯器腳本和GUI腳本來為測試加上配套工具，然後再交給資源生產部門來添加遊戲中的資源。
地下城、任務和戰鬥系統因為涉及到很多和伺服器端的通訊部分，如果需要測試就必須使用一個支持最簡單的客戶端服務端架構的單元測試檔案配置。這裡所說的檔案，就是定義了你全部測試內容數據（或者去哪裡找這些數據）的ScriptableObject。包括你用來測試的帳號、角色信息、測試場景、任務或技能配置等等。以主城和地下城為遊戲內容載體的《蒸汽之城》裡，我們也製作大量測試用的地下城或主城場景作為任務和新功能生產的測試環境。測試環境由美術或策劃來製作，然後交給程序部門來測試代碼，最後再交給QA測試剛完成的功能。
Unity的強大原型製作能力主要還是應該體現在項目初期。一旦客戶端服務端架構形成，可以在穩定的伺服器環境上運行遊戲以後，開發團隊就應該把更多的精力集中在如何能夠在實際伺服器上快速添加新內容並進行測試。《蒸汽之城》有過三組測試伺服器，分別用來進行代碼、資源和網頁接口的測試；此外對於需要頻繁更新調整數據的任務策劃和關卡設計人員，他們會使用在個人電腦上架設的伺服器，來避免數據更新對其他人測試帶來的幹擾。
動態下載和讀取
對於網頁遊戲來說，如果不能做到快速啟動和最小化下載等待時間，相對於端遊的優勢就不存在了。《蒸汽之城》裡所有美術資源都被拆分成了非常小的零件，這樣用戶只要下載一次，就可以在運行遊戲時根據需要來動態組合，大量減少了資源的重複下載率。而地下城製作的時候會使用工具進行Serilization，遊戲時每個地下城只需要下載一份XML表單，然後就會自動從用戶已經下載的「資源零件」中尋找需要的部分並進行動態拼裝。體驗過《蒸汽之城》的用戶可以發現任何地下城的讀取都不會超過數秒。
接下來說說Unity頁遊的一大招牌Asset Bundle的使用。Asset Bundle是可以被用戶stream下載的資源包，其中可以包含任何Unity Project中的文件。要做到動態下載，遊戲中的絕大部分資源就都必須打包成Asset Bundle才能使用。在《蒸汽之城》的開發過程中，我們為大部分資源生產者製作了Unity編輯器內的打包工具，只要選擇相應的菜單命令就能自動完成打包和上傳到測試伺服器上。在以後的項目中我們希望能採用Resource.Load()和Asset Bundle結合的方式，客戶端可以分別讀取原始的資源文件來使調試更方便，而測試通過後又可以切換成使用Asset Bundle來保證遊戲的動態下載正常運行。Asset Bundle還有很多創意用法，大家可以看看官網上Unite2012的相關講座。
技術導向的團隊建設
前面提到了Unity在項目規模和複雜程度從單機到網遊的巨大增加，可以說如果對於國內大部分團隊，使用Unity製作網遊都有著一定的風險和挑戰。簡單的說，Unity對於單機遊戲來說，確實有很多「免費附加值」可以用來快速搭建項目和完善產品功能，但在網遊或較大型項目層面，如果沒有對於項目質量的較高要求，沒有一個好的團隊技術氛圍和建設思路，選擇Unity得到的免費回報和付出的技術建設成本實際是得不償失的。
假如看官讀到這裡還對於使用Unity堅定不移，可以看看下面對於如何建設Unity適用型技術團隊的一些建議。
但作為網遊項目，任何功能和資源都需要在遊戲實際聯網運行環境下進行測試。如何在Unity網遊項目中平衡原型開發和實際聯網測試呢？項目早期基礎功能的原型，包括動畫系統、圖像渲染、角色換裝等等，都是可以直接建立單機原型的。用腳本實現基本功能後再加上編輯器腳本和GUI腳本來為測試加上配套工具，然後再交給資源生產部門來添加遊戲中的資源。
地下城、任務和戰鬥系統因為涉及到很多和伺服器端的通訊部分，如果需要測試就必須使用一個支持最簡單的客戶端服務端架構的單元測試檔案配置。這裡所說的檔案，就是定義了你全部測試內容數據（或者去哪裡找這些數據）的ScriptableObject。包括你用來測試的帳號、角色信息、測試場景、任務或技能配置等等。以主城和地下城為遊戲內容載體的《蒸汽之城》裡，我們也製作大量測試用的地下城或主城場景作為任務和新功能生產的測試環境。測試環境由美術或策劃來製作，然後交給程序部門來測試代碼，最後再交給QA測試剛完成的功能。
Unity的強大原型製作能力主要還是應該體現在項目初期。一旦客戶端服務端架構形成，可以在穩定的伺服器環境上運行遊戲以後，開發團隊就應該把更多的精力集中在如何能夠在實際伺服器上快速添加新內容並進行測試。《蒸汽之城》有過三組測試伺服器，分別用來進行代碼、資源和網頁接口的測試；此外對於需要頻繁更新調整數據的任務策劃和關卡設計人員，他們會使用在個人電腦上架設的伺服器，來避免數據更新對其他人測試帶來的幹擾。
首先，團隊項目負責人和技術骨幹關注Unity官方發布的信息和社區技術熱點討論是必須的。比如說從Unity4開始就可以在手遊上使用動態字體和動態陰影了，而這些消息的發布是在去年夏天的Unite前後，一直關注Unity新技術的團隊就可以為項目提前做好特性計劃。而且Unite上大量非常有價值的官方和開發者講座，也能彌補很多官方教程和手冊中沒有涉及的空白區域，恰好是國內網遊團隊急需的（比如Asset Bundle使用講座，Network基礎講座等等）。另外一個非常重要的知識庫是Unity的官方論壇（http://forum.unity3d.com ）和問答社區（http://answers.unity3d.com ），這兩個社區站由官方技術人員和活躍的
Unity用戶共同提供內容和維護。配合Google搜索，你幾乎可以在這些社區網站上找到任何技術難題的答案，而且還會有各種實際案例的解決過程（因為提問的人很可能和你有著同樣的問題）。當然使用這些官方社區必須要有較好的英語閱讀能力，這本身就對技術團隊的素質有了一定的要求。國內的Unity社區和資訊網站也在越做越好，其中像Unity聖典（http://game.ceeger.com/forum/ ）和Unity教程手冊系列（http://www.unitymanual.com/ )都是不錯的資源入口，建議英文不夠熟練的朋友以這些中文網站為索引，慢慢將獲取知識的渠道擴展到國外網站。
第二，Unity項目要形成有規律的從原型代碼到結構化的重構的循環過程。Unity做原型快，又有很多現成的解決方案，在開發周期緊張的情況下，開發者很容易會不斷添加快速完成的功能，最後讓項目的結構臃腫不堪，內容擴展到一定程度就會遭遇新功能添加的瓶頸。也就是說，如果沒有周期化的重構，項目功能擴展到一定程度後，再添加新功能或調整原有功能，其成本都會成倍上升。而太過頻繁的重構又會影響項目進度，如何把握這個度，就要根據團隊人員的結構來精心安排了。
第三，Unity大型項目非常適合從早期就規劃好完整的工具鏈，根據不同開發者的技能和使用習慣定製不同的工具。對於個人開發者來說，Unity裡有大量的中間件可以滿足不同技術水平用戶的需要。在網遊團隊中也可以用相同的思路來提高效率，應該儘量避免只有程式設計師使用Unity，美術和資源生產都只局限在其他外部工具裡的生產環境。另外工具鏈的功能擴展和完善是一個長期動態的過程，根據項目在不同階段的狀態，對於工具需求的變化是非常正常的。建議團隊從一開始就安排足夠的人手開發工具，並且將工具維護和需求收集作為日常工作流程的一部分看待。
後4.0時代特性展望
Unity適用型技術團隊的一些建議。
但作為網遊項目，任何功能和資源都需要在遊戲實際聯網運行環境下進行測試。如何在Unity網遊項目中平衡原型開發和實際聯網測試呢？項目早期基礎功能的原型，包括動畫系統、圖像渲染、角色換裝等等，都是可以直接建立單機原型的。用腳本實現基本功能後再加上編輯器腳本和GUI腳本來為測試加上配套工具，然後再交給資源生產部門來添加遊戲中的資源。
地下城、任務和戰鬥系統因為涉及到很多和伺服器端的通訊部分，如果需要測試就必須使用一個支持最簡單的客戶端服務端架構的單元測試檔案配置。這裡所說的檔案，就是定義了你全部測試內容數據（或者去哪裡找這些數據）的ScriptableObject。包括你用來測試的帳號、角色信息、測試場景、任務或技能配置等等。以主城和地下城為遊戲內容載體的《蒸汽之城》裡，我們也製作大量測試用的地下城或主城場景作為任務和新功能生產的測試環境。測試環境由美術或策劃來製作，然後交給程序部門來測試代碼，最後再交給QA測試剛完成的功能。
Unity的強大原型製作能力主要還是應該體現在項目初期。一旦客戶端服務端架構形成，可以在穩定的伺服器環境上運行遊戲以後，開發團隊就應該把更多的精力集中在如何能夠在實際伺服器上快速添加新內容並進行測試。《蒸汽之城》有過三組測試伺服器，分別用來進行代碼、資源和網頁接口的測試；此外對於需要頻繁更新調整數據的任務策劃和關卡設計人員，他們會使用在個人電腦上架設的伺服器，來避免數據更新對其他人測試帶來的幹擾。
前面說了些經驗和建議，最後這裡再說說Unity4.0後夢加的開發者還在翹首以待的功能。希望提供給其他開發者作為技術評估的參考，也希望Unity中國的大大們能夠看到並幫助改進吧。
第一，Unity4開始全面進入了使用Retargetable（可重定向）動畫技術和圖形動畫狀態機的Mecanim的時代。Retargetable動畫是遊戲業的巨大福音，製作一套動畫就可以適用於不同的骨骼和蒙皮模型，對於項目生產來說吸引力非常驚人。不過目前為止這個特性還不能用於頁遊的動態載入，因為負責動畫Clip引用的Animator裡不支持任何動態讀取，可以說是阻礙頁遊項目全面升級Mecanim動畫系統的最大障礙了。《蒸汽之城》在Unity3.X時代就開發了自定義的腳本FSM（有限狀態機）來作為動畫控制系統，儘管在Unity4裡我們已經能夠使用Mecanim的Avatar來運行本地原型裡的動畫重定向，但因為不能動態讀取加載，一直還沒有在遊戲中正式更換動畫系統，非常的遺憾。
第二，Unity4裡說好的新GUI系統無限期跳票。GUI的開發對於任何項目來說都意味著很大的挑戰和工作量，《蒸汽之城》的GUI使用的是Unity自帶的GUI系統加上一套自己開發的設計工具來製作。在GUI的設計和圖像生產方面已經做到了高效率，但是調整GUI功能時代碼的修改量還是太大了。儘管很多人在官方新GUI系統跳票之後已經轉投了第三方中間件的解決方案，但作為有自己工具開發組，對項目擴展性要求很高的網遊團隊，始終還是希望能夠拿到官方的解決方案來定製，而不是依賴於某個隨時可能停止維護的第三方插件。由於Unity4.0目前GUI系統的懸而未決，我們在配套GUI系統的優化方面也被迫遭遇了停滯。很希望這個系統能夠最終塵埃落定！
第三，Timeline功能神龍見首不見尾，而且更糟糕的是Unity似乎已經不再維護以前的Animation View了。Unity4裡增加了完整的新動畫系統Mecanim，但對於一些簡單的UI或特效動畫，很多時候開發者還是希望能夠在Unity裡快速調整和製作。Animation View在Unity4裡效率下降，子物體動畫曲線的顯示也有些奇怪。而集更多功能於一身的Timeline在Unite2012上亮相之後卻遲遲不見更新的消息。Mecanim是一個專門處理骨骼動畫、動作捕捉、動畫分層和融合的專業系統，但除此之外一個有時間線和關鍵幀的編輯器還是對任何遊戲項目都非常有用的，個人認為Unity團隊不應忽略這方面的需求。
腳本來為測試加上配套工具，然後再交給資源生產部門來添加遊戲中的資源。
地下城、任務和戰鬥系統因為涉及到很多和伺服器端的通訊部分，如果需要測試就必須使用一個支持最簡單的客戶端服務端架構的單元測試檔案配置。這裡所說的檔案，就是定義了你全部測試內容數據（或者去哪裡找這些數據）的ScriptableObject。包括你用來測試的帳號、角色信息、測試場景、任務或技能配置等等。以主城和地下城為遊戲內容載體的《蒸汽之城》裡，我們也製作大量測試用的地下城或主城場景作為任務和新功能生產的測試環境。測試環境由美術或策劃來製作，然後交給程序部門來測試代碼，最後再交給QA測試剛完成的功能。
Unity的強大原型製作能力主要還是應該體現在項目初期。一旦客戶端服務端架構形成，可以在穩定的伺服器環境上運行遊戲以後，開發團隊就應該把更多的精力集中在如何能夠在實際伺服器上快速添加新內容並進行測試。《蒸汽之城》有過三組測試伺服器，分別用來進行代碼、資源和網頁接口的測試；此外對於需要頻繁更新調整數據的任務策劃和關卡設計人員，他們會使用在個人電腦上架設的伺服器，來避免數據更新對其他人測試帶來的幹擾。
結語
製作網遊或有聯網功能的手遊本身就是艱巨的工程，Unity讓表面的一切看起來更美好和更容易，但不可否認廣泛獲得成功的Unity項目還是以相對簡單的手機遊戲為主。在網遊製作方面開發者能參考的知識和信息還是太少了。夢加團隊從零開始一點點的把Unity網遊製作各個謎題拼起來，到了今天終於有了即將上線的高素質的頁遊《蒸汽之城》。希望我們這裡總結的經驗能夠幫助國內業界的朋友們，我們的解決方案也有很多不足的地方，希望國內開發者們能夠多多分享，促進Unity和網遊開發技術的交流！《蒸汽之城》的中文本地化版本也在進展中，預計暑期就會跟大家見面！