为什么游戏服务端用开发效率低的C++来写,其他语言无法胜任吗?

  1. 云栖社区>
  2. 博客>
  3. 正文

为什么游戏服务端用开发效率低的C++来写,其他语言无法胜任吗?

游客3vgezmwygttgo 2019-04-12 22:03:52 浏览432 评论0

摘要: 其实现在游戏服务端基本上都是多语言组合开发的,C++已经不再是唯一选择,Java、Python、Golang、Erlang、C#以及各种脚本语言都会涉及。但是为什么现如今大多数游戏服务端还是用C++来写呢?我认为一个项目在做技术选型时把C++作为游戏服务端的主要开发语言主要基于以下原因:为什么游戏服务端用开发效率低的C++来写,其他语言无法胜任吗? 十多年前,技术栈,包含编程语言的选择还不是很多。

其实现在游戏服务端基本上都是多语言组合开发的,C++已经不再是唯一选择,Java、Python、Golang、Erlang、C#以及各种脚本语言都会涉及。但是为什么现如今大多数游戏服务端还是用C++来写呢?我认为一个项目在做技术选型时把C++作为游戏服务端的主要开发语言主要基于以下原因:
为什么游戏服务端用开发效率低的C++来写,其他语言无法胜任吗?

十多年前,技术栈,包含编程语言的选择还不是很多。C++是当时看来少数,被证明稳定,可靠,高性能,具备丰富功能的高级语言。所以理所当然被选择作为开发主力。基于此,进程框架,诸如线程模型,定时器,容器等;IPC,比如socket,共享内存,并由共享内存进一步衍生出的数据恢复技术等都蓬勃发展。而且大厂之前都有封闭的思想,这和现在开源流行完全不同。生怕别人知道自己的技术优势,也非常不信任社区产品的质量。结果就是——造轮子,各种造。从数据库,到序列化工具,从xml解析器到负载均衡组件,凡是游戏开发碰到的,全部自己造,而且都拿C++造。
为什么游戏服务端用开发效率低的C++来写,其他语言无法胜任吗?

游戏存在高性能需求场景目前无可替代。别的不说,一个简单的帧同步,每秒30/60帧,多人数据同步。现在我们用C++也只能支持单机小几千,大概就是每秒十多万个包吧。所以没有很强的信心换成别的语言。因为成本已经是这样了,为何要在机器成本没法明显优化的情况下,再去增加技术风险和迁移成本?在一些卡牌类型游戏中,后端也存在大量的数值密集型计算。虽然在架构上可以分布式,可以扩展,但降低机器成本同样非常重要。特别是对在线规模很大的游戏而言尤其重要,因为即使能优化10%,背后的机器数量恐怕也不是一个可以忽略的数目。
为什么游戏服务端用开发效率低的C++来写,其他语言无法胜任吗?

但总体上,随着技术的发展,百花齐放应该是大趋势。选择合适的语言,在合适的场景,做合适的事情,这是大家逐渐认同的。而且很多尝试都在解耦,从库依赖变成服务间通信,这样更有助于不同语言共生。现在基本形成,高性能C/C++,灵活逻辑脚本化,运维工具Python,大数据用spark,日志流用elk,旁路检索或查询用jvm系的局面。对开发人员而言,语言的要求慢慢从一招鲜变成了一专多能。唯一不变的是,业务需求永远在变,解决问题的技术就是好的技术。
为什么游戏服务端用开发效率低的C++来写,其他语言无法胜任吗?

那么C++和其他编程语言在游戏开发上的优劣势对比:
为什么游戏服务端用开发效率低的C++来写,其他语言无法胜任吗?

C++:

网络 IO:历史上这方面曾经是考量的主要因素,近年来几乎所有主流后端语言都封装有高效的网络 IO 库,C++ 已不具备独特优势。

CPU 利用率:C++ 在这方面的优势不需要讨论了。

实时性:无 GC,内存分配延迟可控(内存池、预分配等),毫秒级延迟需求的高频交易都在用。

稳定性和容灾:用C++写出长期稳定运行的服务器程序,对开发团队而言是件要求比较高的事情,尤其在逻辑复杂又变更频繁的前提下。语言本身也不保证内存访问的安全性,如果有内存写越界导致的Crash也很难定位。国内某大厂采用了分离数据和逻辑进程,通过进程间共享内存来通信的方式,来实现逻辑进程崩溃重启不丢失数据。不过这种做法有一定门槛,存在性能开销,而且对开发效率和灵活性也有比较大的约束,也不易整合第三方库,不能算是通用的最佳实践。

开发效率:如果有良好的内力和C++编程素养,并且配合现代C++的一些语法(auto、lambda、智能指针等),开发效率尚可算是勉强及格,但相对以下讨论的其他语言来说仍处于劣势,然而达到上述水准的人力资源成本却要比其它语言要高出不少(人员补充速度、培训周期和薪资)。综合而言,这方面可算 C++的一大短板。
为什么游戏服务端用开发效率低的C++来写,其他语言无法胜任吗?

Java:

优点:

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

缺点:

· 除了原始类型外,不支持自定义值类型。而且泛型是以类型擦除的方式实现。这样的特性导致了:难以把数据连续紧凑地进行表示来优化算法的缓存命中率,比如2D地图的每个格子坐标都是个object。3D 场景的碰撞体每个顶点都是个object。对原本对实时性不甚友好的 GC 造成了更大压力。

· 成熟的 JVM 实现并不怎么侧重 GC 的实时性。如果触发了百毫秒以上的世界冻结 GC 延迟,所有在线玩家都会受到影响。

· JIT 在预热不足的情况下,偶尔会导致性能曲线不平滑,引入预料之外的响应延迟。
为什么游戏服务端用开发效率低的C++来写,其他语言无法胜任吗?

C#:

优点:

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

缺点:

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

· GC 实时性类似 Java。
为什么游戏服务端用开发效率低的C++来写,其他语言无法胜任吗?

Go:

优点:

语法简单易掌握。
开发体验友好。
有值类型。
新版本的 Go,GC 实时性良好(1.8 号称 STW 控制在 1ms 以内)。

缺点:

· 没有范型,某些地方需要转型成 interface{},不过编译器会做逃逸分析,不必要的地方不会自动 boxing,影响不算太严重。
为什么游戏服务端用开发效率低的C++来写,其他语言无法胜任吗?

Rust:

优点:

运行效率比肩 C++。
语言特性优秀。
编译期保证了内存安全,没有 GC 开销。
编译期保证线程安全,可以放心大胆地并发,容易写出高效的多线程代码。

缺点:

上手曲线较陡。
太年轻,生态圈尚未成熟。
较小众,人员补充困难。

经过近几年的发展,C++开发效率也不算低,虽然对新人依然不怎么友好,但是从技术选型的角度来看依然是很多领域的不二之选。

小编推荐一个学C/C++的学习qun 5999,45900
学习从来不是一个人的事情,要有个相互监督的伙伴,工作需要学习或者为了入行、转行
都可以,qun内有开发工具,很多干货和技术资料。

【云栖快讯】阿里巴巴小程序繁星计划,20亿补贴第一弹云应用立即开通购买,限量从速!  详情请点击

网友评论