最近有机会开发回合制战斗系统，记录一下制作过程中的感受和理解，方便后续回顾和反思，同时也梳理一下现有的战斗思路
1.回合制的理解
传统回合制游戏如《仙剑》、《梦幻西游》、《八方旅人》等。该游戏有一些具体特点：
1.确定角色动作顺序和回合时机
2.每个角色每回合只有一次行动机会，但可能有多次释放技能的机会
3.技能或风暴可以触发其他技能或风暴
4. 风暴触发时间难以确定
2、功能生产的方向和目标
我们对战斗的期待更偏向于《八方旅人》。 不过由于我从小就玩仙剑和梦幻西游，而且深受炉石传说和杀戮尖塔的影响，所以在功能制作方向上我会更多地参考梦幻西游和熔炉。 《Tales of Stone》和《Slay the Spire》的相关功能。
3. 战斗逻辑框架
为了保证整个战斗系统的灵活性以及配置各种治疗效果相关功能的复用性，我们决定参考Dota2中的战斗技能模块进行设计和制作。 即采用能力-修改器-动作模式的战斗设计。
能力：
包含固定的执行节点：如添加、删除技能节点、释放技能（技能触发节点）等。
该节点包含一些操作
维护一个修饰符列表，即该技能将包含该技能使用的所有修饰符
修改器：
具有某些触发属性的节点：例如OnAttacked、OnAbilityExcuted
该节点包含一些操作
行动：
具体的执行问题，比如播放特效和音质、添加Modifier等。
我对这个系统的理解是：能力好像是一个很大的技能容器，里面有很多这个技能里的触发器（Modifier），以及很多自己的行为（固定的执行节点逻辑和里面的Action）
一个具体的例子
但这些设计思路都是针对实时moba游戏的。 回合制系统可以在一定程度上简化系统，增加规划的理解成本。 虽然这些技能是计划配备的技能，但是学习成本还是太高了。 而且程序调试起来比较困难。
根据我的理解，设计了一套技能系统：
1. 技能
1.包含多种类型的节点：比如技能何时附加到角色上、何时释放技能、何时移除技能等。
2.相应节点技能要执行的Action列表
3、功能与能力类似，主要作用是作为疗效的容器，有一些固定的执行节点。
2.浅黄色
1. 可以配置的触发节点有很多：OnBuffAdded、OnBuffRemoved等自身行为节点，以及OnRoundStart、OnAttacked等全局或角色对应节点。
2、触发前条件判断（Condition）、触发后执行特定扰动（Action）、触发后执行新技能（Skill）
3. Buffs的存在导致的属性值变化和玩家状态变化（如头痛、睡眠等）
4.对象存储：Buff释放者、所有者等。
5、Buff的有效机制：有效轮数（一定轮数后消除buff）、有效次数（触发一定次数后消除buff）等。
6、Buff之间的关系：互斥关系、叠加关系（Buff层叠加）、替换或延长Buff持续时间等。
2.5. 健康）状况
当Buff在对应的触发节点被触发时，可以通过Condition再次标定Buff，以确定该Buff是否会被触发
3. 行动
具体的风暴执行器包括多种类型的可以执行的风暴，例如给角色添加或移除buff、执行伤害、播放特殊音质等。
可以看到，这套虽然基本是之前那一套逻辑改了改名回合手游源码修改，但按照我的理解做了一些改动，比如删掉了很多和延时相关的功能（我觉得回合制需要限制时间等等，大部分都限制为偶数等），并且增加了一些新的Buff决策逻辑。 这样的设计，我觉得Skill就像一个外壳，Buff就像一个中转站，Action就是具体行为的执行。
也就是说，虽然技能是一个逻辑入口，但是当执行上述Action时，该Action会添加一些Buff，而这些Buff作为传送点可以触发新的Action和技能。
这样就可以实现套娃的逻辑了：SkillA执行ActionA，添加BuffA，触发SkillB，执行ActionB，添加BuffB，触发SkillA（死循环！！）
四、战斗流程设计 1、在整个战斗流程中插入逻辑点
将整个战斗分成几个可以执行Buffs或者做特定逻辑的节点。 例如，对于一个简单的回合制游戏，可以分为：
战斗开始的节点（盘丝岭将化身梦幻西游手游开场）
本轮开始前，剩余Buff将结算至偶数结算节点
每轮开始前的节点
角色动作之前的节点
角色动作节点
角色动作后的节点
圆端节点
这里只是一个反例，中间可以细化更多能用的逻辑节点。
2. 整体风暴流管理：
使用风暴队列+临时风暴栈来管理风暴
1. 本回合的行动顺序在回合开始前已被预估。 本回合任何buff引起的属性变化都不会影响本回合的行动顺序，从下回合开始形成影响。 这样，在本轮开始之前，本轮所有角色的节点和行动顺序就已经确定。
2.很多临时触发的风暴要等到当前风暴执行完毕后才会开始
3.风暴的触发是有顺序的，因为临时风暴还可能触发新的临时风暴（两个反击100%的角色互相攻击时，会形成对决，直到其中一个死亡）
5. 总结
整体的逻辑思路总结起来就是这样。 其实还有很多细节，有些实现方法还没有写详细（我觉得我的代码太草率了，没脸拿出来）。 这里面还是有很多设计的。 虽然我还没有想出一套逻辑上的实现方案（都是硬编码的，比如目标的选择、切换和扩展等），但如果我有一些清晰、有条理的想法摆在我面前，有时我会其实会回去完成这个视图（我很大概率不会，因为我发现写完之后连回去看都困难，更不用说填写新的内容了哈哈哈哈）。
同时，由于我已经做了很长一段时间的UI男孩，虽然这是我第一次自己设计游戏中的完整系统（我设计一个屁，不是复制Dota2设计） ，通过这个我了解了很多关于二次系统开发的知识回合手游源码修改，显然是第一次做这么大的系统。 所以肯定还有很多不足的地方，希望路过的大佬能给我一点建议。
