虛幻4隨筆5 使用中的一些發現

行文匆匆，有些不太明白的地方評論裏有補充，如今這裏抱歉了！

 

半年多沒有維護博客了，一方面是媳婦懷孕，另外一方面是公司年中有一個版本……

最近閒暇時間一直在研究虛幻，目前鋪開了大概六七個原型在作，作的過程當中學到了很多東西，有一些新的想法。

原本這些都是準備展開來講的，可是如今看來，每一個話題展開都是須要大把的精力，因此仍是先寫到這裏。有些已經有一些結論，有些尚未展開研究，就當是挖個坑吧，在後面幾個月陸續填。

目前博主所用的版本是4.4，有些結論未必在將來還繼續有效，若是發現有變化，後面會單起博客說明的。

 

總論：

仍在發展中，若是是準備用來作短時間商業項目的，請合理評估風險。用來進行長期商業項目、或者以爲目前的功能已經可用、或者以研究爲目的的，能夠考慮介入。

優勢是開發架構和框架體系成熟，國內策劃不作腳本不作原型的開發模式可能確實相對不易適應。說程序用BP不習慣的恭喜您說出了一句正確的使人髮指的廢話，BP是設計給策劃和關卡設計師用的，不是給你程序員用的——話說回來，也就在中國須要去把策劃的想法翻譯成代碼的程（Fan一聲）序（Yi四聲）員（Gong一聲）。

再次重申，若是您但願什麼事兒都是程序給吃下來，或者您的項目被迫處於這種態勢，而不是由策劃負責腳本和內容的製做，那麼請出門左轉，找CE、Unity（大霧）或者其它引擎，虛幻這種跟歐美式開發方式深度綁定的引擎絕對不適合您。相信我，您只是在給本身找麻煩，而後回過頭來大罵這是一個垃圾引擎——其實只是您項目的開發模式不是原型開發模式，僅此而已。

沒有程序基礎的，看幾個例子應該也能夠本身用BP動手作點原型了，我如今基本主要遊戲邏輯都用BP作，C++給BP寫節點和第三方庫的整合插件。BP用熟悉了，比手寫代碼的開發效率高多了（編譯和部署時間、調試更直觀方便、並且自己拖圖的效率就不比手寫差太遠，有些狀況下反而比手寫高）。

此外開放代碼，比較深坑的地方能夠本身修改，也能夠隨意整合各類C++庫進來，許多細節的實現比較有參考意義，好比WeakPtr之類的。論壇裏有許多C++庫的整合項目的通知，能夠隨時關注。

缺點是上手須要必定成本，此外，平臺上不支持PSV、PS三、Xbox360這些平臺，手機平臺不徹底支持，但願全機種支持的要注意，目前只能考慮Unity或者MonoGame。

升級快一方面也是一種缺點，舊版本還在玩得不亦樂乎，新版本又添了一堆新東西，這不，博主還在頭疼於本身擴展的自細分地表渲染插件在4.4下表現超級糟糕的問題，4.5出來直接這個問題沒有了……沒~有~了~，我那廢寢忘食地搞了一個週末是圖個啥……圖~個~啥~？！……因此，換句話說，專業的事情，交給專業的團隊去就行了。從新發明輪子這種事兒，十年前是時尚，十年後就是愚蠢了。

 

工程部分：

Module不能出現重名。

Build.cs和Build類名必須一致。

能夠建立獨立的Win32工程了，虛幻3是獨立Exe，若是想用到虛幻的功能，要麼是須要把虛幻按照dll模式編譯加載，要麼是整合在整個Launcher裏，虛幻4能夠建立獨立的Win32工程，工程裏能夠只用到虛幻的某些個子集。具體可參考引擎Solution裏的那些Win32工程，此外，早期版Win32的工程設置和後期版的Win32工程設置不徹底同樣。可根據本身的須要選擇最合適的模式。

多個項目間共享的功能，最好創建plugin工程。也能夠修改UBT，添加本身的文件夾。

目前沒有找到能在獨立路徑下創建plugin的途徑，彷佛只能放到項目的Plugins文件夾裏或者引擎Source下的Plugins文件夾裏。

發佈Plugin給發佈版用，4.3彷佛是須要先找到發佈版的Version.h文件，用這個文件覆蓋對應Release版本Git庫中的對應文件，而後再編譯和發佈Release。

全部虛幻的Plugin是有加載順序的，有依賴關係的插件要注意，能夠經過設定Plugin的加載階段和Dependency來解決這個問題。

一個工程（Plugin或者遊戲工程）裏能夠包括多個模塊（Module），注意最好把核心部分和編輯器部分分開，不然發佈遊戲時發現依賴了一堆不須要的庫，太浪費了。能夠理解Plugin和工程是一個打包單元，但Module是一個組織單元。

 

Object Core

反射實現很經典，不必定優美，可是很實用。博主以前試圖實現過一個C++版的反射，template絕對用得比它好（從boost mpl繼承過來的），就是由於缺了它那個分析代碼獲得Meta數據的東西，致使維護Meta起來太複雜了……再次說明牛逼的技術不是在那裏玩技術玩語法，而是在玩工做流……

類和模塊更名了，致使以前作的資源失效？Config文件中的redirector能夠幫助你。

但不是萬能的，BP重命名要當心，彷佛BP類名改過來了，可是裏面的內容沒有改過來……

資源更換文件夾後，本地仍然留有一個1k左右的"尾巴"？這也是redirector的"功勞"。請使用fix up清理。

虛幻的各個Ptr的實現很精彩。RefCount對象可走SharedPtr，此外還有WeakPtr等。

官方推薦瑣碎而單位時間比較小的異步功能，能夠考慮TaskGraph。時間較長的異步功能能夠本身寫Runnable。TaskGraph還沒太搞明白怎麼回事。

 

Actor - Component

Movement拆出去了，UE3的Movement是整合在Actor體系內的，從新實現不一樣的Movement會比較費勁。如今好了，從新作一新的Movement就好，還能夠在不一樣的工程之間重用。

Component具備父子關係了！不只僅是SkeletalMesh對其它Component的父子關係，其它全部的Component都有父子關係了。

Actor的Tick貌似如今是多線程了，具體尚未跟。

 

Player – Controller

輸入如今多了一個InputComponent，輸入消息由Controller截獲後，有可能會先發給激活的Pawn的InputComponent和其它InputComponent。能夠運行時動態切換輸入所操控的對象。UE3只能由PlayerController發佈全部的指令消息。

Component掛接，UE3的Attach/Detach已經更名爲Register/Unregister，在Register以前，須要先把root設置好。與UE3稍微有點不太同樣的是，Actor沒有顯式Register接口（FinishAndRegister作了一些附加的邏輯，調用前須要先評估是否是本身須要的），Register All什麼的在Component數量多的時候很是昂貴。目前對部分Component的Register操做，經實驗是可使用的。

 

渲染核心

Renderer如今有兩個：ForwardShadingRenderer和DeferredShadingRenderer，4.5的變化還未跟蹤。

默認是不開遠裁剪面的，若有需求得本身主動在View裏面設置遠裁剪面。

雖然多線程的調用型改了，但主體流程與UE3的渲染線程模型基本沒有變化，UE3的全部渲染擴展方式，仍然基本可用，主要須要注意的是對其餘設備的向下兼容性（主要關注Shader裏的那些宏便可）。

 

Blueprint

目前主要用來開發原型，幾個版本的細節修改仍是挺多的。

總而言之，首先須要提醒的是，用BP作項目，目前必定要記得多備份，最好本身架SVN服務器，改一點測一下就上傳一次，特別是跟接口和更名相關的場合。博主爲此浪費了兩天左右的時間。

目前Blueprint建立的Actor基類，其基類中指定的Component是沒法被子類修改的，並且其屬性沒法直接做爲Actor的參數來修改。解決方法是在Actor中增長對應屬性，並在Construct圖中，修正Actor的對應屬性。

不帶函數返回值的BP函數，重載時須要在Event Graph裏進行操做。帶函數返回值的BP函數，則是右鍵重載。修改函數原型時，要注意有可能會發生修改前是個右鍵函數重載，修改後是個Event圖重載。

修改與BP合做的Interface調用型的時候，BP的重載實現有可能會發生找不到或是其餘狀況，要當心，改以前記得備份。

全局方法和靜態方法怎麼辦？能夠作到BPFunctionLibrary裏。

讀表雖然有DataTable什麼的支持，但須要代碼介入，感受不是很舒服，推薦本身整合讀表、讀文件功能到BP中，一勞永逸，代碼能夠參考它Json解析和Csv解析部分。

 

UI

相似WPF，熟悉WPF的人應該很是容易上手，數據綁定什麼的基本都是WPF那套概念，對我這種WPF的鐵桿支持者簡直是如沐甘露。數據綁定也是那種上手很困難，但一旦上手就以爲其它全部UI系統都好Low啊這樣的東西……固然，這玩意兒對性能的負面影響也是客觀存在的。必定程度下，性能跟系統的擴展和方便程度成反比，永遠不要想着魚與熊掌都能兼得，要能的話，早有人作出來了。

並不是惟一選擇，Coherent UI什麼的也有插件提供了，並且Coherent也支持Unity和CE3，商業項目能夠考慮。