客户端发送消息，统一在服务器端触发战斗

服务器端驱动战斗过程

客户端端接收用户输入向服务器发送消息

客户端接收服务器消息显示客户端表现

1. 服务器--客户端交互（战斗流程）

整战斗流程分为4个状态：战斗准备，战斗开始，战斗进行，战斗结束。其中战斗进行状态时服务器客户端可以进行两种交互，一种是服务器端定时器触发战斗循环，另一种是客户端玩家发送战斗操作。具体如下：

a. 战斗准备

b. 战斗开始

· 初始化战斗相关信息，即从基础信息模块中获得角色、阵型、属性，从战斗中获得战场

· 启动战斗实例的定时器，一个战斗实例用一个定时器。

· 在初始化战斗，特别是定时器的数据步骤中，需要根据属性建立战斗对象的出招队列。战斗对象可以在战斗实例定时器下排成队列一个接一个地调用。看策划需求，相较而言ARPG的野怪可以实现为每个野怪在该心跳下的一个定时器而非队列。

c. 战斗循环

· buff发生改变的情况包括：

1. buff定时失效 ，根据buff到达失效时间发送消息

2. buff定时扣血，根据扣血间隔发送buff改变消息

· 客户端接收到buff改变的消息后要在相应操作：

buff扣血 ，客户端播放扣血与buff的动画特效

buff失效，客户端停止播放buff的动画特效

· 获得出招队列首位角色的仇恨对象，如果该角色没有仇恨对象，就直线向前移动，并结束该次心跳

仇恨角色的选取：

1. 玩家指定（我自己设计）

2. 系统指派，系统以一定半径搜索角色周围

· 通过与仇恨对象的距离判断是否攻击

与仇恨对象距离过远，则朝向仇恨对象移动，并结束该次心跳

与仇恨对象距离可以发动攻击，检查攻击间隔

攻击间隔已到则朝对象发动攻击

攻击间隔未到则结束该次心跳

· 如果发动攻击，计算扣血

如果仇恨对象被攻击死亡，清空进攻角色的仇恨对象

d. 战斗操作

我自己设计了玩家在场景中拖拽部队选择其攻击对象的功能。

战斗操作只是更改战斗对象的一些数据，这些数据不会即时影响战斗循环，故不需要与战斗循环的心跳做同步。

e. 战斗结束

2. 服务器端战斗系统结构

CWarMgr是服务器的一个单例组件，负责管理服务器所有的战斗，包括创建战斗、向战斗实例派发消息、维持战斗心跳、结束战斗。

IWar是战斗实例的接口，派生出CWarPve，CWarPvpOnline，CWarPvpOffline三种实现类去处理三种不同的战斗。

IWar的创建应用了抽象工厂模式，由IWarCreator接口派生的实现类创建。

IWar包含了战斗双方的数据，由于服务器战斗循环以及客户端发起战斗操作（在更改战斗双方的数据时需要考虑多线程数据的同步，固客户端更改数据需要加锁？）

3. 客户端战斗系统结构

相较服务器而言，客户端增加了一个CWarScene战斗场景类负责管理战斗场景，它将包含一些IWarEffect战斗特效类（战斗特效的更新与播放）。IWarEffect主要派生出四种具体特效实现类，包括操作特效（仅变化模型着色以提示玩家）、粒子特效（特效只包含粒子）、动画特效（特效包含粒子和动画）、跳字特效（用于扣血等属性数值的增减）。这些特效都在OnUpdate中查询对于的SBuffInfo结构体，以确定特效是否和如何播放。

4. 如何应对策划修改

多数情况下都是策划攻，程序受，一起来探讨一下逆天的策划会有什么逆天的设计，如何留好接口进行扩展去应对这些设计。

a. 世界boss，多个玩家挑战同一个超级boss 

b. 大乱斗，玩家中途参战 

c. 帮派战，前军中军后军3vs3 

d. 自动战斗，中途加入操作