文 / 王楠 (夢加網絡 遊戲製做人)程序員
前段時間關於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腳原本爲測試加上配套工具，而後再交給資源生產部門來添加遊戲中的資源。
首先，團隊項目負責人和技術骨幹關注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腳原本爲測試加上配套工具，而後再交給資源生產部門來添加遊戲中的資源。
前面說了些經驗和建議，最後這裏再說說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團隊不該忽略這方面的需求。
腳原本爲測試加上配套工具，而後再交給資源生產部門來添加遊戲中的資源。
結語
製做網遊或有聯網功能的手遊自己就是艱鉅的工程，Unity讓表面的一切看起來更美好和更容易，但不能否認普遍得到成功的Unity項目仍是以相對簡單的手機遊戲爲主。在網遊製做方面開發者能參考的知識和信息仍是太少了。夢加團隊從零開始一點點的把Unity網遊製做各個謎題拼起來，到了今天終於有了即將上線的高素質的頁遊《蒸汽之城》。但願咱們這裏總結的經驗可以幫助國內業界的朋友們，咱們的解決方案也有不少不足的地方，但願國內開發者們可以多多分享，促進Unity和網遊開發技術的交流！《蒸汽之城》的中文本地化版本也在進展中，預計暑期就會跟你們見面！