更正一下，魔法阵那个伤害计算不太对，因为有可能一个英雄进进出出反而受到更多伤害 
还有这个同步方式应该不算帧同步吧 
补充一些细节，比如我现在正在释放在一个范围内拖拽敌人的技能
现在有1个(正常延迟)的客户端想释放这个技能 和 1个可能会受这个技能影响的(高延迟)的客户端
正常延迟客户端：客户端发送可以释放技能的指令—服务器收到指令确认可以释放—服务器判断当前技能事件触发时影响到的其他客户端分发状态并存储—正常延迟客户端收到指令，在该范围内确实有敌人，播放敌人受拖拽影响的动画(由于正常客户端延迟不大，所以敌人被拖拽的动画近似立即呈现)
受拖拽技能影响的高延迟客户端，由于高延迟，会出现某些情况：
1.我因为同步服务器的移动数据晚，所以我可能并没有走到敌人的技能范围的时候，服务器就已经确认我在这个范围内了，而且我并没有看见对方在释放技能，因为我还没有同步对方的行为
2.正常客户端已经释放完技能了，我是高延迟客户端，我还在进行拖拽动画的播放。
对于这类情况，我想到的是首先在移动指令上做限制，当服务器开始分发所有客户端进行拖拽动画播放的时候，立即屏蔽掉释放这个技能的客户端和受到影响客户端的移动，也就是说，你们2个先别动了，然后在本地客户端的拖拽动画结束之后，本地客户端上传一次我结束拖拽动画的指令，服务器确认了之后，解除该客户端的移动限制。
这样，对于正常的客户端而言，应该是感受不到阻塞感，对于高延迟客户端而言，接收慢上传也慢，高延迟客户端会等拖拽结束后+延迟时间，才能继续接受服务器的同步移动
不知道这点是否正确
貌似学会了一个最基本的平滑公式，比如英雄移速是200。比如寻路完是3条直线，也就是4个点(1个初始点和2个转折点和1个目标点)
服务器60帧1秒计算经过的路径点，每帧经过16.66666ms…，每次计算新坐标后发给客户端同步位置。
公式：每帧新坐标=归一化方向向量(相邻点向量相减) 
移动速度 × 0.0166666
客户端比如是120帧，相当于服务器经过了1帧，而客户端经过了2帧，那么服务器在第1帧结束的时候是没有服务器同步的数据，相当于每2帧都会停1帧在原地，理论显示上就是一跳一跳的。
所以直接用服务器同步下来的坐标点，减去当前客户端坐标获得方向向量，然后将方向向量归一化，然后在客户端的FixUpdated里面让 英雄坐标+=归一化方向向量 移动速度
目的就算让客户端在其余非同步帧时也有坐标变换
小兵的话 我觉得还是状态同步的吧 。
怎么讲呢，你所有的小兵的行进逻辑不会因为在不同设备有不同表现，除非你代码写的问题，举个例子，纯粹的数学题1+2 = ？的答案不应该在不同国家有不同的结果
没事了，之前大部分思路都是错的，现在会了
亲，本地 去判断 先确认当前能不能释放技能？ 还叫状态同步么？这样做出的游戏，随便搞个客户端外挂 你也认可 外挂的操作？
有啥心得，说说，学习学习
已经解决了，服务器编写update状态机等方式判断所有游戏逻辑，最多一星期，现在正在把项目往热更迁移。到时候会出一个小贴子可以来看看
服务端 是用什么语言
golang