这里所说的技能系统包括：技能流程和技能创生体（法术场、弹道和buff）
首先介绍authority和proxy的概念，这两个概念是基于单位unit的基础上进行的区分。
authority表示单位的主控端，即此单位是由客户端和还是服务端控制。对于玩家avatar，玩家本地的客户端就是主控端。而对于怪物，他们的行为由服务端控制，主控端就是服务端。
proxy表示代理端，表示被主控端控制。如对于怪物来说，所有的客户端都是proxy；对于玩家A来说，服务端和其他玩家的客户端都是proxy。
0 技能同步的原则
1.客户端先行
对于玩家控制的单位来说，玩家点击按钮释放一个技能，客户端首先响应，单位播放动作以及相应的技能特效。
据了解，有的已上线游戏并没有做客户端先行，而是所有的技能执行请求都发给服务端，然后由服务端发起。
这种模式技能流程控制会比较简单，但是在网络环境差的情况下，体验可能差一些。但是，目测也是可以接受的。
2.技能流程以authority为发起端
玩家单位技能发起是由她的客户端，怪物的技能发起是由AI也就是服务端。
3.技能结算在服务端发起。
技能真正的结算，比如法术场检测、buff结算、伤害计算以及扣血等，统一在服务端处理。
1 技能执行流程的同步
这里所说的技能执行流程指的是技能树的一个执行节点的流程。
技能流程负责动作、特效以及技能结算，其中技能结算包括：释放法术场、弹道或buff。
一个技能执行节点的执行流程中，需要同步的有两个时间点：
-
技能开始：技能开始播放动作
-
技能结算：前摇结束，即能进入结算逻辑。这类同步消息往往并不是由技能本身去同步，而是技能生成了法术场、弹道等，他们去做相应的同步。
以玩家点击技能按钮开始释放技能为例介绍技能同步流程，如图所示：
-
主控端点击技能按钮，技能开始播放动作，主控端告诉服务端技能开始。
-
服务端广播给所有的客户端(多玩家场景)，告知其他所有的客户端此玩家开始执行技能。其他客户端收到指令后可是播放技能表现。
-
服务端延迟一段时间后，服务端开始进行技能结算，并且将结算结果通知客户端。
延迟时间=技能前摇时间-上行-下行，下行一半不能确定，所以默认为上行=下行
另一种中庸的计算方式是：延迟时间=技能前摇时间-上行，防止要求技能前摇时间过长
使用此同步流程的表现为：
-
要求技能前摇时间>2*网络延迟，若前摇时间短，则延迟时间=0，效果可能差一些
-
authority客户端表现完美。
-
proxy client表现一般，即玩家A看玩家B的效果为：玩家B刚开始执行技能动作，没到前摇时间就进行了技能结算。但是因为玩家一般也不会过分关注其他玩家的动作，所以是可以接受的。
2 技能树的同步
我们游戏使用的是技能树来管理技能流程。那么就面临一个问题，技能树如何同步。
最简单最暴力的方式，是客户端和服务端同时管理技能树，并且将其状态同步。这样，客户端和服务端的技能树状态统一、完备。
后来发现，对于proxy端，并不需要完备的技能树信息，最节省的方式是proxy根本不接受技能树同步信息，只是接受播放动作、技能结算等信息。但这样需要告诉其他proxy播放什么动作、特效等。
在我们系统中，技能同步包括三类同步消息:
-
技能根节点enter (root_enter): 表示一个大技能的进入
-
技能叶子节点enter(action_enter): 表示一个技能树的执行节点的进入。
-
根节点exit(root_exit) ：表示大技能结束
根节点保存一个完整技能的信息，需要和技能模块外部交互，因此需要知道技能的开始和结束。
叶子节点的执行代表着技能真正的执行逻辑，也需要同步。
而对于其他节点，作为流程控制节点，只需要在主端确保技能流程无误即可
后来这里进行了进一步的优化，对于纯根节点，主控端（玩家控制的客户端）将信息同步给服务端，服务端不再同步给其他客户端。有的技能树只有一个节点，那么按照叶子节点的策略，主控端同步给服务端，服务端广播给所有的其他客户端。
3 技能结算的同步
技能结算包括创建法术场、buff、弹道、技能直接伤害等。
法术场、弹道的同步
法术场、弹道的同步比较类似，他们都作为一个entity（网络同步单元）在服务端创建，创建以后使用entity管理机制服务端通知客户端他们的创建和销毁。
以法术场为例，法术场的执行和同步流程：
-
服务端发起创建一个法术场，并且通知客户端
-
法术场每隔一段时间结算一次，注意，法术场结算并不需要同步，每隔一段时间服务端执行检测逻辑，客户端播放结算特效等。两个逻辑互不依赖，也不要求时间一致。
-
当法术场结算时检测到攻击目标时，服务端计算攻击伤害等信息，并将攻击信息发给客户端。
-
客户端收到伤害信息，客户端播放相应的表现，如法术场受击特效等。此处还包括属于通用模块的跳字等。
-
当服务端的法术场时间到了进行destroy时，使用entity的管理机制通知所有客户端destroy法术场。
弹道的同步类似，唯一的区别就是法术场在某一位置使用攻击盒检测目标，而弹道是一个移动的子弹，客户端表现是一个特效在飞，而服务端每隔一段时间根据飞行速度等使用胶囊攻击盒去检测目标碰撞。
由以上可以发现，法术场作为一个entity他的管理成本是比较高的，所以若策划想出一些需求需要使用多个法术场实现，一般通过拓展法术场功能使用一个法术场来实现。
比如，策划要做一个冰火两重天法术场，即法术场在每次结算时使用不同的参数，第一次结算使用火焰，第二次结算是冰霜。若这种需求较少，可以使用两个法术场，但是如果要冰火雷毒水电风魔奥术神圣*N重天，则代价太大。一般可以让法术场支持每次使用不同的结算参数来结算即可。
buff同步
buff是附加在unit身上的东西（没有unit就没有buff，但是没有unit可能有法术场），所以不需要使用entity来同步。
-
服务端确定buff是否可以挂在unit上面。
-
客户端和服务端都维护一个buff管理器，挂buff的消息通知所有客户端，客户端负责表现，服务端负责结算即可。
4 伤害、属性的同步
主要介绍下伤害的同步，顺便附带介绍下属性同步。
对于伤害结算来说，技能、buff、法术场和弹道都可能造成伤害，当服务端发现造成伤害时，服务端首先根据技能信息计算伤害值，计算以后将伤害信息发送给所有客户端，所有客户端接到信息后首先播放技能伤害相关的表现，如受击特效等，然后播放跳字等通用伤害客户端表现。
也就是说，伤害值的同步其实就是简单的rpc消息。
buff可能修改单位属性，如攻击力、攻击速度等。这些属性值的同步一般使用属性同步，属性同步的意思是当一个值改变了，底层自动把这个值同步给客户端。
血量等信息值都是用属性同步方式。
伤害计算和属性模块是一个重要且比较复杂的模块（当然，若游戏数值非常简单也可以很简单）