查看: 672|回复: 0

游戏服务端为什么只能用C++语音来开发,其他就不能胜任呢!

[复制链接]

4783

主题

5079

帖子

1万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
18913

最佳新人活跃会员热心会员推广达人宣传达人灌水之王突出贡献优秀版主荣誉管理论坛元老

发表于 2020-2-10 16:21:10 | 显示全部楼层 |阅读模式
游戏服务端为什么只能用C++语音来开发,其他就不能胜任呢! https://www.gmbbs.net/
事实上,游戏服务端基本上是用多种语言开发的。c不再是唯一的选择。Java、Python、Golang、Erlang、C#和各种脚本语言都将涉及其中。但是为什么现在大多数游戏服务端仍然是用C语言编写的呢?我认为一个项目在进行技术选择时使用C语言作为游戏服务端的主要开发语言的主要原因是:
为什么游戏服务端是用低效率的C语言编写的,而其他语言却不能胜任?
十多年前,技术栈没有很多编程语言的选择。c语言是一种高级语言,在当时似乎很少,被证明是稳定、可靠、高性能和功能丰富的语言。所以,当然,它被选为发展的主要力量。基于此,进程框架,如线程模型、定时器、容器等。诸如套接字、共享内存和源自共享内存的数据恢复技术等IPC正在蓬勃发展。大工厂以前封闭思想,这与当前流行的开源完全不同。因为担心别人会知道自己的技术优势,他们也非常不信任社区产品的质量。结果是——个轮子,各种各样的轮子。从数据库到序列化工具,从xml解析器到负载平衡组件,游戏开发中遇到的所有游戏都是自己构建的,并且都是用c语言制作的
为什么游戏服务端是用低效率的C语言编写的,而其他语言却不能胜任?
游戏对性能要求很高的场景是无法替代的。别的不说,一个简单的帧同步,每秒30/60帧,多人数据同步。现在我们只能支持几千台带C的小型电脑,这可能超过每秒100,000个软件包。所以没有很强的信心去改变成另一种语言。因为成本已经相同,当机器成本不能明显优化时,我们为什么要增加技术风险和转移成本?在一些纸牌游戏中,在后端也有许多数值密集型计算。尽管体系结构可以是分布式的和可扩展的,但是降低机器成本也是非常重要的。这对于大规模在线游戏来说尤其重要,因为即使它可以优化10%,它背后的机器数量可能也不是一个可以忽略的数字。
为什么游戏服务端是用低效率的C语言编写的,而其他语言却不能胜任?
但总的来说,随着科技的发展,百花齐放应该是大势所趋。每个人都逐渐接受选择正确的语言,在正确的场景中做正确的事情。此外,许多尝试将图书馆依赖与服务之间的通信脱钩,这更有利于不同语言的共存。目前,基本形成了高性能的C/C、灵活的逻辑脚本、操作和维护工具Python、大数据的spark、日志流的elk、旁路检索或查询的jvm系统的局面。对于开发人员来说,语言需求已经从一种技能逐渐转变为多种技能。唯一不变的是业务需求总是在变化,解决问题的技术是好技术。
为什么游戏服务端是用低效率的C语言编写的,而其他语言却不能胜任?
然后比较了C语言和其他编程语言在游戏开发中的优缺点:
为什么游戏服务端是用低效率的C语言编写的,而其他语言却不能胜任?
c:
网络信息作战:这是历史上的一个主要考虑因素。近年来,几乎所有的主流后端语言都已经打包了高效的网络IO库,而C语言不再具有独特的优势。
CPU利用率:无需讨论C在这方面的优势。
实时性:无气相色谱,可控内存分配延迟(内存池,预分配等)。),需要毫秒延迟的高频事务正在使用中。

稳定性和容灾性:用c语言编写长期稳定的服务器程序对开发团队来说是一个相对较高的要求,尤其是在复杂的逻辑和频繁变化的前提下。语言本身并不能保证内存访问的安全性,内存写越界导致的崩溃也很难定位。我国某大型工厂采用了数据与逻辑进程分离、进程间共享内存进行通信的方法,以实现逻辑进程在不丢失数据的情况下崩溃和重启。然而,这种方法有一定的门槛、性能开销,并且对开发效率和灵活性有较大的限制。集成第三方库并不容易,也不能被视为常见的最佳实践。
开发效率:如果你有良好的内力和C语言编程素养,并配合一些现代C语言的语法(自动、lambda、智能指针等)。),开发效率仍然很低,但是与下面讨论的其他语言相比,它仍然处于劣势。然而,达到上述水平的人力资源成本远远高于其他语言(人员补充速度、培训时间和工资)。综上所述,这方面可以看作是c的一个大短板。
为什么游戏服务端是用低效率的C语言编写的,而其他语言却不能胜任?
Java:
优势:
生态圈成熟,水库丰富。
网络图书馆具有强大的性能。
Scala和kotlin也可以用于糟糕的语法。
缺点:
除原始类型外,不支持自定义值类型。泛型通过类型擦除来实现。这种特性使得连续紧凑地表示数据以优化算法的缓存命中率变得困难。例如,2D地图的每个网格坐标都是一个对象。3D场景的碰撞体积的每个顶点都是一个对象。这给对实时不太友好的气相色谱增加了更多的压力。
成熟的JVM实现不太重视实时GC。如果触发超过100毫秒的世界冻结时间延迟,所有在线玩家都会受到影响。
当预热不足时,JIT有时会导致性能曲线不平滑和意外的响应延迟。
为什么游戏服务端是用低效率的C语言编写的,而其他语言却不能胜任?
C#:
优势:
友好的发展,甜蜜的语法。
有真正的泛型和值类型。特定的算法有利于优化。
缺点:
微软。微软。微软。在视窗服务器下运行不成问题,但除了许可费,大多数主流开源软件都优先考虑Unix/Linux,如Redis (官方长时间不支持视窗版本)和MongoDB(视窗下的性能比Linux下的弱),而且视窗服务器的网络性能也较弱。除非解决方案都使用微软系列桶,否则部署和操作需要同时维护两个平台.对于Mono来说,与JVM相比,它就像一个玩具。我只能期待罗莎琳成熟。
气相色谱在实时方面类似于Java。
为什么游戏服务端是用低效率的C语言编写的,而其他语言却不能胜任?
开始:
优势:
语法简单,容易掌握。
开发经验是友好的。
有值类型。
新版本的围棋,气相色谱具有良好的实时性能(1.8声称STW被控制在1毫秒以内)。
缺点:
,没有范例,有些地方需要转换成接口{},但是编译器会做转义分析,不必要的地方不会自动装箱,影响不太严重。
为什么游戏服务端是用低效率的C语言编写的,而其他语言却不能胜任?
铁锈:
优势:
运行效率与c相当。
优秀的语言特征。
编译时间确保了内存安全性,而没有垃圾收集开销。
编译时确保线程安全,可以安全并发,并且易于编写高效的多线程代码。
缺点:上手曲线陡峭。
生态系统太年轻,还不成熟。
人群越少,补充人员就越困难。
经过几年的发展,C开发的效率并不低。尽管它对新人仍然不太友好,但从技术选择的角度来看,它仍然是许多领域的最佳选择。




【GM论坛[www.gmbbs.net]免责声明】
1、本站提供的所有资源仅供参考学习使用,版权归原著所有,禁止下载本站资源参与商业和非法行为,请在24小时之内自行删除!
2、本站所有内容均由互联网收集整理、网友上传,并且以计算机技术研究交流为目的,仅供大家参考、学习,不存在任何商业目的与商业用途。
3、若您需要商业运营或用于其他商业活动,请您购买正版授权并合法使用。 我们不承担任何技术及版权问题,且不对任何资源负法律责任。
4、论坛的所有内容都不保证其准确性,完整性,有效性。阅读本站内容因误导等因素而造成的损失本站不承担连带责任。
5、用户使用本网站必须遵守适用的法律法规,对于用户违法使用本站非法运营而引起的一切责任,由用户自行承担
6、本站所有资源来自互联网转载,版权归原著所有,用户访问和使用本站的条件是必须接受本站“免责声明”,如果不遵守,请勿访问或使用本网站
7、本站使用者因为违反本声明的规定而触犯中华人民共和国法律的,一切后果自己负责,本站不承担任何责任。
8、凡以任何方式登陆本网站或直接、间接使用本网站资料者,视为自愿接受本网站声明的约束。
9、本站以《2013 中华人民共和国计算机软件保护条例》第二章 “软件著作权” 第十七条为原则:为了学习和研究软件内含的设计思想和原理,通过安装、显示、传输或者存储软件等方式使用软件的,可以不经软件著作权人许可,不向其支付报酬。若有学员需要商用本站资源,请务必联系版权方购买正版授权!
10、本网站如无意中侵犯了某个企业或个人的知识产权,请告之,本站将立即删除。
   提问发帖求助请点此发帖 https://www.gmbbs.net/
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表