我们知道,除了使用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上的态度。