Evilom
183 lines
12 KiB
Markdown
183 lines
12 KiB
Markdown
# EIWNwKjnIipmStkzIr1cd1kTnPf
|
||
|
||
Source: https://dianchukeji.feishu.cn/wiki/EIWNwKjnIipmStkzIr1cd1kTnPf
|
||
|
||
|
||
# 一.工作内容概述
|
||
- 尝试优化AI自动化关卡生成逻辑
|
||
- 尝试优化自动化关卡截图分析流程
|
||
- 体验《佛系消消消》，补充收集部分关卡样本，作为后续分析参考。
|
||
# 二.关卡生成逻辑优化
|
||
## 目前关卡生成痛点
|
||
目前关卡生成的主要问题集中在高维度关卡，尤其是 10x10、12x12 这类关卡。
|
||
之前的生成方式更偏向先随机生成区域，再通过反复尝试来筛选合适结果。这种方式在低维度关卡上还可以接受，但在高维度关卡上会暴露出几个问题：
|
||
- 很多关卡虽然能生成出来，但并不是唯一解；
|
||
- 有些关卡看起来结构正常，但玩家实际推理时可能无法稳定解出；
|
||
- 通过随机微调区域边界来修复多解问题，成功率很低；
|
||
- 部分备用生成路径虽然能产出关卡，但质量不可控，不适合作为正式发布内容；
|
||
- 原本的难度评估比较粗，只能大致判断关卡是否可解，不能很好反映推理过程到底有多复杂。
|
||
也就是说，当前关卡生成的核心问题不是“能不能生成出来”，而是生成出来的关卡是否满足正式发布要求：
|
||
- 答案是否唯一；
|
||
- 是否能通过逻辑推理解出；
|
||
- 难度是否符合预期；
|
||
- 生成过程是否足够稳定。
|
||
## 优化逻辑
|
||
本次优化的方向，是把关卡生成从“随机尝试”调整为“围绕发布标准进行生成”。
|
||
也就是不再单纯追求生成数量，而是先明确一套正式关卡必须满足的标准：
|
||
- 必须只有一个正确答案；
|
||
- 必须能通过逻辑推理完成；
|
||
- 普通关不能依赖猜测；
|
||
- 高维度关卡允许使用更复杂的推理方式；
|
||
- 备用生成结果不能直接进入正式发布流程；
|
||
- 关卡难度不仅看尺寸和区域数量，也要看实际推理过程。
|
||
同时，对求解器的评分逻辑进行了优化。之前更多是判断“这关能不能解出来”，现在进一步补充**“这关是怎么解出来的”、“用了多复杂的推理步骤”。**
|
||
这样后续就可以更准确地区分：
|
||
- 简单关：通过基础排除就能解出；
|
||
- 中等关：需要结合行、列、区域关系进行判断；
|
||
- 高难关：需要多步推理或组合判断才能解出。
|
||
## 优化步骤
|
||
### 3.1 调整正式生成入口
|
||
将正式生成流程切换到更适合保证唯一解的生成方式。
|
||
之前的生成方式偏随机，适合快速产出候选关卡，但高维度关卡容易出现多解。
|
||
新的生成方式会在生成过程中不断检查并排除错误候选，目标是更稳定地生成只有一个答案的关卡。
|
||
这样做的目的，是优先保证关卡的正确性，再考虑生成效率。
|
||
### 3.2 固化发布标准
|
||
整理并固化了一套正式发布标准：
|
||
- 关卡必须只有一个答案；
|
||
- 关卡必须能被逻辑推理解出；
|
||
- 普通关不允许依赖猜测；
|
||
- 高维度关卡允许使用更高级的逻辑推理，符合关卡定位的同时也能提高生成成功率；
|
||
- 备用生成路径产出的关卡，不直接进入正式发布流程。
|
||
这样可以避免“生成成功”被误认为“可以发布”。
|
||
### 3.3 增加发布审计工具
|
||
新增了关卡发布审计工具，用来自动检查关卡是否符合发布要求。
|
||
它可以检查：
|
||
- 当前关卡是不是唯一解；
|
||
- 是否能被逻辑推理解出；
|
||
- 是否超过允许的推理复杂度；
|
||
- 是否来自不可靠的备用生成路径；
|
||
- 不通过时具体失败原因是什么。
|
||
这样后续批量生成后，可以直接筛选出真正适合发布的关卡。
|
||
### 3.4 优化求解器的策略评分逻辑
|
||
除了判断关卡是否能解出，还进一步记录解题过程中使用了哪些类型的推理方法，以及推理链路有多深。
|
||
可以理解为：
|
||
- 以前只知道： “这关能解。”
|
||
- 现在可以知道：“这关是靠什么样的策略解出来的。”
|
||
这部分优化的价值是：
|
||
- 更准确评估关卡真实难度；
|
||
- 避免只用尺寸或区域数量判断难度；
|
||
- 为后续难度曲线设计和关卡筛选提供依据。
|
||
### 3.5 补充高级推理规则
|
||
针对高维度关卡，补充了一批更复杂的推理规则。
|
||
这些规则主要用于处理一些基础规则无法解决的情况，例如：
|
||
- 某一行、某一列或某个区域中的组合关系；
|
||
- 多个区域之间的容量限制；
|
||
- 某些候选位置会导致矛盾，因此可以被排除。
|
||
这部分优化后，部分原本求解器无法完整解出的 12x12 关卡，现在可以通过逻辑推理完成。
|
||
### 3.6 增加失败原因分析与自动调整
|
||
生成失败时，不再只记录“失败”，而是进一步区分失败原因。
|
||
例如：
|
||
- 是因为答案不唯一；
|
||
- 是因为逻辑推理无法解出；
|
||
- 是因为生成时间超时；
|
||
- 是因为求解过程太复杂。
|
||
根据不同失败原因，再调整对应参数。
|
||
这样生成过程不再是盲目增加次数，而是可以有针对性地优化。
|
||
## 结果测试
|
||
### 4.1 旧生成方案诊断结果
|
||
通过测试确认，旧方案在高维度关卡上生成失败的主要原因是多解。
|
||
在 8x8 / 10x10 / 12x12 测试中，大量失败情况都是因为生成出的关卡不止一个答案。
|
||
同时，随机调整区域边界的修复方式效果也不好，在多组测试中几乎无法稳定修复唯一性问题。
|
||
结论是：旧方案不适合作为正式发布链路的默认生成方式。
|
||
### 4.2 新生成链路测试结果
|
||
切换新的生成链路后，测试结果有明显改善：
|
||
- 8x8：已经比较稳定，可以在较短时间内生成并通过发布检查；
|
||
- 10x10：已经可以生成可发布关卡，但仍需要一定的重试和参数调整；
|
||
- 12x12：已经能生成可发布样本，但成功率还不够稳定。
|
||
目前可以认为：
|
||
- 低维度关卡已经基本稳定；
|
||
- 中等尺寸关卡具备交付能力；
|
||
- 高维度关卡已经跑通流程，但还需要继续优化生成成功率。
|
||
### 4.3 求解器评分测试结果
|
||
优化策略评分后，关卡难度不再只依赖尺寸或区域数量，而是可以结合实际解题过程判断。
|
||
例如，同样是 12x12 关卡：
|
||
- 有些关卡只需要基础规则就能解出；
|
||
- 有些关卡需要行列锁定、区域锁定；
|
||
- 有些关卡需要多步组合推理。
|
||
这让后续难度评估更准确，也方便将关卡分配到普通关、卡点关或每日挑战等不同类型中。
|
||
### 4.4 高级推理规则测试结果
|
||
补充高级推理规则后，对已有样本进行对比测试：
|
||
- 总体逻辑可解覆盖率从 66/68 提升到 68/68；
|
||
- 12x12 关卡覆盖率从 3/5 提升到 5/5；
|
||
- 新规则主要提升的是高维度关卡；
|
||
- 低维度关卡没有明显额外负担。
|
||
这说明新增规则确实解决了一部分高维关卡的求解问题。
|
||
### 4.5 当前剩余问题
|
||
目前关卡生成链路已经从“能不能生成”推进到“能不能稳定批量生成可发布关卡”。
|
||
剩余主要问题是：
|
||
- 12x12 的唯一解生成成功率仍然不稳定；
|
||
- 部分高难关卡需要更复杂的推理策略，难度边界还需要继续评估；
|
||
- 后续需要继续优化高维度关卡的生成效率和稳定性。
|
||
# 三.关卡截图分析流程优化
|
||
## 之前方案
|
||
之前在验证截图关卡时，主要依赖 Agent 的识图能力来识别棋盘中的单元格和颜色区域。
|
||
这种方式的优点是上手快，不需要自己写复杂的图像处理逻辑，只要把截图交给 Agent，就可以让它尝试判断：
|
||
- 棋盘是几乘几；
|
||
- 每个格子是什么颜色；
|
||
- 哪些格子属于同一个区域；
|
||
但实际使用中也暴露出一些问题：
|
||
- 识别结果高度依赖接入的模型能力，不同agent对同一个截图可能会给出不同的结果。
|
||
- 对相近颜色的判断容易出错；
|
||
- 棋盘边缘、阴影、高光、UI 遮挡等因素会影响识别；
|
||
- Agent 的识别过程不够可控，出错后很难精确定位是哪一步出错；
|
||
- 不适合后续接入自动化批量验证流程。
|
||
因此，之前方案更适合临时辅助判断，不适合作为稳定的工具链。
|
||
## 优化思路
|
||
本次优化的方向，是尝试用 OpenCV 替代 Agent 识图，把识别过程拆成更明确、可调试的图像处理步骤。
|
||
新的思路是：
|
||
- 使用 OpenCV 找到棋盘区域，并识别每个单元格的位置；
|
||
- 对每个格子中心区域进行颜色采样
|
||
- 判断哪些格子颜色相同
|
||
- 还原出关卡区域数据
|
||
- 交给求解器验证
|
||
这样做的核心价值是：识别逻辑从“让 Agent 看图判断”变成“用固定算法提取颜色和网格”。
|
||
相比之前方案，OpenCV 方案有几个优势：
|
||
- 识别过程更可控；
|
||
- 每一步都可以输出中间结果进行排查；
|
||
- 颜色采样、阈值、网格识别规则都可以手动调整；
|
||
- 更容易做成批量自动化工具；
|
||
- 出错时可以明确判断是网格识别问题，还是颜色分类问题。
|
||
目前已经尝试实现了一版基于 OpenCV 的识别流程：
|
||
- 通过颜色筛选棋盘色块；
|
||
- 使用轮廓检测定位格子；
|
||
- 根据格子中心点推断完整网格；
|
||
- 采样格子中心区域，减少边框和阴影影响；
|
||
- 根据采样结果对颜色进行分类，将同一颜色的格子归并为同一区域；
|
||
- 最后导出关卡数据，并调用求解器验证唯一性。
|
||
## 目前遇到的问题
|
||
目前 OpenCV 方案已经能在部分截图上跑通，低维度关卡识别效果较好，但在 高维度关卡上还存在颜色误判问题。
|
||
主要问题是：
|
||
游戏内有些区域颜色非常接近，在截图采样后，这些颜色经过量化处理时，可能会被误认为是同一种颜色。
|
||
这样会导致：
|
||
- 原本不同的区域被合并；
|
||
- 还原出的关卡数据和真实截图不一致；
|
||
也就是说，目前 OpenCV 方案的主要瓶颈不是网格定位，而是**相近颜色的稳定区分**。
|
||
后续可以继续从几个方向优化：
|
||
- 提高颜色分类精度，避免不同颜色被合并；
|
||
- 改用更适合区分色相的颜色空间；
|
||
- 对每个格子采样更多像素点，减少阴影和高光影响；
|
||
- 在识别后增加颜色数量校验，发现异常时自动提示。
|
||
目前的阶段性结论是：**OpenCV 方案比 Agent 识图更适合作为长期工具链，但还需要继续优化颜色分类逻辑，尤其是高维度关卡中相近颜色的区分问题。**
|
||
# 四.后续计划
|
||
**界面适配与美术完善**
|
||
- 补充遗漏的美术资源，并对已有资源的细节表现进行优化；
|
||
- 持续完善 UI 动效、特效和交互反馈，提升整体界面表现力；
|
||
- 基于后续测试结果，修复可能遗漏的多分辨率适配问题。
|
||
**关卡与玩法体验**
|
||
- 继续优化自动化关卡截图识别流程，结合体验反馈和样本分析结果，辅助重新规划项目关卡难度曲线，并批量生成、配置对应关卡数据；
|
||
- 继续优化大尺寸关卡的唯一解生成成功率，并结合求解器评分结果，进一步校准不同尺寸、不同难度关卡的生成策略。
|
||
- 继续探索更稳定的自动化或半自动化关卡数据收集方案；
|
||
**平台与真机测试**
|
||
- 持续进行真机测试，排查不同设备、分辨率和平台环境下的显示与交互问题；
|
||
- 结合抖音小游戏环境继续验证构建、运行、存档、广告等平台相关能力；
|
||
- 对测试中发现的问题进行记录、分类和阶段性修复。 |