伟大航路客户端硬规则补充 ¶

文档目的 ¶

本文件补充记录“已经能够直接从客户端和客户端文案中提取出的硬规则”。

与 gameplay-flow-evidence.md 的区别是：

• gameplay-flow-evidence.md 更偏整体流程和证据链。
• 本文件只强调“可以直接落到服务端实现的硬数值、硬阶段、硬时间窗”。

一、赛季切换硬规则 ¶

客户端明确使用 SecondSeasonStart 作为旧盐场和伟大航路的分界：

• funcs-legionWar.js
• config1.json

已确认：

• currentSeasonNum >= SecondSeasonStart 时，客户端按新赛制处理。
• SecondSeasonStart = 7。

结论：

• S7 是伟大航路赛制切换点，不是宣传文案口径，而是客户端真实判断条件。

二、五岛和黄金阶段的正式阶段枚举 ¶

客户端在阶段枚举中已经把伟大航路拆成正式赛制类型：

• Configs.js

已确认：

• GREY_WEEK = 15
• GREY_WEEK_HIGH = 16
• GREY_MONTH = 17
• GREEN_WEEK = 18
• GREEN_MONTH = 19
• BLUE_WEEK = 20
• BLUE_MONTH = 21
• PURPLE_WEEK = 22
• PURPLE_MONTH = 23
• GOLDEN_VICTOR = 24
• GOLDEN_LOOSER = 25
• GOLDEN_FINAL = 26

结论：

• 灰盐岛不只是“周赛 + 月赛”，中间确实单独有“进阶赛”。
• 黄金天宫不是单一月赛，而是明确拆成“胜者赛 / 败者赛 / 总决赛”三类正式阶段。

三、地图类型枚举 ¶

客户端地图类型也已经拆出阶段对应的地图枚举：

• Configs.js

已确认：

• GREY_WEEK_MAP = 13
• GREY_WEEK_HIGH_MAP = 14
• GREY_MONTH_MAP = 15
• GREEN_WEEK_MAP = 16
• GREEN_MONTH_MAP = 17
• BLUE_WEEK_MAP = 18
• BLUE_MONTH_MAP = 19
• PURPLE_WEEK_MAP = 20
• PURPLE_MONTH_MAP = 21
• GOLDEN_VICTOR_MAP = 22
• GOLDEN_LOOSER_MAP = 23
• GOLDEN_FINAL_MAP = 24

结论：

• 客户端不是只按“岛屿”切地图，而是按“阶段”切地图类型。
• 服务端若要完整实现，至少要能正确下发 legionWarType 和 legionWarMapType 的组合。

四、灰盐岛的硬规则 ¶

客户端规则图文中，灰盐岛是最完整的一段。

来源：

• language.json 中 XYC_IMG_RULE2
• language.json 中 XYC_IMG_RULE3
• language.json
• language.json

已确认：

• 报名俱乐部会按总红色淬炼数、总战力等数据计算候选排名。
• 前 2000 名俱乐部进入灰盐岛“首战场”。
• 首战场前 3 场周赛的晋级名额分别为：
  • 第 1 周前 8
  • 第 2 周前 4
  • 第 3 周前 4
• 第 4 周无新的进阶赛晋级名额。
• 进入进阶赛后，每场按小组排名获得岛屿积分。
• 第 4 周进阶赛结束后，小组累计积分前 15 晋级月赛。
• 月赛后，所有参与月赛的俱乐部按总积分排行，前 960 晋级青铜岛。

从客户端提示文案还能确认：

• 第 1 周提示：首战场前8名将晋级进阶赛
• 第 2 周提示：首战场前4名将晋级进阶赛
• 第 3 周提示：首战场前4名将晋级进阶赛
• 进阶赛提示：第4周赛后各小组积分排行前15可晋级月赛
• 月赛提示：月赛后总积分排行前960可晋级青铜岛

结论：

• 灰盐岛不是简单“打一场升岛”，而是月内四周拆段推进。
• 服务端必须能区分“灰盐岛周赛”和“灰盐岛进阶赛”，否则无法对齐客户端规则。

五、青铜岛的硬规则 ¶

来源：

• language.json 中 XYC_IMG_RULE4
• language.json
• language.json
• config1.json
• config1.json
• config1.json
• config1.json

已确认：

• 青铜岛参赛来源包括：
  • 灰盐岛晋升俱乐部
  • 秘蓝岛淘汰俱乐部
• 周赛后按小组排名获得岛屿积分。
• 第 4 周周赛结束后，小组累计积分前 16 晋级月赛。
• 其余俱乐部淘汰回灰盐岛。
• 月赛后，总积分排名前若干名晋级秘蓝岛。

其中“前若干名”的具体数字，客户端常量已经给出三个档位：

• 500
• 380
• 300

对应配置：

• legionWarThirdGreenMonthUp = 500
• legionWarThirdGreenMonthUp3 = 380
• legionWarThirdGreenMonthUp4 = 300

并且客户端会根据 blueRiseCount 动态切换：

• LegionWarExLeagueRankScoreDialog.js
• funcs-legionWar.js

getBlueRiseCount() 的来源不是 UI 本地推导，而是赛程表字段：

• funcs-legionWar.js

其逻辑是：

• 读取当前赛程项的 thirdLegionWarType_2_count
• 作为 blueRiseCount
• 再决定青铜岛月赛升秘蓝岛的名额使用 500 / 380 / 300 中哪一档

结论：

• 青铜岛升秘蓝岛人数不是完全写死，至少客户端已经支持动态档位。
• 服务端必须补充这一动态来源，否则客户端“前500/380/300”的显示会与服务端结果不一致。

六、秘蓝岛的硬规则 ¶

来源：

• language.json 中 XYC_IMG_RULE5
• language.json
• language.json
• config1.json
• config1.json

已确认：

• 秘蓝岛分组池总量为 500 俱乐部。
• 分组来源包括：
  • 青铜岛晋升俱乐部
  • 月宫淘汰俱乐部
  • 天宫归来俱乐部
• 周赛后按小组排名获得岛屿积分。
• 第 4 周周赛结束后，小组累计积分前 16 晋级月赛。
• 其余俱乐部淘汰回青铜岛。
• 月赛后，小组积分前 10 晋级月宫。

配置也支撑该结论：

• legionWarThirdBlueWeekDown = 4，所以每组保留 20 - 4 = 16 个晋级月赛名额。
• legionWarThirdBlueMonthUp = 10，月赛每组前 10 升岛。

结论：

• 秘蓝岛的关键口径已经相当完整，基本可以直接映射为服务端规则。

七、紫青月宫的硬规则 ¶

来源：

• language.json 中 XYC_IMG_RULE6
• language.json
• language.json
• config1.json
• config1.json

已确认：

• 月宫仅由秘蓝岛晋升俱乐部构成。
• 月宫分组规模为 200 俱乐部。
• 周赛后按小组排名获得岛屿积分。
• 第 4 周周赛结束后，小组累计积分前 16 晋级月赛。
• 其余俱乐部淘汰回秘蓝岛。
• 月赛后，小组积分前 10 晋级黄金天宫。

配置支撑：

• legionWarThirdPurpleWeekDown = 4
• legionWarThirdPurpleMonthUp = 10

结论：

• 月宫的晋级/淘汰规则与秘蓝岛结构一致，只是总量更小、终点是黄金天宫。

八、黄金天宫的硬规则 ¶

来源：

• language.json 中 XYC_IMG_RULE7
• language.json
• Configs.js

已确认：

• 黄金天宫只由紫青月宫晋升俱乐部组成。
• 总量为 80 俱乐部。
• 黄金天宫采用双败赛制。
• 失败 2 场的俱乐部结束天宫赛程并淘汰至秘蓝岛。
• 阶段枚举明确有：
  • GOLDEN_VICTOR
  • GOLDEN_LOOSER
  • GOLDEN_FINAL

客户端文案中还能确认每周流转口径：

• 第1周比赛各组前10可保级胜者赛
• 第1周比赛各组后10将参与败者赛
• 第2周胜者赛各组前10可保级该周胜者赛
• 第2周胜者赛各组后10、第2周败者赛各组前10，将参与该周败者赛
• 第3周胜者赛后10、第3周败者赛各组前5，将参与该周败者赛
• 第3周胜者赛前10、第4周败者赛前10，荣获总决赛参赛资格

结论：

• 黄金天宫不是“抽象双败”，客户端已经给出周级别流转提示。
• 服务端后续要实现双败 bracket 时，应优先按照这套客户端提示设计状态机。

九、周赛通用时间窗 ¶

客户端在战场时间计算中仍保留统一的周赛模板：

• funcs-legionWar.js

已确认：

• 报名结束：当日 18:00
• 开战时间：当日 20:00
• 提前进场：开战前 5 分钟
• 周赛结束：openTime + warConst.time

结合旧盐场规则文案可知：

• 周赛报名一般从 8:00 开始
• 公示阶段一般是 18:00 ~ 20:00
• 开战一般是 20:00

结论：

• 即使新赛制改变了阶段和升降规则，客户端仍沿用旧周赛的时间模板。
• 服务端若要切到伟大航路，时间窗大概率也应复用这一模板，除非黄金阶段另有独立赛历。

十、当前仍然没有被客户端完全补齐的点 ¶

即便拿到这些硬规则，仍有几块不能只靠客户端完全确认：

• 青铜岛升秘蓝岛的 500 / 380 / 300 何时切换。
• 青铜岛“前若干名晋级下个岛屿”具体如何和 blueRiseCount 绑定。
• 黄金天宫每周失败判定的精确状态转移表。
• 总决赛后的最终奖励、回流和重置时点。
• 各阶段成员资格锁定时间点。
• 岛屿积分的具体分值表与同分裁定优先级。

十一、对服务端实现最有价值的结论 ¶

本轮客户端深挖后，至少可以直接确定以下实现要求：

1. 服务端必须支持灰盐岛“周赛 / 进阶赛 / 月赛”三个独立阶段。
2. 服务端必须支持岛屿级人数池：
   • 青铜岛 500
   • 月宫 200
   • 天宫 80
3. 服务端必须支持每组晋级口径：
   • 灰进阶到月赛：前 15
   • 青/蓝/紫周赛到月赛：前 16
   • 蓝/月宫月赛升岛：前 10
4. 服务端必须支持黄金天宫双败流转，而不是单次淘汰。
5. 服务端必须考虑青铜岛月赛升秘蓝岛的动态档位 500 / 380 / 300。

十二、主要证据索引 ¶

• language.json
• language.json
• Configs.js
• funcs-legionWar.js
• funcs-legionWar.js
• funcs-legionWar.js
• LegionWarExLeagueRankScoreDialog.js
• LegionModule.js
• config1.json