现如今为什么大多数游戏服务端还是用C++来写?

千_锋小小千 · · 330 次点击 · · 开始浏览    

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

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

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

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

最后附一张游戏开发学习线路图,希望对大家的学习有帮助~

本文来自:简书

感谢作者:千_锋小小千

查看原文:现如今为什么大多数游戏服务端还是用C++来写?

330 次点击  
加入收藏 微博
2 回复  |  直到 2019-02-12 20:32:23
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传