拷問Unity:開發U3D遊戲要思考的問題

Game2遊戲:


昨日game2曾就某投資人把移動團隊失敗原因之一歸於選擇Unity引擎進行了一番評論,工具本身無罪,但如何理解工具、正確使用Unity引擎確實需要討論,在選擇Unity之前你或許需要瞭解下這個引擎實際開發過程中的技術特點、以及適應的遊戲產品類型,game2熱心讀者Fxcarl昨天就這個問題專門撰文一篇,來説明大家瞭解Unity遊戲開發、分享心得,推薦閱讀。

如果有技術大牛看到不妨也發表下觀點,説明大家更好的理解Unity,歡迎投稿( news@game2.com )

文/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

本文轉載gamelook,編輯僅做翻譯。詳細請查看原網站文章。

Comments are closed.