游戏网络同步方案-笔记

游戏网络同步一般两种方案:帧同步和状态同步

核心区分

问题的关键在于:谁来计算游戏逻辑

交给服务端(状态同步):
优点:
1.服务端掌控全局,避免作弊
2.网络问题范围缩小 逻辑都是服务器在算 客户端断线/延迟自己按照服务器的数据包再跑一遍就行
缺点:
1.随着游戏复杂度 服务器的计算负载飙升
2.相应延迟高,无法适用在动作类游戏的时效要求
.
.
.
交给客户端(帧同步):
优点:
1.逻辑基本就是干些客户端的,网络传输只有输入消息.
2.实时本地计算,逻辑表达就更加精确,比如玩家按个闪避 如果还要交给服务器去算 然后返回结果消息,人已经凉了
3.同步内容少,做回放系统相较就简单了
缺点:
1.一旦网络波动,卡顿会非常明显 因为逻辑计算是客户端在参与的,延迟的时间挤压导致卡顿明显,而服务端逻辑 连回来的时候是可以拿到现在应该处于的状态的,进行插值就会比较平滑
2.反作弊效果薄弱,服务器只转发操作信息,玩家拿着本地数据各种操作,这就需要服务器额外验证或者其他反作弊手段了
3.断线重连,dnf为栗子:玩家一掉线 自己的操作是相对正常的,一旦重连上了 各位就开始飘了,客户端要花一段时间来跑遍所有断线时候的逻辑

守望先锋的同步方案

个人理解: 服务端客户端都在算, 客户端自己跑,服务端每隔一段时间来验证客户端的行为对不对,然后给客户端一定的修正指令
这样的方案 上述给出的两种方案的弊病就好转了,保证了客户端这边的相应的及时性,同时服务端也在把控监督
直白点:游戏开不了挂 也不卡
这样的方案也随之会有点问题:
服务器验证玩家数据不对 而产生的回溯
比如猩猩开跳 麦克雷给他晕住了 这样的情形
猩猩的客户端在执行跳跃指令 麦克雷的眩晕在网络指令还没发下来
这个时候就会出现 猩猩起跳了 然后眩晕的指令发下来了 就回溯了起跳指令 到了眩晕状态
即:起跳了 但没完全起跳

最后

以上就是粗暴蛋挞为你收集整理的游戏网络同步方案-笔记的全部内容，希望文章能够帮你解决游戏网络同步方案-笔记所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。