MOBA服务器开发第一阶段完成总结

开发历程

---

 

项目是从8月20日左右开始开发的，到今天一个月不到吧。

除了底层库和服务器架构外咱们大体开发了5个服务器为：

　　一 ) . 战斗服务器

　　二 ) . 匹配服务器

　　三 ) . 验证服务器

　　四 ) . 网关服务器

　　五 ) . 游戏服务器

其中 战斗服务器 和 匹配服务器是我负责的 (确实撸的很爽 哈哈哈) : 

在有一套成熟的框架体系下撸代码的体验就是快速稳定健全。

 

战斗服务器总结

---

战斗服务器是集群节点的配置。

为了提升服务器的容错和开发速度。咱们把全部集群服务器都设置为单线程模式。容许一台服务器部署多个服务器。

战斗服务器主要处理游戏战斗中事务：

　　建立游戏房间

　　提供英雄选择 技能选择 皮肤选择

　　提供游戏过程支持（使用技能 / 请求移动 / 断线重连 / 游戏结算 / 游戏规则 / 战斗回放）

 

逻辑帧

　　咱们在设计战斗服务器之初就定义好了游戏有逻辑帧的概念，同时客户端也遵循该逻辑帧的时间而且客户端的逻辑帧时间由服务器下发。

　　以此概念就能保证在大多状况下客户端和服务器的逻辑帧是相同的，有时候可能会出现指令有1-2帧的偏差，但这并不影响，由于一个逻辑帧也就几十毫秒，玩家基本感知不到。（网络延迟不参与此处偏差计算）

　　有了逻辑帧概念后，服务器只须要将收到客户端的全部请求信息所有压入队列。当下一个逻辑帧到达后将全部消息取出，依次处理并下发游戏消息。而客户端收到网络消息就只需作对应的播放就能够，也就是说客户端就算不请求服务器可是收到了服务器的下发消息也须要对该消息进行播放处理。

 

战斗回访

　　服务器能够借逻辑帧的概念将每帧下发的消息都存储到 redis 而后用于支持战斗回访。

 

技能系统 

　　为了知足策划的脑洞大开，技能系统开发了一版并重构了一版后，目前暂且满意了。

　　刚刚开发技能系统的时候，选择了快速开发的方式简单的对技能进行 分类 / 接口抽离 / 解耦 开发了。

　　在Demo版出来后，发现功能的倒是实现了，技能系统架构也还行，但逻辑层的代码太过于冗余，也不方便后期的扩展和维护。

　　因而重写之，大概的从新分析了下技能的一些处理，好比使用技能开始，使用技能下发。

　　根据以上分析和实际的开发中的心路历程将技能抽象为状态机之。写好了感受也不是最好的方式不过按目前的需求足够了。

　　之因此选择状态机是由于在如今的研发阶段好维护 / 好扩展，重构的话成本也不高。

 

Buff系统

　　Buff系统总共就开发了两个类吧。由于这个比较简单。一个是 BuffNode 节点类，一个是 BuffManager 管理类。　　

　　每个战斗对象会被绑定一个BuffManager管理类。这样就把每一个对象本身的Buff都剥离开了。而且状态操做直接操做对象类就能够了。

 

战斗对象

　　全部战斗中能够和其它对象交互的对象都统称为战斗对象。（能够为 英雄 / 弹道技能 / 甚至阻挡）

　　战斗对象具备类型。对外提供抽象接口。提供统一的查询接口。外部操做都经过接口操做。

　　该设计方便了后期的扩展和维护。

 

游戏规则

　　对外提供规则管理接口，内部规则对管理接口提供内部规则操做接口。实现一接口操做多规则的构架。

　　规则内部以状态机方式实现，实如今不一样状态下的处理剥离。