帧同步和状态同步

帧同步 说白了就是在客服端跑一个服务器,每个服务器基于相同的帧率,同步在相同帧的输入,达到一致性。

状态同步 服务器运算,把状态的改变发给客服端

首先要说 帧同步不是说不能加入状态同步的东西,状态服务就不能有帧同步类似的东西,所以他们的优点只基于

帧同步 服务器和客服端在一块,只发输入

状态同步 服务运算,发状态

网络:

帧同步 的网络负担肯定更小

但是延迟的问题大家都有,解决办法点也不一样。帧同步解决同步问题就是好了,状态解决的办法和思路比较多,比如客服端预判,部分运行客服也做一次等。总的来说帧同步解决网络延迟难度更大,当然解决好了,复用性比较好。状态同步相对容易一点点,只是那么一点点,但是办法多,解决的差也还行。

性能: 状态同步 不是一定要全部服务运算,帧同步 也不是非要全部放到客服端,所有这个基本上半斤八两

体验:帧同步 服务器和客服端在一块,所有输入预判肯定要准确些,但是准确好多,那的看网络情况,这个东西只能可能要好些,好多少难说。具体来说,就是单位越多,帧同步越容易做的更好。有人说格斗游戏帧同步肯定要好些,这点我不赞同。在小数据量,网络情况一样的情况下,发状态一定代表之间有差别么?差别在那?网络延迟?首先我们要清楚,状态同步并不是说客服端不能做已经确定的状态的后续运算,比如移动,动画等,或者做预判处理。所有,状态同步,在小数量级下,同步效果没有理由比帧同步差。

开发难度:帧同步 确实适合大公司,人多的,又有牛人的团队,帧同步其实是难度交给了同步,也就是说吧问题丢给单一人上。状态同步,难度要小些,但如果要做好也非常难。

个人觉得 帧同步 只适合特殊情况,比如数量级和技术能力强的团队

状态同步 适合范围非常大

选择哪个只取决于你的团队情况,帧同步,状态同步 都是需要有经验的人才能做的更好,

技术更强的团队帧同步,游戏理解更好的团队状态同步

另外说一句,不是说 状态同步 就不能在客服端放个服务器,其实这个也是可以,服务器之间用状态同步就可以,如果离线单机可以做成,单机的时候服务器在客服端,多人的时候在服务端。

也不是说 帧同步 就不能用 状态同步 做一些处理,甚至一些用状态同步 一些用帧同步

技术源于对问题的解决 而不是类别

状态同步和帧同步 并不是鸿沟 相反可以融合

时间: 2024-10-29 10:47:45

帧同步和状态同步的相关文章

帧同步与状态同步

从事棋牌游戏三年,一直不知道原来我们游戏使用的服务端编程的专业术语叫状态同步. 状态同步: 服务端:保存的是整个场景实时的状态.对各个对象实体用一些变量描述它当前的状态. 优点:网络流量消耗较小 缺点:当场景里实体对象很多时,需要保存的内存数据就会大大增加.并且不一定可控. 帧同步: 服务端:保存一个时间片(逻辑帧)里各个玩家的操作的指令集 优点:无需保存对象的实体状态 缺点:难以调试,断线重连回来必须执行一遍指令集,会很慢.

两种同步模式:状态同步和帧同步

https://zhuanlan.zhihu.com/p/36884005?utm_medium=social&utm_source=qq 一.同步 所谓同步,就是要多个客户端表现效果是一致的,例如我们玩王者荣耀的时候,需要十个玩家的屏幕显示的英雄位置完全相同.技能释放角度.释放时间完全相同,这个就是同步.就好像很多个人一起跳街舞齐舞,每个人的动作都要保持一致.而对于大多数游戏,不仅客户端的表现要一致,而且需要客户端和服务端的数据是一致的.所以,同步是一个网络游戏概念,只有网络游戏才需要同步,而

状态同步和帧同步个人理解

一.同步 所谓同步,就是要多个客户端表现效果是一致的,例如我们玩王者荣耀的时候,需要十个玩家的屏幕显示的英雄位置完全相同.技能释放角度.释放时间完全相同,这个就是同步.就好像很多个人一起跳街舞齐舞,每个人的动作都要保持一致.而对于大多数游戏,不仅客户端的表现要一致,而且需要客户端和服务端的数据是一致的.所以,同步是一个网络游戏概念,只有网络游戏才需要同步,而单机游戏是不需要同步的. 二.状态同步和帧同步的区别 最大的区别就是战斗核心逻辑写在哪,状态同步的战斗逻辑在服务端,帧同步的战斗逻辑在客户端

[WinForm][DevExpress][TreeList]父子节点CheckState状态同步

关键代码: /// <summary> ///同步父子节点勾选状态 ///说明 ///在AfterCheckNode事件中使用代码 ///eg:e.Node.SyncNodeCheckState(e.Node.CheckState); /// </summary> /// <param name="node">需要同步的节点</param> /// <param name="check">节点当前勾选状态&

DevExpress TreeList 父子节点复选框状态同步

1.给TreeList tlstRegion添加一个自定列(包含) TreeListColumn IsAll; RepositoryItemCheckEdit repositoryChk = new RepositoryItemCheckEdit();chkIsAll.EditValueChanging += chkIsAll_EditValueChanging;tlstRegion.RepositoryItems.Add(chkIsAll);this.IsAll.ColumnEdit = ch

状态同步

[状态同步] 1.将所有的操作发送给Server(T1),由Server计算(T2),并返回结果(T3). 权威服务器架构能够防止很多的作弊,但是直接用这种方法会让游戏的响应变得迟缓. 如果 T1 + T2 + T3 非常大,则游戏体验会非常差.比如,Client_1开了一枪,1000ms 后才收到响应,这个游戏体验非常差. 另外,全球发布的游戏,通信常常是由地球的这一端发送到地球的另一端.光速是300000km/s,而地球半周长是20000km,将花费66.6ms.但这只是最乐观的情况 - 假

# IT明星不是梦 # 图解kubernetes容器状态同步机制核心实现

在K8s中将Pod调度到某一台Node节点之后,后续的状态维护信息则是由对应机器上的kubelet进行维护,如何实时反馈本地运行状态,并通知apiserver则是设计的难点, 本节主要是通过感知Pod状态变化和探测状态改变两个流程来实际分析其核心数据结构,来了解内部设计 1. 状态管理 1.1 静态Pod 静态Pod主要是指的那些不是通过感知apiserver创建的pod, 因为apiserver上并不包含,但是同时也需要维护和获取这类Pod的状态, k8s中就设计了一个镜像Pod的概念,其实就

真正的inotify+rsync实时同步 彻底告别同步慢

我们公司在用inotify+rsync做实时同步,来解决分布式集群文件一致性的问题.但当web文件越来越多(百万级数量html,jpg等小 文件),同步就越来越慢,根本做不到实时,按照网上的调优方法都尝试过,问题根本没有解决.经过我一翻细致研究,终于把慢的核心问题研究明白,先总结一句 inotifywait响应不会有延迟,rsync也很快.大家同样有慢的烦恼,那是因为网上的inotify+rsync的教程都是坑.下面我们来分 析. inotifywait 单独分析 /usr/local/bin/

socket的阻塞与非阻塞,同步与非同步

---恢复内容开始--- 网络编程中通常提到四种方式,同步/异步,阻塞/非阻塞.以下对它们的概念进行总结 1.同步/异步:主要针对C端 同步:所谓同步,就是在C端发出一个功能调用时,在没有得到结果之前,调用不返回,也就是必须一件一件事做,等前一件做完了才能做下一件事. 例如普通B/S模式(同步):提交请求->等待服务器处理->处理完毕返回,这个期间客户端浏览器不能干任何事. 异步:当C端一个异步调用发出后,调用者不能立即得到结果,实际处理这个调用的部件在完成后,通过状态,通知和回调来通知调用者