erlang战斗系统设计

一 需求

播放回合制，外加插入式手操

战斗大致流程如下，

1：战斗开始前单位S1与S2 称之为精灵1,2放完增益/减益技能后退场，战斗进入循环

2：每个循环中按照站位顺序1-12号单位依次释放技能

3：每个单位都可以手动释放技能，释放的技能插入下一个行动之前，比如1号位行动期间，3号位释放了一个主动技能，那么1号位行动后会直接播放3号位释放的技能

4：当一方全部死亡，或者轮数大于一定回合后战斗结束

5：战斗需要支持多人在线PVP

草草画了张流程图

可以看出，这是一个类似卡牌的经典战斗模式，接下来我们将一步步实现它，从框架到具体技能填充，满足策划的变态需求，等等。。

二 主体框架

首先明确一点战斗需要支持多人在线战斗，那么战斗需要由服务器驱动，

同时必须开启一个进程来承载双方的战斗，不能将战斗挂在玩家进程

那么到底是启动gen_server还是gen_fsm？

gen_fsm不熟悉的可以先看一下解释

A behaviour module for implementing a finite state machine. A generic finite state machine process (gen_fsm) implemented using this module willhave a standard set of interface functions and include functionality for tracing and error reporting. 

gen_fsm在状态较多的时候相对于gen_server易于管理

我们分析一下战斗的状态

1：perparing 战前准备状态，用于调整站位技能等信息

2：loading 加载界面状态，多人在线战斗时，由于机器/网络情况不一样，需要等待所有人加载完毕才开始战斗

3：fight 战斗状态,战斗进入正常循环

4：fight_over 战斗结束处理

我们会有4个大的状态，以及2个小状态，使用gen_server会比较难以管理，所以决定用gen_fsm启动进程

进程大体如下

绿色代表gen_fsm的状态, 蓝色字代表每个状态的事件

gen_fsm大体结构就是这样

接下来我们需要想一想一场战斗需要的数据

首先看一下最终我使用到的结构

1：战斗类型

2：参与战斗玩家列表

3：战斗单位状态

3.1 站位

3.2 单位行动了几次

3.3 技能列表

3.4 其他根据游戏不同拥有不同的属性

4：准备完成玩家列表      发送准备数据后需要等待所有玩家响应返回

5：加载完成玩家列表      发送加载数据后需要等待所有玩家响应返回

6：胜利条件

7：第几轮

8：总体行动了几次，用于与前端同步

9：当前轮已行动单位列表

10：当前行动已相应的玩家列表

11：释放的主动技能列表

至此一个初始的战斗进程被拉起来

三 与前端通信

与前端通信的关键是如何实现插入式的技能释放，即将上一次行动中释放的技能在下一次行动播放

我们使用了，每一次行动通信一次的做法，客户端每一次的行动都由服务器通知，

当客户端播放完成接收到的行动后，通知服务器，当所有玩家都返回通知后服务器再发送下一次行动

如图，服务器会不断比较下一次行动的数据，等到所有人相应后推送给前端展示，

发送的行动可能是顺序播放的技能，也可能是玩家主动释放的技能

当多个玩家同时在上一次行动释放技能，则按顺序发出