客户端发送消息，统一在服务器端触发战斗
服务器端驱动战斗过程
客户端端接收用户输入向服务器发送消息
客户端接收服务器消息显示客户端表现
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. 自动战斗，中途加入操作
我所理解的网络游戏<？>：战斗逻辑设计