关于ue4 射击游戏架构设计

这篇具有很好参考价值的文章主要介绍了关于ue4 射击游戏架构设计。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

传统mmo的服务器架构

网关--->游戏逻辑服--->游戏db服
网关---> 游戏逻辑服--->关系服务器master

其结构简单,方便维护,但是在应对射击游戏时候暴露出很大的缺陷

但是随着大dau产品的像和平精英等游戏问世

腾讯主要的服务器是基于tbus4j,基于共享内存+ socket的数据交互,该框架的相对重度在外面资料相对比较少,基本基于共享内存可以支持的c++重启,因为网关tconnd + lobby是都是共享内存交互,tconnd基本上不重启,如果涉及到加字段的,lobby 是需要重启,天美王者的底层是这样去实现,晚上经常看到他们重启。

和平的是用Lua,基于tbus 的tapp 导出lua run ontick onstop onreload作为程序入口,基于tbus 导出发送、接收数据的回调。

在针对遍历玩家行为,采用类似遍历玩家行为采用分帧做法去处理,内存增长多少以后启动GC,这个值要适当,否则会造成明显CPU锯齿,根据各个系统去取制定

基于数据Table去pack可以做到支持无间断更新,还有采用版本号去支持跨版本DS,这样可以让玩家尽量的留存在游戏,避免更新。

腾讯的产品使用TcaplusDB,做为数据数据库,在数据库保存上采用最新版本号保存,防止数据覆盖问题。

为了防止的单点,在仲裁服那边采用租赁协议+tcaplushdb的最新版本号机制去,实现主从的切换,仲裁服获取最新续约的时间,然后同步到路由服,路由服更新的仲裁服的节点状态。

网关 -->游戏逻辑服 --->游戏db服

                路由服务 

                索引服

                仲裁服

                 好友服

                 军团服

                  房间服

                 匹配服

                 对战服管理服

                 邮件服

                 聊天频道服

像邮件服都才采用Lru的机制去做设计的,缓存热数据在队列的,淘汰没用的数据

在分布式的负载均衡,hash 算法、主从、rand,id的生成在大厅这边生成,确保可以hash 到目的服务器,提高负载能力

对战服管理服,采用开房间,主要是采用fork的参数机制的,定时的上报的机器的负载信息,cpu、内存、房间数、真人数,房间服那边的跟筛选压力最低的战斗服,然后同步到战斗管理服,由战斗管理服去分配的端口,然后通知客户端,客户端再去连接的对战服的端口、IP,然后进行战斗,战斗结束后把战报发送战斗管理服,由它经过路由再转发到大厅,如果玩家在线,直接保存在到历史的战绩,如果不在线保存到离线数据,等玩家上线再加载处理离线数据,然后加入到历史战绩。

匹配服,玩家点匹配然后根据的玩家hash到对应匹配服,根据2人组 4人组 单人组,进行男女混合搭配,在匹配队列是根据段位的设计的slot挂在这些队伍信息,然后优先筛选的属于玩家段位附近的,超时再扩展扫描段位的,然后分组的,把匹配成功后把把队伍信息通知到roomsvr。roomsvr再把筛选到的ds战斗管理服,把房间队伍消息转发过,在上飞机前,房间不够的从再去转到匹配服再去补人,如果再补不到人最后补机器人。机器人段位信息采用的是真人的段位四个码求和的除总人的均值,然后再把消息转发到ds。

基于

和平的协议主要lua table 动态协议,有点动态扩展,缺点也明显很难维护的。

压缩算法 采用的是lz4具备有 压缩、解压缩性能高的特点文章来源地址https://www.toymoban.com/news/detail-786327.html

到了这里,关于关于ue4 射击游戏架构设计的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包