昨日gamelook曾就某投資人把移動團隊失敗原因之一歸于選擇Unity引擎進行了一番評論，工具本身無罪，但如何理解工具、正確使用Unity引擎確實需要討論，在選擇Unity之前你或許需要了解下這個引擎實際開發過程中的技術特點、以及適應的游戲產品類型，gamelook熱心讀者Fxcarl昨天就這個問題專門撰文一篇，來幫助大家了解Unity游戲開發、分享心得，推薦閱讀。
文/FXCarl
代碼驅動帶來的技術題
游戲碎片化。U3D 引擎有個很有力的特色，就是實時編譯運行。這意味著無論在任何時候，只要按下運行圖標，當前的場景就會進入可執行狀態。這導致了游戲在開發的過程中經常陷入一種不應當的自信狀態。同時也導致了游戲內容長期處在碎片狀態下，并低估游戲功能整合時可能遇到的困難。
資源管理是 U3D 引擎的一個難點。U3D 的資源管理系統因為跨平臺的緣故和操作系統的文件系統是脫鉤的，需要熟練的掌握 Resources 目錄和 Assetbundle 的技術才能靈活的控制游戲中的資源使用情況。但這一工作時常會被簡單的理解為將資源放置在游戲工程目錄下，剩下的交給引擎自己搞定 ……
需要自己做數據系統。我們如今國內研發的作品，絕大多數是數據密集型(策略、經營、卡牌、KRPG)，這和 Temple Run 這樣的游戲類型有些不同。數據密集型的游戲需要采用數據驅動的形式來進行游戲的設計和開發，但是 U3D 提供的框架是一個代碼驅動型的結構(對于原型開發來說極為有力)很多時候會讓研發團隊陷入泥潭 —— 看起來功能開發出來了(只要在U3D的對象檢查器里調調參數就能工作)，卻遲遲無法進入大規模制作階段(策劃拿著數據表格卻無法應用到游戲里)。U3D 引擎本身也沒有提供任何在數據方面的支持，數據表要么需要自行處理，要么需要自己尋找嵌入式的數據庫解決方案。
網絡連接部分其實也是類似。U3D 本身集成的網絡模塊并不是為大規模 C/S 結構的游戲所設計，常需要自行開發一套客戶端和服務器結構。當然也可以求助中間件來解決 …… 但是容易讓人迷惑的地方在于，U3D 既可以使用 .net 的網絡機制像端游一樣工作，也退一步可以用加密的 www 機制，當一個簡單的頁游來處理。如何抉擇是個難題，貿然貪多求全往往換來遙遙無期。
測試 U3D 開發的游戲亦一個很麻煩的過程。原因也是那個幾乎不會崩潰，隨時可運行的場景/邏輯混成編輯器 —— 它會讓開發團隊誤算自己當前的游戲完成度，以及需要什么樣的測試。
尖端技術帶來的麻煩事
高精尖的動態光照和復雜材質系統。U3D 比起其他的移動平臺或者網頁游戲開發工具而言，往往最打動人的就是其無與倫比的畫面渲染效果。但是在光鮮的官方演示背后，仿佛總有看不到的壁壘阻礙著其他開發者的步伐。實際上駕馭 U3D 所需要的能力是超乎一般想像的。U3D 的渲染架構的確夠強大，完成 Unreal 甚至 CryEngine 級別的畫面渲染質量都是可能的，但是它并沒有包裝這些系統而是將靈活性交給了開發者。我們的程序員是否已經控制住了渲染管線的復雜度?我們的技術美術是否可以指導我們的美術完成充分發揮 U3D 能力?美術制作人員是否有具有勝任所謂“次世代”精度要求的游戲內容制作?這些東西屬于小團隊嗎?
全局光照烘培。這是一個非常非常非常實用的 U3D 功能。理應所有的 U3D 團隊都靈活使用。但是想要用好就有了另外一番難度 —— 美術和場景制作人員的配合，而誰來負責就比較難說了。另外美術必須用非常精準的尺寸來制作場景中的物件，否則 U3D 將無法正確的處理全局 UV。
工具鏈帶來的紛紛擾擾
GUI 系統的各種理論。所有人都在吐槽 U3D 自帶的 GUI 系統太慢 —— 問題是真的有證據嗎?一方面很多人說我做測試的時候做了一大堆的控件，的確很慢。另外一方面大家也會發覺 GUI 系統會帶來一些不必要的渲染請求(Draw Call)。于是大家都在拼了命的做兩件事情，一個是減少渲染請求，一個是想盡一切辦法的避開 GUI。但其實情況沒那么嚴重，無論是挑選替代中間件如 NGUI 還是直接使用 U3D 的 UI 系統都不會巨大的影響 —— 除了不當使用之外極少見到 GUI 成為性能焦點的時候。不過無論是 NGUI 還是 U3D 內置 UI 都沒有很好的 UI 工具 —— 要么過于程序員導向，要么過于偏向布局而不方便增加代碼功能。內部開發一些擴展工具或者工作流程都很有必要。
版本控制的難題。Asset Server 還是 SVN 其實多多稍稍都有不適應 U3D 的情況。但是更關鍵的地方在于整理好文件的內部結構以及經常備份。恰當的使用 U3D 的命令行模式可以實現 U3D 工程的自動編譯發布。
擴展 U3D 本身功能的能力。因為 U3D 較為完整的功能而忽視對 U3D 本身的功能拓展是一種常見狀態，隨時保持專人不斷的優化 U3D 本身的功能是非常重要的，譬如各種各樣的批量化操作等等。但是這有個前提，擴展工具需要充分理解工具，U3D 相對來說功能過于強大，以至于很多團隊中的成員會害怕學習，而將 U3D 作為少數團隊成員或專屬于程序員的工具 —— 這就很成問題了。
需要前瞻性的判斷能力
每一個，每一個國內開發 U3D 游戲的團隊都在抱怨 U3D 的中文字體支持問題等等。可是實際上真正用前瞻性的角度在使用 U3D 引擎的團隊并不多 —— 以今天此時此刻為例，U3D 4.0 已經可以在任何平臺上使用動態的字體，支持 Unicode 編碼 —— 中文不在話下。從 U3D 3.5 遷移到 4.0 幾乎不用對項目做任何的修改，而如果說之前并不知道 4.0 會支持動態字體的話，那么為什么不多去官方論壇關注一下每個版本的開發進度情況呢?每一個在 2013 才會發布的游戲都不應該擔心字體問題才對嘛 ……
保持對每個版本 U3D 更新內容和未來 U3D 功能的關注可以大量減少重新發明輪子的問題，也能在遇到一些困境時保持更好的心態。直接郵件開發者也會是個很好的選擇，請一定要多騷擾他們!一般提前3個月到6個月就能獲知將來版本可能更新的內容的。
1 “Code-Driven”
State Management
Assets Management
Data Management
Networking
Testing
2 CuttingEdge Techs
Dynamic Lighting & Complex Materials (Textures)
Lightmapping
Nav mesh
Mecanim
DX11
3 Toolchain
GUI
VersionContorl
4 Vision
原文地址:http://game.zol.com.cn/354/3543149.html