帧同步的一些思考(二):平滑位移与UDP通信

本文探讨了帧同步中的平滑位移技术,适用于保持游戏画面流畅。在网络延迟100-200ms的环境中,帧同步游戏表现良好。针对UDP通信,讨论了可靠UDP和纯UDP的选择,以及不同网络条件下的处理策略,包括单发、双发以及服务器端的冗余数据处理,确保实时性和稳定性。
摘要由CSDN通过智能技术生成

平滑位移

前面在IO游戏同步系列文章中介绍过客户端影子追随算法:

  • 渲染球追着逻辑球位移
  • 逻辑球没更新,则渲染球保持逻辑球当前速度继续做位移(当前速度为0,即为停止状)

这样在可以接受的网络中,画面可以保持流畅。

上述 影子追随算法,在帧同步游戏中同样适用。

帧同步游戏本身就是 游戏逻辑与渲染逻辑相分离 为基础;影子追随算法也是这样。

2者有天然的契合度。

可以接受的网络

前面在IO游戏同步系列文章中介绍过UDP、TCP通信对比,

一般在100-200mm延迟的网络,都属于是可接受的网络。

帧同步中,在网络上可能遇到的问题

帧同步,网络上能想到的问题,如:

  1. 多个客户端如何同时开始游戏?

    根据影子追随算法特性,画面始终在平滑过渡到最新收到的网络包。

    因此,在可以接受的网络中,多个客户端画面也是基本一致,看不出差别的。

  2. 各种原因导致,包延迟到达客户端了,怎么办?

    根据影子追随算法特性,具备一定的预测能力。

    可以接受的网络中,延迟到达的包能很好的被平滑过渡。

  3. 各种原因导致,包提早到达客户端了,怎么办?

    客户端需要缓存这个包,按游戏逻辑帧率来提取处理这个包。

UDP通信

使用UDP有2种方式:

  • 可靠的UDP
  • 纯UDP

首先如果是移动网络的话,建议用UDP通信而不是TCP通信。
如果对实时性要求不是非常高的游戏,可以采用可靠UDP在客户端延迟播放帧,延迟的时间周期可以通过UDP包丢失后重传机制进行补齐后再继续播放帧。
如果对实时性要求非常高的游戏,如上通过ACK确认UDP丢包后再重传机制可能时间上来不及了,这时候直接采用双发重复发送UDP包的机制可能更好。双发会带来网络流量翻倍上升,这时候可以通过统计识别出来哪些玩家的网络好哪些玩家的网络不好,对于网络好的玩家使用正常的单发UDP包,对于网络不好的玩家才使用双发UDP包。

以上引用,来至 《帧同步中,如何网络不好,具体该如何平滑位移》

因此看帧同步游戏的实时性要求:

  • 可靠的UDP:对实时性要求不是非常高的游戏
  • 纯UDP:高实时性游戏

可靠的UDP有不少成熟库,因此这里主要谈论下纯UDP。

有以下2种情况:

  1. 客户端UDP发送操作指令给服务器

    两种方法:

    方法1:网络好的玩家单发UDP包。网络不好的玩家才使用双发UDP包。

    方法2:一般服务器66毫秒或100毫秒广播一次所有玩家的指令包。这里假设66毫秒一次。那么客户端可以按30毫秒频率重复发送当前指令,直到收到服务器ACK包,或者收到服务器发来了下一帧,或者指令被替换。

    乐观帧同步下,客户端UDP不需要“可靠性”。UDP包未及时到达,服务器会自动补空帧。

    因此上述2种方法,均是OK的。

  2. 服务器UDP转发操作指令给客户端

    方法1:方法客户端收到UDP包后,均会ACK服务器。服务器每次UDP包携带前未ACK的UDP一并冗余发送。若超过548字节,则分多个包发送。

    方法2:服务器端冗余前N帧数据,客户端在缺帧时,向服务器请求某帧

参考文档

参考文档:《帧同步中,如何网络不好,具体该如何平滑位移》

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

fananchong2

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值