别说cocos做不了物理同步,几行代码助你轻松实现物理同步

意思是计算判断都放c艹里?然后js就拿个结果展示?

我的意思是u3d c#都可以打包成cpp了 我们还在js里面写脚本 游戏逻辑消耗就比别人高得多

大家讨论的好激烈,要不来我这看看。我这用了一个取巧的方法支持了物理同步
https://store.cocos.com/app/detail/3426

1赞

简单的测试后,3D物理似乎也能完美同步,每一帧的坐标和角度都完全一致 :smiley:

3D demo来了

2赞

更新:

  • 体验地址换成国内服务器,现在秒进
  • 2.x版本box2d支持wasm.ios小游戏物理新能提高5倍.(3.x版本就等官方支持了或者用论坛提供的方案)

更新:

  • 微信小游戏支持可靠的udp传输.

大佬~连接无效了 是下架了么~~

进不去呀大佬~

@sixian 在不同分辨率下box2d的世界坐标都变了,还能同步吗?比如一个是960 * 640,一个是1280 * 640

我想请教一下,这里是不是把物理处理那块搬到了服务器上计算,客户端只是展示结果呢?
这里大家担心的应该是跨平台float数和π值不同的影响
连带的一套数学库,cos,sin等 在ios平台和android平台有一些细小的差异,而随着时间差异会越来越大
最后就是由于网络线路的原因,不同地区接收到消息的时间点不同, 碰撞的双方前后时间点的不同, 结果也会不同

如果由服务端运算, 就是服务端不断按帧计算物理, 那麽服务端压力也太大了, 一台机器只能服务几场战斗。
我看了源码, up主是改了sin和cos的算法以及pi的定义, 始终帧同步还是适合由客户端主运算

1赞

:+1: 感谢分享思路

那客户端不能做任何预测吧, 是服务端收集了所有用户的Input操作后, 然后下发到用户客户端,这样才能保证就算不同时间接收到消息也能保持同步吧

没有经过充分验证的东西就感拿来卖钱,和骗有什么区别

我自己调研过,我以经典的比卡丘排球为例, 其实预测方面的话, 如果是自身的操作可以进行预测, 因为你本地一定领先几帧, 不需要等服务端推送后才播放自身的变化, 但对于对手和球, 如果不是一些高频变化的可以根据对手的当前移动方向去预测变化, 但像在比卡丘排球 对手动操作很频繁而且还受重力影响下, 预测就没意义了,100%是错的。

另外就是因为我是用rapier.js物理引擎, 为了有预测所以是建立了两个物理世界,a世界有双方比卡丘和球的刚体和场景碰撞器,b世界只有我方的一只比卡丘和场景碰撞器, 服务端驱动过来的是a世界更新step,渲染上球和对手立即更新, 然后判自身与b世界的自身在该帧下的操作or变化是否相等, 相等自身不更新继续保持领先状态, 否则回滚, 将a世界的该帧快照在b世界回滚使用, 然后b世界按回固定帧率更新

rapier.js 我也用过 ,貌似原生和H5都是一致的,但不太确定

其实我有个想法,在帧同步中使用不确定性运算的库(比如物理引擎)的方案(没有验证)

  • 在帧同步传递操作的基础上,将所有不确定的数据发送出去。
  • 客户端的每个逻辑帧(服务器下发的帧),使用逻辑帧里面的数据作为确定性数据,然后再进行确定性运算。
  • 其它逻辑,比如预测什么的都按照帧同步的基本做法做就行。

可以使用 实时竞速游戏验证过了: 竞速类物理引擎帧同步实现方案 - Creator 3.x - Cocos中文社区

为什么下架了,是有问题吗