CS模式网络游戏的运动同步总结
2017-01-02 14:35
253 查看
概述
目前有2种网络游戏拓扑结构:Peer to Peer和Client/Server模式。在RTS类型的游戏中大都使用Peer to Peer的帧锁定同步算法(如红警、帝国时代、war3等)。目前主流引擎都自带的是Client/Server模式的服务器(如Unity3d, UE4等)。在此推荐《multiplayer game programming》,该书对帧同步算法和CS模式的同步都有详细的阐述;并且该书介绍的对象同步思路与ue4的思路类似。
本文只对CS模式下的运动同步进行总结,CS模式下,server是绝对的权威,一切以server为准。
记住:延迟是无法消除的,要尽可能地隐藏延迟,让玩家具有良好的体验。
先定义一个符号:
运动状态 S: S表示某个运动状态(如位置、速度、转速等)
操作事件 I: I表示运动输入命令事件(如 加速度、立即停止、力等)
突发事件 E: 如受到阻挡、炮弹冲击等非人为直接输入。
0. Round Trip Time(RTT)
![](https://img-blog.csdn.net/20170105160533165?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaHVhbmd6aGlwZW5n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
1. 哑终端方式(dump terminal)
类似早期的终端,只发送键盘和鼠标输入给服务器,客户端不具有逻辑计算功能。
时序图如下:
![](https://img-blog.csdn.net/20170105163837555?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaHVhbmd6aGlwZW5n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
如上图所示,客户端状态需要服务器同步过来,自己没有主动性,表现出一卡一卡的体验。
用户的输入需要过RTT后才能得到反馈,客户端的状态比服务器滞后RTT/2时长。
2. client Interpolation
还是使用的哑终端方式,服务器给出状态a,b;然后客户端使用ab的插值进行平滑过渡。
时序图如下:
![](https://img-blog.csdn.net/20170105170613870?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaHVhbmd6aGlwZW5n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
客户端比服务器滞后RTT/2 + 包同步间隔,客户端逻辑带有内插值功能。
3. client prediction & server correction
客户端具有预测功能(和服务器具有同样的代码逻辑),服务器会将状态同步到客户端,然后客户端进行较正。这个里面细节较多,主要分2个方面
进行考虑:
a. 非本地玩家(机器人、其它远程玩家)的运动同步
时序图如下:
![](https://img-blog.csdn.net/20170105174656908?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaHVhbmd6aGlwZW5n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
客户端0收到同步消息时,计算出当前服务器的状态;然后我们并不能立即用这个状态(会造成突兀抖动),需要进行插值平滑过渡到该状态。
b. 本地玩家的运动同步
时序图如下:
![](https://img-blog.csdn.net/20170109094624861?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaHVhbmd6aGlwZW5n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
本地玩家端会立即响应用户输入,这样会比服务器端状态提前。当没有用户输入时,收到服务器的同步校正信息后,处理情况跟simulate模式相同。
要注意输入的时间戳和服务器发送的输入处理结果时间戳, 它们都是该客户端的本地时间。
c. 上述情况的合成时序图
将上述2个图拼在一起进行观察。
d. 我们还需要平滑地插值
为了避免出现抖动,我们都到服务器的同步校正后,不能立即设置运动状态,需要进行平滑过渡到该状态。
目前有2种网络游戏拓扑结构:Peer to Peer和Client/Server模式。在RTS类型的游戏中大都使用Peer to Peer的帧锁定同步算法(如红警、帝国时代、war3等)。目前主流引擎都自带的是Client/Server模式的服务器(如Unity3d, UE4等)。在此推荐《multiplayer game programming》,该书对帧同步算法和CS模式的同步都有详细的阐述;并且该书介绍的对象同步思路与ue4的思路类似。
本文只对CS模式下的运动同步进行总结,CS模式下,server是绝对的权威,一切以server为准。
记住:延迟是无法消除的,要尽可能地隐藏延迟,让玩家具有良好的体验。
先定义一个符号:
运动状态 S: S表示某个运动状态(如位置、速度、转速等)
操作事件 I: I表示运动输入命令事件(如 加速度、立即停止、力等)
突发事件 E: 如受到阻挡、炮弹冲击等非人为直接输入。
0. Round Trip Time(RTT)
1. 哑终端方式(dump terminal)
类似早期的终端,只发送键盘和鼠标输入给服务器,客户端不具有逻辑计算功能。
时序图如下:
如上图所示,客户端状态需要服务器同步过来,自己没有主动性,表现出一卡一卡的体验。
用户的输入需要过RTT后才能得到反馈,客户端的状态比服务器滞后RTT/2时长。
2. client Interpolation
还是使用的哑终端方式,服务器给出状态a,b;然后客户端使用ab的插值进行平滑过渡。
时序图如下:
客户端比服务器滞后RTT/2 + 包同步间隔,客户端逻辑带有内插值功能。
3. client prediction & server correction
客户端具有预测功能(和服务器具有同样的代码逻辑),服务器会将状态同步到客户端,然后客户端进行较正。这个里面细节较多,主要分2个方面
进行考虑:
a. 非本地玩家(机器人、其它远程玩家)的运动同步
时序图如下:
客户端0收到同步消息时,计算出当前服务器的状态;然后我们并不能立即用这个状态(会造成突兀抖动),需要进行插值平滑过渡到该状态。
b. 本地玩家的运动同步
时序图如下:
本地玩家端会立即响应用户输入,这样会比服务器端状态提前。当没有用户输入时,收到服务器的同步校正信息后,处理情况跟simulate模式相同。
要注意输入的时间戳和服务器发送的输入处理结果时间戳, 它们都是该客户端的本地时间。
c. 上述情况的合成时序图
将上述2个图拼在一起进行观察。
d. 我们还需要平滑地插值
为了避免出现抖动,我们都到服务器的同步校正后,不能立即设置运动状态,需要进行平滑过渡到该状态。
相关文章推荐
- 隐身术——使用Tor匿名网络与proxychains构建SOCKS代理链IP跳板,在***测试与******时销声匿迹
- 谈谈网游里的黑势力
- 小语网络加速器,让您的游戏不再卡,网页开飞快!
- VC++实战《星际传奇》网游课程第二部分:网络游戏开发基础篇(D3D11编程)视频教程
- 游戏平台运维自动化扩展之故障自愈
- 社交网络发展引发休闲游戏风潮
- 网络游戏安全策略(Coderui原创)
- 谷歌中国发布年度热榜 iPhone成全球最流行词
- div的问题!求救
- 第二人称源码分析(2)基本功能
- 创娱首款手机网络游戏
- 转,于大家共勉
- 2007年3月中国风险投资市场研究报告发布(有添加)
- 三成白领借培训转型
- 网络与文化
- 笔记本使用GPRS上网教程
- 三大因素让RMT声名狼藉
- RMT在大航海時代引发的血案
- 网络游戏程序员须知 基础概念篇
- 有没有人能告诉我什么叫“很黄很暴力”