Open zhkuang opened 9 years ago
服务器端生成战斗总共做了两次，cocos一版、pixi一版，两次都花费了很多时间，很大的精力，因为我个人能力问题，最终没能成功实现服务器端的战斗过程，但是还没有完，I'll be back!
简单地说就是服务器生成战斗数据，分析战斗数据，加载人物骨骼资源，人物技能资源，技能脚本，待资源加载完毕后，初始化战斗逻辑，然后开干，结束后回传战斗后每个英雄的数据，然后服务器回传过来结果，战斗结束。
那么一个人物攻击敌人经过了什么样的过程呢，首先是根据当前技能选取目标，根据攻击距离确定攻击位置，然后移动，检测目标是否在攻击范围，满足技能所需条件，开始播放atk动画，atk播放过程中监听atk_fire事件，捕获事件，开始执行脚本。脚本中有各种逻辑处理，伤害或者怎么样。
战斗主要依赖那些东西：
这块其实还是蛮蛋疼的，服务器传过来的数据是战斗双方的基础属性，需要从中提取出需要的资源文件列表，然后加载，通过sid获取spine资源以及技能脚本，技能脚本这块我考虑的确实欠佳，最开始是打算技能脚本完全独立，给谁都能用，但是后面我考虑技能就是针对某个英雄的，像sid一样，所以就把脚本绑到固定的英雄身上了。然后需要根据对应的技能加载不同的技能所需图片资源。这三部分资源都准备好以后，就可以初始化自己的数据结构，进而开始游戏
这是我改的最多的一块，改版了好多次，但是现在依然觉得很薄弱。主要分为Character, skill, sprite, body,states. 其中character 包含着主要的逻辑处理，skill是技能的管理器，body为任务model, states掌管着所有状态机。
各种技能脚本，人物移动都需要action的支持
无论是action 还是 spine animation 都需要Loop以及delay time.
从上面就能看出，无论在哪，只要我有上面几个东西，我就能搞战斗。所以我就从这几个方面入手的。
资源加载解析： 服务器端的资源加载解析和前端不能通用的，所以需要实现一套服务器能跑起来的，资源加载好说（其实也不好说，资源的管理就是个问题），直接require同步将资源加载过来，而且是所有资源都搞进来，因为服务器端要图片没用，所以只加载spine的json和atlas,以及技能图片的json. 前端解析是依赖引擎的spine模块，cocos和pixi都有，服务器上没法用或者移植过去成本比较大，所以我打算只解析spine的json,从json中获取技能的播放时间，帧事件的触发时间，在播放器中正确的时间fire出对应事件。 合图资源是脚本中用的很多的，合图的尺寸也影响着战斗的过程，所以合图的json需要解析出来，并且自己实现sprite类，返回的不包含texture的sprite，尺寸什么的都和前端的一样。这样就能模拟出来了。
播放器： 这个地方就是我失败的地方，主要是movieclip的播放。前端movieclip的播放是依赖pixi的ticker的，我服务器那版用的是delaytime，哎，这块我没能很通透，后面一定会好好搞搞。 spine的播放器我认为我那版是没有问题的，几种基本事件也都是正常使用，暂时没发现什么问题
数据层和逻辑层都是共用的，loop也差不多，但是前端的setTimeout什么的真的太慢了，还是用while吧！
目测问题主要在播放器那块，因为时间关系，不能再拖进度了，就选择了前端生成。真是失败！
服务器调试其实有点伤，因为只能看log调试，哎，这不算完，不管后续如何，一定会搞服务器版！！
未完待续。。。
记录一下，以免后面忘了
服务器端生成战斗总共做了两次，cocos一版、pixi一版，两次都花费了很多时间，很大的精力，因为我个人能力问题，最终没能成功实现服务器端的战斗过程，但是还没有完，I'll be back!
为什么要做
战斗是怎么跑起来的
简单地说就是服务器生成战斗数据，分析战斗数据，加载人物骨骼资源，人物技能资源，技能脚本，待资源加载完毕后，初始化战斗逻辑，然后开干，结束后回传战斗后每个英雄的数据，然后服务器回传过来结果，战斗结束。
那么一个人物攻击敌人经过了什么样的过程呢，首先是根据当前技能选取目标，根据攻击距离确定攻击位置，然后移动，检测目标是否在攻击范围，满足技能所需条件，开始播放atk动画，atk播放过程中监听atk_fire事件，捕获事件，开始执行脚本。脚本中有各种逻辑处理，伤害或者怎么样。
战斗主要依赖那些东西：
资源以及对应的解析器
播放器
数据
这块其实还是蛮蛋疼的，服务器传过来的数据是战斗双方的基础属性，需要从中提取出需要的资源文件列表，然后加载，通过sid获取spine资源以及技能脚本，技能脚本这块我考虑的确实欠佳，最开始是打算技能脚本完全独立，给谁都能用，但是后面我考虑技能就是针对某个英雄的，像sid一样，所以就把脚本绑到固定的英雄身上了。然后需要根据对应的技能加载不同的技能所需图片资源。这三部分资源都准备好以后，就可以初始化自己的数据结构，进而开始游戏
逻辑
这是我改的最多的一块，改版了好多次，但是现在依然觉得很薄弱。主要分为Character, skill, sprite, body,states. 其中character 包含着主要的逻辑处理，skill是技能的管理器，body为任务model, states掌管着所有状态机。
Action
各种技能脚本，人物移动都需要action的支持
Loop
无论是action 还是 spine animation 都需要Loop以及delay time.
OK，可以开搞了
从上面就能看出，无论在哪，只要我有上面几个东西，我就能搞战斗。所以我就从这几个方面入手的。
资源加载解析： 服务器端的资源加载解析和前端不能通用的，所以需要实现一套服务器能跑起来的，资源加载好说（其实也不好说，资源的管理就是个问题），直接require同步将资源加载过来，而且是所有资源都搞进来，因为服务器端要图片没用，所以只加载spine的json和atlas,以及技能图片的json. 前端解析是依赖引擎的spine模块，cocos和pixi都有，服务器上没法用或者移植过去成本比较大，所以我打算只解析spine的json,从json中获取技能的播放时间，帧事件的触发时间，在播放器中正确的时间fire出对应事件。 合图资源是脚本中用的很多的，合图的尺寸也影响着战斗的过程，所以合图的json需要解析出来，并且自己实现sprite类，返回的不包含texture的sprite，尺寸什么的都和前端的一样。这样就能模拟出来了。
播放器： 这个地方就是我失败的地方，主要是movieclip的播放。前端movieclip的播放是依赖pixi的ticker的，我服务器那版用的是delaytime，哎，这块我没能很通透，后面一定会好好搞搞。 spine的播放器我认为我那版是没有问题的，几种基本事件也都是正常使用，暂时没发现什么问题
数据层和逻辑层都是共用的，loop也差不多，但是前端的setTimeout什么的真的太慢了，还是用while吧！
现况
目测问题主要在播放器那块，因为时间关系，不能再拖进度了，就选择了前端生成。真是失败！
服务器调试其实有点伤，因为只能看log调试，哎，这不算完，不管后续如何，一定会搞服务器版！！
未完待续。。。