JWeBot/docs/cs-major-autochess-design.md

CS Major 自走棋设计稿

本文档定义一个完全本地、确定性结算、以 CS 职业选手为棋子的群聊 小游戏方案。赛事包装统一为“第 n 届 IEM 盐田 Major”。AI 默认负责主持、 裁判、播报和剧情生成；主持人也可显式加入一支本地确定性 AI 战队。

1. 设计目标

1. 做成一个多人报名、多人运营、多人对战的群聊自走棋。
2. 玩法重心放在每轮选秀和阵容运营，而不是复杂微操。
3. 用 Major 赛事包装 PvE、小组单循环、淘汰赛和终局剧情。
4. 结算逻辑必须完全本地、可重放、可持久化、可回档验证。
5. 每一段剧情都要落档，且剧情只能在数值结算之后生成。

2. 核心体验

一句话定义：

公开 6 人选秀 -> 凑羁绊与升星 -> 打 PvE 拿资源 -> 打 PvP 跑 Major 赛程 -> 保存每轮赛报与剧情

玩家感受到的乐趣应当主要来自：

• 抢 6 人选秀里的关键卡；
• 决定要不要升教练等级、保经济还是强行 D 牌；
• 赌阵容成型时点；
• 看小组单循环和淘汰赛赛报；
• 看最终冠军剧情与本届 Major 档案。

3. 对局对象与规模

3.1 报名

• 开局命令由任意玩家发起。
• 其他玩家在报名窗口内加入。
• 建议一局支持 2~8 名真人玩家。
• 主持人可在报名阶段发送 /自走棋加AI战队：
  • 两名真人时加入 AI 战队 A、B；
  • 三名真人时加入一支 AI 战队。
• 两种测试模式都补满四队，直接生成 1v4、2v3 半决赛。
• AI 占一个参赛席位，但不对应群成员，也不调用在线模型。
• AI 每回合以确定性规则买牌、升级教练、调整首发和选择克制战术。

3.2 玩家初始状态

每位玩家开局拥有：

• 生命值：100
• 金币：10
• 教练等级：1
• 完整首发：5 名一星选手 + 1 名教练
• 阵容位：固定 5 个选手位 + 1 个教练位，比赛时必须全部上场
• 备战席：8 格
• 连胜/连败计数：0
• 本局独立事件档案编号

开赛时系统从低费池为每位玩家确定性分配 5 名首发选手，保证第一场 比赛就是完整的五人阵容。后续选秀用于替换、强化和升星，而不是解锁 上场人口。

4. 选手池设计

4.1 选手来源

只使用“近期非常出名”的职业选手。第一期池子优先覆盖以下俱乐部与明星：

• Spirit
• Vitality
• Falcons
• G2
• FaZe
• NAVI
• MOUZ
• The MongolZ
• Astralis
• Liquid
• FURIA
• Eternal Fire

选手数据不是对真实比赛数据的一比一复刻，而是基于公众认知做游戏化映射。 首发版本固定维护 60 名棋子，运行期不在线抓取或改写数值。

4.2 费用层级

选手分为 1~5 费，越高费越稀有，基础数值和成长更强。

示例分层：

• 5 费：donk、ZywOo
• 4 费：m0NESY、NiKo、ropz、frozen
• 3 费：apEX、b1t、xertioN、w0nderful、malbsMd
• 2 费：辅助型或中坚选手
• 1 费：前期过渡与羁绊补齐牌

正式实现时应维护一份固定的选手静态表，不允许运行期随意漂移。

4.3 定位

只保留三个核心定位：

• 步枪手
• 狙击手
• 指挥

定位不是羁绊，而是战斗中的属性倾向与技能触发来源。

4.4 羁绊

只保留两类羁绊：

1. 战队羁绊
2. 国家羁绊

战队羁绊可来自：

• 当前主战队；
• 历史待过的关键战队；
• 每名选手最多挂 3 条战队标签，避免过度泛化。

国家羁绊只有 1 条。

5. 选手数值

5.1 基础数值轴

为避免面板过宽，第一期只展示三个主数值：

• 火力
• 稳定
• 残局

其中指挥位额外拥有隐藏或显式的 指挥 修正值，用于影响全队。

5.2 数值范围

• 1 费：52~68
• 2 费：60~76
• 3 费：68~84
• 4 费：78~92
• 5 费：88~98

要求同费位内部也要有明显差异，不能所有 4 费都只有一两点波动。

5.3 派生战斗权重

可先采用以下简单模型：

单卡战力 = 火力 * 0.45 + 稳定 * 0.30 + 残局 * 0.25 + 星级修正 + 羁绊修正 + 教练修正

若定位是狙击手，可给火力更高上限； 若定位是指挥，可给团队修正更高权重。

5.4 属性与定位克制

战斗不能只比较总战力后掷骰子。三项主属性形成闭环：

• 稳定克火力：稳定阵容能吸收强攻的第一波冲击；
• 火力克残局：前期人数优势会压缩残局发挥空间；
• 残局克稳定：高残局能力能打破按部就班的默认局面。

三个定位也形成轻量闭环：

• 狙击手克步枪手
• 步枪手克指挥
• 指挥克狙击手

玩家每回合可选择 /战术 火力|稳定|残局。战术选择会强化对应属性， 并在克制对方战术时获得额外修正。属性、定位和战术的总克制修正上限 应明显高于随机波动，让调阵和判断对手比运气更重要。

6. 升星规则

• 3 张同名 = 2 星
• 9 张同名 = 3 星

升星收益建议：

• 2 星：基础战力乘 1.35
• 3 星：基础战力乘 1.80

升星后保留原有羁绊与定位，不改变标签。

7. 教练系统

教练位不是普通战斗单位，但始终与 5 名选手一起上场。

7.1 教练等级作用

教练只提供额外的全队战术加成，不控制上场人数，也不占用选手位。

建议加成：

• 1 级：全队战力 +2%
• 2 级：全队战力 +4%
• 3 级：全队战力 +6%
• 4 级：全队战力 +8%
• 5 级：全队战力 +10%

7.2 教练升级

玩家可花金币升级教练经验。

建议升级费用为 6 / 10 / 16 / 24 金币。升级只提高上述战术加成。 高费选手的商店概率改为随赛事回合推进，不再绑定教练等级。

8. 每轮 6 人选秀

这是本模式的核心。

8.1 固定规则

• 每轮只展示 6 名候选选手。
• 这 6 人对所有玩家公开可见。
• 每位玩家始终保有 5 名首发；购买的新选手进入备战席或与同名选手合成。
• 调整阵容时必须用备战席选手替换首发，不能让首发少于 5 人。
• 第一版采用“公开同池、各自购买”的简化方案：
  • 所有人看到同一组 6 人；
  • 某个玩家选择后，不会把该候选从其他玩家界面里抢空；
  • 但底层共享总卡池仍然会影响后续刷新概率。
• 每名候选都必须展示完整数据：
  • 编号 1~6
  • 选手名
  • 费用
  • 定位
  • 国家
  • 主战队
  • 历史战队
  • 主数值
• 玩家通过编号选择，不输入复杂自然语言。

8.2 选秀指令

建议指令面如下：

/自走棋开始
/自走棋报名
/自走棋加AI战队
/自走棋状态
/选1
/选2
/选3
/选4
/选5
/选6
/刷新
/锁定
/升级教练
/战术 火力|稳定|残局
/上阵 备战编号 [首发位]
/下阵 首发位 备战编号
/出售 备战编号
/阵容
/赛程
/结束回合

中文是主命令，英文别名可以后补。

8.3 刷新与锁定

• 每轮默认展示一组 6 人。
• 玩家可支付金币执行刷新。
• 玩家可锁定本轮 6 人，使下一轮仍保留同一组候选。

8.4 顺位

• 开局首轮选秀顺位随机。
• 后续普通回合不再做蛇形公共抢位，而是每位玩家各自面对同一组 6 人池。
• 如果后续想加竞技性，可在第二阶段引入“共享卡池抢空”机制。

第一期建议先做“公开同池、各自结算”，避免群聊交互过重。

9. 回合流程

建议一整回合拆成五段：

1. 回合开始播报
2. 6 人选秀 / 刷新 / 升级 / 调阵
3. PvE 或 PvP 结算
4. 回合结算与经济发放
5. 剧情归档

10. PvE 设计

PvE 不叫“打野怪”，统一包装成赛事内活动。

10.1 PvE 类型

• 训练赛
• 媒体日
• 热身赛
• 赞助挑战
• 地图专项训练

10.2 PvE 作用

PvE 的目标不是淘汰人，而是给资源：

• 金币
• 装备
• 战术卡
• 教练经验
• 临时 buff

10.3 PvE 结算逻辑

PvE 对手是模板化敌方阵容或阈值型事件，不需要复杂 AI。

示例：

玩家总战力 >= 目标战力 则获胜，否则失败。

这样实现简单，也利于稳定复盘。

11. PvP 赛制

11.1 赛事包装

整局赛事名称固定为：

第 n 届 IEM 盐田 Major

11.2 按参赛人数生成赛制

• 2 人：直接进入决赛。
• 3 支队伍：进行完整单循环，前 2 名进入决赛。
• 4 人：不打小组赛，按报名种子直接进行 1v4、2v3 半决赛。
• 5~8 人：进行完整小组单循环，每两支队伍只交手一次，前 4 名晋级。

奇数队伍的小组比赛日会有一队轮空，但不会获得胜场。 小组赛每场采用 BO3。

11.3 小组排名

小组赛首先按胜场排序；同胜场依次比较：

1. 相互交手结果；
2. 当前完整五人阵容战力；
3. 剩余生命值；
4. 固定种子编号。

所有配对在开赛时一次性生成并落档，不允许运行中根据结果重排赛程。

11.4 淘汰赛

• 四强固定为 小组第 1 vs 第 4、第 2 vs 第 3。
• 3 人赛制由小组第 1、2 名直接进入决赛。
• 4 人赛制使用报名种子 1v4、2v3。
• 2 人赛制直接进入决赛。
• 半决赛胜者进入总决赛，决出本届冠军。
• 半决赛和总决赛均采用 BO5。

12. 战斗结算

12.1 目标

战斗要做到：

• 本地确定性；
• 单轮可解释；
• 支持战报；
• 不依赖在线模型。

12.2 简化模型

建议第一期采用“阵容总分 + 对位修正”的轻量模型。

步骤 1：计算阵容基础战力

阵容基础战力 = 5 名首发选手战力总和

步骤 2：加上团队修正

团队修正来源：

• 战队羁绊
• 国家羁绊
• 教练等级提供的全队百分比加成
• 装备/战术卡
• 连胜或特殊事件 buff

步骤 3：计算克制修正

依次计算：

1. 稳定 > 火力 > 残局 > 稳定 的属性对位；
2. 狙击手 > 步枪手 > 指挥 > 狙击手 的定位对位；
3. 双方本回合主动选择的战术对位。

克制结果必须进入结构化战报，明确展示双方修正值。

步骤 4：加入小幅波动

只允许 -2% ~ +2% 的确定性哈希波动。单次运气不能覆盖成型阵容的 属性、定位和战术克制优势。

步骤 5：计算比分

单图采用 MR15：

• 常规时间先到 16 分获胜；
• 常规时间 15-15 进入加时；
• 加时可产生 19-17，多轮加时可产生 22-20 等比分；
• 每次加时除结构化单图结果外，必须额外生成一段加时剧情并落档。

小组赛按 BO3 先赢 2 图，淘汰赛按 BO5 先赢 3 图。系列赛战报必须展示 大比分、每张图比分、加时次数和克制修正。

13. 剧情系统与落档

这是本模式的强制要求。

13.1 归档原则

必须先结算，后写剧情。

即：

1. 固化数值结果；
2. 存档回合事实；
3. 基于事实生成文字赛报；
4. 再把文字赛报作为附加档案保存。

13.2 必须落档的节点

• 开局报名完成
• 每轮 6 人选秀结果
• 每次刷新和关键升星
• 每次 PvE 事件结果
• 每场 PvP 结果
• 小组赛排名、晋级和淘汰节点
• 淘汰赛对阵与结果
• 冠军总结

13.3 档案结构

建议至少保存两类记录：

1. 结构化事件档
2. 文本剧情档

结构化事件档用于回放和调试； 文本剧情档用于玩家阅读。

示例：

{
  "run_id": "major_0001",
  "round": 4,
  "phase": "group_2",
  "event_type": "pvp_result",
  "player_a": "Jacky",
  "player_b": "Alice",
  "winner": "Jacky",
  "score_band": "close_win",
  "roster_a_power": 418,
  "roster_b_power": 403
}

14. 数据持久化设计

建议新增以下 SQLite 表。

14.1 对局主表

autochess_runs

• run_id
• group_fingerprint
• season_number
• state
• created_at
• updated_at

14.2 玩家状态表

autochess_players

• run_id
• person_key
• display_name
• hp
• gold
• coach_level
• coach_xp
• wins
• losses
• streak
• board_json
• bench_json
• shop_json
• locked_shop

14.3 选秀记录表

autochess_shop_events

• run_id
• round_number
• person_key
• visible_pool_json
• action_type
• action_payload_json
• created_at

14.4 战斗结果表

autochess_battles

• run_id
• round_number
• phase
• battle_type
• player_a
• player_b
• result_json
• created_at

14.5 剧情归档表

autochess_story_logs

• run_id
• round_number
• phase
• story_type
• story_text
• facts_json
• source_event_id
• created_at

14.6 幂等与重放表

autochess_action_replay

• run_id
• person_key
• round_number
• event_id
• action_kind
• response_text
• created_at

15. 回放与幂等

因为群聊环境会出现重复事件、OCR 重读和命令重放，必须保证：

• 同一事件只执行一次；
• 同一回合不能重复发奖或重复扣款；
• 同一段剧情不能重复写多份版本；
• 回合失败时整段事务回滚。

建议沿用现有本地游戏的幂等思路，为自走棋单独增加 action replay 表。

16. 指令交互风格

建议所有回复都遵循现有小游戏风格：

用户名 #局号：内容

例如：

Jacky #3：第 4 回合开始，你当前 32 金币，教练 3 级。
本轮选秀如下：
1. donk 5费 步枪手 Spirit 俄罗斯 火力96 稳定88 残局86
2. apEX 3费 指挥 Vitality 法国 火力68 稳定81 指挥95
...
发送“选1”到“选6”，或发送“刷新”“锁定”“升级教练”。

16.1 Taffy 主持状态机

Taffy 必须承担完整赛事主持，而不是只在结算时出现。

开赛时必须包含：

• 欢迎大家来到第 n 届 IEM 盐田 Major
• 本届参赛者和种子
• 当前人数对应的完整赛制
• 小组赛 BO3、淘汰赛 BO5、单图 MR15 和加时规则
• 当前回合内容
• 第一位需要准备的玩家

每回合按真人玩家生成确定性的准备顺序。AI 自动准备，不占真人操作轮次。 只有当前玩家可以购买、刷新、选择战术和调整阵容。提交后必须明确交棒：

Taffy：Jacky，请做好赛前准备；完成后发送 /结束回合。
Taffy：Jacky 准备完成！到 Alice 做准备了。
Taffy：Alice 准备完成！全员准备完毕，主持人可以结算。

下一回合轮换首位准备者，避免固定由同一个人总是先操作。

以下节点都必须由 Taffy 主持并落档：

• 报名开启和新选手加入
• AI 测试战队加入
• 赛制与种子公布
• 每位玩家开始/完成准备
• 每轮开始和结算
• 每场 BO3/BO5 对阵与结果
• 每张加时地图
• 小组排名和前四晋级
• 1v4、2v3 半决赛
• 总决赛和冠军颁奖

17. 实现顺序建议

建议按三个阶段落地。

第一阶段：最小可玩版

• 建局 / 报名 / 状态
• 每轮 6 人选秀
• 买卡、卖卡、升星
• 教练等级
• 简化 PvE
• 简化 PvP
• 基础剧情归档

第二阶段：赛事化增强

• 小组单循环完整配对
• 1v4、2v3 淘汰赛树
• 羁绊与装备系统细化
• 战报模板优化

第三阶段：内容扩展

• 在固定 60 人首发池基础上增加新赛季棋子
• 更多俱乐部和国家
• 特殊赛事事件
• 更细的剧情风格与本届 Major 年鉴

18. 第一版明确不做的内容

为保证能上线，第一版先不做：

• 实时地图微操
• 复杂技能动画
• 过多职业分类
• 在线爬取实时战队数据
• 大量开放文本输入解析

19. 最终结论

这套模式最适合按“强运营、轻操作、重赛报”路线实现。

最重要的三个锚点已经确定：

1. 每轮固定 6 人公开选秀
2. PvE 负责资源，PvP 负责小组单循环与淘汰赛
3. 每一段剧情都必须落档

如果按这个设计推进，实现出来的成品会更像一场可回放、可复盘、 可连载的本地 Major 模拟器，而不是一个只有数值结算的普通抽卡游戏。