Initial import of HEROLL source and design documents
This commit is contained in:
toshiocn
@@ -0,0 +1,252 @@
|
||||
# HEROLL 2.0.1 关卡楼层分布与刷新规则逆向报告
|
||||
|
||||
> 仅限本机内部玩法验证。本文描述 HEROLL 2.0.1 的逆向结果，不授予原作代码、配置或美术资源的发行权。
|
||||
|
||||
## 1. 结论摘要
|
||||
|
||||
此前“关卡楼层分布和刷新规则”的任务没有形成独立交付物；本报告补齐该任务，并覆盖旧 GDD 中“每层固定注入 2 个有益地块”等未经闭环的描述。
|
||||
|
||||
### 1.1 两套关卡终局规则
|
||||
|
||||
普通主线共有 52 个启用关卡，分成两类：
|
||||
|
||||
| 规则 | 关卡数 | 配置值 | 实际含义 |
|
||||
|---|---:|---:|---|
|
||||
| `Default` | 33 | 10 / 13 / 15 | 固定楼层数；与 `board.csv` 对应关卡的行数完全一致 |
|
||||
| `DiceGauge` | 19 | 50 | 每次合格的完整落地结算向实时 Boss Gauge 增加 50；不是“50 层”也不是直接阈值 |
|
||||
|
||||
`Default` 关卡的配置分布是：2 个 10 层关、3 个 13 层关、28 个 15 层关。所有 33 个关卡都满足：
|
||||
|
||||
```text
|
||||
bossSpawnRuleValue == board.csv 中该 Normal Stage 的楼层行数
|
||||
loop 索引范围 == 0 .. bossSpawnRuleValue - 1
|
||||
```
|
||||
|
||||
因此第 1 关的权威规则是：`stage=0`、`Default=10`、`loop=0..9`，完成第 10 层后进入 `boss_0`。`board.csv` 的每一行是对应楼层的敌方数值模板，不是地块布局表。
|
||||
|
||||
### 1.2 棋盘不是逐层重建，而是持续变异
|
||||
|
||||
玩家通过起点时进入下一层。换层状态机执行“增加新的有益地块和敌人”，而不是重新生成整张棋盘。官方商店页也明确描述为：每次经过起点，新的敌人与事件会被加入不断变化的棋盘。
|
||||
|
||||
核心调用顺序为：
|
||||
|
||||
```text
|
||||
经过起点 / 完成一圈
|
||||
→ AddNextLoopTiles(loopIndex)
|
||||
→ AddRandomGoodTiles(loopIndex + 2)
|
||||
→ 等待表现完成
|
||||
→ AddRandomEnemyTile(enemyTilesPerLoop, false)
|
||||
→ 等待新增敌人及地块表现完成
|
||||
```
|
||||
|
||||
注意：`loopIndex + 2` 是“有益地块元数据抽取/安装尝试次数”，不是无条件保证最终新增同样数量的可见地块。候选位置不足、地块保护规则或安装失败均可能使最终可见数量较少。
|
||||
|
||||
新局初始化是独立路径：
|
||||
|
||||
```text
|
||||
SpawnInitalTiles
|
||||
→ 执行初始地块生成（内部调用传入常量 3，但被调用方法的参数名未恢复）
|
||||
|
||||
InitNewGame
|
||||
→ SpawnInitalTiles
|
||||
→ SpawnAllCornerTiles
|
||||
→ AddRandomGoodTiles(8)
|
||||
```
|
||||
|
||||
`enemyTilesPerLoop` 是 `BoardController` 的序列化字段；本次 APK 表和已导出的场景资料没有恢复它的原始序列化数值。初始状态机中的常量 3 也不能在缺少方法参数名时直接等同为“3 个敌人”。因此可以准确实现调用结构，但不能把 3 或其他猜测值写成原作每层敌人数常量。
|
||||
|
||||
### 1.3 玩家有益地块不是固定事件池
|
||||
|
||||
`AddRandomGoodTiles(N)` 从玩家当前可用/装备的 `OutGameTile` 元数据牌组取 N 次，而不是直接从 `newtile.csv` 的全部 `GoodEvent` 等权抽取。
|
||||
|
||||
牌组规则已经从 `GetNextMetadata` 闭合：
|
||||
|
||||
1. 缓存 `_shuffledDeck` 与 `_currentDeckIndex`。
|
||||
2. 牌组为空或索引到尾时，以当前玩家可用的局外地块列表重建并洗牌，索引归零。
|
||||
3. 每次返回当前索引的一个元数据，然后索引加一。
|
||||
4. 因而同一轮牌组内不重复；请求次数超过牌组大小时会重新洗牌，跨轮可能再次抽到同类地块。
|
||||
5. 抽到的 `OutGameTile.refNewTileId` 再映射到 `NewTile`，播放 `PlayGoodFX` 并调用 `AddTileActEvent` 安装。
|
||||
|
||||
新账号有 8 个 `defaultEquip=True` 的稀有地块，刚好对应初始化的 8 次抽取：铁匠铺、恢复、传奇装备、英雄体、宝箱、抓娃娃、泡泡龙和 Spito。完整表见 `tables/default-good-tile-deck.csv`。
|
||||
|
||||
这意味着第 1 层初始化时，在牌组和位置均有效的前提下，默认 8 张会各抽到一次。后续层的抽取次数随传入的零基 `loopIndex` 增长。若 UI 楼层 `F` 以 1 开始，常规换层调用对应 `loopIndex=F-1`，则进入该层时的尝试数为 `F+1`；第 1 层仍走独立的固定 8 次初始化路径。
|
||||
|
||||
### 1.4 自然生成地块的资格过滤
|
||||
|
||||
`newtile.csv` 的关键字段含义由表头与运行时消费共同确认：
|
||||
|
||||
| 字段 | 规则 |
|
||||
|---|---|
|
||||
| `isEnabled` | 是否允许进入自然生成候选 |
|
||||
| `minStage` | 最低主线 Stage |
|
||||
| `minLoop` | 最低零基 Loop（楼层门槛） |
|
||||
| `ETileTypeV2` | Empty / NormalEnemy / GoodEvent / BadEvent / BossAttack / Corner 等分类 |
|
||||
| `maxCornerPerGame` | 单局同类角落地块上限；`-1` 表示该字段不设限 |
|
||||
|
||||
Stage 0 的自然候选在 `loop=0` 已包含 4 类普通敌人、6 类 GoodEvent、3 类 BadEvent、5 类 Corner、祝福、空地等；`loop=3` 解锁黑市、传送、彩票、21 点、Power Star、Dice Machine、泡泡龙，`loop=5` 解锁 Dice Catapult。`GoodEventGoldCarriage` 与 `GoodEventSpito` 还要求 `minStage=1`，因此不应在第 1 关自然生成。
|
||||
|
||||
这里必须区分两条入口：
|
||||
|
||||
- 自然生成：受 `newtile.isEnabled/minStage/minLoop` 过滤。
|
||||
- 玩家有益地块注入：以当前 `OutGameTile` 牌组及 `refNewTileId` 为源，再由安装位置保护规则决定能否落盘。
|
||||
|
||||
完整资格表见 `tables/enabled-tile-eligibility.csv`。
|
||||
|
||||
### 1.5 商店刷新
|
||||
|
||||
起点是换层触发点。公开玩法资料明确记录“商店每 3 层在起点出现”，与原作实机和既有 GDD 的第 3、6、9 层观察一致；原生 `BoardController` 同时存在 `shopPerLoop` 字段和换层状态机中的商店分支。
|
||||
|
||||
玩法验证实现应采用：
|
||||
|
||||
```text
|
||||
displayFloor % 3 == 0 → 起点显示商店
|
||||
```
|
||||
|
||||
商店不属于每层随机地块抽取；它依附起点，并由层间隔控制。商店内部商品刷新、费用和购买规则属于单独的商店逆向报告。
|
||||
|
||||
## 2. Boss 压力刷新
|
||||
|
||||
### 2.1 `Default` 关卡
|
||||
|
||||
`Default` 不使用实时压力 Gauge。以 `stageinfo.bossSpawnRuleValue` 作为总楼层数，读取 `board.csv` 的 `loop=0..N-1` 数值；最后一层完成后进入关卡 Boss。第 1 关为 10 层后 `boss_0`。
|
||||
|
||||
存在 `midBossSpawnValues` 时，`Default` 关卡用楼层进度注册中 Boss。配置值 7 与楼层中点一致，但原生比较中的零/一基显示转换没有恢复出托管变量名；因此只能把“7”作为原始门槛配置，验收时必须以原作录像校准 UI 层号和触发帧，不能直接断言是内部 `loop=7` 或用户可见“第 7 层”。
|
||||
|
||||
### 2.2 `DiceGauge` 关卡
|
||||
|
||||
每次合格的落地结算执行：
|
||||
|
||||
```ts
|
||||
runtimeBossGauge = clamp(
|
||||
runtimeBossGauge + stageInfo.bossSpawnRuleValue,
|
||||
0,
|
||||
100,
|
||||
);
|
||||
```
|
||||
|
||||
当前 19 个 `DiceGauge` 关卡的增量都为 50，所以正常路径两次完整掷骰/落地结算蓄满 100。`MoveTile` 随后依次检查 `TrySpawnBossTilesByGauge` 与 `TryRegisterMidBossByGaugeAsync`。
|
||||
|
||||
结合原生数据流和项目中已验证的原作实机观察，完整周期为：
|
||||
|
||||
```text
|
||||
Gauge 0
|
||||
→ 第 1 次完整落地：50
|
||||
→ 若配置 midBossSpawnValues=20，中 Boss Gauge 注册路径已具备数值条件（强推断）
|
||||
→ 第 2 次完整落地：100
|
||||
→ 进入 Boss 压力倒计时
|
||||
→ 后续 4 次玩家掷骰：4 → 3 → 2 → 1 → 0
|
||||
→ 随机转换 4 个互不重复、非祝福地块为 Boss 压力地块
|
||||
→ 实时 Gauge 清零，进入下一周期
|
||||
```
|
||||
|
||||
`BoardController.BossDiceCounter` 是倒计时显示字段，不是实时 Gauge。`AddBossDiceNumber(v)` 只做 `counter += v`，`HandleBossDiceRolled(v)` 只做 `counter -= v`；两者不得与 `runtimeBossGauge` 合并成同一个变量。`midBossSpawnValues=20` 被 `TryRegisterMidBossByGaugeAsync` 消费的总体语义可信，但被混淆的共享谓词没有恢复成可读比较式，所以精确的 `>=20` 运算符仍标为强推断。
|
||||
|
||||
原生证据能确认：Gauge 加 50、上下限 0/100、移动后进入 Boss 生成链、保存被替换前地块、生成后同一 Gauge 字段清零。4 次倒计时、4 个唯一非祝福地块来自原作运行时观察。以下边界仍未从静态代码恢复成可靠托管语义：
|
||||
|
||||
- 合格候选不足 4 个时的降级顺序；
|
||||
- 除祝福外是否还存在模式专属保护地块；
|
||||
- 被 Boss 压力覆盖的地块在攻击结束后是原样恢复还是按事件结果恢复。
|
||||
|
||||
玩法验证版应把这些边界做成可配置策略并记录 seed/候选列表；在获得对应录像前不得声称是原作精确规则。
|
||||
|
||||
## 3. 第 1 关开发用规则
|
||||
|
||||
| 项目 | 原作规则 | 来源/置信度 |
|
||||
|---|---|---|
|
||||
| Stage | `0`，Grass，Normal | 源码确认 / 高 |
|
||||
| 楼层 | 10 层，内部 `loop=0..9` | `stageinfo` 与 `board` 完全闭合 / 高 |
|
||||
| 最终 Boss | `boss_0`，`skill_0`，攻击冷却 7 | 源码确认 / 高 |
|
||||
| 敌人数值 | 严格逐行读取 `stage0-loop-enemy-stats.csv` | 源码确认 / 高 |
|
||||
| 初始角落 | `SpawnAllCornerTiles` | 原生调用确认 / 高 |
|
||||
| 初始有益地块 | `AddRandomGoodTiles(8)` | 原生常量确认 / 高 |
|
||||
| 默认有益牌组 | 8 个默认装备的 OutGameTile | 配置确认 / 高 |
|
||||
| 换层有益注入 | `AddRandomGoodTiles(loopIndex+2)` | 原生算术确认 / 高 |
|
||||
| 换层敌人注入 | `AddRandomEnemyTile(enemyTilesPerLoop,false)` | 原生调用确认；数量值未恢复 / 中高 |
|
||||
| 商店 | 起点每 3 个显示楼层出现 | 实机/社区交叉验证 + 原生字段 / 中高 |
|
||||
| Boss 压力 Gauge | 第 1 关不启用 | `Default` 配置 / 高 |
|
||||
| 通关 | 完成第 10 层后进入 `boss_0` | 配置与楼层表闭合 / 高 |
|
||||
|
||||
第 1 关 MVP 不应继续使用以下旧假设：
|
||||
|
||||
- 每层固定新增 2 个有益地块；
|
||||
- 六类事件每局强制各出现一次；
|
||||
- 全部 GoodEvent 从固定池等权抽取；
|
||||
- 第 1 关使用两掷蓄压、四掷 Boss 压力循环。
|
||||
|
||||
## 4. 实现伪代码
|
||||
|
||||
```ts
|
||||
function enterNewRun(stage: StageInfo, playerDeck: OutGameTileMeta[]) {
|
||||
loopIndex = 0;
|
||||
spawnInitialTiles(); // 内部常量 3 的参数语义仍需动态闭环
|
||||
spawnAllCornerTiles();
|
||||
addRandomGoodTiles(8, playerDeck);
|
||||
}
|
||||
|
||||
async function passStartTile() {
|
||||
loopIndex += 1;
|
||||
if (isDefaultStage && loopIndex >= stage.bossSpawnRuleValue) {
|
||||
enterFinalBoss(stage.bossID);
|
||||
return;
|
||||
}
|
||||
|
||||
await addRandomGoodTiles(loopIndex + 2, currentPlayerGoodTileDeck);
|
||||
await addRandomEnemyTiles(enemyTilesPerLoop, false);
|
||||
|
||||
const displayFloor = loopIndex + 1;
|
||||
if (displayFloor % shopPerLoop === 0) {
|
||||
showShopOnStartTile();
|
||||
}
|
||||
}
|
||||
|
||||
function drawGoodTileMeta(): OutGameTileMeta | null {
|
||||
if (eligiblePlayerDeck.length === 0) return null;
|
||||
if (!shuffledDeck || currentDeckIndex >= shuffledDeck.length) {
|
||||
shuffledDeck = shuffle(copy(eligiblePlayerDeck));
|
||||
currentDeckIndex = 0;
|
||||
}
|
||||
return shuffledDeck[currentDeckIndex++];
|
||||
}
|
||||
|
||||
function onQualifiedTileSettlement() {
|
||||
if (stage.bossSpawnRule !== 'DiceGauge') return;
|
||||
runtimeBossGauge = clamp(
|
||||
runtimeBossGauge + stage.bossSpawnRuleValue,
|
||||
0,
|
||||
100,
|
||||
);
|
||||
tryRegisterMidBossByGauge();
|
||||
trySpawnBossTilesByGauge();
|
||||
}
|
||||
```
|
||||
|
||||
## 5. 证据链
|
||||
|
||||
| Evidence | Finding | Design/Path |
|
||||
|---|---|---|
|
||||
| E-STAGE-CONFIG-001 | 两类 Boss 规则；Default 值与楼层行数完全一致；地块门槛和默认牌组 | F-STAGE-001, F-TILE-001 |
|
||||
| E-STAGE-NATIVE-001 | 初始化 8 次、换层 `loop+2`、敌人字段注入、洗牌无放回、Gauge 加法/清零 | F-REFRESH-001, F-GAUGE-001 |
|
||||
| E-STAGE-RUNTIME-001 | DiceGauge 的 2 次蓄压、4 次倒计时、4 个非祝福覆盖 | F-GAUGE-002 |
|
||||
| E-STAGE-WEB-001 | 经过起点换层、每 3 层商店、每圈新增敌人与事件 | F-REFRESH-002 |
|
||||
|
||||
本地证据为主，互联网资料仅用于交叉验证玩家可观察语义；其中 Steam 页面属于同系列后续公开描述，不能替代 2.0.1 本地证据。外部参考：[Heroll Wiki Tiles](https://heroll.fandom.com/wiki/Tiles)、[Steam《HEROLL: IF》页面](https://store.steampowered.com/app/4838670/)。
|
||||
|
||||
## 6. 配套表格
|
||||
|
||||
- `tables/stage-boss-rules.csv`：52 个普通主线关卡的 Boss / 中 Boss 配置。
|
||||
- `tables/stage0-loop-enemy-stats.csv`：第 1 关 10 层敌方数值。
|
||||
- `tables/enabled-tile-eligibility.csv`：启用地块的 Stage / Loop 门槛与角落上限。
|
||||
- `tables/default-good-tile-deck.csv`：新账号 8 个默认有益地块元数据。
|
||||
|
||||
## 7. 验收用例
|
||||
|
||||
1. 对全部 33 个 `Default` 关卡校验 `boardRows == bossSpawnRuleValue`。
|
||||
2. 第 1 关只读取 `loop=0..9`；第 10 层后进入 `boss_0`，不得启用 DiceGauge。
|
||||
3. 新局固定调用 8 次有益地块抽取；在默认 8 张牌组下，首轮抽取不重复。
|
||||
4. 换层调用次数必须是 `loopIndex+2`，并记录“请求数 / 成功安装数 / 失败原因”。
|
||||
5. 同一洗牌轮不重复；耗尽后重洗，固定 seed 下结果可复现。
|
||||
6. `minStage/minLoop/isEnabled/maxCornerPerGame` 的自然生成过滤逐项测试。
|
||||
7. DiceGauge 关卡两次合格落地达到 100，之后四次掷骰倒计时，生成 4 个唯一非祝福候选并清零。
|
||||
8. Gauge 与 BossDiceCounter 使用两个字段，存档恢复时不得相互覆盖。
|
||||
9. 商店仅依附起点，并按显示楼层 3 的倍数触发。
|
||||
10. `enemyTilesPerLoop` 在恢复原作序列化值前标为外部配置，不得硬编码猜测值并标注“源码确认”。
|
||||
Reference in New Issue
Block a user