Evilom
9.9 KiB
FYKlwX7D5ibbmSkaVMucgKAWnOe
Source: https://dianchukeji.feishu.cn/wiki/FYKlwX7D5ibbmSkaVMucgKAWnOe
一.工作内容概述
- 使用 AI 分析《佛系消消消》的资源分包加载机制，结合本地缓存、运行日志和 Addressables catalog 文件，解析出关卡分包对应的 CDN bundle 地址，批量拉取主线 33 个关卡资源包并完成解包解析，提取主线普通关卡 3296 关，连同双牛模式、方块模式，总计整理 4452 关独立关卡数据。
- 优化关卡生成器逻辑，提升其产出交付合规关卡的稳定性
- 参与AI游戏开发交流会
二.《佛系消消消》关卡数据提取
利用AI对手机本地的《佛系消消消》包体资源进行了逆向分析和提取，目标是获取游戏中的完整关卡数据，并理解其关卡文件组织方式和加载逻辑。 前期已经通过解包确认，主包中只内置了第一批关卡 LevelPart01，后续 LevelPart02-33 并没有直接存在于本地包体中。后续继续通过逆向解包、日志分析、本地缓存检查和 catalog 解析的方式，最终整理出游戏远程关卡分包的真实下载链路。
试错过程概述
一开始尝试从几个方向直接查找关卡数据：
- 逆向解包主包，搜索 LevelPart02-33；
- 检查本地缓存目录，寻找已下载的分包文件；
- 尝试抓包观察游戏运行时的资源请求；
- 直接猜测服务器接口或资源路径。 但这些方式都没有直接得到完整关卡。 主要原因是： 因此后续思路调整为：不再直接搜索关卡文件，而是先还原游戏的远程资源加载链路。
最终提取流程
逆向解包主包，确认资源不完整
首先对游戏主包和 Unity 资源文件进行逆向解包分析。 解包后发现，主包中确实存在部分关卡文本和配置表，例如 LevelPart01、LevelJsonBatchMap、LevelId、DailyLevel 等。 但同时也确认了一点：主包中只注册和内置了第一批关卡，后续 LevelPart02-33 并不在主包内。 这说明完整关卡数据不是一次性打进本地包体，而是采用远程分包加载方式。
分析运行日志，寻找 CDN 入口
确认主包中没有完整关卡后，下一步转向运行日志。 运行日志中记录了游戏启动和加载资源时的一些路径、版本号和远程地址。 虽然日志不会直接列出全部关卡文件，但可能会暴露远程资源系统的入口。 这次在日志中找到了关键线索：游戏使用的是 Unity Addressables 远程资源加载机制，并且日志中出现了 CDN 上的 settings.json 地址。 可以把 settings.json 理解为远程资源系统的“入口说明书”。它主要告诉游戏：
- 当前资源版本是多少
- 资源目录在哪里
- 后续 catalog 应该怎么加载
有了 CDN 入口后，后续就不需要继续盲猜，而是可以顺着资源加载链路继续追踪。
确认资源版本，定位 catalog
远程资源通常会按版本管理。
如果版本号不对，即使 CDN 路径正确，也可能找不到对应资源。
通过日志和本地 hash 文件整理后，确认当前有效资源版本是 0.0.106。
接下来根据资源版本继续寻找 catalog 文件。
这里可以把几个文件的关系理解为：
- settings.json = 入口说明书
- catalog = 资源目录
- bundle = 真正的资源包
- LevelPart = 关卡内容 其中，catalog 是最关键的一环。 它本身不直接保存关卡内容，但会记录每个资源分包的真实 CDN 下载地址。
结合本地缓存与运行日志，确认 catalog 版本
这一步是本次提取流程的核心突破。 前期已经确认游戏使用 Addressables 远程资源加载机制。后续结合运行日志和本地缓存目录中的 catalog hash 文件，确认当前有效资源版本为 0.0.106，并整理出对应的 catalog_0.0.106.json。 catalog 本身不直接保存关卡内容，但会记录资源路径与对应的 bundle 下载地址。拿到 catalog 后，就可以从中解析出 LevelPart分包在 CDN 上的真实下载链接。 也就是说，本地缓存和日志提供了 catalog 版本与资源目录线索，catalog 文件进一步提供了后续批量下载关卡 bundle 所需的 CDN地址。
解析 catalog，提取所有关卡分包地址
拿到 catalog 后，继续解析其中的资源记录。 catalog 可以理解为一张资源索引表，里面记录了：
- 资源名称
- 资源类型
- 资源所在分包
- 分包的 CDN 下载地址 通过解析 catalog，找到了三类关卡分包：
- Normal 主线关卡分包；
- DoubleBull 双牛模式关卡分包；
- Block 方块模式关卡分包。
其中主线普通关卡一共有 33 个 LevelPart 分包。
批量下载 CDN 上的关卡分包
解析出所有 bundle 地址后，就可以按 catalog 中记录的 CDN 链接批量下载关卡分包。 最终下载到三组资源：
- 主线关卡：LevelPart01.bundle ~ LevelPart33.bundle
- 双牛关卡：DoubleBull01.bundle ~ DoubleBull09.bundle
- 方块关卡：Block01.bundle ~ Block03.bundle 这些 .bundle 文件可以理解为 Unity 打包后的资源箱，里面还不是直接可读的关卡文本，需要继续解包。
解包 bundle，提取关卡文本
下载下来的 bundle 继续使用 Unity 资源解析工具进行解包。
解包后，从里面提取出真正的关卡文本，并保存为json文件。
到这一步，关卡数据已经从“远程 Unity 资源包”变成了可以直接分析的文本数据。
对比 ResourceId，确认数据完整
提取出文本后，还需要确认数据是否完整。 游戏中每个关卡都有一个 ResourceId，可以理解为关卡的唯一编号。 通过对比主包中的映射表和提取出的分包文本，确认这些关卡编号能够对应上。 最终确认：
[嵌入电子表格: H9qosRTUMhbxf4toGVpc...]
总计 4452 关独立关卡数据。
三.AI游戏开发交流会相关收获
明确 AI 的使用边界
本次交流中，一个比较核心的启发是：AI 更适合承担“讨论、生成、启发、辅助分析”这类不确定性较高的工作，而不适合直接负责强确定性的执行环节。 例如在配表问题中，AI 可以帮助讨论数值节奏、字段结构、关卡难度曲线等设计思路，但如果直接让 AI 批量填写具体数值，就容易出现漏填、错填、跳号等问题，而且这种错误往往不容易被肉眼发现。 这和我之前使用 AI 生成关卡、生成 UI 资源时遇到的问题有相似之处：AI 的结果有时看起来是对的，但如果没有校验机制，就很难判断它是否真正可用。 因此后续使用 AI 时，需要更加明确区分：
- 创意和方案讨论可以交给 AI 辅助；
- 精确计算、批量填充、资源切分、数据校验等环节，应优先交给脚本或确定性工具；
- AI 输出的内容必须经过人工理解和规则校验，不能只看表面效果。 这点对后续关卡配置、资源批处理、数值表整理都有较强参考意义。
AI 生成风格要先验证可复现性
本次交流中另一个重要启发是：AI 生成出来一张好看的图，并不等于这个风格可以用于项目。对于游戏 UI 来说，真正重要的是稳定复现能力。 之前在项目美术探索中也遇到过类似问题：某一次生成的角色或界面效果很好，但后续继续生成按钮、弹窗、图标、棋盘格时，很难保持同样风格。如果风格不可复现，后续资产越多，维护成本越高。 因此后续确认美术风格时，不能只看单张效果图，而应该增加一个验证步骤：
- 先生成 2-3 个核心界面或核心组件；
- 再生成按钮、弹窗、图标、棋盘格等不同类型资产；
- 连续多次测试风格是否稳定；
- 如果风格波动很大，即使第一张效果很好，也要谨慎采用。 这对当前项目后续继续补充 UI 资产、活动弹窗、商店界面、皮肤界面等内容都有帮助。相比追求单张图惊艳，更应该选择 AI 稳定擅长、可持续批量产出的风格方向。
云存档和服务端可以先按“弱联网”思路评估
关于存档和云服务的讨论，也解决了我之前的一个疑问：当前项目是单机小游戏，是否需要现在就接入云存档。 这次交流后，我的理解是：是否需要服务端，主要取决于两个问题：
- 是否需要跨设备保留数据；
- 是否需要防作弊或服务端校验。 如果只是单机体验，短期可以继续本地存档。但如果后续涉及账号数据、体力、道具、签到、皮肤、付费、排行榜等内容，就需要考虑至少做弱联网方案。 现阶段比较适合的思路是：
- 本地存档继续作为基础；
- 关键数据预留云端同步结构；
- 体力、道具、皮肤等可在后续做云端备份；
- 涉及支付、排行榜、防作弊时再引入更完整的服务端校验；
- 存档迁移时允许玩家在本地和云端之间选择。 这对后续项目规划有帮助。短期不一定马上接入完整服务端，但需要在存档结构设计时预留扩展空间，避免后面重构成本过高。