UE4隨筆 二 第一印象

打開UE4，短暫的興奮事後，開始大概掃一掃UE4的編輯器，整個界面比UE3更有現代氣息：

 

以前看其餘人寫的文章，虛幻4最重要的改動集中在下面幾個方向上：

跨平臺：

WIN和MAC平臺都能使用，這就意味着必須使用兩個平臺都能接受的方案。

界面：

因爲上述的原則，WPF界面雖然很酷，不支持MONO就只能跟好評無緣了（順便吐槽一下微軟，基於NET作了那麼多東西，卻老是有始無終）。所以虛幻這回是本身搞了個界面系統出來……並且更喪心病狂的是這個界面能夠用在遊戲裏……

C++化：

不知道是由於Unreal Script在移動平臺上的性能表現不給力，仍是由於本身維護一套Script成本稍顯浪費，不管如何，UE4開始，以前負責鏈接工具和邏輯、內容提供者和解決方案提供者的Unreal Script讓位給了"格式化"的C++。

這個改動並非孤立的，相應的，整個解決方案更明晰地劃分爲了核心層、插件、邏輯層，一方面也提升了跨平臺方面的能力。

同時，圍繞着這個特性，最重要的應該就是熱更新功能了吧？邏輯層代碼因爲已經獨立於核心層，因此C++編撰的邏輯層代碼修改，不須要退出編輯器，就能夠在編輯器中天然而然地編譯並從新載入——參與過實際項目的戰友們應該都明白這意味着什麼。

另外一方面來講，國內很多戰友拿到這種國外的引擎每每是一種暴殄天物的用法，把這些引擎改得亂七八糟。因此筆者我的感受Unity從新定義了國內的引擎用法——沒代碼引擎變相的"好處"——人們再也不是關注與技術細節，而是關注與Workflow了，然後者纔是國外引擎如今真正的核心和強大之處。筆者本人如今就深陷於一個因爲改造了國外本來優秀引擎而致使滿地大坑的項目中……不過想來將來會愈來愈好——國內的開發者若是如今再準備把引擎改得亂七八糟，是要被策劃和美術同窗鄙視的——人家自己這麼牛逼的特性，你一弄，沒了，咋回事兒？給個解釋唄？

Blue Print：

其實就是以前的Kismet的強化升級版，UE3單用Kismet能作出遊戲，升級版的Blue Print應該只強不差。

UPK：

不見了，資源單文件存儲：爭議滿滿的UPK終於離開歷史舞臺了，全部資源如今以.uassert的後綴名分散在Content文件夾下的各類場合。這也意味着以前資源包升級和DLC最大的一個攔路虎沒有了。看Launcher自己就作了自動更新，想來自動更新應該是引擎自己就能夠支持了吧？

 

大概用了用，瀏覽了一下它的一些例子，感受都很不錯。

若是想開始製做本身的遊戲的話最好先看看Content Examples：介紹虛幻4的基本特性和用法。從頭至尾瀏覽一遍基本上這個引擎的使用方法就都清楚了，將來這塊兒的工做應該主要是美術和策劃的工做，程序大致應該瞭解一下，特別是若是尚未接觸過虛幻的同事們，這個可讓你很快明白虛幻的整個工做流。

基本上，除了藍圖（虛幻3裏KISMET的加強版）、地形有些變化外，其它內容部分相對UDK並沒有太大變化，虛幻3玩家應該能很快就上手。

其餘例子可能是一些手機版的遊戲例子，不過例子不在多在完整。順便說一句，Strategy Game這個能夠關注一下。當年跟不少人爭辯說虛幻能用來作RTS沒人信，這個例子雖然不徹底是一個RTS，可是基本上能夠改變"虛幻只能用來作FPS和TPS"的印象了吧？

 

本身創建一個例子工程，隨便找了個Third Person的模板，帶BP的模板是指純Blue Print，不帶任何代碼的。筆者建立的是帶代碼的版本：

Binaries顧名思義，這個例子最後會生成一個DLL在Binaries裏，而後編輯器會從新加載這個DLL。熱更新的具體代碼還沒看，可是應該是這個路數沒跑。

Config跟UE3的Config同樣，項目級別的系統設置，後面詳細展開，通常來講，若是要改設置的話是改這裏的Config。

Content就是原來UE3的Content，美術、策劃資源全在這裏，不解釋。

DerivedDataCache還不知道是作什麼的，後面看看吧。

Intermediate是生成的臨時文件，包括工程、中間文件。

Saved包括一些運行時會建立並維護的內容：備份、日誌、運行期的Config，跟UE3的方法同樣：這個Config不須要去改，改動的應該是根目錄Config下的內容。

Source不用說就是代碼了。

會自動生成SLN，打開這個SLN就能夠開工了，就像Unity會自動幫你創建一個Mono Develop工程同樣。

如前所述，虛幻引擎所使用的是C++，而不是C#、Java代碼。有人總以爲C++會致使虛幻上手難度變高，筆者我的感受還好，由於你用到的C++是帶有必定限制的，這些C++類是須要考慮與引擎其它部分的關係，以及考慮與編輯器的關係的，再加上虛幻本身實現了垃圾回收，因此整個調用並不會比C#麻煩太多——固然，LINQ什麼的特殊語法就罷了。

生成的代碼包括：

ThirdPerson：模塊文件，彷佛是定義這個DLL模塊的，追溯了一下感受像是DLL Entry這樣的東西。

ThirdPersonCharacter：第三人稱模式下，控制器操做的對象。目前裏面寫了不少跟輸入消息綁定的語句。

ThridPersonGameMode：Game Mode是UE3帶過來的概念了，當前第三人稱遊戲的一些設置，目前這裏面定義了當前遊戲控制器的操做對象：

    // set default pawn class to our Blueprinted character

    static ConstructorHelpers::FObjectFinder<UClass> PlayerPawnBPClass(TEXT("Class'/Game/Blueprints/MyCharacter.MyCharacter_C'"));

    if (PlayerPawnBPClass.Object != NULL)

    {

        DefaultPawnClass = PlayerPawnBPClass.Object;

    }

注意這裏，不是直接註冊的ThirdPersonCharacter，那ThirdPersonCharacter還有什麼用？

別急，咱們先看看：

Class'/Game/Blueprints/MyCharacter.MyCharacter_C'

這個意思是從Content/下的Blueprints里加載MyCharacter.MyCharacter_C，並把它認成一個Class。

咱們去資源裏找這個BluePrint：

打開：

解釋一下就是這個BluePrint是從ThirdPersonCharacter派生的……OMG

因此，寫在ThirdPersonCharacter代碼裏的那些與輸入消息的綁定纔有用：由於是這個MyCharacter是從這個C++腳本派生的嘛。

可是這麼一來，MyCharacter一方面能夠集成程序提供的基本操做方案，另外一方面，策劃能夠經過BluePrint爲其設計一些特殊的連線流程，一箭雙鵰啊！

有些東西，不想給策劃弄的，或者策劃弄不了的，好比AI底層，程序來集成就行了。想給策劃弄的，這麼一來你本身Blue Print去吧。

這塊兒筆者真心給跪了。Orz

 

過去的UE3的Kismet也不是不能跟對象一塊兒用，但那若是在編輯器裏操做，就是得用Prefab，自己Prefab沒有任何跟代碼相關的概念，基本相似於一個各類對象放一塊兒的大組。從某類繼承？對不起，沒這個概念。

因此UE3裏，這種狀況就得本身用Unreal Script寫個UC類，而後在代碼裏本身手動拼各個組成組件的空間關係……加上Kismet互操做的代碼來進行Kismet的互操做。

如今這Blue Print徹底超越了Prefab這個概念，至關於把原來Unreal Script的這個工做用圖形化的方式接管過來了……難怪Unreal Script被完全拋棄。

點

開始運行，享受了一番，在ThirdPersonCharacter的方法裏斷點調試了一下，與猜想基本無差。

最牛逼的是，咱們把代碼裏Move Right代碼注了，

編譯，而後再跑，不關編輯器，角色的向右移動就被咱們給斃掉了，只能向前衝。

這個過程稍微有點危險，筆者致掛一次，記得保存改動先。

 

還想繼續整整，到上班點了，最近公司工做較忙，只能先放放後面弄了。

筆者如今進行的其實就是UE3以上、UE4未滿的工做：策劃經過圖表完成本身的想法。在一個老企業中推行這種其實已經不算新，但在國內特別是北京圈還不算很是能讓人接受的作法。但願此次UE4的出現能讓各位大爺們好好冷靜下來想一想。不要老說"國內這麼作遊戲是有理由的"，我想說的是國外的遊戲作的比你好，也是有理由的！