chore:文档补全
This commit is contained in:
Evilom
@@ -0,0 +1,128 @@
|
||||
# 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 稳定擅长、可持续批量产出的风格方向。
|
||||
## 云存档和服务端可以先按“弱联网”思路评估
|
||||
关于存档和云服务的讨论，也解决了我之前的一个疑问：当前项目是单机小游戏，是否需要现在就接入云存档。
|
||||
这次交流后，我的理解是：是否需要服务端，主要取决于两个问题：
|
||||
- 是否需要跨设备保留数据；
|
||||
- 是否需要防作弊或服务端校验。
|
||||
如果只是单机体验，短期可以继续本地存档。但如果后续涉及账号数据、体力、道具、签到、皮肤、付费、排行榜等内容，就需要考虑至少做弱联网方案。
|
||||
现阶段比较适合的思路是：
|
||||
- 本地存档继续作为基础；
|
||||
- 关键数据预留云端同步结构；
|
||||
- 体力、道具、皮肤等可在后续做云端备份；
|
||||
- 涉及支付、排行榜、防作弊时再引入更完整的服务端校验；
|
||||
- 存档迁移时允许玩家在本地和云端之间选择。
|
||||
这对后续项目规划有帮助。短期不一定马上接入完整服务端，但需要在存档结构设计时预留扩展空间，避免后面重构成本过高。
|
||||
Reference in New Issue
Block a user