虛幻4隨筆 三 從UE3到UE4

筆者有幸參與過兩個UE3項目，徹底不一樣的使用方法，總共用了五、6年。引擎學習最好仍是能參與項目，本身看的話每每容易糾結到一些細節上去，而引擎之因此是引擎，重要的偏偏是在容易被人忽視的工做流上。單從細節上看，UE3的代碼不少地方並不完美，甚至有些奇怪，可是一旦作到工做流上，就會發現整個UE3工做流的強大之處。

先回顧一下UE3系統的一些結構要點，權當作個記錄，看看UE4在這些方面有什麼不一樣，做爲咱們接下來讀碼的突破口。

若是真心想要學習這個引擎，最好仍是能用它來作作項目，項目不分大小，只論完整程度，筆者短期內看來是沒機會了。

一、BuildTools

UE4除了工具和插件外，本體不分工程了，UE3的核心部分最後分了Core、Engine、Editor、WinDrv、Network、Renderer等十數個工程，UE4就一個UE4工程。但工程歸工程，編譯時仍是分得很開的。

並且這個工程猜想是靠BuildTools來生成出來的（一開始那個bat）。看起來，散落在各個文件夾下的.cs文件就像CMakeList.txt那樣，它們纔是整個工程的組織核心。

事實上從UE3時代，就能夠徹底脫離Visual Studio IDE來工做了，UE3的工程自己都已經再也不是典型的VC工程，代碼編完後，實際上最後執行的是Build.bat、調用UnrealBuildTools.exe來編譯，因此要改工程設置，也是須要去修改UnrealBuildTools工程的。

** 估計，若是要改工程組織結構，增長文件什麼的，也須要維護這個.cs文件吧。這個可能得等作作才知道了。

不過應該能夠看出來，UE4這裏是爲了支持項目和引擎分離而進行的。

 

二、Core

我的觀點，UE3的Core重點是下面幾個部分：

做爲整個虛幻構架基礎的UObject和由一大堆宏和各類Classes.h這套組織結構反射系統——圍繞它的包括GC、UObject與UnrealScript的互操做性、與編輯器的互操做性、自動序列化、對象克隆等。這個很是重要，整個虛幻體系的核心就是這一套東西，若是前面不注意的話，後面早晚會在這裏栽點跟頭。

序列化和統一具名訪問：ULinkLoader，起這個名字可能主要是由於加載的時候，它會自動分析Object的引用鏈，而且根據須要繼續往下加載。另外，全部虛幻的Object都會有本身獨一無二的具名路徑，例如xxx.umap:persistentLevel.Pawn_0，xx.Material.Material_0，任什麼時候候，只要使用LoadObject、FindObject並傳入這些名字，就能夠訪問到對應的對象。這個在編輯器的維護中是至關方便的一個底層特性。甚至，這個具名路徑還能夠訪問到腳本中的類、內置模板資源等等。

MakeCommandlet和UC腳本核心：Core中間編碼了整個Unreal Script的編譯和運行時環境。Unreal Script編譯過程當中會生成相應工程的Unreal Script/C++互操做文件：xClasses.h以及一堆自動生成的方法和調用。編譯後的結果是.u文件，其實同時就是跟.upk資源文件同樣的格式——虛幻2不清楚，但至少從虛幻3時代開始，資源和腳本就被看成是同一個東西，腳本是可執行的資源，資源是不可執行的腳本。另外與此相關的就是一套調試器——不少人用了半天虛幻3殊不知道虛幻腳本是能夠調試的……AutoDebug命令行或者ToggleDebugger指令搜一下，印象中調試器的核心接口是基於UDebuggerCore仍是UDebuggerInterface這個類。VS裝nFringe插件後、或者自帶的UDE均可以對腳本進行調試。

狀態機：腳本的特殊語法，狀態機是在腳本類內部的概念，每一個狀態能夠重載腳本類某些函數的實現，這樣當狀態切換到這個狀態的時候，就只是執行狀態內的函數而非腳本類的函數自己。Actor和Controller裏大量用到。

Latent：腳本的特殊語法，基本相似於不經過連線的Kismet，latent相似於Erlang這樣的Coroutine語言，每一個語句都是步驟而非過程，步驟可能會花不少幀去執行，執行完畢後接着進行下個步驟，傳統語言的過程只能當前幀執行完畢。

 

其它就是一系列的數學庫、內存管理、輔助函數。內存管理比較有意思，一開始看總以爲問題較大，當時組裏的內存專家Aman Jiang老師實際打出來報告後發現這塊兒管的仍是很不錯的，碎片率遠低於咱們的預期。

 

三、Engine

至關龐大的集合，我的觀點，重點在於：

Actor-Component體系：組件化結構的虛幻版，組件化如今應該是大多數引擎的標配了吧？這塊兒能夠說中規中矩，主要組件仍是得花心思去看看，不然極易在接口調用順序亂掉的狀況下發生問題。渲染器與遊戲上層邏輯經過Component來接口，提供新的渲染技術後，只須要作一個對應的Component就能夠了——SpeedTree什麼的就是這麼集成進來的。

Game-Player-Controller體系：Game Mode決定了當前關卡的遊戲玩法，一個關卡能夠有不一樣的遊戲玩法——對於FPS你能夠想象虛幻競技場中的不少地圖都同時支持Free for all、奪旗、Team計分。對於網絡遊戲，你能夠想象一個關卡資源能夠用來作戰場、也能夠用來作副本。Player是全部IO的總入口，通常一個遊戲只有一個Player，就是Local Player。主機遊戲能夠設計同時存在兩個Player的場合，能夠用分屏顯示來分離各自的IO。進入地圖後，會針對當前地圖生成Controller，來實際從Player截獲輸入和部分輸出操做，並真正影響到遊戲中。相應的概念還包括View（實際上的攝像機）、ClientViewport（遊戲和編輯器窗口）。

Controller-Pawn體系：Pawn是能夠被Controller控制的東西，Controller把IO和UI消息轉化爲對Pawn的操做，通知Pawn完成其功能，並把這些功能執行過程反饋給IO和UI。在遊戲中能夠切換Controller內部的不一樣狀態，例如根據Pawn是在走仍是在爬牆，把輸入消息轉化爲對Pawn不一樣的指令。還能夠切換Controller，好比進載具了，Controller一換就Ok。甚至技能中也能夠切換Controller，比較經典的例子就是虛幻競技場3裏的榴彈炮：普通架起來的狀態下打出的是通常炮彈，炮彈飛行過程當中鼠標能夠一直控制其方向，右鍵能夠把這個炮彈展開使其定位在空中，而後你的視角一直停留在這個炮彈上，鼠標變成在地面選擇一個區域，火炮變成一門發射榴散彈的大殺器，把致命散彈砸向這個區域。筆者接觸過很多遊戲的遊戲系統了——不幸的是這個流程不多有系統可以不加大改地實現。AI也是一種Controller，操縱的是Bot這個特殊的Pawn，這塊兒有興趣也能夠研究一下。

World-Level-Actor體系：World裏存一堆Level，Level裏存一堆Actor， Build後的光照跟Level走，Level是關卡部分的資源單位。但場景圖根是World裏的Hash，虛幻3裏是個八叉樹實現。World裏實現了基本的場景功能，角色的走跑、懸崖邊緣的檢測、走到碰撞體前被擋住、碰撞體位置變化時致使本身上面放置的其它碰撞體變化……你若是有本身的場景需求，能夠修改World裏面的這個部分。注意，在虛幻3裏場景和物理雖然有關，可是本質上仍是分離的，引擎提供了默認的整合方式，但你能夠在Actor裏從新控制這種整合。

資源體系：沒什麼好說的，Material、Texture、各類Mesh、Particle。Material連線球很贊，可是跟渲染Stage有較深的關聯，筆者試圖作過一個自覺得比他更好的，跟Stage能夠必定程度脫耦的材質連線球系統——可是最終發現材質這東西根本上仍是離不開渲染Stage，什麼都想控制的結局必定是什麼都控制不過來。

渲染體系：就不說什麼了吧，Deferred Lighting的Stage體系，網上的文章海了去了，作圖形的這個早就拋腦後了吧。最近一兩年的版本支持了Deferred Shading。這套Stage的低端化替換仍是很方便的——畢竟如今須要考慮到遊戲可能更可能是會在intel HD 3000/4000這種顯卡上跑的可能性了。

 

四、UnrealEd

編輯器……怎麼說呢，這個無法按體系來了，太多了，有些精品也有些糟粕，反正編輯器這東西，無法說，須要擴展的時候本身去改吧。

注意屬性編輯器是如何發揮反射的強大效力的。

有些細節問題，實際作了可能會遇到：拷貝對象時，有些屬性是引用的（通常的Object屬性不加任何描述），有些是複製的（editinlinenew、instance和duplicate），有些是捨棄的（transient）。還有就是虛幻比較喜歡用Prototype + Clone的方式來實現Template-Instance這種需求，典型的例子是Animation Tree和Prefab，實例都是直接從資源拷貝出來的。主要是由於UE3的反射外圍有一個比較強大的Clone系統，可是前提是您得對剛剛列舉的那些關鍵字比較熟悉，不然爲這些系統擴展時就比較容易遇到問題。

多說一句：編輯器選物體用的是把物體的ID渲到一張Render Target上再去這個Render Target上查找鼠標點Id的作法，叫HitProxy，若是你的遊戲想支持像素點選，能夠參考這個東西，很容易就能把這個Stage集成到遊戲Stage裏。

 

五、其餘工程

就沒什麼好說的了：

渲染器：Renderer，DX九、DX十、DX十一、OpenGL的實現都有，DX10只有一個版本曇花一現。

平臺庫：以XXXDrv爲名，例如WinDrv。主要提供平臺方法，沒什麼好說的。

網絡庫：IpDrv、Channel什麼的，也沒什麼好說的。

 

網遊的開發者很喜歡本身構造上層，我參與的第一個UE項目就是這麼作的，實際上最後作出來的上層後來看來比虛幻的整個上層體系差的太遠。第二個項目筆者就一直推進着在虛幻框架上的小修小改。最後能實現什麼呢？能實如今編輯器里根服務器通訊，編輯器調整完Kismet連線圖、資源、布怪點後，不用退出，直接就能夠啓動開發服務器，而後在編輯器內測試剛剛本身作的東西對不對，惋惜由於資金緣由沒作下去，兩年前這個級別的工具集成，不知道有多少人作到了？至少我如今在這個項目裏還沒能推廣到，也不可能推廣到那個程度（筆者鼻子翹起來了~*^_^*）。不過將來不須要再弄了——看看虛幻4的Blueprint，能夠考慮這個級別的集成了。

 

筆者一直認爲，虛幻3強大的地方不在於他的圖形，而是在於這套強大而穩固的結構和迅速的工做流，而當你握這套結構和工做流後，筆者發現全部引擎在本身的面前索然無味，圖形雖然還在追求，但已經退居次席了，而本身從新去作引擎的衝動則不斷下降，直至徹底消失。

用虛幻必定要首先明白一個原則，就是這是個解決方案式引擎，不是OGRE那樣的圖形工具庫，因此你的全部改動必定要符合虛幻的基本結構假設，不然你只是在給本身找麻煩。可是，相信我，符合這些基本的結構假設一點不會讓你的自由度下降，你的控制能力把控能力仍是至關強的——不信你看，筆者上面列舉的框架部分，有哪一個是會影響你的發揮的？M——World-Actor、V——Player、C——Controller，哪一環是能夠省略的？固然，若是您的體系結構設計的比這個還好，那真的很恭喜您了，一山更比一山高，筆者只能感嘆於本身的時運不濟了……

 

這兩天仍是在看例子，看幾個Blueprint的例子，順便回想一下UE3的那些事兒。最近的緊張局面可能會延續到4月中旬，屆時纔有可能有更多時間來看UE4。目前感受變化仍是挺大的，不過，喜在框架方面的改動彷佛頗有限。

從另外一個方面，也證實了UE3的這套遊戲上層邏輯框架，是多麼地穩固和強大。