浅析播报制战斗的代码实现

最近做了一个包含播报制战斗的活动，活动大致是玩家一起挑战某个世界boss，直至将boss消灭，按伤害量进行奖励。该活动的战斗是播报类型的，即战斗过程是完全无操作，玩家只是要看完整个完整的战斗过程。

很显然，在玩家一开始进行战斗时，战斗结果已经确定了，客户端只是在接收到服务端发来的该场战斗的数据后，像播“视频”般将整场战斗播放出来。在此总结分析下战斗部分的代码。

 

与战斗相关的UML类图：

 

Main为活动的核心类，拥有很多模块的引用，如声音模块，网络通讯模块，资源加载模块，窗口管理模块，这些在上面的UML类图里没有一一列出来。CombatVideo（战斗播放）和StateTask（状态机）则是与战斗最为相关的模块。

 

状态机：

通常来说，拥有较多状态表现且状态经常改变的模块，适合设计成状态机模式。

针对播报战斗而言，有进入战斗Loading，请求战斗初始数据，初始化战斗面板UI，加载战斗资源，播放出场动画，请求战斗结果数据，播放战斗，退出战斗等状态，且某些状态需要符合一定条件后才可以转变成下一个状态，如向服务端请求战斗结果，只有当接收到服务端的数据后，才能进入播放战斗的状态。因此，很适合以状态机模式来设计。

战斗模块的状态转换还是非常简单的，基本是线性的，CombatCallState->CombatWaitingState->CombatLoadingState->SCombatResLoadedState->CombatSpiritOutState->CFightRoundState，不涉及复杂的状态变换。

由StateTask按顺序执行各个State的execute方法，当某一State的工作完成后，调用StateTask的pushTask接口，新增一个新的State。

 

战斗播放：

拿到后台返回的一推战斗数据后，如何将其表现成一场完整的战斗过程，这是整个战斗系统的核心。

核心类：

CombatVideo：持有CombatVideoPlayer，Screen，VideoConverter，负责了整个战斗播放的控制工作

CombatVideoPlayer：战斗播放器，接收Segment数据，负责战斗播放。

CombatData:服务端的战斗数据。

VideoConverter：将服务端的CombatData转换为Segment数据。

 

Segment：战斗播放的最小的单位数据，由CombatVideoPlayer控制播放。Segment的粒度细分到：受到buff、近程攻击、远程攻击、换宠、逃跑等。持有对Screen的引用，是实际逻辑的实现类，什么意思？就是整个舞台什么时候做什么事，做什么逻辑，是由Segment来控制的，因此称Segment为“实际逻辑的实现类”。用剧本片段来比喻Segment是最恰如其分的。

以换宠这个Segment为例：

1、先在舞台相应位置create一个宠物球特效

2、特效播放完后，UI（血条，图标等）信息更新为新宠物的信息

3、在舞台相应位置create新宠物，播放从小变大的帧动画

4、宠物播放idle动画，UI添加buff信息。

当上面四个过程都完毕后，类本身派发ON_SEG_END事件，表明该Segment已经播放完毕。

 

可以说，一场完整的战斗，所有的细节都是细分成Segment的。当客户端收到该轮战斗的CombatData时，根据其类型下发给相应的Segment处理，进而将冷冰冰的战斗数据，变成有血有肉的视觉表现。CombatVideoPlayer则负责播放一帧帧的Segment，串联成一场战斗。

 

Screen：战斗场景的容器类，持有对战斗Sprite，特效，UI的引用。

 

CombatVideoPlayer负责按序执行处理队列里的Segment数据，调用Segment的start方法，并监听VideoEvent.ON_SEG_END事件，每个Segment执行完毕后，派发VideoEvent.ON_SEG_END事件。CombatVideoPlayer监听到VideoEvent.ON_SEG_END事件后，就处理下一个Segment数据。直到处理完所有的Segment数据。

Segment可细分为不同类型的Segment，ActionChangeSpiritSegment、ActionFightSegment、ActionStartSegment分别对应换宠、打击、进场等动作片段。各Segment通过接口控制Screen的Spirit进行各种动作表现，如宠物进场/退场、宠物打击/受击等。

转载于:https://www.cnblogs.com/leoin2012/p/4260778.html