客户端发送消息,统一在服务器端触发战斗
服务器端驱动战斗过程
客户端端接收用户输入向服务器发送消息
客户端接收服务器消息显示客户端表现
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. 自动战斗,中途加入操做