保全派驻功能实现逻辑

[YipKei]

需求分析

是否已经有现成的方案：

是的

目前已知的是有脚本实现了 泥岩 + 菲亚梅塔 / 澄闪 的前三层通关策略，但相关脚本的对应功能依旧存在较多的问题：

1. 战斗过程为硬编码，每次出现新的地图都需要核心开发者进行爆肝手写流程，虽然更新频率不高，但核心开发者应当致力于完成更多更适合自身开发的工作。
2. 前三层通关的战斗效率过低，为确保稳定性，在设计上需要重复 12 次战斗流程，虽然加上检测之后可能实际只要大约 8 ~ 10 次，但整体时间开销依旧过高，因为保全派驻的特殊性，前三关需要占用约20分钟的时间，整体战斗流程可能需要消耗 3 ~ 4 小时，目前刨去大多数应变之后的战术实际上可以支撑到保底五层，这样就只需要三轮，约 1.5 小时即可完成战斗，节省大量时间。
3. 纯硬编码的战斗流程对于后期牌组过大的问题不能很好地支持，浪费了自动战斗这一功能的潜力。

保全派驻自动战斗的功能需求分析：

什么人需要保全派驻自动战斗功能：

1. 没有前台时间手动操作完成保全派驻的玩家
2. 实际游玩过程中过于贪心和手贱导致翻车的玩家
3. 没有时间或者精力学习保全派驻套路的玩家

这个功能应该如何实现？

首先，不应该是集成战略模式

集成战略的游戏内容随机性过强，固定作业的方案虽然目前拥有最稳定的深层潜力，但是玩家间不同的配置都需要独立的作业设计，推广性相对较弱。
如果采用玩家共建作业的形式，因集成战略的复杂性，每一套作业的设计难度都非常之大，一般玩家制作作业的正向反馈过小，可以预见地不会有太多人会热衷于创造作业。
因此，集成战略当前采用的是一部分受邀请的开发者研究通用决策方式的形式来设计完全没有玩家参与的全自动作战流程。
保全派驻存在一定的随机性，但没有高到这种程度

其次，常规的作业形式无法满足保全派驻的战斗需求

保全派驻除了常规的战斗之外，还存在选牌、抽牌、选装置等多种操作需求，战斗中的内容可以为普通的战斗逻辑增加一个抽牌行动的方式来解决，但其他的区别对传统自动战斗的逻辑需求增加的内容过多，而自动战斗的部分逻辑对于保全派驻而言需求不高，可以被优化掉。设计一套新的方案在开发成本上可能还会更低一些。

现有的自动战斗为有序执行逻辑模式，这种模式相对于保全派驻的战斗需求而言是一种拖累，保全派驻的战斗更适合进行无序执行列表中的内容，准确点说，使用动态顺序的形式执行。
这样可以降低作业的编写难度，同时大幅提升战斗操作的兼容性。

另外还有一个稳定性噩梦的地方在于，保全派驻的地图具备一定的随机性，这意味着会干废目前的自动战斗逻辑，或者需要为此额外重写一个检测项，而这个检测项对于普通的自动战斗是完全没必要存在的。

理想的保全派驻自动战斗，应当可以做到除了选择作业并点击开始之后，所有流程由 MAA 进行接管

这意味着所有的随机事件选择逻辑都需要在作业配置中得到定义

需要有一套相对完善的衔接逻辑完成楼层的选择

需要有相对稳定的作业实现和失效反馈逻辑

实现方式

配置文件 与 战斗文件 分离

配置文件 core.json 仅记录适用于全局需求的一些选项，比如干员的选择，战术装备的选择，每层强制塞人的选择逻辑等。
也可以记录少量的通用战斗选择，比如 核心的战术装备配置情况，但不记录任何与具体地图相关的实际战斗逻辑

战斗文件 LT[n].json 仅包含具体地图的战斗逻辑，包括刷开局、每个波次的叠层需求，以及特殊环境下的应变（这个功能根据实际情况再考虑如何实现，以及支持的程度如何吧，但设计阶段肯定要提出来），战斗文件需要依赖配置文件进行执行，自身不保存任何与具体干员除识别ID外的相关的配置信息。

在这一机制上，作业分为三个类型：

1. 配置文件，无法独立使用，在高级模式下用户可以自行选择
2. 战斗文件，依赖配置文件，在高级模式下用户可以自行选择需要的文件，选择后 MAA 会自动在作业站寻找绑定的配置文件
3. 执行列表，本质上是一组包含一个配置文件和一系列战斗文件的记录文件，在简单模式下，用户选择执行列表，MAA 会自动加载列表中的配置文件，并顺序执行战斗文件，这是一般用户的使用逻辑。

将作业文件拆分的方式有几个优点：

1. 更新单层作业不用重新发布其他内容信息
2. 只要采用同一份核心配置，不同玩家开发的作业之间就具备良好的兼容性，同时也相当于降低了玩家单次开发作业的成本
3. 独立的文件方便在编写作业的同时查看核心配置信息，进一步降低开发难度
4. 核心配置可以提供足够多的配置项，尽可能地包办战斗中的所有事件，实现完美托管。

用户界面设计

简单模式

用户选择加载一份 执行列表，MAA 会自动寻找列表中的配置文件并加载，并顺序执行列表中的战斗文件。

有三种情况 MAA 会结束当前的保全派驻：

1. 当结算界面中，两种材料均检测到 Max，或者出现其他表明材料刷满的情形
2. 当列表中最后一个战斗文件执行完毕，同时 连续战斗 的选项为关闭时
3. 战斗失败次数超出限制时

简单模式下，MAA 提供三个选项开关：

1. 连续刷取，默认开启。开启后会重复执行当前执行列表，直到材料刷满。
2. 隐藏模式，默认关闭。开启后会无视当前材料刷取情况进行战斗，战斗过程中只要出现战斗失败的情形就从头开始重开，执行完成当前列表后自动暂停。
3. 跳过检测，默认关闭。开启后，MAA只检查是否存在未选择助战的情况，如果存在则过一遍干员选择，如果不存在则跳过；不检查战术装备的配置情况，不检查塞卡策略。以现在的执行效率来看，每轮作战也就省个一两分钟吧，不做其实也就强迫症比较难受。

如果加上记录执行列表的功能，那么理论上每个月用户只需要点两次就能刷完保全派驻了。

高级模式

在这一模式下，用户仍然可以选择加载执行列表，但配置文件和战斗文件都将可以独立选择。

基础执行逻辑和简单模式一致，但是允许玩家覆写其中的部分配置项：

1. 战斗失败尝试次数可以自定义，默认值为3次。
2. 隐藏模式变为强制战斗模式，用于给作业编写者测试执行列表的稳定性，这一模式下同样会无视材料刷取情况，但战斗失败的尝试次数由玩家自行定义。
3. 刷开局尝试次数可以自定义，我在想这个是否应该和战斗失败重试次数合并，但想了想两者是不一样的东西，应该独立。

用户在高级模式下完成战斗后，可以将当前的配置打包成执行列表并发布，执行列表的可行性是否需要经过使用测试后面可以再讨论。

文件逻辑

配置文件 core.json

配置文件
 ├─文档说明
 │ ├─作者
 │ ├─简要介绍
 │ └─兼容性说明
 │   └─在怎样的情况下你可以跳过检测执行文件
 ├─基本信息字段
 │ ├─标题 / 名字
 │ ├─最低需求版本
 │ ├─适用地图
 │ └─可选替换配置，当前配置检测失败时尝试更换的对象，替换后应当不会影响目标作业的识别，但执行可能出错。
 ├─开局配置（勾选跳过检测时会跳过这部分内容，不写时默认跳过）
 │ ├─调配策略
 │ ├─战术装备选择
 │ └─起始配队
 │   ├─核，不可替换，找不到且无法通过助战选择时报错退出
 │   ├─辅助核，找不到对应干员时选择同职业高优先级的卡
 │   └─占位符，仅指定职业和选择逻辑
 ├─干员配置（核会在战斗文件中占据指定的部署位置，而辅助核默认不分配部署位置，只作为过牌使用）
 │ ├─核
 │ │ ├─战斗标记，不填时默认记录为干员名字
 │ │ │ └─如果使用战斗标记的话，将允许配置检测失败时使用另一套在作业上完全兼容的配置文件。PS：也就是不支持替换次要核心。
 │ │ ├─基本信息，名字、技能逻辑、练度需求等与常规作业一致的内容
 │ │ ├─最终装备状态，无论实际需求，请按需求顺序写满 5 层，实际使用时根据实时需求进行截尾无序判断
 │ │ │ └─最终等级需求，在条件允许的情况下可以偷偷多叠几层，但如果进行了部署配置的要求，则以最终等级需求为准。
 │ │ │   如红蒂定义为 0 级需求，但实际可能会贪个 2 级术师装备，这样可能可以提高通关稳定性，但优先级低于未满足需求的核。
 │ │ ├─部署位置，相对判定，MAA 不再进行子职业判定，请手动写，默认为与默认位置相同，如多萝西需要定义为相反，温蒂则为无限制
 │ │ ├─高频技能优化，可选，默认不优化
 │ │ └─是否做垫子，默认不做
 │ └─辅助核：被标记的辅助核不一定要在开局被选取，也可在道中被选取
 │   ├─战斗标记，不填时默认记录为干员名字
 │   ├─基本信息，但仅包含ID，精二检测，技能选择
 │   ├─技能使用逻辑
 │   │ ├─使用次数
 │   │ └─技能长度，避免技能刚开就被过卡，想让过载打完的话就选择0次，25秒
 │   ├─临时终端判断，如果设置为临时终端，则在出现下一张临时终端，或满足生成终端前不进行使用
 │   └─特殊链接：辅助 / 陷阱师，召唤物需要作为独立的辅助核被定义并使用
 ├─道中选卡逻辑
 │ ├─主逻辑：练度优先 / 费用优先
 │ │ └─不管选择哪个，都遵循 未满工具卡[0] > 辅助[1] > 非刚需工具卡[2] > 已满工具卡[3] > 特种A[4] > 其他 的判断逻辑
 │ │   非刚需工具卡指超出最终等级需求的已定义装备，比如 2先锋 泥岩状态下的更多先锋
 │ └─追加逻辑：用于在道中抓特定卡，提高通关可行性，可以有多条
 │   ├─优先级：执行该判断相较主逻辑的优先级顺序，数字相同时优先判断追加
 │   ├─最大生效楼层：默认 8，超过之后不再考虑抓 ta
 │   └─练度判断：只支持精英化等级判断，不满足时不生效
 ├─导能单元选择逻辑
 │ └─按优先级列出来，然后写个数量就行，进行顺序判断
 │    默认值：战备2 > 改派2 > 预备2 > 休整2 > 召回2
 │    允许的写法：战备1 > 改派1 > 战备1
 │    二者在判断上的执行逻辑不一样
 └─辅助与单元抽卡 / 单元删卡顺序判定
     内置逻辑为：核不删，未用完的工具卡不删
                先抽核，再抽工具卡，再抽特种，再抽辅助，没有就随缘

具体文档等到时候再写

战斗文件 LT[n].json

战斗文件
 ├─绑定信息
 │ ├─配置文件识别字段
 │ ├─LT[4] 判断（决定是否进行战术装备检测，也可以core内自动化支持）
 │ └─是否存在卡组污染（钢铁萝卜矿区）
 ├─默认设置（可以被高级模式的输入数据覆盖）
 │ ├─战斗失败尝试次数
 │ └─最大刷开局次数（开局刷不出来提示换作业或者升级）
 ├─刷开局设置
 │ │ ╰─流程包括初始检查、洗牌、首轮抽牌，三步执行完毕后算作开局完成
 │ ├─最低需求，三步执行完成后仍不满足时重开
 │ │   ╰─应当允许设置多套配置，但理论上不需要超过 3 套，按顺序选择即可
 │ └─留卡顺序，在洗牌之前，根据预设配置按顺序保留手牌，然后剩下的洗牌0~4张
 │   │ ╰─在没有额外标记时，按照辅助、特种、医疗、重装、近卫、术师、狙击、先锋的顺序进行弃牌
 │   ├─必留牌，一定不会被洗掉的牌，请不要设置过高的值，建议设置为开局出核的最小公约数
 │   └─可留牌，在弃牌数不足 4 时，从这系列中倒序弃牌
 ├─基础布局
 │ │ ╰─核心部署在无限制的前提下，MAA 会进行不断尝试直到核心满级，可选部署逻辑不一定会生效，且依赖后续调用使用
 │ ├─核心部署位置（对象组）
 │ │ ├─核心识别名
 │ │ ├─部署坐标
 │ │ ├─部署朝向
 │ │ └─最大等级覆写（覆盖战斗配置中的最大装备等级）
 │ ├─可选部署逻辑
 │ │ │ ╰─如果需要干员支持装备等级，请以核心形式部署，同一核心如需支持多核请分别单列配置并作为兼容项处理
 │ │ ├─可用辅助核识别表（支持多目标，但只能按顺序生效一个精二对象）
 │ │ ├─部署坐标
 │ │ └─部署朝向
 ├─战斗流程 Round[1]
 │ │ ╰─支持留空，有三个波次，如果第一个波次完成了所有的任务，后面的波次就可以留空不进行任何操作
 │ ├─技能闲置时间，适用于技能开启设置为自动使用的角色，目的是避免波次开始时空放技能，不影响叠卡与部署干员的操作
 │ ├─屏蔽部署，被屏蔽的核会尝试堆叠，但在其他任务完成前不会进行堆叠，且不会将最终核心进行部署
 │ │ └─核心识别名
 │ ├─优先目标，在未被标记屏蔽的核心中，会优先占用可用的升级卡
 │ │ └─核心识别名
 │ └─特殊操作，仅在当前手牌存在对应干员时触发，如铃兰开 3 技能，灵知开 3 技能等
 ├─战斗流程 Round[2]
 └─战斗流程 Round[3]

简单说一下，战斗文件包括三个部分：

1. 开局
2. 辅助 B 使用逻辑
3. 战斗流程

战斗流程部分简单概括就是：

1. 为每个核分配一个固定的坑，在坑上按配置文件记录的逻辑叠工具卡
2. 每个波次作为一个执行区块，同一执行区块内的操作为动态执行判断，允许二选一操作，允许交替执行（考虑）。
3. 可以指定特定操作执行的判定时间，比如当前波次结束时操作，或者当前波次开始时操作，这是针对一些不需要叠满，但贪装备可以提高稳定性的核来使用的。
4. 对一些辅助核的操作可以进行额外定义，不存在相应辅助核时自动无视相关操作。
5. 还有一些和波次相关的独立定义信息，比如波次开启时，技能的延后开启、保存技能等，具体怎么支持到时候再慢慢讨论

文档格式

待更新

代码实现逻辑

待更新与讨论

[YipKei]

更新了战斗文件逻辑树