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的出現能讓各位大爺們好好冷靜下來想想。不要老說"國內這麼做遊戲是有理由的"，我想說的是國外的遊戲做的比你好，也是有理由的！