如何評價虛幻4的藍圖系統？

01-03

謝邀

藍圖是非常先進的編程環境，非常先進的一種編程方式。來看看其他領域工具的圖形化編程工具是個什麼樣子？

先看看arduino的一種圖形化編程IDE

這種IDE 一看就讓人明白，學習起來非常方便。並且如果代碼塊做的好，開發起來效率真的很高。只是很多程序員不習慣而已。

在看下面這個 Labview

這些工具更加適用於面向組件式開發，這是說的，不是專業領域的專家說的。

比如我們需要一輛汽車，直接拖一輛汽車進入IDE，然後連連線就可以實現各種功能，而不用從代碼層橋來敲去，是極大的提升了編程效率。現在遇到的各種問題是很多傳統的程序員不習慣這種連連線的方式來開發。比如說幾萬行的代碼換成圖形化語言，那密密麻麻的連接線就已經搞死一片人了。可能我們還沒習慣用連連線來進行編程。

回頭說說unreal的藍圖，藍圖之前也出現在UDK版本裡面，當初叫做kismet。

到了unreal4 時代，簡直是將這種圖形化編程發揮到了極致。

扯太多也沒多少時間，直接簡單的做個總結。

優勢：

1.開發方便。

2.容易上手。

3.面向組件。

4.開發效率高。

劣勢：

1.維護複雜。

2.二次開發使用C++，是優勢也是劣勢，菜鳥沒法玩。

3.老程序員入門比較慢，因為不習慣這種方式編程。基本上就這些吧。

首先要明確一點，Epic從來沒想過用Blueprint來取代C++，樓上一眾說「沒什麼卵用」，「用來拉攏小白用戶的一個手段罷了」的不知道你們想過Blueprint真正的應用場景是什麼？

Epic自己的說法是，Blueprint可以實現大部分C++的功能，甚至小型遊戲可以完全通過Blueprint來實現，但對於大中型的遊戲是不建議這樣做的。為什麼？因為這不是Blueprint的設計目的，也不是其發揮優點的地方，你非要趕豬上樹還嫌豬爬樹沒貓爬的快？

正確是流程是由程序員使用C++來開發核心的框架邏輯，並暴露一些參數及介面，設計師創建由C++類繼承的Blueprint，進行簡單的參數配置或業務邏輯擴展，實現設計目標。通過這樣的方式設計師不需要會C++也能夠從程序員的工作獲利，並且在有微小改動的時候可以自行解決而不需要回頭找程序員修改底層代碼。

BP就是解放程序員的，讓LD完成他應該完成的工作

程序員就去做哪些高大上的功能。

同時也能讓沒有程序員的團隊做好遊戲。

優點

有效的降低了引擎的學習成本，我一個完全不會編程的兄弟用一個星期左右就能用藍圖實現簡單的功能。

有效的提高了項目開發的效率，複雜的功能用c++封裝成模塊，在藍圖中直接調用，調整方便。

缺點

可讀性差，有人說過，代碼寫出來是給人讀的，只是恰好能夠運行罷了。藍圖的可讀性不好，拿到別人的藍圖通常要讀很久才能搞懂邏輯。

不易交流，通常我們在社區討論藍圖演算法時，只有通過截圖，無法像程序一樣貼代碼，如何把複雜的程序通過截圖的形式表達出來也是一件讓人很頭疼的事

容易混亂，(我覺得這是人為原因)用藍圖編程，常常會把藍圖搞成一團亂麻，線飛過去飛過來的，用連線做循環的跟用goto語句的一樣。。。

相比優缺點，我更加讚賞藍圖，因為效率真的非常重要，簡單的功能用藍圖兩分鐘搞定。當然，我認為藍圖布線的管理非常重要，布線好，邏輯清晰的藍圖對整個項目維護都非常重要。嗯，是的，這是個非常適合處女座的工作

所見即所得，熱更新，做功能相當方便。

規模一大容易混亂，不如代碼清晰。

寫起來超級麻煩啊。

這樣遊戲設計師和美術也可以做獨立遊戲了

我說本質上它就是給美術用的你信不

會了藍圖你就不想換引擎了……

C++我目前認為還是首選

不過最合適的還是C++為主藍圖為輔來做遊戲（獨立開發）

哪個也不能扔

藍圖我覺得是非常具有創新的一個設計，而且設計的非常好

極大降低了程序製作的門檻

讓遊戲設計者能把概念做出來，降低了產品經理和程序員之間的溝通成本

大概就和BSP的意義一樣，作為一個產品經理，我把原型做出來了，雖然不一定能用，但是我就是把產品做出來了，至於怎麼讓這個產品上線到用戶的手機或者steam上，那是你們程序員要乾的活，你們想辦法把程序吃的資源降低，讓產品上線就行，反正我把產品的樣子做出來了。

上述其實不嚴謹，藍圖也可以做遊戲的。

但是會寫程序的人寫的更快，效率更高。

藍圖還是給不會寫程序的人留下了一條活路

而且並不覺得不會程序的人就是小白用戶，術業有專攻而已，那些厲害的美術，不一定不如會寫程序的程序員，做個遊戲沒程序員不行，但是沒有美術，同樣啥都做不出來。

藍圖就是為這些美術人員降低了技術壁壘吧。

所以是絕對先進的技術。（個人觀點）

沒用過ue4的藍圖，

我認為有兩個好處

1、可以用來拉攏小白用戶的一個手段罷了。

2、想快速嘗試引擎的某個組件的功能，看看效果。有了藍圖能夠快速的看到效果。

但是如果真正開發工程，帶來的這點好處微不足道。

圖形比代碼直觀是有前提的，規模稍微一大，圖形直觀的優勢蕩然無存，

且不說要批量替換、查找、merge 等等。

C++與藍圖的關係，很像老司機和自動擋的關係，一個老司機他了解汽車的組成結構，對各個組件零件的作用熟爛於心，他駕駛手動擋的時候能感受到機械之美，駕駛樂趣，這輛車子在任何路況下他都可以得心應手，藍圖更像自動擋駕駛，我不想關心什麼汽車結構知識，我只關心蹬一腳油門就往前竄，我的關注點是更簡單方便的到達目的地，而不是繁瑣的駕駛本身！

C++是龐大的編程學術知識，而藍圖是這個知識體系下的生產工具，至於是老司機更優秀還是自動擋更迅捷，他們關注的目的不同而已，一個運輸隊他總需要很少的老司機和大部分的自動擋，這樣才能真正的去運貨而不是整個車隊都在秀操作玩極限漂移。

那麼個人又該如何選擇呢？看你的目的了，你想要更偏重底層，偏重引擎本身知識，那你就去做個老司機，如果你的目的不是引擎工具，而是想藉助工具快速實現某個東西，那還是蹬腳油門往前竄更實在！

搞搞動畫，搞搞材質紋理，搞搞umg還是可以的，別的還不如整常見腳本。。。不過官方死活不弄。。

ue4的圖形化編程，一開始我是非常的不習慣，很納悶這玩意能有個啥用，現在手機遊戲一個比一個邏輯複雜，藍圖邏輯一旦複雜了，就基本上沒法維護了。

但是後來我自己開始用ue4做app試水，在使用的過程中才發現藍圖的設計理念其實非常強大，和c++的介面無縫對接，給人一種極其愉悅的編程體驗，相比之下看看lua和c++或者和c#對接，各種數據結構的轉換，各種奇葩技巧將c#或c++中的類導出到lua中，這個過程就算不能形容為痛苦，也著實在開發的過程中感覺到很噁心。ue4這方面就做的非常到位，藍圖和c++代碼的對接入行雲流水一般順暢。

ue4的上手速度要比unity這些引擎要快得多，你可以想像一下，完全沒有任何基礎代碼的情況下，需要做個帶界面的簡單app，unity需要做多少準備工作？如果還想在unity里嵌入lua的話，找個lua庫，以及lua和ui的交互的代碼準備多長時間？而ue4，直接藍圖拖節點就能開搞，無需準備那麼多不得不需要的基礎代碼。

我以前找一個能快速開發的引擎找了很久，試過unity，cocos2dx，還有以前的as3，感覺這些引擎雖然強大，但是想要快速開發一個項目還是需要準備不少基礎代碼，直到我發現了ue4的藍圖，才發現ue4才是開發小型app的最佳平台，沒有之一。

就是想把遊戲開發業者綁在引擎上面，若真的是為了解決問題，引入一個腳本語言即可。