多人联机的物理游戏，一般是帧同步，并且使用定点数的物理引擎。
在服务器端使用一个物理引擎，没有渲染功能，单纯模拟物理，
然后模拟的数据同步前端，前端节点再插值更新位置和角度。
这种方式在商业游戏上有什么问题吗？
你说的是状态同步吧，帧同步只传用户输入的数据，所有结果客户端自己算的
对，用状态同步，然后物理引擎在服务器端。前端只负责插值渲染。
这种感觉同步就没有任何问题，但是商业游戏有这么做的吗？会有哪些问题，想了解下。
是不是服务器计算太大，无法承受。还是说网络传输延迟，不可行。
有没有问题取决于你们老板有没有钱力部署那么多机房来全国加速。。
这一条很重要，如果你们这个游戏一个月就收入个万把块，服务器的钱都不够用
1.服务器压力大
2.服务器成本高
3.需要模拟的参数过多，实现难度大
4.相比起前端物理引擎将算力分发在每个用户的客户端，服务器物理引擎得不偿失
不过如果只是简单的2D割草算算应该可行，但是依然不如前端算
看你的游戏类型，需要实时同步就选帧同步，比如多人联机的动作、射击、Io类，缺点是实现难度大，数据不安全
对实时性要求不高，就选状态同步，比如Mmorpg、棋牌，优点是数据安全
但是可以对客户端的性能要求降低，没有了物理计算，只是渲染服务器的数据。未来网速会越来越快，流量成本不高。另外未来游戏可能会融入AI系统，可能客户端性能就吃不消了，尤其是手机。所以把AI的计算和物理的计算都放到服务器上会比较好。 网络同步频率和服务器帧率可以设置高低，控制成本。
你买过服务器就知道了，服务器太贵了，花那么多钱为了能让诺基亚玩上我的游戏，值得吗？当然你的想法肯定已经有大厂实现了的，像吃鸡这种游戏肯定是客户端和服务器都要有物理引擎的，各自负责不同的算法，普通公司怕是支撑不起
嗯嗯，有点偏云游戏的感觉了。
必须状态同步, 帧同步除非你基于整数而不用浮点.
状态同步服务器跑物理和主要逻辑, 你要是卖道具还可以, 不卖道具若用户量稳定, 一台服务器一个月能剩个几百块钱的营收.
最重要的是开发十分复杂, 服务端必须用CPP否则吞吐量不行.
总结就是: 有没有版号, 没有版号无意义;
借贴问问大佬们永劫无间这种是状态同步吗
可以让一个玩家（比如房主）的主机做物理状态的转发服务，其他玩家的物理禁用，把操作发送给房主，状态都用房主同步过来的状态。