现在别人都是可以to cpp 了
意思是计算判断都放c艹里？然后js就拿个结果展示？
我的意思是u3d c#都可以打包成cpp了 我们还在js里面写脚本 游戏逻辑消耗就比别人高得多
更新:
- 微信小游戏支持可靠的udp传输.
大佬~连接无效了 是下架了么~~
进不去呀大佬~
我想请教一下，这里是不是把物理处理那块搬到了服务器上计算，客户端只是展示结果呢？
这里大家担心的应该是跨平台float数和π值不同的影响
连带的一套数学库,cos,sin等 在ios平台和android平台有一些细小的差异，而随着时间差异会越来越大
最后就是由于网络线路的原因,不同地区接收到消息的时间点不同, 碰撞的双方前后时间点的不同, 结果也会不同
如果由服务端运算， 就是服务端不断按帧计算物理， 那麽服务端压力也太大了， 一台机器只能服务几场战斗。
我看了源码， up主是改了sin和cos的算法以及pi的定义， 始终帧同步还是适合由客户端主运算
1赞
感谢分享思路
那客户端不能做任何预测吧， 是服务端收集了所有用户的Input操作后, 然后下发到用户客户端，这样才能保证就算不同时间接收到消息也能保持同步吧
没有经过充分验证的东西就感拿来卖钱,和骗有什么区别
我自己调研过，我以经典的比卡丘排球为例， 其实预测方面的话， 如果是自身的操作可以进行预测， 因为你本地一定领先几帧， 不需要等服务端推送后才播放自身的变化， 但对于对手和球， 如果不是一些高频变化的可以根据对手的当前移动方向去预测变化， 但像在比卡丘排球 对手动操作很频繁而且还受重力影响下， 预测就没意义了，100％是错的。
另外就是因为我是用rapier.js物理引擎， 为了有预测所以是建立了两个物理世界，a世界有双方比卡丘和球的刚体和场景碰撞器，b世界只有我方的一只比卡丘和场景碰撞器, 服务端驱动过来的是a世界更新step，渲染上球和对手立即更新， 然后判自身与b世界的自身在该帧下的操作or变化是否相等， 相等自身不更新继续保持领先状态， 否则回滚， 将a世界的该帧快照在b世界回滚使用， 然后b世界按回固定帧率更新
rapier.js 我也用过 ,貌似原生和H5都是一致的,但不太确定
其实我有个想法，在帧同步中使用不确定性运算的库(比如物理引擎)的方案(没有验证)
- 在帧同步传递操作的基础上，将所有不确定的数据发送出去。
- 客户端的每个逻辑帧(服务器下发的帧)，使用逻辑帧里面的数据作为确定性数据，然后再进行确定性运算。
- 其它逻辑，比如预测什么的都按照帧同步的基本做法做就行。