利用惯性和加速度进行网游位置同步
带宽限制下的视觉实体属性传播
(Propagation of Visual Entity Properties Under Bandwidth Constraints)
一文中使用滞后补偿时间(LCT, Lag Compensation Time)来平滑客户端的显示.
在此方法下, 客户端主角显示在未来位置, 超前于服务器时间,
而同伴显示过去的位置, 滞后于服务器时间.
所以两个人一齐跑时, 总是会发现同伴落后于自己.
为了减弱同伴落后问题, LCT应该用于远方物体的位置同步, 越远LCT可以越大.
就像我们观察星星, 我们看到是其实是几万年前星星的样子, 因为星星距离我们有几万光年.
对于周围近距离的物体, LCT应该尽量小, 接近0.
所以上文并没有解决客户端的平滑问题.
文中所述的导航预测算法(DR, Dead Reckoning)并不应该放弃.
导航预测算法的原理是推算出未来的位置,LCT是将过去的位置作为现在位置来处理.
对于邻近物体, 应该显示未来的位置.
因为出于操作感的考虑, 主角的位置是超前于服务器的, 不可能等服务器确认后再移动.
所以周围同伴的位置也应该是超前的, 这样才不会有同伴总是落后于自己的现象.
导航预测算法不适用的主要原因是, 网游人物的移动是高度随机的, 状态更新太频繁.
这其实不是问题, 因为有预测肯定比没有预测要好.
在预测范围内, 就不必发位置更新.
最差情况下, 每个预测结果都是错误的, 必须修正为实际的位置,
这就退化成为没有预测的简单的位置更新方法.
但是如果网络延时50ms, 这50ms的预测是必须的.
因为客户端表现的是超前服务器50ms前的景象.
这就存在同伴掉下悬崖的现象, 因为同伴在悬崖边上的停止的消息要在50ms后才到.
这种问题在预测法中是无法解决的, 除非添加行为预测.
但是可以添加一个加速度来减少这种预测错误.
导航预测算法适用于飞机飞行模拟这类具有很大惯性的移动.
网游中的移动问题根源就是惯性不足, 有了惯性, 角色将无法任意更改移动状态,
从而大大减少预测错误.
人物在悬崖边上停止的动作必须有个减速的过程, 只要在50ms之前减速,
就会正确计算出停止点, 避免了坠崖. 开始移动时也是有个加速过程.
并且, 客户端主角的惯性可以大于服务器端, 而周围物体的惯性可以小于服务器端.
产生的效果是, 主角的动作变迟钝, 减少超前时间.
而周围物体稍稍灵活, 增加了超前时间.
或许我们所处的世界也是虚拟的, 创世者为了位置同步而给我们这个世界加上了惯性和加速度的规则.
金庆的专栏
利用惯性和加速度进行网游位置同步
原创wx648abf25141f7 博主文章分类:网游开发 ©著作权
文章标签 网游 服务器 constraints 算法 properties 文章分类 Python 后端开发
上一篇:网关按区域聚集玩家
下一篇:什么是开发人员有意义的方向

-
Android 线性加速度 线性加速度公式
实时步进电机仅通过加法和乘法实现线性斜坡 1.运动基础线性加速度(斜坡)公式为: &nb
Android 线性加速度 步进电机 延迟时间 浮点 -
Python 加速度 振型 python计算平均加速度
目录1.相关数据展示2.数据滤波处理及展示3.计步功能实现1.相关数据展示 数据为开源数据,遵守开源数据库协议(Open Database License (ODbL)),数据格式为csv文件。 数据集有多个维度
Python 加速度 振型 python 开发语言 stm32 数据 -
python 加速度波形换算为速度 python计算平均加速度
1、场景描述在数据统计分析过程中,求累计值(总和)是最常用的统计指标之一,市面上的各种流行数据库均支持的查询方式基本如下:select sum(c) from table_name;当数据量在小规模时,sum只是一瞬间的事情,让你感觉电脑真牛逼啊,我掰手指头要算半天的数,它居然可以这么快,下面是1万多条数据的字段求和,只用了8ms。 但是当数据量不断增长到一个量级时,比如
python 加速度波形换算为速度 python 求均值 python 求平均值 python求平均值 向量化