UE4学习笔记(三): 为什么使用C++替代UnrealScript?

原文链接: https://forums.unrealengine.com/showthread.php?2574-Why-C-for-Unreal-4&p=16252&viewfull=1#post16252 之前的三代Unreal引擎中都包含了一种叫UnrealScript的脚本语言, 用它来写游戏玩法简直太方便了, 根本不用去接触复杂的C++引擎. 虽然脚本十分受新手的欢迎, 但它却成为了创新和发布的障碍. 在Unreal引擎成长的过程中, 我们不断地踩到这样的坑. 所以在2011年, 我们转移到了一个纯C++的架构上. 这么做有大把的理由:

• 随着引擎和社区的成长, 迫于压力不得不给脚本暴露越来越多的C++特性. 本来是个很好玩的沙盒, 最后却变成了个大沙漠.
• 随着脚本接口的扩充, 用于函数调用和类型转换的通信中间层变得越来越复杂和低效. 像容器这样的高级数据类型的互操作变得让人抓狂, 因为脚本语言很难表示C++的模板语义.
• 开发者寻求高级C++特性的结果就是把他们的代码分成脚本和C++两块, 然后花费了大量时间在中间扯淡.
• 开发者如果想了解某个程序的行为时, 很快就会发现C++和脚本的调试工具是水火不相容的. 明明知道脚本中的一个值错了, 但却不知道是哪里的C++代码引起的, 反过来也一样.

就是这些原因, 最终把Epic逼成了纯C++. 带来的好处有很多: UE4变成了一个高度统一和易于调试的代码库, 没有了坑爹的互操作, 并且完全开放给程序员学习, 修改和扩展. 顺带不但游戏玩法代码的性能提升了, 而且C++中间件的集成也变容易了. 把UE4建设成一个统一的C++代码库, 让游戏引擎和玩法程序员写代码时避免了中介两头忽悠, 及大地提升了便利性. 这并不能代表C++就是理想的编写游戏玩法的语言了. 因为比起UnrealScript, C#和JavaScript, 它不但更复杂, 而且更危险. 不过这也从另一个角度也证明了它更强大, 正所谓”权利越大, 责任越大”. 为了在C++的复杂性和代码编写中保持平衡, 我们根本没有做什么限制. 不管你是调试整个代码库, 或是跟底层引擎系统聊天, 揍它们一顿, 还是跟操作系统或其它高级的第三方中间件谈恋爱...