为什么知名游戏开发者吐槽C++是一门糟糕的编程语言

前不久,知名游戏”Braid“和”The Witness“的作者 Jonathan Blow接受采访时表示,C++ 太复杂了,严重影响了他的工作,他被迫在项目中工作时停下来思考编程可以悲惨到什么程度,并开发了自己的 Jai 语言来替代 C++。

为什么知名游戏开发者吐槽C++是一门糟糕的编程语言

然而C++ 真的有这么糟糕吗?

其实不同的游戏之间业务逻辑和适用架构区别很大,小编认为不能一概而论,毕竟游戏也分不同领域。比如对于大部分手游、页游来说,追求短平快的开发节奏也不要求太高的实时性和计算效率,C++在这些领域的使用属于杀鸡用牛刀。

先来列举一些曾经比较流行的游戏平台/类型:

  • PC单机游戏(Windows)
  • PC网络游戏(Windows、Linux)
  • 移动平台游戏(J2ME、Symbian、Palm……)
  • 家用游戏机游戏(PS1/2/3/4、XBox、Wii……)
  • 掌上游戏机游戏(GB、GBA、NDS、PSP……)
  • 网页游戏(HTML、Flash)
  • 智能移动设备游戏(iOS、Android)

不难发现,除了J2ME和网页游戏外,大多数的平台都支持(或只支持)原生编程。而原生编程最常用的就是C/C++和汇编。

其实做游戏开发并不是全部都用C++,只是最主要的架构核心部分用C++而已

一个游戏引擎涉及到的内容超级庞大,又要搞效率高性能,又要好效果和易于扩展。高性能的关键核心代码会使用汇编实现,比如SIMD指令进行各种浮点数学运算,高开发效率比如工具层,会使用脚本等来实现。而只有C++这样的全能语言才能做到在汇编和脚本语言中间进行承上启下。

也就是说C++在游戏引擎中负责最主要的架构部分

这部分包含了最重要的工程组织,从底层的基础库: 扩展std/boost数据结构,封装时间、IO/文件系统、多线程、反射、内存管理、数学库……到中间层:窗口、游戏循环、输入设备/消息、图形渲 染接口层抽象、实时图形渲染管线设计、物理/碰撞检测、寻路、骨骼、动作、模型……再到通用最上层的世界空间层次组织、天空盒、植被、水、粒子特效、相机……

当然C++并不是搞游戏开发的唯一选择,比如Java、C#都可以实现,先来评估下这两种语言的优缺点:

Java:

优点:生态圈成熟,库丰富。Netty 网络库性能强悍。不爽语法还可以用 scala 和 kotlin...

缺点:除了原始类型外,不支持自定义值类型。而且泛型是以类型擦除的方式实现。这样的特性导致了难以把数据连续紧凑地进行表示来优化算法的缓存命中率,比如2D地图的每个格子坐标都是个object,寻路算法呵呵。3D 场景的碰撞体每个顶点都是个object,物理引擎呵呵。对原本对实时性不甚友好的 GC 造成了更大压力。成熟的 JVM 实现并不怎么侧重 GC 的实时性。如果触发了百毫秒以上的世界冻结 GC 延迟,所有在线玩家都会受到影响。JIT 在预热不足的情况下,偶尔会导致性能曲线不平滑,引入预料之外的响应延迟。

C#:

优点:开发友好,语法糖甜。有真正的泛型和值类型。特定算法好优化。

缺点:微软家的。微软家的。微软家的。跑在 Windows Server下没什么问题,然而抛开授权费不谈,大部分主流的开源好物都是优先考虑 Unix / Linux,比如 Redis(长期没有 Windows 版本的官方支持)、MongoDB(Windows 下性能要弱于 Linux 下),而且 Windows Server 的网络性能也要弱一些。除非解决方案都用微软全家桶,不然部署和运维就需要同时维护两个平台。

对于一个新兴领域而言,C/C++很多情况下是别无选择的东西。比如移动化浪潮刚起步的时候,还没有啥 cocos或者 unity真要开发游戏,必须迅速的使用起 OpenGL ES和 OpenSL,然后再叠加某一脚本,以快制胜,第一批移动浪潮上发财的就是这些游戏。又或者,可以根本躲开,先不介入,等到几年后cocos和 unity成熟了,在介入用lua / C#写程序。再比如服务端如果离开熟悉的游戏和web,去开发一个陌生的领域,如流媒体服务,会发现这怎么和10年前的游戏一样呀,什么高级工具都不给用用,这时可以再等个四五年应该高级工具会出现,异或想领先别人时,就果断的拿出 C/C++来解决,这就是C独有的开拓新领域的能力。

觉得文章有用大家可以转发+收藏,获取更多编程干货欢迎大家关注的我的头条号~

c++

相关推荐