AActor

首先是繼承自UObject的AActor，它代表著游戲中的種種表示，不只是游戲物體對象這種概念，而且囊括了GameMode,GameState等這些屬于游戲機制游戲規(guī)則的靈體AActor，這些存在與游戲世界中，但是卻沒有具體的空間表示，因此對于UE4中Actor不像Game Object一樣自帶Transform。

UE4同樣也是使用一種實體組件的模式，即ECS模式，“組合優(yōu)于繼承"，但是多component的組合會產(chǎn)生一些組件通信，耦合依賴過深導致的接口便利損失，而且在UE4的邏輯中，是不希望我們的游戲邏輯寫在component里面的，因此component的功能很獨立單一。

UE4非常強調(diào)的一點就是表現(xiàn)層和邏輯層分離，因此對于一個多component的Actor來說，所有的這些Component都融合進了一個整體的Actor，這個Actor就是一個封裝的盒子，而在這個盒子的內(nèi)部，就可以做一些針對component的相關邏輯操作。

ULevel

level的概念其實同unity 的scene概念類似 ，就是一個世界表示，但是UE4會考慮到資源加載的玩家可見范圍優(yōu)化，因此level是更細粒度的世界表示，更高一層是world，由各個level組成。

level是自帶一個關卡藍圖ALevelScriptActor的，我們可以在里面獲取整個關卡的相關信息，同時由于各個關卡的一些規(guī)則屬性不同，因此衍生出一個world setting來記錄，這個world并非之前說的大的world屬性，而是針對我們的一個個小的level的設置的。

關卡藍圖準確的說也是一個Actor，但是我們在實際的藍圖界面中卻看不見有component添加的選項卡，這只是UE4引擎給我們的一個提醒，不希望我們在關卡藍圖中復雜話它的組件構成，即添加組件，但是在實際中其實我們是可以通過藍圖連線接口Add Component來添加組件的，但是這是不好的，復雜化關卡構成會對整體游戲的Actor邏輯產(chǎn)生影響，因為level是包含世界中的Actor的，而具體的Actor勢必會存在各種組件，這些組件或許會迷惑分不清是關卡組件還是游戲?qū)ο蠼M件。還是那種說法，邏輯與表現(xiàn)分開，其實UE4也已經(jīng)幫我們做好的邏輯的分離，Game Mode，Game Controll其實就是針對具體level的邏輯控制Actor。

world是一種level的集合，提供一種level動態(tài)加載的方法，但是在world加載的時候總是會有一個persistentLevel來初始化世界的.

world的概念不是那么簡單的，不只是我們理解的游戲世界，首先World就不是只有一種類型，比如編輯器本身就也是一個World，里面顯示的游戲場景也是一個World，這兩個World互相協(xié)作構成了我們的編輯體驗。然后點播放的時候，引擎又可以生成新的類型World來讓我們測試。

游戲邏輯的承載，Pawn和Controll

對于unity，由于組合思想，引擎將游戲邏輯也作為一個組合體放在游戲?qū)ο笾?，作為一個ScriptComponent來承載游戲的邏輯，但是這樣的話，是由一個component來管理其他的component，這種同層級別的管理其實是不太好的。

對于游戲中的游戲?qū)ο?，有些是需要由邏輯控制的，在世界中是動態(tài)的，但是有些對象在世界中只是作為一種表示，而沒有具體的移動和邏輯控制，因此它是不需要進行附加邏輯的。對于那些動態(tài)的對象，玩家需要控制的對象，UE4繼承分割出Pawn，更深層次是Character。

對于Pawn而言，它實現(xiàn)的是響應控制，”可被控制“，對于按鍵操作之后是按鍵響應，而在按鍵之后，如何移動就是一個簡單的move操作，這就是輸入響應的結果，而對于邏輯控制則是更高層的行為，比如尋路或者其他的邏輯。

對于Pawn和Controll的對應關系，UE4的限定是1：1的對應關系，當然也能夠?qū)崿F(xiàn)一對多，但是這種多個關系的維護會對控制者的邏輯和性能有一定的混亂和影響。

對于Controll的邏輯信息，Pawn表示的是能進行操作，controll決定的是怎樣進行操作。同時，controll的生命周期是比pawn長的，因為在實際游戲中會存在玩家死亡復活的情況，復活后的controll是不需要變化的，同時還要維護新的pawn的狀態(tài)，因此它的生命周期要長。