本文不涉及任何实际实现，仅为个人目前看法。因此可能也会有所不对的地方，若有问题还请指正。
# 前言
这里特指网游，且非状态同步战斗类型。
主要指：房间类 或 挂机类，且有玩家数量限制。
之所以单独提出这两种类型，是因为这两种类型战斗 (/ 服务器) 是可以独立形成一个系统，而像状态同步类型游戏则不同，因为随时可以战斗或进行其它操作，战斗本身与正常游戏流程逻辑也会是有一定耦合的。以前那些 MMO 端游一般就是这种模型，这种类型个人没作过多研究，猜测如此。
而 房间类 或 放置类 则不同，一般来说，都会有一个独立的战斗服务器，无论是仅仅作数据分发，还是逻辑演算或本身就跑了一个完整战斗系统。
# 分类
# 状态同步类型
状态同步即服务器运行一个完整的『游戏世界』，一般见于大世界即时战斗的端游。不过也可以用于上述两种类型。
玩家操作会先发给服务器，服务器执行完毕，再将执行结果同步给客户端。即所有实际逻辑，客户端都不执行，而仅更新表现。例如玩家的位置：在状态同步中，玩家的位置信息，会以指定频率与服务器保持一致。客户端本身一般没有操作权限 (不排除那种直接客户端移动，然后将位置同步给服务端的)。
# 纯战报型
直接后台根据交战双方生成『战报』，然后将战报发回前台，前台仅作『回放』
该功能连战斗逻辑都是由后台实现，无论是 PVE 还是 PVP，流程都一样。一般用于回合制，且所有战斗都不允许玩家操作的游戏。
例如：新仙剑奇侠传手游
前台接收到的为『每一个回合』战斗对象的行为描述，例如我方 A 攻击敌方对象 B，或者我方 B 释放了某个技能。
而且由于接收到的是纯战报格式数据，基本上杜绝作弊可能性，前台仅需根据每回合对象战报描述，作对应表现即可，也不会涉及什么复杂逻辑，因此难度为简单。
不过由于整个战斗都纯粹由系统『自动』进行，交互能力较弱，属纯挂机类战斗。
这种类型由于毫无操作玩家毫无操作余地，只有一些老手游使用，新出的基本没有了。
# 回合制交互
指以『回合』作为战斗流程，每回合由玩家选择释放指令，每回合有接收指令超时时间，超时则执行默认指令。
例如 电击文库：零境交错
主要有两种：在进入战斗后，服务器可以实时运行一个战斗系统进行管理，也可以仅作指令分发，最终统计玩家指令，并重新跑一次战斗作验算。
其中统计指令，最终验算的方式性能较优，不过也有一定作弊风险。而 PVP 就必须实时运行一个战斗系统进行管理，因此这样 PVP 与 PVE 的处理就有一些差异 (也可以就采用一套实时系统，只是会增加服务器压力)。由于是回合制，玩家操作一次才会有一次指令，因此同步网络要求不高，可以直接在普通的通信接口处理指令分发。
同时由于 PVP 过程中，每一回合都需要同时等待双方玩家完成操作，体验不会太好，因此也有采用回合制游戏去掉了 PVP 操作支持，仅保留 PVE 的玩家操作，若属于玩家双方对决，则直接令双方『自动战斗』。(例如：三国志幻想大陆)
# 帧同步弱交互
特指在完整帧同步结构上进行一部分删减，去掉实时的战斗服务器，战斗服收到数据，直接返回战斗结果 —— 严格来说，已经不算是帧同步了，而叫『指定命令同步』。
例如：新三国汉室复兴
不过除此之外，其他要求几乎与帧同步一致，而且也没看到其他介绍类似方式的名字，因此个人还是这样在称呼。
同样可以在客户端统计完毕玩家所有操作指令后 (即前端战斗表现完成)，统一上传服务器跑一次战斗作验证，战斗服的功能主要是返回一个战斗结果，例如双方剩余血量，胜方等等。
看起来与上述回合制交互有些类似，但是更复杂一些，特别是前后端执行时涉及到同步『一致性』问题时。
表现上主要指不支持 PVP 战斗的交互，PVE 中玩家操作也比较简单的情况，一般就操作一下释放技能的时机等，目前挂机类游戏，例如策略类游戏大多可能使用该方法。
该方法战斗不以回合作区分，而以『帧』或『时间』作战斗流程。
例如，规定一帧等于多少秒，然后将两者联系起来。
战斗系统中，更新一次算作一帧，直到满足战斗结束条件而结束，得出胜利失败方结果。
此种类型交互处理流程为：前端记录玩家操作指令，战斗结束发回后台验证，后台得出胜利失败结果后下发前端，前端以后台结果为准进行展示。
这种了类型虽然叫弱交互，实际上也是可以实现除 PVP 大部分玩家操作的，因为每个操作都算作一个指令，只要指令正常记录，验算结果不出问题即可。
该类型需要一个战斗服务器作结果验算。
# 帧同步强交互
该类型需要一个实时战斗服务器作操作指令分发或验算。
由于仅同步指令，而非所有状态，因此数据占用相对状态同步更低 (玩家数量不多的情况)。
此种类型大体与上面弱交互类型类似，不过由于有实时战斗服支持，因此可以实现 PVP。(其实个人感觉上面弱交互也可以一定程度实现 PVP，就是由系统外做服务器的同学实现一个 “指令分发” 的效果，不过由于不是每帧实时同步，而是在玩家触发 “点击操作” 时分发指令，可能导致战斗流程不是很流畅，且存在 “不同步” 及大延迟的风险)
例如：王者荣耀
(注：玩家数量过大的战斗只能使用状态同步)
参考：
帧同步和状态同步该怎么选（上）
帧同步和状态同步该怎么选（下）
# 设计
这里特指『房间类』战斗模式：即战斗过程会进入一个新场景，而非直接在当前情况下执行战斗 (若那样就是纯状态同步网游了，实现原理就不一样，跟后台就挂很大勾了)
首先，作为这种类型的战斗，无论是性能还是维护上的考虑，前后端的战斗系统本身应该一致。
因为后端也需要运行，因此战斗系统必须完全独立，可以通过指定数据接口进行交互，例如事件系统。
后端由于无表现层，可以选择在需要的事件上进行注册即可。前端表现层所有数据皆以系统内部为准，例如角色位置、方向等等，并且不允许对系统内部的『直接』的更改。所有的玩家操作，都必须是一个『指令』，方便上传服务器使用。
因此主要大概可以再分为以下模块：
- 场景：视战斗场景复杂度情况而定，若仅为『平面』战斗，且要求不高，则自己实现一个性能更优的四叉树一类场景管理亦可。也可以找 Github 上开源的物理引擎 (如 Box2D)。
寻路：例如 A*、Navmesh
事件系统：仅负责时间分发，本身并无特殊功能，因此可以算是最简单的一份
定 (/ 计) 时器：管理技能 CD、延迟触发等相关行为，与事件系统类似
角色：主要又分为三类
- 技能
- AI
- Buff
其中，战斗逻辑中，『技能』应该算是最重要的一个，AI 其次。
作为技能主要有两类：
- 一种是策划提供描述，程序编码实现
- 一种由程序提供『积木』，由策划组合逻辑
第二种一般都得有配套的编辑器工具，例如像行为树编辑器那种 —— 不过取决于本身需求设计。
常规还有『链式』结构：执行一个技能时，会附加初始节点到角色身上，当前挂载节点为当前生效功能，节点结束或满足一定条件，则执行其后节点，直到终点。
开场 ——> 接战 ——> 战斗中 ——> 战斗结束
待补充......
