【本題被選為20190923-20190929的精選題目。在此期間後本題答案最高贊答主將獲得虛幻官方送出的周邊禮品一份】

自Unity2018.3beta當中加入Prefab嵌套以來，Prefab與UE4中的Blueprint使用越來越相近（編程方式截然不同）。那麼二者相比，各有哪些優點，又有哪些缺點？你覺得哪一種設計更好用？

好問題，我就來口嗨一波吧。

對比 Prefab 和 Blueprint，從多個視角入手。（這裡直接假設是 Actor Blueprint 了，其他的並沒有可比性）

  • Prototype
    • Prefab 不用多說，他本來就是用來干這事的。
    • 對於 Blueprint 來說，存在一個 CDO（Class Default Object）的概念，通過複製這個對象來實現。
  • 編輯流程
    • Prefab 可以直接在資源管理器中創建，也可以把場景中的實例反向轉化為 Prefab，在新的 Unity 里，編輯流程集成到了場景編輯器里，可以進入 Prefab 模式編輯 Prefab（2020 版本還可以在場景內高亮 Prefab 進行編輯）。
    • Blueprint 是一個帶 Default Object 的 Class，所以他是一個 Class 不是一個 Object，編輯只能在 Class 編輯器里做，引擎在編輯器里提供了一個獨立預覽窗口。
  • 復用，單繼承
    • Prefab 可以通過 Prefab Variant 來實現這一點，可以進行 Override，可增可減，對實例的修改可以選擇性的同步到 Prefab。
    • Blueprint 可以通過 OOP 的繼承來實現這一點，只增不減。
  • 範式，編碼方式
    • Prefab 十分清晰，用 Behavior 編碼，用 Prefab 組合。
    • Blueprint 比較混亂，可以在 Actor 里編碼，並陷入繼承地獄，也可以在 Component 里編碼並用 Blueprint 組合。
  • Nested Prefab，擁有層級結構的對象集合，
    • Blueprint 要實現這個功能可以掛載 ChildActorComponent，而這麼做的工作流和場景編輯器無法兼容，基本沒法用（上面已經提到過），這一點上 Blueprint 完敗了。（經評論區提醒，有插件彌補了一些缺陷）

總結來說，雙方提供的功能差距不是很大，Blueprint 靈活上手簡單。而 Prefab 結構更加清晰，工作流更加連續，並提供了正確的引導（組合優於繼承），隱式的增加了可維護性，所以本次的贏家是 Prefab。

其實仔細對比，兩者根本就不是一種東西。

藍圖主要意義是編寫邏輯。prefab主要意義是邏輯+資產的管理工具。

藍圖很像unity的monobehavior，是一種概念上的component，實際上unity assets store也有一些節點編程的插件。開發者是可以在unity中做一些類藍圖的事情的。

prefab則是一個靜態實體，component參數暴露出來給設計師修改，核心邏輯不暴露。在UE中就相當於把一個Actor打包好，可以快速調用，批量複製。

如果要強行對比優劣，我建議你用youtube搜索關鍵詞blueprint prefab或者ue4 prefab或者unity blueprint。

明顯ue社區對prefab工具的渴望比unity社區對blueprint的渴望高多了

這真的代表不了什麼/狗頭

Prefab有個不知道算優點還是缺點，我是覺得算優點，接受不同意見。

Prefab比起BP，最根本的關係在於：心裡有點B數，知道自己是幹啥的。

作為一個序列化文件，以掛載腳本的信息為己任，他的任務基本只有一個：掛載信息。Prefab是不主動參與邏輯的，所謂的掛載腳本也不過是一個保存著「我有XXX這個C#腳本」的信息。

而BP本身有點搞不清楚自己的定位，可能是因為連連看的原因，我會覺得這個序列化文件居然跟程序聯繫到一起了，這就讓我覺得非常不舒服，覺得BP有點不知道天高地厚敢跟天王老子爭高下的意思。。雖然最終編譯的結果是一樣或者差不多，但是在開發時有這麼一手還是很膈應，很噁心。

目前我個人推崇不使用藍圖開發任何邏輯，堅持把BP當成純數據格式使用，並使用純C++開發，那這就不是問題，甚至Actor的設計還是優勢。但是我很難保證如果要進入一個開發團隊，這樣的習慣是否能夠堅持不被動搖，所以我還是認為官方應該從根本上斷掉毛病根源。

先介紹一下背景：

  • 本人未使用過UE藍圖，但完整參與過用類似風格的育碧內部引擎的多個項目，最大一個為3D暗黑風格多人遊戲，規模約&>50人*3年，職務：通用程序員
  • 兩個U3D引擎的3D-多人ARPG項目，單個規模&>20人*2年，一個已經正式上線，一個已90%。職務：伺服器主程+客戶端打雜

其實我認為兩者對比不是很合適，而藍圖和常規腳本語言對比，Prefab和常規配置文件對比，可能更好一些。所以我這裡就用可視化腳本代替藍圖，按我自己的經驗總結了一個簡單的表格，裡面的分數是相對得分，僅作為對比：

簡單的單項對比，總分高不代表可以獨立使用

有空我再對每個特性的細節進行展開描述。

大項目當時是：可視化腳本+自定義2進位配置文件+C++，因為經驗不足，開發效率和維護性問題很嚴重，越往後維護佔用越多時間，反而沒有多少時間開發新功能，甚至每個裡程碑專門預留2個月給技術組重構。後期引擎組意識到問題準備添加腳本支持，但是項目因為開銷太大周期太長成果有限，最後項目取消。

U3D項目這邊：Prefab+Lua+C#+Csv，當然吸取了之前的經驗，充分利用各工具的長處，前期3個程序員就完成70%進度，後招進來的新人基本1-2個月可以順利產出，開發效率非常滿意，最後項目也順利上線。

總結：

這裡沒有要黑藍圖的意思，尺有所短寸有所長，合理使用各種的工具太重要了。單個技術對比（比如c++和c#）好像差別不大，但是多個技術累積起來，差異就非常明顯了。如果讓我選擇的話，我會選擇：藍圖編輯可視化相關內容+Lua做高層邏輯+Csv做配置+C++做核心（即圖中綠色的特性組合起來）。

揚長避短，實用第一。

正如大家說的Prefab和藍圖對比不太恰當，因為藍圖是一個可視化編程的語言，而Prefab只是個資源，和藍圖對應的東西其實Unity里現在還找不到（Unity的C#應該對應虛幻的C++）。

要知道要開發藍圖這種可視化編程的工具開發量可不小（編輯器、編譯器、虛擬機）。

虛幻提供了藍圖這個系統的好處是可以更好的將邏輯進行工程化的分層，而其實對應特殊的系統需求，應該特化出對應類型的藍圖來處理，而不是使用通用藍圖直接硬幹（有些人嫌棄藍圖做數學運算節點太多可讀性差就是一個例子）。

特化藍圖最簡單的方式就是合併成函數節點。

而最理想的方式是直接拓展藍圖系統，定製自己特化的藍圖類型，定製特化的藍圖節點對複雜的邏輯需求進行定製化的抽象。

下面列出虛幻幾個特化的藍圖類型：

  1. 動畫藍圖
  2. UMG
  3. GameplayAbilitySystem

在我看來動畫藍圖是比較能表達藍圖抽象能力的一個特化，它將動畫的各種IK、混合、過渡等邏輯抽象進一個個特殊的節點中，實現了和業務邏輯的解耦，而業務邏輯直接通過動畫調度這些節點，能快速的進行動畫需求的開發。

下面是我定製藍圖做的角色的調度系統，拓展了藍圖的編譯器使得具備了遊戲特殊需求的編譯時檢查能力，定製了藍圖節點來抽象角色的特定行為。

然而這套系統在Unity的當前的生態下現在實現起來是很困難的，再把它工程化就更困難了。

總結下藍圖這種可視化的編程工具現在Unity生態下還沒有完全和它對應的功能，而這種可定製的節點化編程工具可以提供非程序的各種設計人員（遊戲藝術家和設計師）操作遊戲邏輯的可能，多總比少好是吧？

推薦閱讀：
相关文章