IcdpwGeP2ixZqSkNpmOcy8hInXc

Source: https://dianchukeji.feishu.cn/wiki/IcdpwGeP2ixZqSkNpmOcy8hInXc

一.工作内容概述

分析《佛系消消消》的关卡系统逻辑，并以此作为参考，对项目现有关卡系统进行重构；
将解包提取出的关卡数据完整迁移至重构后的关卡库中，作为项目关卡内容填充；
制作并接入加载场景界面，完善场景切换过程中的过渡体验。

二.《佛系消消消》关卡系统逻辑

在完成《佛系消消消》关卡数据提取后，今日进一步梳理了其关卡系统的组织方式和运行逻辑。整体来看，它并不是简单采用“第几关对应一个关卡文件”的存储方式，而是通过分层结构来管理不同模式下的关卡选择、索引映射和资源加载。从逻辑上看，《佛系消消消》的关卡系统大致可以拆成三层：玩法编排层、模式索引层、资源定位与数据存储层。

玩法编排层

主要负责决定当前要进入哪一类关卡。不同模式不会直接读取具体关卡文件，而是先根据当前游戏状态选择关卡。例如，普通模式根据主线进度选择关卡；每日挑战根据日期索引选择关卡；生存模式则根据当前波次、难度组或关卡池规则选择关卡。这一层更关注玩法规则和关卡投放逻辑，而不是具体资源路径。

模式索引层

主要负责把“玩法层选中的关卡”转换成稳定的 resourceId。这里会用到 LevelId、LevelPoolGroups、DailyLevel、DoubleBullLevel、SurvivalLevel 等索引表。resourceId 可以理解为关卡资源的稳定编号，它和玩家看到的显示关卡号是解耦的。例如玩家看到的是第 100 关，但底层真正加载的是某个 resourceId 对应的资源。这样后续即使要插入关卡、调整顺序、复用关卡或做关卡池循环，也不容易影响已有进度。从实际提取的数据看，各索引表的分工比较清晰：LevelId 负责前 200 个主线关卡映射；LevelPoolGroups 负责 201 关之后的主线关卡池化；DailyLevel 负责每日挑战关卡循环；DoubleBullLevel 负责双牛模式；SurvivalLevel 则按波次和难度组维护关卡池。也就是说，不同玩法虽然有不同的选关规则，但最终都会统一落到 resourceId 上。

资源定位与数据存储层

resourceId 会继续通过 LevelJsonBatchMap 查询到具体资源位置，包括 bundle 名称、chunk 文件名和棋盘尺寸等信息。BatchMap 相当于一张总资源定位表，覆盖 Normal 和 DoubleBull 两种模式的全部关卡。真正的关卡数据则存放在 LevelPartXX.json、DoubleBullXX.json 这类分包文件中。具体数据上，Normal 模式共提取到 3296 关，按 LevelPart01–33 拆分；DoubleBull 模式共 856 关，按 DoubleBull01–09 拆分。每个 chunk 通常存放约 100 关，内部再通过 levels 数组保存具体 LevelData。每条 LevelData 中包含 resourceId、棋盘大小、区域划分、种子坐标等运行时需要的数据。这种结构的核心特点是：玩法选择、关卡索引和资源存储三者分离。玩法层只关心当前要玩什么，索引层负责把玩法需求转换成稳定资源编号，资源层再根据编号定位并加载具体数据。这种设计带来的好处也比较明显：

显示关卡号和真实资源编号分离，方便后续插入、重排和复用关卡；
多个关卡合并成 chunk 存储，减少大量单关文件带来的管理成本；
通过 BatchMap 统一定位资源，不同玩法可以复用同一套底层关卡数据；
每日挑战、生存模式等玩法可以引用已有主线关卡，减少重复数据；
生存模式可以通过关卡池和难度组进行抽取，便于控制渐进难度；
配合 Addressables 或远程资源加载，可以减少首包体积，后续按需下载。这次分析的价值不只是拿到了关卡数据，更重要的是学习了上线项目在关卡数量增长、多模式复用、包体控制和后续扩展方面的组织方式。相比把所有关卡直接堆在 resources 目录中，这种“模式索引 + 稳定 resourceId + BatchMap 定位 + 分包 chunk 存储”的结构，更适合长期维护和持续扩展。

三.项目关卡系统逻辑重构

在分析完《佛系消消消》的关卡系统后，今日也同步对当前项目的关卡存储和加载逻辑进行了重构。本次重构的目标不是单纯替换一批关卡数据，而是将项目原本较直接的资源读取方式，调整为更适合长期维护的分层式关卡管理结构。原先项目中的关卡资源更偏向按玩法目录分别存放，例如普通关卡、每日关卡、双牛模式、生存模式各自维护一套资源目录。这种方式在关卡数量较少时比较直观，但随着关卡数量增加、玩法模式变多，会逐渐出现几个问题：

不同模式之间难以复用关卡数据，容易产生重复资源；
显示关卡号和真实关卡文件绑定过紧，后续插入或重排关卡容易影响已有进度；
所有关卡都放在 resources 下，不利于后续做小游戏分包、远程加载或按需加载；加载逻辑也分散在不同调用方中，维护成本会变高。因此，本次重构参考《佛系消消消》的组织方式，将项目关卡系统调整为“玩法索引 + resourceId + BatchMap + bundle chunk”的结构。

新增统一索引表

项目中加入了 LevelId、LevelPoolGroups、DailyLevel、DoubleBullLevel、SurvivalLevel、LevelJsonBatchMap 六张 JSON 表。其中，前几张表负责不同玩法模式下的关卡选择和 resourceId 映射，LevelJsonBatchMap 则负责根据 resourceId 统一定位资源所在的 bundle、chunk 和棋盘尺寸。这样以后无论是普通模式、每日挑战、双牛模式，还是生存模式，都可以走同一套底层资源定位逻辑。

新增 bundle 数据目录

关卡数据不再按照旧的 resources 目录零散存放，而是迁移 leveldata_normal、leveldata_doublebull 等 bundle 目录中，并按照 LevelPartXX、DoubleBullXX 这种 chunk 方式组织。当前 Normal 模式共 3296 关，DoubleBull 模式共 856 关，合计 4152 条关卡资源定位记录。这样的结构天然适合后续做小游戏分包，也为远程加载、云端关卡更新和资源热更新预留了空间。

重构 LevelRepository

它现在作为关卡系统的统一入口，负责把上层玩法需求转换成具体关卡数据。整体流程可以概括为：先加载索引表，再根据玩法类型解析 resourceId，接着通过 BatchMap 定位关卡所在的 bundle 和 chunk，最后加载 JSON 数据并取出对应的 LevelData。为了减少重复加载，LevelRepository 内部还加入了多级缓存机制，包括 bundle 缓存、chunk 缓存和单关数据缓存。这样同一个 bundle 或同一个 chunk 被多次访问时，不需要反复读取资源，可以降低运行时加载开销。对调用方来说，玩法逻辑不再需要关心某一关具体存放在哪个文件里，只需要告诉 LevelRepository 当前要加载普通第几关、每日哪一天、双牛哪一关，或者生存模式第几波即可。

同步适配各玩法调用方

主线和双鸡模式通过 LevelRepository 加载对应 displayLevel；每日挑战根据基准日期计算 dayIndex 后加载每日关卡；生存模式根据当前 wave 从对应难度组中抽取关卡。这样四种模式虽然选关规则不同，但最终都统一到同一套资源解析和加载流程中。目前新的关卡 bundle 结构、索引表和 LevelRepository 加载链路已经接入项目，旧的关卡目录也已经清理。整体来看，项目关卡系统已经从“按目录直接读取资源”的方式，升级成了更完整的“索引驱动 + 分包加载 + 统一仓库管理”结构。短期来看，这次重构主要解决了外部关卡迁移、多模式加载和资源组织混乱的问题。长期来看，它为后续关卡扩展、小游戏分包、云端关卡下发、资源热更新，以及不同玩法复用同一批关卡数据打下了基础。

四.后续规划

制作新手教程，帮助玩家理解基础规则、操作方式和关卡目标，降低首次进入游戏时的理解成本；
制作设置面板，并接入音效、音乐、震动等相关开关逻辑，补齐基础系统功能；
利用 AI 生成适合当前美术风格和玩法节奏的音效资源，并配置到按钮点击、关卡反馈、胜利结算等关键交互中；
接入广告 SDK，完善看广告体力恢复、复活、多倍奖励获取等功能的完整链路；
使用云服务制作简单的云存档逻辑，优先保障玩家账号数据和关卡进度能够在云端保存，降低设备更换或本地数据丢失带来的影响。

8.7 KiB Raw Blame History Unescape Escape