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