Evilom
8.1 KiB
Hv4uwS6U9iqN1skMIKIczOgAnKb
Source: https://dianchukeji.feishu.cn/wiki/Hv4uwS6U9iqN1skMIKIczOgAnKb
一.工作内容概述
- 基本完成项目主要系统界面的多分辨率适配逻辑梳理与落地调整。
- 尝试使用 OpenClaw 自动收集整理抖音平台上《佛系消消消》的关卡数据，并验证视频反向提取方案的可行性。
二.多分辨率适配相关
经过一天的尝试、排查和反复验证，基本完成了当前项目各主要系统的 UI 适配逻辑梳理，包括局内界面、主菜单、碎片收集面板、结算弹窗、通用弹窗、背景层以及部分特殊交互节点的适配处理。 本次适配工作的重点不只是修复单个界面的显示问题，而是对项目整体 UI 结构进行了一次重新整理。由于早期 UI 制作阶段没有针对多分辨率适配制定统一层级规范，部分界面中背景、内容、按钮、弹窗、交互区域混在同一套节点层级中，导致后续适配时容易出现互相影响的问题。 因此今日在实际试错的基础上，基本完成主要系统的适配逻辑梳理与落地调整，并总结出一套后续可以继续沿用的 UI 层级规范和适配思路。
最终确定的 UI 层级规范与适配思路
当前阶段确定的整体原则是：背景独立处理，内容按区域分组，交互节点单独维护，弹窗使用独立规则。
UI 层级规范
统一按照背景层、顶部区域、主内容区域、底部操作区域、弹窗层进行组织，不同层级分别承担铺满、展示、交互和覆盖职责，避免所有节点共用同一套缩放链路。 这种分层方式可以让不同类型的 UI 使用不同适配策略，避免背景、内容、交互和弹窗互相影响，降低后续维护成本。
适配思路
- **背景层：**采用独立铺满策略，根据实际可见区域动态拉伸，保证不同屏幕比例下不会出现留白或裁切。
- **普通 UI 内容：**优先按照功能区域进行分组，例如顶部组、内容组、底部组。运行时主要调整分组容器的位置和缩放，尽量保留编辑器中已经确定好的子节点相对关系，避免代码逐个硬编码子节点坐标。
- **棋盘网格、可点击格子等带有交互逻辑的节点：**需要单独维护适配逻辑。此类节点不能简单跟随父级整体缩放，否则可能导致视觉位置和点击命中区域不一致。
- **弹窗类 UI：**不直接套用主场景适配规则。弹窗的目标是完整显示、居中展示和保证可交互，因此统一采用遮罩铺满、主体居中、超框缩小的方向。
思考与复盘
通过今天的适配工作，比较明确地暴露出前期 UI 结构上的问题：如果一开始没有制定层级规范，后期再做多分辨率适配时，就大概率需要付出额外的节点层级调整工作，以符合适配方案需求。 之前部分界面的问题，本质上不是某一个节点位置不对，而是背景、内容、按钮、弹窗、交互区域之间缺少清晰边界。不同节点共用同一父级、同一缩放逻辑或同一布局方式后，在宽屏、长屏、低分辨率设备上就容易出现连锁问题。 因此后续新界面制作时，需要在 UI 搭建阶段就提前考虑适配规则，而不是等界面完成后再补适配逻辑。合理的做法是先确定层级，再确定每一层的适配方式，最后再处理具体节点细节。
阶段成果
已经基本完成当前项目主要系统的 UI 适配逻辑整理，并形成了较清晰的通用规范。后续将基于这套规范继续进行不同屏幕比例下的集中验证，并对少量边缘界面进行补充复查。
三.OpenClaw关卡数据采集相关
尝试使用 OpenClaw 对抖音《佛系消消消》相关的视频里的关卡盘面进行采集，目标是持续收集并维护关卡库，用于后续辅助分析其关卡难度分布以及验证求解器的兼容性。
采集方案尝试
最初考虑通过 Agent 直接操作微信或抖音小游戏进行自动化采集，使用模拟器配合 ADB 进入游戏、截图、识别棋盘并导出数据。 但实际尝试后发现，微信和抖音对模拟器存在较多限制，很难在模拟器里登录这两个应用。因此今日改为尝试另一条路线：从抖音视频平台搜索《佛系消消消》每日挑战相关视频，通过视频帧反向提取关卡数据。 这一路线的大致思路是：
- 使用 OpenClaw 接入浏览器环境；
- 通过 MediaCrawler 搜索“佛系消消消 每日挑战”相关视频；
- 从视频中截取包含完整棋盘的帧；
- 通过图像识别分析棋盘颜色区域；
- 最终整理为 regionIds 数组和截图样本。 今日已完成了视频搜索链路的初步验证，MediaCrawler 能够正常接入抖音网页环境，并获取到一批相关视频候选结果。但后续在具体关卡提取阶段暴露出较多问题。
实际测试问题
实际测试下来，视频采集路线的稳定性和效率都不理想。 首先，Agent 很难稳定从视频帧中正确识别完整关卡结构。视频中的棋盘往往受到清晰度、压缩、遮挡、操作进度、画面缩放、颜色相近区域等因素影响，即使截取到了包含棋盘的画面，也不代表能够准确还原出 12×12 的颜色区域分布。 其次，图像分析过程经常出现读取超时或识别中断。单个视频从搜索、定位有效片段、截帧、识别、校验到整理数据，流程较长，中间任何一步失败都会导致整条链路需要重新尝试。 另外，Agent 对视频内容的理解仍然不够稳定。它可以辅助筛选和分析画面，但还不能可靠判断哪一帧是“初始完整棋盘”，也不能稳定区分棋盘区域、颜色区域边界和游戏内其他 UI 元素。 因此目前测试结果是：单个视频关卡的成功提取率较低，且耗时过长，不适合作为当前阶段的主要批量采集方案。
思考与复盘
本次尝试的主要价值在于验证了“从视频平台反向采集竞品关卡数据”这条路线的可行边界。 相比直接操作小游戏，视频平台采集确实绕开了模拟器和小游戏环境限制，也能更容易获取大量候选素材。但它的问题在于数据源并不结构化，视频画面本身存在大量不确定因素，导致后续识别成本非常高。 尤其对于依赖精确棋盘结构的游戏来说，关卡数据不能只做到“大致识别”，而是需要准确到每一个格子的颜色区域归属。一旦某几个格子识别错误，后续求解器验证和难度分析都会失去意义。 因此，该方案当前只能作为人工辅助采样的补充手段，暂不适合作为主要的自动化采集方案。后续如果继续推进，可以考虑改为半自动流程：由工具负责搜索和截取候选帧，再由人工确认有效盘面，最后辅助生成并校验 regionIds 数据。
四.后续计划
界面适配与美术完善
- 补充遗漏的美术资源，并对已有资源的细节表现进行优化；
- 持续完善 UI 动效、特效和交互反馈，提升整体界面表现力；
- 基于后续测试结果，修复可能遗漏的多分辨率适配问题。 关卡与玩法体验
- 继续探索更稳定的自动化或半自动化关卡数据收集方案；
- 体验《佛系消消消》，总结其关卡设计思路、难度节奏。
- 基于体验和分析结果，重新生成并配置项目关卡；
- 如现有关卡编辑器无法满足后续配置需求，再考虑补充编辑器功能。 平台与真机测试
- 持续进行真机测试，排查不同设备、分辨率和平台环境下的显示与交互问题；
- 结合抖音小游戏环境继续验证构建、运行、存档、广告等平台相关能力；
- 对测试中发现的问题进行记录、分类和阶段性修复。