原文链接: 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++中间件的集成也变easy了.
把UE4建设成一个统一的C++代码库, 让游戏引擎和玩法程序猿写代码时避免了中介两头忽悠, 及大地提升了便利性.
这并不能代表C++就是理想的编写游戏玩法的语言了. 由于比起UnrealScript, C#和JavaScript, 它不但更复杂, 并且更危急. 只是这也从还有一个角度也证明了它更强大, 正所谓”权利越大, 责任越大”.
为了在C++的复杂性和代码编写中保持平衡, 我们根本没有做什么限制. 无论你是调试整个代码库, 或是跟底层引擎系统聊天, 揍它们一顿, 还是跟操作系统或其他高级的第三方中间件谈恋爱...