游戏开发技能系统常用概念

一个角色同一时间可能存在多个Skill，一个当前播放的主动技能，还有好几个不在播放中，但是也没有结束的。
技能事件： 实现具体的技能功能，技能动作的执行都是通过触发事件来触发的，比如（时间帧，命中，受伤，正常结束，异常结束）
公共：移动(因为需要服务器计算移动位置)，播放动画，标准子物体，按键跳转，线框判定，开启包围盒和关闭包围盒（服务器记录标识，不会一直都开着，性能问题）,技能段跳转
客户端：播放音效，模型变色，播放特效，隐藏装备，显示装备
服务器事件：修改属性相关
客户端事件其他端也是靠播放技能播放，公共事件和服务器事件其他端靠各个系统的ntf播放

动画事件：1.根据时间帧的方式方便策划配置 2.动画事件策划不方便配置，可能很多动作文件都要配一遍，编辑器下可以复制黏贴，一般都是特殊的需要代码处理的动画中断点才配置比如拔刀收刀只有主角有。StateMachineBehaviour脚本，挂在动画上主要是为了动画开始和结束时候的回调方便传给逻辑代码使用，比如采集动作的完成。

动作和特效都是0帧起手要马上播放，但是因为加载有延迟时间，怎么解决?
1.根据表格里面预加载一些动画 2.加载动画完成后根据配置是否从头开始播放，否则计算跳过加载完成时间-开始调用时间，从新的时间段开始播放。

状态模式的运用: 加载过程中（加载开始，加载中，加载完成，加载失败），位移中（根据速度情况不同状态），热更新流程中分成好几个状态

动画加载：根据配置，基本上都是动态加载，加载出来后可定时根据时间间隔卸载或者永不卸载，可配置预加载，异步加载的好处：角色刚出来加载状态机需要花费很多时间和内存，减少加载时间和内存占用空间。

主角移动协议：
通过摇杆更新，定时都会同步数据，通过摇杆获取输入，获得输入方向，主端进行移动，然后发送位置，速度和方向

状态同步：一般跟着动作，比如一个技能段播放一个动作其中触发多个技能事件，发送技能开始协议传简要的dstSid和技能id等数据，等到技能段的时候同步目标具体的buff状态，符文属性等相关信息，技能段也是协议数据量最大的地方。
客户端上只有公共事件才需要发技能事件start给服务器
技能中的位移：定时时间间隔发送更新位置信息，帧同步
游戏中发射的子物体也是公共事件，需要服务器知道，因为要记录子物体信息(通过同一个技能事件的req)，以后碰撞要进行校验，子物体的位移处理：客户端自己处理，根据子物体的运行状态的时候决定是否要更新位置

移动位移：是定时发送位置同步，主角相关
击退位移，目标角色的事件ntf的广播根据击退现场拿到对应的击退的角色播放击退动作和客户端模拟位移
受击的时候位移是同步的，每个端的那个角色都一样，而音效，闪白，受击特效是只有自己客户端碰撞检测到的那个端才播

怪物技能：服务器控制决策，通过决策ntf发给主端，主端执行play skill方法，然后就是和主角一样通用的协议

子物体同步：状态同步，分为开始状态，更新状态，即将消失状态和销毁状态，更新状态是在重置目标点的时候更新一次速度朝向位置，开始状态更新位置速度朝向

一个简单的攀爬用例：https://blog.csdn.net/qq_27361571/article/details/53307366?ops_request_misc=&request_id=&biz_id=&utm_medium=distribute.pc_search_result.none-task-blog-2_alles_rank~default-2-53307366.es_vector_control_group&utm_term=%E6%94%80%E7%88%AC%E6%95%88%E6%9E%9C&spm=1018.2226.3001.4187

技能段的超时结束，有什么作用，服务器的超时结束吗，为什么会有这个
给其他端同步的时候防止其他端迟迟收不到主端的技能段结束ntf，而无法结束定义的超时结束
防止作弊：如果客户端发送了技能请求但未能在合理时间内完成技能动作（可能是由于客户端崩溃或恶意修改），服务器可以通过超时机制取消该技能，防止作弊行为。
超时结束的原因主要包括网络延迟，客户端崩溃或异常、防止作弊