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