blog版：http://dorgon.horizon-studio.net/archives/773
欢迎大家指教 : )
================本文开始=============
我们知道，除了使用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-Tim(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语言支持？根据官方于论坛上的回答，主要是因为以下几点原因：
1. 在引擎过去几十年来的演进中，随着使用人数的增加，有越来越多的使用者要求将C++中的某个特性开放给Script使用。而不断开放这些进阶功能的后果，这层为了减少复杂性而封装起来的Sandbox环境看起来就跟C++中的宣告没二样。这时候再透过一层Script接口层的封装，反而增加了整体理解的复杂度。
2. 随着Script接口层的扩张，其在跟C++层沟通的成本跟复杂度会变的非常大。又尤其要将一些比较复杂的资料型态互相传输时，例如Container，在Script跟C++的语意跟语法都不太相同的情况下，肯定会造成不少的维护成本。
3. 当开发者在寻求一些更进阶的功能时，势必要将程式的逻辑分割成“Script部份”跟“C++部份”，而开发时间就在双方的呼叫逻辑撰写地狱中损失掉了。
4. 当开发者需要进行断点做程式的追踪时，马上就会发现script的debug工具跟C++使用的debug工具是完全的二回事。若你没办法直接从script层追到C++层的话，那么在做除错时就会变的非常的困难。(反之亦然)
从上面所列出的原因中我们可以发现，不支援Script有很大的原因，都是由于C++跟Script之间的互相操作性(Interoperability)在引擎演化到最后完全失控了。回归纯粹的C++架构，不仅可以解决引擎维护与除错上的痛点，而且附加好处，则是效能上的增进与简化跟第三方C++ Library的整合。
这个决策或许有些人并不认同，但至少我们可以看出官方目前对内建其他script上的态度。