NBA2KOnline帧同步方案简介..ppt

谢谢大家！ QA * 大家好，我先简单做个自我介绍。 说话一定要慢，便于思考。 * 今天我要介绍的内容主要有以下5点，首先是背景介绍，然后是方案的形成过程，第三个方案的简介，第四个是几个关键点，第五个后续发展 * 我原来想在这里介绍下帧同步的定义，觉得一开始就说定义也不一定合适，那接下来我们直接进来之前我们项目所面临的问题吧。 * * 与SC类似的结构 * 连接数15：5，5V5的话是45：10 * 连接条数的上升是线性的，不像之前是用P2P的话5V5一局一共45条。 连接质量是稳定的，因为大家只有中转服务器相连，中转服务器一般位于骨干网IDC，相当可靠。 P2P架构下，完全打通时，包不用经过中转服务，延迟更小，只限理想情况下会如此，一般情况下只要有人没打通就一样了。 完全采用中转服务器，原先有大量采用P2P的流量都转到了中转服务器上 * 中转服务器地址由GS下发，进出房间会不断连接与断开，采用无状态的UDP更加便于维护，如果比较后面才连的话，像UDP的PING之类也无法在房间界面展示 不需要TCP的各大功能，像丢包乱序由同步层保证。如果要发送少量可靠的协议，直接采用等停算法 * * 按最新算法, 不应该出现, 往往是玩家使用加速器, 或者玩家的网络抖动和丢包过于剧烈. 或者是算法上的bug. 总体来说, 只有帧来不及播放, 才会快播. 这部分玩家就是电脑性能太差. 33ms不能渲染帧, 或者画质设置太高 * 只能防君子，不能防小人 * 赛事的观战直播非常能造势，看人的也爽，打的人也爽。SC2中的观战只能10个，很多时间远远不足。打累的人有时也希望看看学习下。新手也一样。 * 《NBA2K Online》帧同步方案简介 个人简介 经历过QQ幻想，自由幻想，MHFC等项目 09年起参与筹建NBA2KOnline项目，担任客户端前台开发主程序。 欢迎大家随时来交流。 目录 方案背景介绍 NBA项目帧同步方案的形成过程 帧同步方案简介 关于帧同步的几个关键点 后续的发展 背景介绍 NBA2KOnline是一款高拟真的篮球类游戏，已历经7次CE测试，2次内测，计划今年年中公测。 做为运动类游戏要求响应及时，手感良好，公平公正。 CE4以前延时过大，单局正常结束比例过低 第一版帧同步方案数据 单局比赛数据 第一版帧同步方案结构 基于P2P架构 链路复杂 RS无逻辑 第二版帧同步方案数据 单局比赛数据 第二版帧同步方案简介 完全基于中转服务器，无P2P，链接简单 对比 何为改进，为何改进 连接条数稳定，方便扩展 连接质量较高 去除木桶短板效应 加强中转服务器控制逻辑 带宽增加 完美情况下延迟会加大 部分概念说明 游戏服务器 中转服务器 客户端帧缓冲区 帧播放状态：快播帧，正常帧，停顿帧 PlayerInput FrameInput 帧同步基本流程 客户端游戏逻辑产生输入数据 将输入发送给中转服务器 中转服务器进行切帧组帧 服务器发送帧数据给每个客户端 客户端帧接收层 帧缓冲区平滑算法 游戏内核进行运算渲染 基本流程图 主要关键点 客户端拥有全部运算逻辑，游戏服务器事件校验 中转服务器进行造帧切帧组帧数据 客户端帧缓冲区调整算法，根据抖动实时调整 上下行冗余策略，丢包重传策略 客户端根据硬件画质进行帧数扩展 关键帧改进策略 校验，反外挂 流量，带宽与延时 观战与赛事直播 录像机制，回放校验 网络模型的选择 帧缓冲区调整算法 客户端需要设置一个帧缓冲区，用于平衡网络对客户端帧率产生的抖动。 理论上帧缓冲区中的值越小，延迟就会越小，体验就会越好，但是限延迟抖动能力就会越差。 这里我们采用的算法是根据过往帧数据的网络延迟情况建立网络延迟模型，设定缓冲区最大值大小，平滑抖动。 实际测试中的帧绘冲区值 丢包重发逻辑 丢包重发: 客户端发现帧数据中间有空, 就请求重发. 超时重发: 客户端发现帧数据超时未收到, 则请求重发. 两种算法, 实测结果接近，第一种实现简单，优先采用。 少量的丢包希望冗余来保证 上下行冗余 上行即将自己的PlayerInput数据用UDP发送给中转服务器。 上行是允许丢包的，但丢包后部分操作会丢失 服务器会为丢包上行包的客户端伪造输入操作 下行帧数据是不允许丢包，丢包客户端会停住 最简单方案固定冗余帧数 上下行冗余（续） 根据网络质量情况，冗余不同的帧数，丢包请求多冗余的越多 网络正常丢包请求少，基本不冗余。 尽量不要超过一个MTU 实测下来平均冗余值为0.2帧，相比起固定冗余4帧少了节约了大量的带宽流量，但效果没受到任何影响 关键帧与数据压缩 定义操作变化的帧为关键帧 服务器收到关键帧后直到下一个关键帧到达前客户端都可以不用再发送 减少上行流量，方便处理 同样服务器下行时可以类似处理进