开发历程
项目是从8月20日左右开始开发的，到今天一个月不到吧。
除了底层库和服务器架构外我们大致开发了5个服务器为：
一 ) . 战斗服务器
二 ) . 匹配服务器
三 ) . 验证服务器
四 ) . 网关服务器
五 ) . 游戏服务器
其中 战斗服务器 和 匹配服务器是我负责的 (确实撸的很爽 哈哈哈) :
在有一套成熟的框架体系下撸代码的体验就是快速稳定健全。
战斗服务器总结
战斗服务器是集群节点的配置。
为了提高服务器的容错和开发速度。我们把所有集群服务器都设置为单线程模式。允许一台服务器部署多个服务器。
战斗服务器主要处理游戏战斗中事务：
创建游戏房间
提供英雄选择 技能选择 皮肤选择
提供游戏过程支持（使用技能 / 请求移动 / 断线重连 / 游戏结算 / 游戏规则 / 战斗回放）
逻辑帧
我们在设计战斗服务器之初就定义好了游戏有逻辑帧的概念，同时客户端也遵循该逻辑帧的时间并且客户端的逻辑帧时间由服务器下发。
以此概念就能保证在大多情况下客户端和服务器的逻辑帧是相同的，有时候可能会出现指令有1-2帧的误差，但这并不影响，因为一个逻辑帧也就几十毫秒，玩家基本感知不到。（网络延迟不参与此处误差计算）
有了逻辑帧概念后，服务器只需要将收到客户端的所有请求信息全部压入队列。当下一个逻辑帧到达后将所有消息取出，依次处理并下发游戏消息。而客户端收到网络消息就只需做对应的播放就可以，也就是说客户端就算不请求服务器但是收到了服务器的下发消息也需要对该消息进行播放处理。
战斗回访
服务器可以借逻辑帧的概念将每帧下发的消息都存储到 redis 然后用于支持战斗回访。
技能系统
为了满足策划的脑洞大开，技能系统开发了一版并重构了一版后，目前暂且满意了。
刚刚开发技能系统的时候，选择了快速开发的方式简单的对技能进行 分类 / 接口抽离 / 解耦 开发了。
在Demo版出来后，发现功能的却是实现了，技能系统架构也还行，但逻辑层的代码太过于冗余，也不方便后期的扩展和维护。
于是重写之，大概的重新分析了下技能的一些处理，比如使用技能开始，使用技能下发。
根据以上分析和实际的开发中的心路历程将技能抽象为状态机之。写好了感觉也不是最好的方式不过按目前的需求足够了。
之所以选择状态机是因为在现在的研发阶段好维护 / 好扩展，重构的话成本也不高。
Buff系统
Buff系统总共就开发了两个类吧。因为这个比较简单。一个是 BuffNode 节点类，一个是 BuffManager 管理类。
每一个战斗对象会被绑定一个BuffManager管理类。这样就把每个对象自己的Buff都剥离开了。并且状态操作直接操作对象类就可以了。
战斗对象
所有战斗中可以和其它对象交互的对象都统称为战斗对象。（可以为 英雄 / 弹道技能 / 甚至阻挡）
战斗对象具有类型。对外提供抽象接口。提供统一的查询接口。外部操作都通过接口操作。
该设计方便了后期的扩展和维护。
游戏规则
对外提供规则管理接口，内部规则对管理接口提供内部规则操作接口。实现一接口操作多规则的构架。
规则内部以状态机方式实现，实现在不同状态下的处理剥离。