Download

[原創]關於C++、Blueprint與Script的一些雜談

我的部落格版本: http://dorgon.horizon-studio.net/archives/773
我正在販賣的plugin: Content by dorgon chang - UE Marketplace

歡迎指教與討論 :slight_smile:

=================本文開始========================

我們知道,除了使用Blueprint之外,還可以選擇使用C++來進行開發。然而,UE4中的C++有著許多跟標準C++不太一樣的規則。這是由於引擎為了減少使用C++編程時的門檻,因此在底層實作了一套Reflection(UProperty)跟Garbage Collection(GC)的機制。只要照著UE4的編程規則進行C++類別的設計,不僅可以減少各種資源管理上的議題,還能夠自動享受到由引擎方所提供的許多便利功能。

或許有人會有疑問:C#或JAVA也有Reflection跟GC,為什麼UE4還要自己用C++實作一套?直接跟Unity一樣用C#當成Script來撰寫遊戲邏輯部份不就好了嗎?

其實UE4++跟.NET C#在機制上有著根本上的不同。前者是在執行編譯之前,會先使用Unreal Header Tool(UHT)產生相關需要的資訊,然後用著同一套C++ Compiler將這些產生出來的Code編譯成可以執行的Native Code;而C#則是先編譯成Bytecode,在.NET中稱為Common Intermediate Language(CIL),然後再實際安裝到目標機器或第一次呼叫相關方法時,呼叫Just-In-Time(JIT) Compiler將Bytecode編譯成Native Code執行。

UE4的方法可以想見,其執行速度會比較快,但由於最後的執行檔內包含了所有的Reflection資訊,因此檔案會變大;而使用Bytecode的方法,我們所損失的就只有第一次執行程式時的速度,以及一些可以使用在C++中的優化技巧。

其實在UE4釋出之前的幾代引擎,是有自己的一套UnrealScript來當成遊戲邏輯的編程使用,其第一代遊戲引擎更是在1998年就已經釋出。因此我們的問題應該要換成:為什麼要將UnrealScript從四代的移除?雖然使用Script會需要以執行期的效能為代價,但先編成Bytecode的方式,不僅可以避免因為C++語言的複雜性而造成新手進入的障礙,而且還能讓開發者減少許多等待C++編譯的時間。若真的非常需要效能應用,還是有技術能將這些Script轉譯成C++後再編譯。

相較之下,似乎沒有特別的理由堅持使用C++來進行開發,不是嗎?

是的,這也是為何官方將三代中的Kismet這套視覺編程系統進行強化,重新命名為Blueprint後,強勢回歸到四代引擎的原因。對於完全不懂程式的使用者,其實可以完全使用這套系統建構出一個遊戲。

這套強化過後的視覺化Script系統就是官方所給出的解答。

只是完全使用Blueprint來寫程式還是有不少的限制,尤其視覺編程系統實在是不適合用來撰寫複雜的邏輯。而且在多人協作上,由於寫出的檔案為Binary的格式,目前也沒辦法使用git進行merge。

基於以上限制,我們還是需要一個完整的純文字格式的Script語言給進階使用者不是嗎?不管是直譯式語言或是編譯式語言,將C++的複雜性從開發流程中隔離出來,對開發不是會比較有效率嗎?

事實上,在引擎底層是有開放接口,讓使用者自己綁定其他想使用的Script語言。而且目前在markplace上也可以找到Unreal.js這套免費的Plugin將V8 JavaScript Engine跟引擎進行綁定。其他如python、lua、C#……等等,也都有非官方的實現。

但問題是,為什麼官方堅持不在引擎層提供一套正式的純文字格式Script語言支持?根據官方於論壇上的回答,主要是因為以下幾點原因:

在引擎過去幾十年來的演進中,隨著使用人數的增加,有越來越多的使用者要求將C++中的某個特性開放給Script使用。而不斷開放這些進階功能的後果,這層為了減少複雜性而封裝起來的Sandbox環境看起來就跟C++中的宣告沒二樣。這時候再透過一層Script介面層的封裝,反而增加了整體理解的複雜度。
隨著Script介面層的擴張,其在跟C++層溝通的成本跟複雜度會變的非常大。又尤其要將一些比較複雜的資料型態互相傳輸時,例如Container,在Script跟C++的語意跟語法都不太相同的情況下,肯定會造成不少的維護成本。

當開發者在尋求一些更進階的功能時,勢必要將程式的邏輯分割成「Script部份」跟「C++部份」,而開發時間就在雙方的呼叫邏輯撰寫地獄中損失掉了。

當開發者需要進行斷點做程式的追蹤時,馬上就會發現script的debug工具跟C++使用的debug工具是完全的二回事。若你沒辦法直接從script層追到C++層的話,那麼在做除錯時就會變的非常的困難。(反之亦然)

從上面所列出的原因中我們可以發現,不支援Script有很大的原因,都是由於C++跟Script之間的互相操作性(Interoperability)在引擎演化到最後完全失控了。回歸純粹的C++架構,不僅可以解決引擎維護與除錯上的痛點,而且附加好處,則是效能上的增進與簡化跟第三方C++ Library的整合。

這個決策或許有些人並不認同,但至少我們可以看出官方目前對內建其他script上的態度。

本文為個人原創,未經授權,謝絕轉載

脚本和 Blueprint 的目的也是为了提升开发效率, 我更人比较喜欢 Buleprint 是因为它的可视化,不需要让内容制作者涉及到太多的脚本和代码工作,把重点放在内容制作上。
在做 Prototype 的时候,Blueprint 可以非常快速的实现一些功能,团队交流也会更方便一些。

非常感谢你的分享经验。

脚本语言只算是一种工具吧,我觉得主要提供了几点便利:

1.提供了反射的机制,使得开发者可以方便地通过字符串来索引相应的c++函数
2.在工程的角度上,这相当于加了一层间接层,实现了解耦,提高了扩展性和鲁棒性
3.做IOS网络手游的话,可以用脚本来更新逻辑,能够减少频繁大包更新造成的玩家流失

对于虚幻这个引擎本身,不引入脚本语言,虽然不是太方便,但这三点也都可以做到了,所以不是必须用脚本。

至于c++和脚本语言pk开发效率的话,我觉得对于合格的程序员来说,用什么都不是问题。

说得很通透:rolleyes:
前段时间在做一个ChessGame,用BP写AI部分的时候已经崩溃,现已经全面换成C++了